代理回應完整性測試：識別截斷、解壓錯誤與假成功
代理請求即使回傳 HTTP 200，也可能沒有完成業務任務。正文可能提前結束、壓縮內容可能無法解碼、串流解析器可能只接受前幾筆紀錄、範圍回應可能被錯誤拼接，應用程式也可能快取了殘缺物件。若把這些嘗試計為成功，出口池看起來很健康，下游資料卻會持續缺失。
因此，回應完整性是獨立於可達性、延遲、地理位置與狀態碼的品質維度。應先用自有或明確獲授權的確定性測試物件驗證，再信任正式環境結果。
分層定義「完整」
不要用一個雜湊取代分層診斷。實用測試至少區分：
- 傳輸完成：連線與協定串流正常結束；
- HTTP 訊息完成：正文符合適用的邊界規則；
- 表示層完成：內容編碼成功解碼並得到預期位元組；
- 應用層完成：必要紀錄、欄位、分頁標記或結束符存在；
- 業務完成：結果新鮮、屬於請求區域，並可用於核准目的。
RFC Editor 的 HTTP 規範提供協定邊界。在 HTTP/1.1 中，收到的位元組少於 Content-Length 宣告值時，訊息不完整；分塊傳輸缺少終止零長度區塊時也不完整。HTTP 語意還區分編碼後的表示與解碼內容，並規定位元組範圍相對於編碼序列的關係。
建立確定性測試物件
只使用自有或明確獲授權的端點。建議準備：
- 已知位元組數與摘要的小型未壓縮文字；
- 紀錄數固定、適合壓縮的大型 JSON；
- 用戶端支援時提供 gzip 與 Brotli 版本；
- 已知摘要的二進位物件；
- 支援單一位元組範圍請求的資源；
- 帶明確最終紀錄或結束標記的串流格式；
- 在測試環境中故意提前關閉的回應。
每個物件都必須版本化，並記錄編碼長度、解碼長度、摘要、媒體類型、內容編碼、預期紀錄數與修改識別。不要把可能隨時變化的公開頁面當成直連與代理比較的唯一基準。
保留足夠且克制的證據
每次試驗可保留以下去識別化紀錄：
試驗編號
測試物件版本
代理路線別名
請求區域與觀察區域
位址族與協定版本
狀態碼
Content-Length
Transfer-Encoding
Content-Encoding
Content-Range
接收線路位元組數
解碼位元組數與摘要
紀錄數與結束標記
嘗試次數
失敗層級
總耗時不要保存代理密碼、Cookie、權杖、個人資料或未受控的完整正文。摘要與少量結構斷言通常已足以重現比較。
建立直連與代理矩陣
在相同用戶端版本、逾時、請求標頭與觀察視窗下，對同一測試物件比較：
- 原則允許時的直連對照；
- 帶驗證的 HTTP 或 HTTPS 代理；
- 依需求設定本機與遠端 DNS 的 SOCKS5；
- 輪換住宅路線；
- 黏性住宅工作階段；
- 靜態或專用路線；
- 所需 IPv4 與 IPv6 路徑；
- 業務涉及的 Global、North America、Europe 與 APAC 區域。
每個單元要重複足夠次數以發現低頻截斷，但不得製造不必要負載。隨機化路線順序，避免短暫來源站問題只影響某一家服務商或某一區域。
先驗證 HTTP 邊界，再解析內容
Content-Length 回應
在解壓前，把實際收到的訊息正文位元組數與宣告長度比較。連線提前關閉或逾時時，應記錄為訊息不完整，不能把殘缺位元組交給下游解析器並計為有效物件。
HTTP/1.1 分塊回應
必須驗證區塊語法與終止零長度區塊。正常 TCP 關閉不能取代正確的分塊結束。區塊大小無效、終止符缺失或連線過早關閉都屬於邊界失敗。
HTTP/2 與 HTTP/3
使用用戶端函式庫提供的串流完成與重設訊號，不要套用 HTTP/1.1 的分塊規則。把串流重設、協定錯誤與應用逾時分開記錄。收到部分 DATA 訊框不代表回應已完成。
以連線關閉定界的回應
此類回應很難與網路中斷區分。完整性測試應盡量採用長度或編碼定界物件；無法避免時，必須保留底層連線或 TLS 關閉證據。
驗證內容編碼與表示位元組
明確傳送 Accept-Encoding，不要沿用未知用戶端預設值。記錄伺服器回傳的 Content-Encoding 順序，依序解碼，並在解壓錯誤時失敗關閉。
條件允許時同時比較：
- 線路長度與編碼摘要；
- 解碼長度與解碼摘要；
- 媒體類型與字元集；
- 解碼後的結構化解析結果。
代理或用戶端可能透明解壓並調整標頭。必須先定義擷取點看到的是編碼位元組還是解碼位元組，並在所有對照試驗中保持一致。
謹慎測試位元組範圍
對已授權且支援範圍的測試物件：
- 請求一個已知單一範圍；
- 伺服器接受範圍時要求有效的
206 Partial Content； - 驗證
Content-Range的起點、終點與總長度； - 確認正文位元組數等於包含首尾的範圍長度；
- 與標準編碼物件相同切片的摘要比較；
- 請求無效範圍並驗證預期的
416； - 恢復下載時要求穩定驗證器，避免合併不同版本位元組。
伺服器可以忽略範圍並以 200 回傳完整資源。用戶端必須區分這種合法行為與被錯誤標記的部分回應。
增加應用層完成斷言
協定完成不能證明資料可用。依格式選擇斷言：
- JSON 必須完整解析並含必要頂層欄位；
- 行式 JSON 必須以完整紀錄結束且紀錄數正確；
- CSV 必須有完整表頭且欄數一致；
- HTML 需有完整結構與穩定業務標記；
- 壓縮檔可以開啟並通過內部測試；
- 媒體或二進位容器包含預期尾部或索引；
- 分頁資料包含預期終止游標或明確續頁狀態。
不要只用 HTML 總長度或一個短語做斷言。合法內容變化會造成誤報，而錯誤頁也可能包含同一短語。
重試前先分類
使用能對應處置方式的失敗類型：
proxy_connect：未連上閘道；proxy_auth：憑證被拒絕；dns：閘道或目的站解析失敗；tls：憑證或交握失敗；http_framing：宣告的訊息未完成；content_decode：內容編碼無法解碼；range_integrity：範圍中繼資料或位元組不一致；semantic_integrity：正文完成但結構斷言失敗；business_validation：結構正確但業務結果不可用。
只有操作可安全重複且失敗可能為暫時性時才重試，並設定嘗試預算、指數退避與抖動。除非協定、驗證器與應用明確支援安全恢復，否則不得拼接不同完整請求回傳的位元組。
衡量有效交付，而不是請求成功
依服務商、路線類型、區域、位址族與協定追蹤：訊息完整率、解碼完整率、語意完整率、有效結果率、截斷位置分布、單次有效結果重試數、有效結果耗時、位元組成本與單次有效結果成本。
便宜路線若產生更多殘缺回應，在加入重試、解析失敗與缺失紀錄後，實際成本可能更高。
驗收檢查清單
- [ ] 測試物件自有或明確獲授權，並已版本化。
- [ ] 已知編碼與解碼長度及摘要。
- [ ] 直連與代理試驗使用同一用戶端與標頭。
- [ ] 先驗證 HTTP 邊界，再進行應用解析。
- [ ] 解壓錯誤會失敗關閉。
- [ ] 範圍回應驗證狀態、中繼資料、長度與摘要。
- [ ] HTTP/2 或 HTTP/3 重設單獨記錄。
- [ ] 已斷言必要紀錄與完成標記。
- [ ] 可偵測直連回退與意外快取命中。
- [ ] 重試有次數預算、退避與抖動。
- [ ] 證據不含憑證與個人資料。
- [ ] 可依路線、區域、位址族與協定比較結果。
常見問題
Content-Length 足以證明完整性嗎？
不足。它在適用情境協助判斷訊息是否完成，但長度相同不能證明位元組正確、新鮮或可用，還要增加解碼摘要與語意檢查。
摘要應涵蓋壓縮前還是解壓後的位元組？
理想情況應在定義清楚的擷取點同時記錄兩者。編碼摘要用於定位傳輸差異，解碼摘要驗證應用實際使用的表示。
能否比較公開網頁的直連與代理結果？
只能作為補充。個人化、邊緣節點、時間、同意狀態與實驗都會造成合法差異。完整性門檻應使用確定性且獲授權的測試物件。
所有不完整回應都應重試嗎？
不應。先確認請求可安全重複、失敗可能為暫時性且仍有重試預算。持續出現完整性問題時，應隔離路線，而不是無限循環。
合規與安全操作
只使用獲授權的端點、帳號、資料與區域。遵守存取控制、平台條款、隱私規則、地區法律與速率限制。不得利用代理繞過限制或隱藏禁止的資料蒐集。保持 TLS 驗證開啟，保護憑證，盡量少保存正文，並在分享前將證據去識別化。
繼續閱讀代理請求標頭完整性測試、代理 TLS 工作階段恢復測試與代理 WebSocket 長連線測試。
內部研究依據：RFC Editor，RFC 9110《HTTP Semantics》與 RFC 9112《HTTP/1.1》，均發布於 2022 年 6 月；2026 年 9 月 12 日查核。
