讓一次代理請求成功很容易,建立可靠代理工作流程則需要工程化控制。正式任務必須設定明確逾時、有限重試、穩定的工作階段規則,並用日誌區分代理故障與 DNS、TLS、限流或目標端錯誤。
本文使用 Python Requests 與 urllib3 Retry。Requests 官方文件支援按請求傳入代理字典、使用 Session 重複使用連線,並透過傳輸配接器設定重試。文件也提醒:環境變數中的代理設定可能覆蓋 Session,因此範例在每次請求中明確傳入 proxies。

1. 從最小且安全的設定開始
不要把帳號密碼寫進原始碼或日誌。完整代理 URL 應保存在密鑰管理服務或環境變數中,文件只使用佔位符。
import os
import requests
proxy_url = os.environ["PROXY_URL"]
proxies = {"http": proxy_url, "https": proxy_url}
response = requests.get(
os.environ["TARGET_URL"],
proxies=proxies,
timeout=(5, 20),
)
response.raise_for_status()
print(response.status_code)
二元逾時分別控制連線時間與讀取時間,避免故障路線長期佔用工作執行緒。只有當業務確實把非 2xx 狀態視為失敗時,才呼叫 raise_for_status()。
2. 先確定輪換與黏性工作階段規則
代理可能按請求、連線、時間視窗或工作階段標識輪換。獨立取樣任務通常適合新路線;登入後的多步驟、已授權流程則需要保持 Cookie、地區和網路身分一致。不要透過新出口盲目重試寫入操作,否則可能重複提交。除非業務實作冪等鍵,否則自動重試應限制在 GET、HEAD 等冪等方法。
3. 使用指數退避和有限重試
import os
from requests import Session
from requests.adapters import HTTPAdapter
from urllib3.util import Retry
retry = Retry(
total=3,
connect=3,
read=2,
status=2,
backoff_factor=0.5,
status_forcelist={429, 502, 503, 504},
allowed_methods={"GET", "HEAD", "OPTIONS"},
respect_retry_after_header=True,
)
session = Session()
session.mount(" HTTPAdapter(max_retries=retry))
response = session.get(
os.environ["TARGET_URL"],
proxies=proxies,
timeout=(5, 20),
)此策略只處理少量瞬時故障,並尊重伺服器的 Retry-After。重試次數必須有限;連續失敗通常意味著設定、授權、容量或目標端問題。
4. 有意識地管理 Session
Session 會重複使用連線和 Cookie。建議每個邏輯身分或任務邊界使用獨立 Session,避免在沒有隔離設計時跨客戶或跨任務共享可變 Session。黏性代理任務應在完整流程內保留相同工作階段標識,結束後主動關閉。
5. 記錄可用於排障的證據
每次嘗試記錄去識別化任務 ID、目標主機、地區、代理產品、工作階段標識雜湊、嘗試次數、連線耗時、總延遲、HTTP 狀態與異常類型。絕不記錄代理密碼、完整驗證標頭、Cookie 或敏感回應內容。
- DNS 錯誤:連線前無法解析主機。
- 連線逾時:路線或閘道無法建立連線。
- TLS 錯誤:憑證或交握失敗,正式環境不能用關閉驗證來「修復」。
- 407:代理驗證失敗。
- 429:目標限流,應降低速率並遵守 Retry-After。
- 403 或挑戰頁:應檢查授權與目標政策,不進行繞過。
- 讀取逾時:已連線但回應未在限制內完成。
6. 擴容前先做小規模驗證
先用獲准存取的檢測端點確認出口國家、ASN、IP 版本與工作階段行為,再以保守速率測試真實目標。衡量有效結果率、延遲、重試率和單位有效結果成本,而不只看 HTTP 成功。
上線檢查清單
- 憑據來自密鑰儲存並從日誌中去識別化。
- 每個請求都有連線與讀取逾時。
- 重試有限、帶退避且不覆蓋危險寫入操作。
- 工作階段生命週期符合業務身分要求。
- 遵守 429、Retry-After、目標條款與適用的 robots 指令。
- 保持 TLS 驗證。
- 儀表板統計有效產出而非虛假成功率。
選擇合適的代理模式
公開資料蒐集與分散式測試可評估 98IP 的動態住宅代理;需要更長期網路身分時,可比較黏性工作階段或靜態住宅代理。本文由 98IP 團隊發布並揭露服務關係,只應用於你有權存取的系統與資料。
官方參考
Requests Advanced Usage,查閱於 2026 年 8 月 16 日,包含代理字典、Session 與 urllib3 Retry 的說明。
結論:可靠性來自明確控制和可衡量結果,而不是無限重試。