購買代理方案前，如何估算每月頻寬容量

代理方案通常按 GB 銷售，但許多買家只用最終 HTML 內容大小估算容量，實際流量往往因此被低估。一個有效結果產生前，代理可能已承載請求標頭、上傳資料、重新導向、失敗回應、重試、壓縮資源、瀏覽器子資源與連線負擔。

更可靠的方法是從有效業務結果反推計費流量。目標不是用試算表精確預測帳單，而是形成透明的低位、預期與高位區間，再透過小規模、已獲授權的試行驗證，之後才決定是否購買更大方案。

計算位元組前先定義有效結果

先用一句話寫清楚什麼才算有效結果。例如：商品頁包含預期欄位且符合新鮮度；廣告驗證截圖來自指定市場；API 回應通過結構與完整性檢查。

連線成功、HTTP 200 或下載到文件都不一定有效。封鎖頁、同意畫面、錯誤語言、過期快取、截斷內容與空結構都可能消耗流量，卻沒有完成工作。

為每類工作負載記錄：

• 每月需要的有效結果數；
• 已獲授權的目標類別與市場；
• 用戶端類型：HTTP 程式庫、無頭瀏覽器或完整瀏覽器；
• 工作階段模式：逐請求輪換、有限黏性工作階段或靜態路由；
• 首次嘗試有效率；
• 每個結果允許的最大嘗試次數；
• 每次嘗試的預期請求與回應位元組；
• 重新導向、資源、上傳與失敗內容是否計費；
• 成長餘量與事故餘量。

瀏覽器與 API 工作負載應分開計算，兩者流量形態差異太大，不能以同一平均值代表。

使用「按有效結果反推」公式

對一個工作負載單元估算：

每月位元組 = 有效結果數 × 每個有效結果的嘗試次數 × 每次嘗試的計費位元組

再加入成長與安全餘量：

容量位元組 = 每月位元組 ×（1 + 成長率）×（1 + 安全餘量）

如果供應商合約沒有另行定義，十進位 GB 可按 位元組 / 1,000,000,000 換算。必須記錄後台使用十進位 GB 或二進位 GiB。

最重要的變數是每個有效結果的嘗試次數。首次有效率為 90% 時，平均嘗試次數不一定簡單等於 1 / 0.90；有上限的重試、終止型拒絕與相關性故障都會改變結果。應在試行中直接測量：

每個有效結果嘗試次數 = 全部計費嘗試 / 有效結果數

這個比例會直接暴露重試放大。

分層測量位元組

不要只相信一個應用程式計數器，至少記錄三層：

校準時，利用相同請求 ID 與時間區間對比三層資料。代理頻寬帳單核對指南提供受控核對流程。最終預測應採用供應商書面計費定義，其他計數器作為診斷依據。

分別建立 API 與瀏覽器模型

HTTP 或 API 蒐集

每次嘗試應納入請求標頭、請求內容、回應標頭、回應內容、重新導向，以及挑戰或錯誤內容。自動解壓縮可能讓應用程式緩衝區大於傳輸回應，必須刻意區分編碼後與解碼後大小。

瀏覽器蒐集

瀏覽器可能載入 HTML、指令碼、樣式、圖片、字型、影片、分析請求、API、Service Worker 更新與預先載入資源。因此，一張截圖消耗的流量可能是主文件的許多倍。

為已獲授權的工作建立必要資源清單。只有確認資源與輸出無關時才阻止載入；不能為節省流量而破壞同意機制、安全行為或應用邏輯。冷快取與熱快取應分開測量，隔離設定檔和輪換工作程序可能無法獲得相同快取收益。

建立低位、預期與高位情境

不要只做單點預測。為每個工作負載單元分別設定三組「每個有效結果嘗試次數」與「每次嘗試位元組」。

以一個已獲授權 API 工作為例：

若預期月成長為 15%，安全餘量為 20%，預期容量約為 56.64 × 1.15 × 1.20 = 78.16 GB。

這些數字只是範例，不是通用預設值。必須使用自己的合規工作負載測量；完整瀏覽器工作可能高出數個數量級。

分段計算後再加總

至少按下列維度拆分單元：

• 目標或端點類別；
• 區域與國家層級；
• 瀏覽器或 API 用戶端；
• 住宅、靜態住宅、行動或資料中心產品；
• 同時使用時的 IPv4 與 IPv6；
• 黏性與輪換工作階段策略；
• 尖峰與離峰時段。

最後再加總。全球平均值可能掩蓋一個關鍵小市場：它的回應更大，或重試率更高。每個關鍵單元都應保留高位或高百分位流量估計。

納入失敗流量，但不為規避限制編列預算

計算合法的暫時故障、閘道錯誤、已接收部分資料的逾時，以及有上限的重試。不要為反覆繞過目標站拒絕預留容量。403 或 429 應觸發停止或暫停策略，而不是無限輪換額度。

代理重試預算指南可限制多個工作程序的總嘗試次數；再搭配每個成功請求成本指南，避免便宜的 GB 單價掩蓋昂貴的無效結果。

執行校準試行

1. 為每個重要工作負載單元選擇具代表性的授權網址或 API 呼叫。
2. 先以低並行並關閉自動重試，測量首次嘗試流量與有效率。
3. 啟用規劃中的有限重試策略，測量每個有效結果的嘗試次數。
4. 依相同請求 ID 與時間區間蒐集應用程式、用戶端與供應商計數器。
5. 分開執行瀏覽器冷快取與熱快取測試。
6. 涵蓋所需區域與時間區間。
7. 將實測總量與預測比較，並修正假設。

不要從少量成功請求直接外推。應持續試行，直到高影響單元有足夠觀察值形成穩定區間。

採購檢查清單

• [ ] 有效結果定義不只 HTTP 狀態。
• [ ] API 與瀏覽器工作負載分開建模。
• [ ] 請求、回應、重新導向、上傳、失敗與重試流量均已納入。
• [ ] 供應商計費單位與計量邊界有書面記錄。
• [ ] 壓縮與快取行為固定。
• [ ] 每個有效結果嘗試次數來自測量，而非猜測。
• [ ] 按區域、產品、位址族與工作階段模式分段。
• [ ] 已計算低位、預期與高位情境。
• [ ] 成長與事故餘量分別列出。
• [ ] 持續執行重試上限與目標站停止訊號。
• [ ] 小規模試行已核對預測與供應商後台。
• [ ] 已審查超額單價、結轉、失效時間與最低承諾。

合規與安全

只預測與測試已獲授權的工作流程。遵守目標站條款、robots 指引、速率限制、隱私義務、保留規則與資料最小化要求。不得載入無關資源、重複被拒請求或輪換位址規避存取控制。容量規劃應減少浪費與意外，而不是增加未經批准的流量。

常見問題

網頁蒐集需要多少代理頻寬？

沒有通用數字。它取決於有效結果數、用戶端類型、頁面大小、重試、重新導向、快取、上傳、市場與計費規則。應測量代表性流量並採用區間。

可以按平均頁面大小估算嗎？

不建議。平均值會隱藏大型頁面與失敗放大。應分段計算，並為關鍵單元保留高位或高百分位情境。

更頻繁輪換會增加頻寬嗎？

輪換本身不直接增加負載，但額外握手、工作階段建立、重複驗證、失敗路由與應用程式重試可能增加流量。應在試行中比較不同策略。

應增加多少餘量？

根據成長不確定性、事故歷史、採購週期與超額風險決定。成長與安全餘量應作為兩個獨立假設，便於審查。