如何稽核代理公平使用政策，避免隱藏限制拖慢正式環境

「無限流量」不一定等於無限正式環境容量。代理方案仍可能設定公平使用門檻、單一連接埠吞吐上限、同時連線限制、目標限制、滾動時間窗或人工審查。即使是按流量計費的住宅代理，重試、瀏覽器資源與失敗回應也可能消耗可計費流量。

採購時最重要的問題不是「方案是否無限」，而是：量測哪一種資源、使用哪個時間窗、跨過各門檻後究竟會發生什麼？ 本指南把這個問題轉換成適用於合規代理工作負載的採購與營運稽核流程。

測試前建立限制清單

要求供應商說明所有可能降低、暫停或重新計價服務的控制項，並把答案寫入訂單或服務附件，而非只留在銷售對話中。

清單至少應涵蓋：

• 上行與下行中哪些流量會被計入；
• 使用十進位 GB 或二進位 GiB；
• 每月、每日、每小時及滾動時間窗門檻；
• 帳號、區域、連接埠與單一 IP 限制；
• 連線、請求與瀏覽器工作階段並行量；
• 達到門檻前後的吞吐上限；
• 自動超額、錢包扣款、加購與硬停止規則；
• 失敗回應、重試、重新導向與資源檔是否計費；
• 未使用流量是否到期或結轉；
• 通知管道與預警門檻；
• 暫停、恢復及申訴流程。

如果政策只寫「合理使用」，應要求供應商提供目前實際門檻，以及門檻變更時的通知程序。

區分五種容量

單一「頻寬」數字可能掩蓋完全不同的限制，應分開觀察以下面向。

不限資料量不保證不限吞吐或並行；較高並行上限也不表示出口池能在失敗率不升高的情況下承受該負載。

定義計費分母

試用前建立自己的用量模型，至少記錄：

operation_id
attempt_id
started_at_utc
proxy_product
zone_alias
target_class
request_bytes
response_bytes
status_class
content_valid
retry_reason
first_attempt_success
eventual_success

記錄中不得保存代理密碼、Cookie、權杖或不必要的完整目標網址。

至少計算三個指標：

wire_bytes = request_bytes + response_bytes
bytes_per_valid_result = total_wire_bytes / valid_results
retry_overhead = retry_wire_bytes / total_wire_bytes

供應商後台是計費依據，自有量測則是對帳控制。兩者可能因協定開銷、壓縮前後口徑、部分回應或進位方式而有差異，合約應說明量測點。

對帳供應商後台與本地量測

在授權範圍內，以已知回應大小執行小規模傳輸測試。測試前後記錄供應商用量，並考量其公開的統計延遲。

建議步驟：

1. 暫停測試區域中的其他流量；
2. 記錄後台時間、時區與目前用量；
3. 透過目標協定傳送固定請求集；
4. 記錄應用層位元組、代理嘗試與有效結果；
5. 等待供應商說明的彙整週期；
6. 匯出或保存更新後的用量；
7. 計算絕對差值與百分比差值；
8. 分別加入一次失敗回應、一次重試與一次瀏覽器導覽後重複測試。

少量差異不能直接證明計費異常。應先排查進位、統計延遲、通道開銷與瀏覽器子資源，並只以可重現且已去識別化的證據升級問題。

以分階段負載測試軟上限

不要等到客戶工作負載執行時才發現限速。應使用測試帳號或經核准的低風險時段，逐級增加用量。

每個階段維持相同目標組合，並量測：

• 閘道連線成功率；
• 首次嘗試有效結果率；
• 吞吐量中位數與 p95；
• 首位元組時間中位數與 p95；
• 使用中連線數與排隊時間；
• 出口地區可用性；
• 黏性工作階段存活情況；
• 供應商回報的消耗量。

條件允許時，可在 20%、50%、75%、85%、95% 及略低於公開門檻的階段比較。除非供應商授權測試且財務風險已封頂，否則不要主動跨過硬限制。

如果服務仍可連線，但跨過某個用量邊界後吞吐、並行、位址池權限或支援優先順序改變，就可能存在軟上限。記錄首次出現具有統計與業務意義變化的階段。

驗證預警與耗盡行為

合格方案應給營運人員足夠反應時間。需要驗證或取得以下證據：

• 第一次預警門檻；
• 電子郵件、Webhook 或後台通知方式；
• 資料回報延遲；
• 接收者與升級設定；
• 額度耗盡時間預測；
• 加購是否立即生效；
• 是否自動進入超額計費；
• 既有黏性工作階段是否會終止；
• 付款或續費後的恢復時間；
• 硬停止是否安全關閉，而不是靜默繞過代理。

內部告警應早於供應商告警。例如：50% 檢查預測、75% 通知負責人、85% 降低負載或按核准加購、95% 進入事故門檻。實際數值需依方案與流量波動調整。

建立消耗速率預測

每月平均值無法及時發現重試風暴。應同時使用短時間窗與長時間窗預測剩餘容量。

short_rate = bytes_used_last_hour / 1 hour
long_rate = bytes_used_last_24_hours / 24 hours
hours_remaining_short = remaining_bytes / short_rate
hours_remaining_long = remaining_bytes / long_rate

即使長時間窗預測安全，只要短時間窗顯示會在下一次有人值守前耗盡，就應告警。依工作負載、市場、代理產品與重試原因拆分用量，才能削減正確的流量。

控制重試與瀏覽器放大

額度事故往往是其他故障的結果。攔截頁、大型媒體回應或同步重試迴圈可能在月度後台反應前成倍消耗流量。

應實施：

• 限制每個業務操作的嘗試次數；
• 使用含抖動的指數退避；
• 遵守目標明確回傳的限流訊號；
• 不重試政策拒絕及無效憑證；
• 測試允許時阻擋不必要的圖片、影片與字型；
• 下載大型次要資源前先驗證正文；
• 為每個工作負載設定獨立預算；
• 禁止直接連線回退，避免額度耗盡後流量繞過代理。

應量測每個有效結果成本，而不只看每 GB 單價。無法產生有效結果的便宜流量並不經濟。

把變更控制寫入合約

公平使用規則可能改變。採購時應爭取：

• 門檻或量測方式變更的提前通知；
• 可追溯版本的政策封存；
• 計費爭議聯絡人；
• 可匯出的用量資料；
• 明確申訴期限；
• 關閉自動超額的權利；
• 最高費用上限；
• 重大變更後的降級或退出權。

續約時，以及供應商調整價格、產品名稱、網路架構或後台量測器時，營運負責人都應重新稽核政策。

採購驗收清單

• [ ] 所有量測資源與時間窗均已書面確認。
• [ ] 「無限」已與吞吐、並行及位址池權限分開。
• [ ] 已定義一般流量、失敗流量、重試與協定開銷。
• [ ] 已用受控測試對帳本地與供應商量測。
• [ ] 已驗證預警門檻、接收者與通知延遲。
• [ ] 已在財務風險受控條件下測試軟上限。
• [ ] 自動超額可以關閉或封頂。
• [ ] 額度耗盡不會觸發不安全的直接連線回退。
• [ ] 已啟用工作負載級預算與重試上限。
• [ ] 用量匯出和政策版本不會保存秘密資訊。
• [ ] 升級與爭議流程已有文件。
• [ ] 重大政策變更會觸發複審或退出權。

相關控制可繼續閱讀 98IP 的每個成功請求成本指南、代理並行爬坡測試與獨立 SLA 驗證指南。

常見問題

無限代理流量是否代表沒有公平使用政策？

不一定。方案可能不按 GB 收費，但仍保留吞吐、同時連線、目標、連接埠或滾動時間窗限制，應索取完整限制表。

本地位元組數必須與供應商後台完全一致嗎？

通常不會完全一致。量測點、通道開銷、進位與統計延遲都會造成差異。應先定義容許範圍，再調查超出範圍的變化。

額度耗盡後應如何處理？

應事先選擇：經核准加購、封頂超額、削減非關鍵工作負載或硬停止。絕不能讓應用程式靜默繞過代理並暴露非預期網路路徑。

如何比較無限方案與計量方案？

在相同授權工作負載下比較有效結果、尾端延遲、可用吞吐、故障行為與總成本。計費標籤本身不是效能指標。

合規說明

代理容量只應用於合法且已獲授權的目標與資料。遵守目標條款、robots 指令、速率限制、同意要求、隱私法律與供應商政策。不得利用更高額度、並行或路由輪替規避存取決定、隱藏遭禁止的活動或蒐集受限資訊。用量匯出與支援證據中不得包含憑證及個人資料。