代理池隔離與復原：避免異常出口過早回流

輪替代理或住宅代理池的整體指標可能看似正常，但少量出口會反覆失敗、短暫通過一次探測後又立即出錯。若系統看到一次成功就恢復滿量流量，出口會在「健康」與「異常」間抖動，造成逾時、工作階段漂移、重複重試與有效結果下降。

隔離是一種暫時的維運狀態，目的不是懲罰出口，也不是繞過目標網站的存取決定。它暫停把正常業務交給可疑路徑，同時蒐集足夠證據，判斷問題來自用戶端、閘道、出口、目標端或應用邏輯。

先分類故障，再決定隔離

單次失敗不足以驅逐出口。逾時可能發生在 DNS、用戶端佇列、代理閘道、出口網路、目標端或業務期限。建議使用低基數原因類別：

目標範圍的證據應分開保存。某出口對一個獲准目標失敗，不等於它對所有目標都異常；但任何情況都不能用輪替規避存取控制或速率限制。

使用五態狀態機

1. 健康： 可承擔正常流量份額。
2. 可疑： 只保留極小流量，在短確認視窗內蒐集證據。
3. 已隔離： 不承載正式流量，只允許受控探測。
4. 觀察復原： 探測通過後接收少量金絲雀流量。
5. 恢復健康： 只有觀察視窗的所有門檻通過後才恢復正常權重。

每次狀態轉換記錄原因碼、UTC 時間、單調時長、路由別名、地區、位址家族、閘道別名、出口指紋與目標類別。使用帶密鑰指紋，不公開完整住宅位址；日誌不得包含代理密碼、Cookie 或非必要個資。

明確定義隔離觸發器

隔離應同時依賴多個訊號，並設定最小樣本量：

可隔離 =
  請求數達到最小樣本
  且分類失敗率超過門檻
  且至少兩個工作節點觀察到失敗
  且證據位於規定時間窗內

對受控端點的 TLS 身分不符等嚴重事件，可採較小計數；對雜訊較大的目標回應，則要擴大樣本並與全池基準比較。目標端整體事故不應把所有出口都驅逐。

同時限制可隔離的最大容量。觸及上限時，應削減或排隊非關鍵工作、發出告警並保護健康容量，不能靜默切換為本機直連。可先用代理並行飽和測試估算自動隔離所需的容量餘裕。

讓冷卻時間隨復發增加

固定短延遲容易造成抖動。保存隔離次數，復發時延長冷卻：

冷卻時間 = min(基礎冷卻 × 復發倍數, 最大冷卻)

加入有限抖動，避免大量出口在同一時間恢復探測資格。一次成功不能立即清除歷史，應在長時間健康後逐步降低復發倍數。

具體值取決於請求頻率、池規模與業務期限，但必須具備下限、上限、復發記憶與隨機化。設定值應隨結果保存，讓後續稽核可重現決策。

復原探測必須接近真實業務

TCP 握手成功遠遠不夠。低流量且獲准的復原探測至少應驗證：

• 閘道連線與代理驗證；
• 預期的本機或遠端 DNS 模式；
• 不關閉驗證的 TLS 檢查；
• 出口指紋與要求地區；
• 延遲是否位於規定範圍；
• 自有或獲准端點的有效業務標記；
• IPv4 與 IPv6 分開驗證；
• 正式環境會使用的新連線與重複使用連線。

條件允許時使用兩個獨立工作節點。單一節點可能有自身解析器、網路或時鐘問題；跨節點的一致成功比同一機器連續探測更可信。

若目標端已回傳限速或拒絕存取，不應持續輪替探測尋找「能成功的出口」。復原探測只驗證服務健康，不規避政策。

連續證據通過後才進入觀察復原

出口必須在最小時間跨度內連續通過多次有效探測，才能進入觀察復原；同類故障再次出現時，應重設或延長門檻。

範例條件包括：兩個節點共三次有效探測；十分鐘內沒有傳輸或 TLS 失敗；p95 延遲不超過全池基準加約定餘量；每次地區與位址家族正確；回傳有效業務結果而不只是 HTTP 200；沒有直連回退；重試量位於預算內。

這些只是範例，實際門檻應依自身基準設定並經變更審查。

分階段恢復業務流量

觀察復原先接收極少量冪等工作，再依 1%、5%、20% 和正常權重逐級放量，每級均設定觀察視窗。門檻同時包含時間與請求數，避免低流量出口在沒有足夠證據時通過。

每階段比較有效結果率、分類失敗率、連線/TLS/首位元組延遲分布、佇列時間、活動並行量、每個原始操作的重試數、工作階段與地區連續性，以及目標回應分布。

任何門檻失敗都應回到隔離並保留復發計數，不要在滿量與零流量之間來回切換。搭配閒置逾時與保活測試，避免陳舊重複使用連線造成假復原或假失敗。

區分出口、閘道與目標範圍

若同一閘道後的多個出口同時失敗，共因可能是閘道、DNS 路徑或用戶端地區。至少維護三種範圍：

• 出口範圍： 同一指紋在多個節點異常；
• 閘道範圍： 多個出口只在某個閘道後失敗；
• 目標範圍： 多條健康路徑只對某類目標失敗。

隔離大量出口無法修復壞閘道；故障移轉也不能抹除出口證據。每條請求鏈都應保留路由識別。

使用可決策的指標

請求時長應記錄為直方圖，錯誤使用可預測、低基數分類。原始位址與不受控目標字串會提高成本並洩漏敏感資料。

至少記錄健康、可疑、隔離與觀察復原出口數；依原因統計隔離與復發；穩定復原時間；每個原始操作的請求數；有效結果率。對狀態快速切換、隔離比例上升、反覆觀察失敗、健康容量耗盡，以及 HTTP 成功與業務成功之間的差距設定告警。

可搭配HTTPS 代理 TLS 鏈路稽核，補足信任邊界驗證。

上線步驟

1. 先以僅觀察模式執行分類器，並與人工判斷比較。
2. 只為一種高可信度故障類別啟用隔離。
3. 設定嚴格的最大驅逐比例，強制代理流量必須關閉失敗。
4. 初期由人工核准復原，只有穩定證據支持的門檻才自動化。
5. 依地區與位址家族逐步啟用。
6. 演練閘道級與目標級事故，確認不會誤殺健康出口。
7. 每次策略變更後檢討誤判、復原時間與容量損失。

檢查清單

• [ ] 已區分本機、代理、出口、目標與業務故障。
• [ ] 已定義最小樣本量與確認節點數。
• [ ] 最大隔離容量不會破壞池可用性。
• [ ] 冷卻時間隨復發增加並含有限抖動。
• [ ] 探測覆蓋驗證、DNS、TLS、地區與有效結果。
• [ ] 不透過輪替繞過拒絕存取或限速。
• [ ] 觀察復原使用分階段流量與明確門檻。
• [ ] 出口、閘道與目標範圍保持分離。
• [ ] 強制代理流量不會洩漏為直連。
• [ ] 日誌不保存密碼、Cookie 與原始個資。

常見問題

每個 403 或 429 都應隔離出口嗎？

不應。這類回應通常反映目標驗證、授權或速率政策。應尊重回應並檢查獲准整合，不能輪替出口繞過決定。

一次健康檢查成功能恢復流量嗎？

不能。一次探測可能碰到短暫正常，也可能沒有涵蓋故障層。需要連續、具代表性的證據與有限的觀察放量。

隔離會不會讓容量不足？

會。必須限制驅逐比例、預留餘裕，並在容量不足時削減非關鍵工作，不能用無限重試掩蓋問題。

是否應全域隔離某個出口？

只有證據證明出口是全域異常時才這樣做。目標級或閘道級問題應保留其範圍，避免移除仍然健康的路徑。

合規說明

本流程僅用於獲准營運或測試的代理資源、帳號與目標。遵守合約、robots 與存取政策、速率限制、隱私義務及資料最小化要求。隔離與復原用來提高可靠性，不得用於繞過封鎖、冒充使用者或掩蓋被禁止的資料蒐集。