代理失敗在應用程式端往往看起來相同：預期資料沒有回來。然而 407、429、逾時與連線重設發生在不同層級，也需要不同處理方式。把所有故障都交給「立即重試」，只會放大限流、拉長佇列並掩蓋真正原因。
先定位故障層級
將一次請求拆成用戶端、代理驗證、代理出口、目標服務與應用邏輯五層。固定目標、區域、工作階段策略與並行度，並記錄 UTC 時間、請求 ID、代理區域、HTTP 狀態、相關回應標頭、失敗階段與總耗時。每次只改變一個變數，才能判斷問題來自憑證、配額、網路或目標站點。
407：先修正驗證，不要盲目輪換
407 表示代理要求驗證。先核對使用者名稱、密碼、端點、連接埠與驗證方式；確認 URL 編碼沒有破壞憑證，也沒有把目標站點的 Authorization 與代理的 Proxy-Authorization 混用。
以單一、低並行請求測試相同憑證。若所有節點都回傳 407，應優先檢查帳戶狀態、方案權限與 IP 白名單；若只有部分節點失敗，再隔離區域、協定與端點。更快輪換並不能修好錯誤憑證。
429：遵守 Retry-After 並降低壓力
429 是速率限制訊號，可能由代理、其他閘道或目標站點產生。可用時先檢查 Retry-After 與 Proxy-Status，再判斷是哪一跳套用了限制。
不要立即更換 IP 並維持原速率。應降低並行度、採用帶隨機抖動的指數退避、設定每個網域的請求預算，並快取不需頻繁更新的資料。每個重試策略都要有最大嘗試次數與總時間預算；超出預算的工作應進入延遲佇列，而不是無限循環。
逾時：依連線階段拆分
分別量測 DNS、TCP 連線、TLS 握手、首位元組時間與回應本文讀取時間。連線逾時常指向路由、節點可用性或防火牆；首位元組逾時較可能涉及目標回應慢、出口壅塞或請求過重；讀取逾時則需檢查大型回應、頻寬與串流處理。
應分開設定連線逾時與讀取逾時，避免單一總逾時掩蓋真正失敗階段。
連線重設：檢查協定與重用
重設可能來自代理、目標站點、中間設備或用戶端連線池。先關閉連線重用作為對照，再比較 TLS 版本、HTTP/2 或 HTTP/3 協商、閒置連線壽命、請求本文大小與每條連線的請求數。
若重設集中於某區域或節點，應暫時隔離並進行健康檢查；若只在高並行出現，則降低每條連線的請求數並縮短過長佇列。
有界限的重試矩陣
- 407：只有在憑證或白名單改變後才重試。
- 429：遵守 Retry-After、退避並降低並行度。
- 連線逾時：在嚴格次數預算內切換健康節點。
- 讀取逾時：先檢查回應大小與目標效能。
- 連線重設：短暫等待後建立新連線，保留節點與協定證據。
- 確定性的 4xx 業務錯誤：除非請求條件改變，否則不要重試。
最小診斷記錄
每次失敗至少保存請求 ID、UTC 時間、目標主機、代理區域、工作階段類型、狀態碼、失敗階段、耗時、重試次數與最終結果。不要在日誌中保存完整代理密碼、Cookie、個人資料或目標站點敏感內容，並為營運日誌設定存取控制與保留期限。
發布前檢查清單
- 單一請求是否成功？
- 407 是否已排除憑證、白名單與方案權限問題？
- 429 是否遵守等待時間並限制重試？
- 是否分別量測 DNS、連線、TLS、首位元組與讀取時間？
- 重設是否與協定、區域、節點、重用或並行度相關？
- 是否設定最大嘗試次數、總時間預算與熔斷？
- 日誌是否排除憑證與個人資料？
FAQ
可以用無限輪換解決 429 嗎？
不建議。429 是容量或政策訊號，無限輪換可能加重壓力並違反目標規則。應先降低速率、遵守等待時間並確認活動已獲授權。
407 與目標站點的 401 有何不同？
407 通常屬於代理驗證層，401 通常屬於目標資源的身分驗證層。應檢查對應的驗證挑戰標頭，並將兩套憑證流程分開。
哪些故障適合自動重試？
短暫網路故障可以在嚴格預算內重試；驗證失敗、權限失敗與多數確定性 4xx 不應在條件未改變時重試。
合規、低速率且可稽核的資料流程，比單純增加 IP 更可靠。進行合法的區域與工作階段測試時，可從 98IP 首頁 了解代理類型，並遵守目標條款、適用法律與資料最小化原則。
資料依據：RFC Editor，HTTP Semantics，2022 年 6 月；Additional HTTP Status Codes，2012 年 4 月；The Proxy-Status HTTP Response Header Field，2022 年 6 月。
