題幹與適用場景
客戶端請求啟用透明內容協商的資源，伺服器返回 HTTP 506 Variant Also Negotiates。系統含 Apache 風格協商、反向代理和快取。請說明 506 語義、觸發循環、診斷路徑、快取和回退。
面試官考察點
- 是否知道 506 源自 RFC 2295 透明內容協商。
- 能否區分協商循環、406 Not Acceptable 與代理 502。
- 是否會檢查 Alternates、Variant-Vary、TCN 等元資料。
- 是否能定義客戶端重試、快取與降級邊界。
- 是否考慮循環檢測、觀測和設定發布門禁。
回答前需要釐清的問題
確認 Accept/Accept-Language、資源是否為 variant list、哪一層產生 506、是否經過代理快取，以及客戶端能否接受固定 representation。假設代理把 variant 選擇再次指向同一協商資源。
30 秒回答框架
506 表示透明內容協商在選擇 variant 時形成循環，伺服器無法得到最終 representation。先從回應鏈和協商元資料確認循環，不把它當作普通上游錯誤。客戶端可請求固定資源或不帶協商的表示；相同設定不應盲目重試。伺服器限制深度、修正 variant，並監控 506 與 406。
分步驟深入解答
1. 解釋透明協商
RFC 2295 允許 origin server 發布可選 variant，客戶端和中間節點依請求標頭選擇 representation。最終請求必須收斂到具體資源。
2. 識別 506 循環
若 variant 又指向需要透明協商的資源，選擇會回到原始物件。記錄 resource URI、variant URI、協商代理、請求 id 和 visited 集合；再次訪問同一節點即可證明循環。
3. 區分相鄰狀態碼
406 表示沒有表示符合客戶端條件；502 表示閘道從上游得到無效回應。506 應追查協商層閉環，不能只依邊緣狀態碼判斷。
4. 設計客戶端回退
相同條件重試不會消除循環。客戶端可請求固定 variant、移除透明協商，或提示伺服器修復；只有設定變更或明確暫時訊號時才在預算內重試。
5. 處理快取與 Vary
快取鍵要包含實際協商的 Vary 維度，不能把 506 當成任意 representation 的長期結果。錯誤回應依 Cache-Control 決定；修復後要考慮舊快取和代理刷新。
6. 伺服器修復與安全
發布器上線前建 variant 圖並做環檢測，限制深度與時間。回應只給關聯 id，不暴露內部 URI 圖。代理保留原始狀態、Via 和 trace id。
7. 驗證與觀測
測試自循環、雙節點循環、深但無環列表、不同 Accept、語言、代理快取、灰度和回滾。監控 506/406、協商耗時、fallback、快取命中和修復時長。
高品質示範回答
506 是 RFC 2295 透明內容協商的循環錯誤。variant 再次指向協商資源時，伺服器無法得到最終表示。我會記錄 URI、variant、代理和 request id，用 visited 集合證明循環，並保存每跳原始狀態和 trace。
相同條件下客戶端快速失敗，不盲目重試；可請求固定 variant。伺服器發布前建 variant 圖做環檢測，限制深度和時間，校驗 Vary 與快取鍵。驗收覆蓋 Accept/語言、代理快取、灰度、回滾，以及 506 與 406 的區分。
常見錯誤
- 把 506 當成 406 或 502。
- 只看代理最終狀態，不追蹤 variant 圖。
- 對同一協商設定無限重試。
- 快取鍵缺少 Vary 維度。
- 上線前沒有環檢測和深度限制。
- 錯誤回應暴露內部 variant URI。
追問及應對
追問一：506 與 406 的差別？
406 是沒有可接受表示；506 是協商過程形成循環，選擇無法收斂。
追問二：客戶端能重試 506 嗎？
相同設定不應重試；只有修復設定或收到暫時訊號才在預算內重試。
追問三：如何證明是代理改碼？
比較每跳 trace、Via、原始狀態和協商標頭，必要時直連 origin 對照。
追問四：錯誤回應要不要快取？
遵循 Cache-Control，避免擴大循環；修復後清理受影響舊快取。