題幹與適用場景
一批使用者在飯店或機場網路中存取 API，代理返回 511 Network Authentication Required，有人卻把它改成 401 或 302，導致 SDK 重試、快取和登入流程混亂。請說明 511 的責任邊界、與 401/407 的區別，以及如何讓瀏覽器、行動端和非瀏覽器客戶端安全恢復。
這道題適合通用後端、網路和平台職位。重點是識別攔截代理與源站的邊界，不把網路准入驗證誤當成應用帳號驗證。
面試官考察點
強回答會指出 511 通常由控制網路存取的攔截代理生成，表示客戶端需要先完成網路准入；401 是源站或受保護資源要求驗證，407 則是代理要求客戶端提供代理憑據。還應說明 511 不是應用登入成功、不能由源站隨意偽造，也不能讓 API 客戶端盲目跟隨 HTML 跳轉。
回答前需要釐清的問題
- 511 是哪一跳生成的，客戶端是否能區分本地代理和源站回應？
- 這是瀏覽器頁面、原生行動端、命令列還是後台服務？
- 網路登入頁是否有穩定的檢測位址和返回協定？
- API 請求是否可重試，重試前如何確認網路已經放行？
- 是否涉及 TLS、憑證固定、代理驗證或敏感憑據傳輸？
30 秒回答框架
「511 表示網路准入層要求驗證，通常由攔截代理生成；401 是資源本身要求應用驗證，407 是代理要求代理憑據。不能把 511 改成 302，也不能讓 SDK 直接把 HTML 當 JSON。瀏覽器可以展示受控的網路登入提示，非瀏覽器客戶端應返回結構化網路狀態、停止盲目重試，並在網路確認放行後重新發起原請求。全程不向未知登入頁傳送應用憑據。」
分步驟深入解答
第一步：定位 511 的生成者
RFC 6585 定義 511 用於表示客戶端需要驗證才能取得網路存取，MDN 明確它不是由源站生成，而是由控制網路的攔截代理生成。常見場景包括公共 Wi-Fi 接受條款、入口網站登入或裝置登記。回應鏈路應記錄代理和網路環境，但不能假設客戶端總能可靠識別中間設備。
第二步：區分 401
401 表示請求缺少目標資源所需的有效驗證憑據，通常由源站配合 WWW-Authenticate 挑戰。客戶端可以按應用協定刷新令牌或提示登入。它表達的是資源權限問題，不代表本地網路尚未放行。
第三步：區分 407
407 是代理驗證要求，客戶端應根據 Proxy-Authenticate 提供 Proxy-Authorization。代理憑據與應用帳號憑據屬於不同信任域，不能把 407 當成 401，也不能把使用者密碼塞進代理標頭。企業代理和公共網路的憑據儲存策略應單獨設計。
第四步：為什麼不能直接返回 302
302 會把客戶端引向另一個 URL，瀏覽器可能跟隨，但 API SDK、Webhook 消費者和快取層可能把登入 HTML 當成業務回應。跨域入口網站還可能洩露請求上下文。若確需瀏覽器入口網站，應在受控導覽流程中開啟登入頁，登入完成後再重新請求原資源，而不是讓任意 API 回應隱式跳轉。
第五步：設計瀏覽器處理
瀏覽器可以展示明確的網路登入提示，提供入口網站和重試動作。入口網站不能要求使用者輸入應用密碼，也不能把 OAuth 回呼 token 暴露給不受信任的代理。登入完成後，透過網路檢測確認存取已放行，再重新載入原始頁面。
第六步：設計非瀏覽器客戶端處理
行動端、命令列和後台服務應識別 511，記錄網路准入狀態並停止指數重試。客戶端可呼叫受信任的網路檢測介面，或把狀態交給系統網路層；檢測成功後再重送具備冪等語義的請求。對不可重試的寫入請求，必須避免因入口網站未完成而重複提交。
第七步：處理 TLS 與安全邊界
HTTPS 連線中，攔截代理通常無法安全偽造源站內容，除非裝置或企業安裝了受信任的中間憑證。客戶端不應為了「自動登入」關閉憑證驗證。任何入口網站位址、憑證和重導向策略都要經過產品和安全審核，尤其是會話、支付和管理 API。
第八步：驗證、監控與恢復
用真實公共網路和模擬代理測試瀏覽器、原生端、CLI、後台任務、快取和重試。記錄 511 比例、網路區域、入口網站完成率、恢復後首個請求成功率和重複寫入請求。驗收還要確認 401/407 仍按各自契約處理，511 不會被快取成長期錯誤頁面。
設計取捨與邊界
511 的價值是讓客戶端知道阻塞來自網路准入，而不是源站帳號；但中間代理環境並不總是可觀測或可信。應用應把它作為恢復提示，不把它當成身份驗證成功證明。對 API，穩定的錯誤結構和停止重試比自動開啟未知頁面更安全。
不要把所有無法存取都映射成 511。源站登入用 401，代理憑據用 407，限流用 429，網路連線失敗可能根本沒有 HTTP 回應。狀態碼必須反映實際生成層和恢復動作。
落地計畫與證據
先在測試網路中確認 511 的回應標頭、正文、快取行為和生成代理，再為每種客戶端定義狀態機：檢測、提示、等待放行、重試和失敗上報。瀏覽器使用受控入口網站，非瀏覽器交給系統網路層或運維，不把應用憑據交給頁面。
建立指標面板和取樣日誌，按網路、客戶端版本和請求方法分析。對寫入請求增加冪等鍵或明確不可重試契約；對讀取請求在網路恢復後重新取得。每次入口網站供應商或代理策略變更都執行完整驗收。
常見誤區與追問
把 511 當成 401
511 是網路准入問題，401 是資源驗證問題。兩者的挑戰標頭、憑據和恢復流程屬於不同信任域。
讓 SDK 自動跟隨 302
登入 HTML 可能被當成 JSON 或快取。應先識別網路狀態，再由受控流程完成入口網站登入。
向入口網站傳送應用密碼
公共網路代理不應接觸應用憑據。入口網站只完成網路准入，應用帳號驗證仍走源站協定。
對 511 無限重試
網路尚未放行時重試只會放大流量，寫入請求還可能重複。暫停重試，等待受信任的放行訊號並使用冪等語義。
如何測試非瀏覽器客戶端？
在模擬代理和真實公共網路中覆蓋 CLI、行動端、後台任務、快取和恢復後讀寫請求，檢查 511 識別、停止重試、入口網站完成和重複提交指標。