1. 題目與適用場景
登入後頁面經 CDN、負載平衡器與服務網格存取 API，部分使用者收到 431 Request Header Fields Too Large；無痕視窗與 curl 正常。請說明 431 的語意、逐層定位方法、修復策略與上線驗證。假設請求可能使用 HTTP/1.1 或 HTTP/2，且日誌不能記錄完整 Cookie 或 Authorization。
2. 面試官考察點
- 是否區分總請求標頭過大與單一欄位過大，並知道 431 屬於請求處理前的用戶端錯誤。
- 是否能沿 CDN、閘道、代理到應用逐層測量，而不是只修改應用伺服器設定。
- 是否辨識 Cookie 膨脹、重複 Set-Cookie、過長權杖與轉發標頭為主要來源。
- 是否會在保留安全性的前提下壓縮狀態、輪換憑據並建立大小監控。
3. 回答前需要釐清的問題
- 431 是哪一跳產生的？回應標頭、伺服器識別與邊緣日誌能否定位節點？
- 失敗請求的請求標頭總位元組數、最大欄位與協定版本分別是多少？
- 瀏覽器是否攜帶多個舊 Cookie、跨子網域 Cookie 或持續增長的工作階段資料？
- 各層限制是總標頭區塊、單一欄位、請求行還是緩衝區，是否存在 HTTP/2 解碼限制？
4. 30 秒回答框架
431 表示伺服器拒絕處理請求，因為請求標頭總量或某個欄位超過允許範圍；RFC 6585 沒有規定固定位元組上限。先從用戶端、邊緣、閘道、代理到應用記錄脫敏後的總量與最大欄位，找出首次回傳 431 的層。瀏覽器獨有時優先檢查 Cookie、重複 Set-Cookie 與 Authorization，而不是先調大上限。修復應減少用戶端狀態、縮短或改為伺服器端工作階段引用，清理舊 Cookie，並讓所有層的預算一致；調大限制只能作為完成容量與 DoS 評估的短期措施。
5. 分步驟深入解答
第一步：確認狀態碼與產生位置
記錄請求經過的節點、協定、回應標頭與關聯 ID。用最小重現請求分別直連源站、繞過 CDN、經過閘道以及使用瀏覽器匯出的脫敏標頭，比較首次出現 431 的位置。某些代理使用 400 或廠商自訂 494 表達同類限制，因此不能只依賴狀態碼；要結合節點日誌與設定確認拒絕原因。
第二步：按位元組測量標頭
對每個欄位計算編碼後的位元組數，並同時記錄總請求標頭、請求行、最大單一欄位與欄位數量。不要把字元數當作位元組數，也不要把壓縮後的 HTTP/2 標頭區塊大小等同於解碼後的欄位總量。日誌只保留欄位名稱、長度、雜湊前綴與請求 ID，禁止記錄 Cookie 值、Bearer 權杖或完整 Referer。
第三步：定位瀏覽器特有來源
Cookie 通常是首要嫌疑：多個路徑或子網域設定同名 Cookie、把使用者資料放進 Cookie、每次回應追加新版本，都會讓後續請求持續膨脹。檢查 Set-Cookie 的 Domain、Path、到期時間與刪除邏輯；確認舊名稱真的過期，而不是只覆蓋目前路徑。Authorization 權杖應保持短小，更新權杖放在受控的伺服器端工作階段或安全儲存，不要把可變業務資料塞進權杖。
第四步：處理代理鏈與 HTTP/2
每一層可能有不同的總量、單欄位與緩衝區限制，轉發時還會新增 X-Forwarded-*、追蹤與認證標頭。把預算寫成設定契約，並用最小值作為用戶端設計上限。HTTP/2 使用 HPACK 壓縮傳輸，但端點仍需解碼標頭欄位並執行限制；不要用壓縮率證明業務標頭安全。若閘道拒絕而應用未收到請求，應在閘道指標中告警。
第五步：選擇修復與防禦
優先刪除重複 Cookie、縮小工作階段內容、把狀態移到伺服器端並只傳不可猜的短引用。對權杖設定最大長度、輪換與撤銷策略；對未知或異常大的自訂標頭直接拒絕。只有在確認記憶體、連線並發與解析成本後才提高限制，並為不同租戶或路由設定合理預算，避免擴大 DoS 面。
6. 高品質示範回答
我會先找出回傳 431 的第一跳，再對失敗請求做脫敏測量：總標頭位元組數、最大欄位、請求行、欄位數量與 HTTP 版本。瀏覽器失敗而 curl 正常，優先檢查重複或跨子網域 Cookie、膨脹的工作階段資料與 Authorization 長度；不能只調大應用伺服器上限，因為 CDN、負載平衡器或服務網格可能更早拒絕。修復包括刪除舊 Cookie、縮小用戶端狀態、改用伺服器端工作階段引用與統一各層預算。HTTP/2 的壓縮傳輸不等於解碼後沒有限制。上線後監控按節點與欄位名稱聚合的大小分位數，日誌只保留長度與雜湊前綴，不記錄憑據。
7. 常見錯誤
- 只清瀏覽器 Cookie： 可能暫時恢復，但沒有修復重複
Set-Cookie根因；應追蹤設定者、Domain、Path 與到期邏輯。 - 把 431 當成固定 8 KB： RFC 沒有規定統一上限；應讀取每層實際設定並按位元組測量。
- 只提高源站限制： CDN 或閘道仍可能先拒絕，且解析成本與 DoS 風險上升；應先統一預算與容量評估。
- 記錄完整請求標頭排查： 會洩露 Cookie 與權杖；只記錄欄位名稱、長度、雜湊前綴與關聯 ID。
- 認為 HTTP/2 壓縮消除了限制： 端點仍要解碼欄位並執行限制；應分別測試壓縮傳輸與解碼後大小。
8. 追問及應對
追問一：為什麼 curl 正常而瀏覽器失敗？
瀏覽器會自動攜帶該網域匹配的全部 Cookie、認證與追蹤標頭；curl 的請求通常更小。匯出瀏覽器請求後逐個刪除欄位做二分實驗，再在每一跳測量，能區分用戶端來源與代理限制。
追問二：能否把 JWT 放進 Cookie？
可以，但每次請求都承擔權杖位元組成本，且多個 Cookie 疊加可能觸發限制。只放短引用或最小宣告，把可變資料與撤銷狀態放在伺服器端，並設定長度預算與輪換策略。
追問三：什麼時候可以調大上限？
只有在確認業務確實需要、所有層都能承受解析記憶體與並發成本，並完成容量、逾時與 DoS 測試後才調整。發布時同時保留大小監控、限流與回滾設定，不能把提高上限當作唯一修復。