如何測試代理標頭大小上限，避免大型 Cookie 造成正式環境故障
代理工作可能連續數週正常執行，卻在 Cookie 逐漸增大、追蹤欄位多了一個節點，或驗證方案改用更長權杖後突然失敗。表面現象可能是 400、431、502、連線關閉、空回應或瀏覽器錯誤。輪替出口 IP 通常無法解決根因：路徑中的某一層拒絕了請求或回應標頭。
本指南適用於已授權的 HTTP、HTTPS CONNECT、SOCKS 和瀏覽器自動化工作。目標是找出最小失敗邊界、確認由哪一層執行限制，並把結果轉換為安全的標頭預算。
列出所有限制執行點
一次 HTTP 交換可能跨越多個獨立上限：
- 建立請求的應用程式或瀏覽器；
- HTTP 用戶端程式庫與協定實作；
- 正向代理或住宅代理閘道；
- CONNECT 終結點或 HTTPS 代理前端；
- 負載平衡器、服務網格或 CDN；
- 目標 Web 伺服器與應用框架；
- 回傳路徑上的回應解析器。
狀態碼不一定能指出拒絕層。有些元件回傳 431 Request Header Fields Too Large，有些使用 400、413、502，也可能重設連線或替換成閘道錯誤頁。因此必須使用受控目標並同時收集兩端證據。
分開定義三個上限
不要只測一個總數，應分別量測：請求標頭總位元組、最大單一請求欄位，以及回應標頭總位元組與最大回應欄位。
也要記錄欄位數量，因為元件可能另外限制欄位數。HTTP/2 與 HTTP/3 會在線路上壓縮標頭區塊，但實作仍會限制解碼後的欄位清單和單一欄位大小。不能把壓縮後傳輸量當成邏輯上限。
建立安全測試夾具
使用自有或受控的網域與端點。夾具應只回顯核准合成欄位的名稱和位元組長度、回傳確定性的內容標記、產生可設定的合成回應欄位、記錄請求是否抵達應用、避免記錄欄位值，並設定保守最大值以避免記憶體壓力。
擴充欄位只能使用無意義測試字元。絕不可放大真實 Cookie、Bearer 權杖、代理憑證、個人識別資料或客戶標頭。每個案例使用短合成 ID，並放在非擴充欄位中。
先建立小型基線
分別透過直接連線控制組和每條核准代理路徑送出小請求，驗證目標標記、路徑身分與狀態。直接連線僅供診斷；代理應用必須關閉直接回退。
記錄：
case_id
route_class
protocol
address_family
request_field_count
request_header_bytes
largest_request_field_bytes
response_field_count
response_header_bytes
largest_response_field_bytes
status_or_error_class
destination_saw_request
response_marker_ok
retry_count
duration_ms整個實驗使用同一套計數規則，並說明是否包含欄位名稱、分隔符號、換行與協定框架。
每次只增加一個維度
從明顯低於預期上限的位置開始，只增加單一欄位長度、欄位總數或回應標頭大小中的一項。先用較大步距找到首次失敗，再在最後成功和首次失敗之間做二分測試。
例如：2 KiB 成功、4 KiB 成功、8 KiB 失敗，再測試 6 KiB，直到邊界足以支援營運決策。必要時重建連線，避免一次失敗影響後續案例。最終邊界應重複數次；結果浮動可能代表不同代理節點或上游元件配置不一致。
依風險類別測試請求欄位
分開測試單一逐步增大的類 Cookie 欄位、大量小型類 Cookie 鍵值對、使用假值的大型類授權欄位、包含許多項目的分散式追蹤 baggage、多個轉送與用戶端提示欄位，以及合法但較大的自訂中繼資料欄位。
不要把逐跳欄位當作一般端對端中繼資料。代理新增、刪除或正規化欄位的行為，應透過獨立的代理請求標頭完整性指南驗證。
獨立測試回應路徑
保持請求很小，讓受控目標逐步增加合成回應欄位。確認用戶端收到完整內容標記，並核對目標是否正常完成。
需要區分：閘道拒絕上游回應並回傳自有錯誤、用戶端解析器在轉送後拒絕回應、欄位被截斷或靜默移除、內容前連線關閉，以及內容存在但必要中繼資料缺失。
即使狀態是 200，只要必要回應欄位或內容標記不完整，都不能計為有效結果。可使用代理回應完整性測試避免把閘道錯誤頁寫入業務資料。
比較 HTTP 版本與代理模式
在實際技術堆疊支援時，透過 HTTP/1.1、HTTP/2 和 HTTP/3 執行相同邏輯案例，並分別涵蓋一般 HTTP 代理、HTTPS CONNECT、HTTPS 代理傳輸及必要 SOCKS 模式。
不要假設 HTTP/2 壓縮會允許更大的 Cookie。用戶端程式庫與伺服器通常仍對解碼後欄位清單執行限制。記錄協商協定和連線是否重用。
IPv4 與 IPv6 也應獨立測試。位址族不應改變標頭語意，但不同監聽器或區域閘道可能採用不同配置。
判定拒絕層
| 證據 | 可能解釋 |
|---|---|
| 目標沒有案例 ID，代理記錄拒絕 | 代理端請求上限 |
| 目標沒有案例 ID，代理也無請求記錄 | 用戶端或更早的中介層 |
| 目標已處理，用戶端收到閘道錯誤 | 回傳路徑拒絕回應 |
| 直接連線在相同邊界失敗 | 較可能是目標或用戶端限制 |
| 僅一個代理地區失敗 | 區域閘道配置不一致 |
| 新連線通過、重用連線失敗 | 連線狀態或協定實作問題 |
若無法存取日誌，可組合「直接/代理、小/大、請求/回應」三組對照，通常不需收集內容就能縮小範圍。
防止重試放大
在配置與請求內容未變時，超大標頭屬於確定性失敗。用相同請求輪替出口只會浪費頻寬，也可能表現為濫用。對 400、431、解析器上限錯誤及可重現的重設，在一次受控確認後應分類為不可重試。
不得透過出口輪替規避目標的標頭政策。應縮小請求、清理不必要狀態或調整已核准配置。對有副作用的請求，在斷線結果不明時不得自動重播。
建立營運預算
不要貼近測得的最大值執行。以所有必要路徑、地區、位址族和協定中最小穩定上限為基準，預留代理新增中繼資料和未來應用變更所需空間。
正式環境只記錄安全指標：分區間的請求與回應標頭位元組、最大欄位大小但不記錄值、欄位數、400/431/502 與解析失敗率、對應重試次數，以及依用戶端版本、代理地區與協商協定劃分的邊界。
在觸及硬上限前發出警示。持續增長的 Cookie 或追蹤欄位應在造成區域故障前修正。
驗收檢查清單
- 受控端點和代理路徑均已授權。
- 測試值不含憑證、Cookie 或個人資料。
- 請求總量、最大欄位和欄位數分別量測。
- 回應標頭上限單獨測試。
- 直接連線回退已關閉。
- HTTP 版本和代理模式清楚標示。
- IPv4、IPv6 與必要市場均已涵蓋。
- 最後成功與首次失敗都重複驗證。
- 拒絕層有證據支援。
- 超大失敗不會觸發出口輪替。
- 正式環境預算包含書面餘量。
- 日誌只保存大小與案例 ID，不保存欄位內容。
常見問題
431 一定由代理回傳嗎？
不一定。用戶端、代理、中介層或目標都可能執行限制，有些會使用其他狀態或直接關閉連線。必須關聯目標端與代理端證據。
HTTP/2 壓縮能解決大型標頭嗎？
不能。壓縮減少線路表示，但實作仍限制解碼欄位清單和單一欄位；大型 Cookie 也會消耗壓縮狀態與處理資源。
是否應全面提高上限？
不應自動提高。更高上限會增加記憶體與濫用風險。先移除不必要狀態，再經容量與安全審查做最小範圍調整。
更換代理出口能修正錯誤嗎？
可能暫時落到配置不同的節點，但這只是隱藏不一致。浮動邊界應視為供應商或代理叢集配置問題。
應預留多少餘量？
應低於最小可重現邊界，並為代理新增欄位留出空間。驗證、追蹤、Cookie 或閘道配置變更時重新評估。
合規說明
只測試自有或已授權的系統、代理帳戶與目標。使用合成欄位、保守並行度和嚴格最大值。不得用超大請求對第三方基礎設施施壓、繞過存取控制或規避發布者限制。
