代理閒置逾時與長連線測試：避免陳舊連線故障
代理請求成功後，連線可能在閒置期間被其中一層關閉，但用戶端仍將通訊端視為可用。來源站、代理閘道、負載平衡器、防火牆、NAT 裝置及用戶端連線池都可能使用不同期限。若在真實工作到達時才發現差異，便會出現重設、空回應、尾端延遲或額外重試。
本指南用於找出安全重用視窗，並把 HTTP 持久連線、TCP Keepalive、代理工作階段期限與應用逾時分開管理。
先列出每個逾時
分別記錄代理連線建立、目的端連線與 TLS 交握、回應標頭、內容無資料、用戶端連線池閒置、閘道或中介設備閒置、TCP 探測起始與間隔、HTTP/2 或 HTTP/3 工作階段與串流限制、住宅代理黏性工作階段期限、總請求截止時間與重試預算。
這些計時器用途不同。黏性工作階段期限描述出口選擇，不必然等於一條 TCP 連線的期限；TCP Keepalive 可發現無回應對端，但不能保證 HTTP 連線仍可重用或上游映射仍存在。
建立確定性測試資源
只使用自有或明確授權的端點。準備已知雜湊的小型回應、能揭露內容中斷的大型回應、回傳脫敏連線編號的端點、可控延遲標頭或內容區塊的端點、正常與突然關閉樣本，以及所需的 HTTP/1.1 和 HTTP/2 路徑。
固定方法、標頭、代理憑證、市場、位址族和用戶端版本。持續變動的公共頁面不能作為唯一重用證據。
從三層收集證據
每次嘗試保存脫敏欄位：試驗編號、代理路由與工作階段別名、協定、位址族、要求與觀測市場、連線編號、閒置間隔、通訊端年齡、是否重用、狀態碼、回應雜湊、失敗階段、錯誤類別、嘗試次數與有效結果耗時。
可加入用戶端連線池計數、作業系統通訊端狀態及供應商遙測。不得記錄代理密碼、權杖、Cookie、客戶原始資料或不受限內容。
找出實際重用邊界
完成一個經過內容驗證的請求後，使用同一連線池依序等待 0、1、5、15、30、60、120、300 秒再發送相同請求。每個間隔重複多次；開始失敗後，以更多中間值縮小邊界。跨路由隨機安排順序，避免暫時來源站問題只影響最長等待組。
完整回應、雜湊、語意、市場及工作階段都正確，才算安全重用。連線池悄悄新建連線並成功，只能算請求成功，不算重用成功。
比較直連與代理路徑
政策允許時先做直連對照，再涵蓋 HTTP/HTTPS 代理、指定 DNS 模式的 SOCKS5、輪換與黏性住宅路由、靜態出口、IPv4/IPv6，以及實際使用的 Global、North America、Europe、APAC 市場。
若直連和代理在同一間隔失敗，先檢查來源站、用戶端或共用網路；若只有代理失敗，再隔離閘道、隧道、NAT 和路由政策。不要假設每次重設都由供應商造成。
區分四種結果
- 安全重用： 原連線承載完整有效回應。
- 乾淨淘汰： 傳送應用資料前識別關閉並建立新連線。
- 透明復原： 陳舊重用失敗，一次安全且受限的重試成功。
- 使用者可見失敗： 請求遺失、損壞、重複或超過服務目標。
通常應讓連線池提前乾淨淘汰。只有操作可安全重試且額外延遲和成本符合預算時，透明復原才可接受。
測試半開連線與競態
在受控環境測試：代理先關閉但用戶端仍標記閒置、來源站關閉隧道另一端、網路狀態未經正常關閉便消失、閒置清理與新請求同時發生、多個工作程序選擇同一老化連線、重用時取消或結束，以及 HTTP/2 GOAWAY 或串流重設靠近新請求。
確認一條連線失敗不會重播不安全操作、洩漏監聽器、影響其他多工串流或引發重試風暴。
設定用戶端淘汰餘量
用戶端閒置上限應短於最低可靠的中介邊界，並為排程抖動、網路延遲及設定漂移保留餘量。不要直接採用觀測中位數，應以跨路由和市場的保守分位數決定。
若路由差異顯著，可使用各自連線池，或採用最安全的共用值。代理方案、閘道、系統、執行環境、程式庫或區域基礎設施變更後必須重測。
TCP Keepalive 要獨立驗證探測能否穿過完整路徑，且錯誤能否足夠早送達應用；不要為保持連線而無限占用不必要通訊端。
設計安全重試
僅在操作具冪等性或核准的冪等控制、失敗發生在不含糊的提交前、陳舊連線已移出池、新嘗試使用新連線、嚴格限制次數並採用退避與抖動、總截止時間與成本符合政策時重試。
不能因「沒有收到回應」就重複非冪等請求；沒有回應不證明來源站未執行。
指標與警示
按供應商、路由類型、市場、位址族和協定追蹤各閒置區間的驗證重用成功率、乾淨淘汰率、陳舊重用失敗率、新連線後備率、每個有效結果重試數、p50/p95 有效結果耗時、失敗時連線年齡、測試後通訊端與控制代碼，以及黏性工作階段連續性。
邊界移動本身也要警示。安全視窗從數分鐘降為數秒時，交握負載及尾端延遲可能已上升，但總成功率尚未明顯惡化。
驗收檢查清單
- [ ] 每個逾時和負責人已記錄。
- [ ] 測試資源確定、可控且已授權。
- [ ] 直連和代理使用相同用戶端設定。
- [ ] 閒置間隔涵蓋常用及邊界條件。
- [ ] 重用與新建連線分開量測。
- [ ] 已驗證回應雜湊及語意完成。
- [ ] 正確區分 HTTP/1.1 與多工協定。
- [ ] 已涵蓋必要位址族、路由及市場。
- [ ] 用戶端淘汰包含保守餘量。
- [ ] 重試安全、有限且使用新連線。
- [ ] 已檢查通訊端、控制代碼和記憶體復原。
- [ ] 證據不含秘密或不必要個人資料。
常見問題
HTTP keep-alive 與 TCP Keepalive 相同嗎？
不同。HTTP 持久連線允許多個請求共用連線；TCP Keepalive 以傳輸層探測識別無回應對端，兩者控制與錯誤訊號不同。
用戶端閒置逾時應等於代理逾時嗎？
不應相等。用戶端應在最低可靠中介邊界之前淘汰連線並保留餘量，相等會在最差時刻造成競態。
每個請求都建立新連線能解決問題嗎？
它能避免陳舊重用，但會增加交握、延遲及資源成本。應先測量保守連線池是否能維持正確性。
成功重試會掩蓋陳舊連線故障嗎？
會。應分別報告首次失敗、新連線後備和最終有效結果，否則看不到重試放大。
合規與安全操作
只使用已授權帳號、目的地、資料和市場；遵守存取控制、隱私要求、平台條款及速率限制。不得保持連線來規避工作階段政策或存取限制。保護憑證、保持 TLS 驗證，並最小化證據保存。
接著閱讀代理回應完整性測試、住宅代理工作階段黏性測試及Node.js 代理用戶端金絲雀方案。
標準依據：RFC Editor，《HTTP Semantics》《HTTP/1.1》，2022 年 6 月；《Transmission Control Protocol》，2022 年 8 月。2026 年 9 月 12 日查核。
