題幹與適用情境
HTTP 511 表示客戶端必須先完成網路存取認證。它通常由攔截代理或 captive portal 回傳，而不是目標來源站。後端工程師要判斷請求是否真的到達來源站，避免把網路入口問題誤判成業務認證失敗。
面試官考察點
- 能否說清楚 511 的產生者是網路中的攔截代理。
- 能否區分網路認證、來源站認證與代理認證。
- 是否知道 511 回應不得快取，且不應把登入介面偽裝成來源站頁面。
- 是否能設計非瀏覽器客戶端的安全處理，而非盲目追蹤重新導向。
- 是否能用代理、DNS、TLS、鏈路日誌證明故障位置。
回答前需要釐清的問題
- 請求來自瀏覽器、行動 App，還是無頭服務端客戶端？不同客戶端處理入口頁面的能力不同。
- 511 直接來自企業代理、公共 Wi-Fi portal，還是應用閘道？產生者決定排查邊界。
- 請求使用 HTTP 還是 HTTPS？TLS 流量被攔截時可能先出現憑證錯誤。
- 客戶端能否存取登入資源並保存網路會話？不能時只能提示使用者換網路。
- 目標是診斷偶發代理錯誤，還是整合 captive portal？後者還需要會話協定。
30 秒回答框架
“511 是網路入口認證，不是來源站使用者登入。RFC 6585 建議由攔截代理產生，回應提供登入資源連結且不得快取。遇到它，我先記錄最終回應的 IP、代理標記與 TLS 狀態，確認請求是否到達來源站；瀏覽器可引導使用者開啟 portal，服務端客戶端不能把 511 當 401 重試。對比 401 的來源站認證與 407 的代理認證後，再決定修復網路、代理設定或客戶端提示。”
分步驟深入解答
步驟 1：定位回應產生方。 對比目標網域解析位址、TCP 對端、Via 或代理標頭、來源站存取日誌和閘道 trace。來源站沒有對應請求時，511 很可能來自中間網路。
步驟 2：理解協定語意。 511 的目的在告知客戶端網路尚未放行；回應可連結到提交憑據或接受條款的資源，但不應把 portal 登入表單當成原始 URL 的來源站內容。
步驟 3：區分相鄰狀態碼。 401 由來源站要求資源認證，通常配合 WWW-Authenticate；407 由正向代理要求代理憑據，配合 Proxy-Authenticate；511 解決的是網路本身的存取門檻。
步驟 4：定義客戶端動作。 瀏覽器可展示網路登入提示；API 客戶端應回報明確的網路不可用狀態、記錄 portal URL，等待使用者或網路管理員完成認證。不要自動把業務憑據提交給未知中間人。
步驟 5：處理 HTTPS 與快取。 認證前攔截 HTTPS 可能造成憑證不符，不能用關閉憑證驗證來解決。511 回應不得被快取，否則臨時網路門檻會傳給已認證使用者。
步驟 6：建立排查證據。 在同一網路用 HTTP 探針和目標業務請求比較；記錄時間、代理、DNS、憑證鏈、狀態碼和來源站日誌。Microsoft Learn 也把 511 列為代理連線檢查的可能結果。
步驟 7：說明替代方案和邊界。 企業 API 通常應修復代理白名單、服務帳號出口或網路認證，而不是在業務 API 中支援 511 登入。公共網路則應提供使用者可完成的 portal 流程和逾時提示。
高品質示範回答
“我會先把 511 定義為網路入口狀態：攔截代理告訴客戶端必須先認證網路，來源站通常沒有看到請求。它和 401、407 的差別分別是來源站資源認證、代理憑據認證與網路存取認證。排查時我比較 DNS、TCP 對端、代理標頭、TLS 憑證、來源站存取日誌和 trace，確認 511 的產生方。瀏覽器可以開啟 portal 連結；無頭 API 客戶端不能當成 401 自動重試，也不能把業務憑據交給未知代理。511 回應不應快取，HTTPS 被攔截時的憑證錯誤也不能靠跳過驗證解決。”
常見錯誤
- 把 511 當 401 → 向來源站刷新業務權杖但請求仍未出網 → 先確認回應產生方。
- 把 511 當 407 → 設定代理憑據卻忽略 portal 會話 → 區分網路入口與正向代理認證。
- 自動追蹤未知登入連結 → 可能洩露憑據或接受釣魚 portal → 展示來源與安全提示，交由使用者確認。
- 快取 511 → 已完成認證的請求仍收到舊門檻 → 依規範禁止快取並檢查中間快取。
- 關閉 TLS 驗證 → 中間人風險擴大 → 修復網路認證或憑證鏈，不降低驗證強度。
追問及應對
追問 1：來源站沒有請求，但客戶端收到 511，下一步查什麼？
抓取連線對端、代理鏈與回應標頭，再在同一網路存取已知 HTTP 探針；若多個目標都回傳同類回應，先檢查出口代理或 captive portal。
追問 2：為什麼不能把 portal HTML 直接當 API JSON 回傳？
非瀏覽器客戶端可能把 HTML 當業務回應而解析失敗；更嚴重的是可能誤認為來源站內容。應使用明確錯誤分類和可驗證的登入入口。
追問 3：HTTPS 請求為什麼常見憑證錯誤而不是 511？
攔截代理無法安全替換原站 TLS 憑證時，握手會在 HTTP 狀態碼之前失敗；客戶端不能假設所有網路認證都能用 511 表達。
追問 4：收到 511 可以重試嗎？
完成網路認證並確認會話建立後可以重新發起原請求；認證前盲目重試只會放大流量，也不應自動重放業務寫入。
追問 5：如何區分代理誤報和真實 portal？
比較不同網路、不同網域、代理設定、來源站日誌和 portal 會話；若只有一條企業出口出現 511，優先核查代理策略與白名單。
追問 6：行動 App 沒有瀏覽器登入介面怎麼辦？
回傳可讀的網路不可用狀態，引導使用者開啟系統網路登入頁或切換網路；認證完成後重新建立連線，不能在 App 內嵌頁面靜默提交未知網路憑據。
追問 7：為什麼 511 回應不得快取？
網路認證是會話和客戶端相關的暫時狀態，快取會讓其他客戶端錯誤看到同一門檻，使已放行使用者仍然失敗。