購買更多代理流量前，如何稽核頻寬計費
代理後台顯示的流量常高於應用程式認為自己下載的資料。這不一定表示計費錯誤。應用通常只計算最終回應載荷，代理服務可能計算請求、回應、HTTP 標頭、失敗嘗試、重新導向、上傳及通道兩側流量；壓縮與自動重試還會擴大差距。
正確問題不是兩個數字為何沒有完全相同，而是能否透過獨立、受控、可重現的實驗解釋供應商計費量。
同時定義三種位元組計數
不要只以最終檔案大小對照後台。必須針對同一 UTC 時段保存三層資料。
應用載荷位元組
指應用主動傳送或消耗的請求本文與壓縮回應本文，往往不含 HTTP 標頭、連線建立、重新導向及程式庫隱藏的重試。
代理線路位元組
包含 HTTP 標頭、通道協商、加密記錄、上傳、重新導向鏈、重試與失敗回應，是最適合與流量型產品對照的獨立數值。
供應商計費位元組
指等待官方說明的統計延遲後，後台或 API 顯示的用量差值。必須同時記錄產品、閘道、區域、單位，以及是否同時計費上行與下行。
核心比率為：供應商計費位元組 ÷ 獨立測得的代理線路位元組。
建立有邊界的測試環境
測試目標必須是自有或明確獲准的系統。準備兩個可預測端點：一個壓縮與未壓縮大小已知的靜態物件，以及一個只產生一次已記錄重新導向的小型端點。
以單一併發和一個黏著代理工作階段執行。關閉應用重試、預先擷取、背景 Worker 與平行下載，固定客戶端版本、User-Agent、代理協定、位址族與閘道區域。
第一輪測量乾淨傳輸，第二輪確認重新導向流量是否依預期計入。
主動控制壓縮
壓縮是常見誤判來源。未壓縮為 20 MB 的內容，在線路上可能只使用其中一部分；應用也可能回報解壓後大小，而供應商計算壓縮傳輸與協定開銷。
分別執行關閉壓縮與固定壓縮方式的測試，記錄 Content-Encoding、宣告長度與實際載荷。不可混合不同編碼行為的結果。
排除隱藏重試
許多 HTTP 程式庫會自動重試連線重設、特定狀態碼或冪等請求。瀏覽器自動化也可能重新請求導覽資源，而商業層日誌看不到所有嘗試。
稽核期間應：
- 將重試設為零；
- 固定連線與讀取逾時；
- 記錄代理連線數與 HTTP 請求數；
- 第一次意外失敗即停止；
- 只保存去識別化請求編號與位元組總量。
若零重試實驗可以對齊而生產用量無法對齊，更可能是營運放大問題。購買流量前先檢查代理重試風暴防護。
區分 GB 與 GiB
1 GB 為 1,000,000,000 位元組，1 GiB 為 1,073,741,824 位元組，差距約 7.4%，不是兩倍。單位轉換只能解釋有限偏差，不能單獨解釋穩定翻倍。
分開測量上行與下行
部分產品對兩個方向都計費。下載型工作仍會上傳請求標頭、Cookie、POST 資料、驗證交換及通道資料。
至少記錄客戶端到閘道位元組、閘道到客戶端位元組、成功與失敗回應數、重新導向數及連線數。若後台只有合併總量，應先將兩個方向的線路計數相加。
重複三次獨立實驗
單次結果可能受統計延遲或連線重用影響。使用互不重疊的時段至少重複三次，每次等待供應商公布的彙總延遲。
每個時段保存 UTC 起訖時間、去識別化工作階段標籤、產品與閘道區域、協定與 IPv4/IPv6、物件識別、應用載荷、線路上下行位元組、後台起訖計數，以及請求、重新導向、重試和失敗數量。
證據中不得保存代理密碼、驗證標頭、Cookie 或原始工作階段權杖。
解讀結果
差距小且穩定：通常來自 HTTP 標頭、TLS 記錄、通道建立與測量邊界，應納入成本模型。
差距隨重新導向或失敗增加：代表請求被放大，應檢查重新導向、重試、逾時與錯誤回應本文。
只在瀏覽器自動化出現：檢查次要資源、Service Worker、預先擷取、遙測與背景請求。
長期接近固定倍數：核對雙向計費、單位及後台範圍；若仍無法解釋，要求供應商針對一個精確時段書面對帳。
後台資料移到時段外：停止傳送新流量，只延長觀察，把統計延遲與位元組計算分開。
公平比較供應商
對每個候選供應商執行相同測試，保持目標、客戶端、時段、區域、協定與工作階段模式一致。比較每個有效結果的成本，而非宣傳的每 GB 價格。
低單價若伴隨高失敗率、重試或工作階段不穩，實際成本可能更高。可搭配代理池 ASN 集中度稽核與住宅代理工作階段黏著度測試。
採購檢查清單
- [ ] 上下行計費方向有書面說明
- [ ] 明確採用 GB 或 GiB
- [ ] 失敗請求與重新導向規則清楚
- [ ] 後台統計延遲已知
- [ ] 可依時段匯出用量
- [ ] 測試期間重試已關閉
- [ ] 壓縮行為固定
- [ ] 載荷與線路位元組分開測量
- [ ] 三個時段結果穩定
- [ ] 客服可書面對帳一個精確時段
FAQ
TLS 開銷會等於載荷大小嗎？
通常不會。大型傳輸的 TLS 與通道開銷比例較低，但大量小請求與短連線會讓其更明顯。
輪換代理會增加計費流量嗎？
輪換本身不產生載荷，但頻繁建連、失敗出口、重複驗證及應用重試會增加總量。輪換與黏著工作階段應分開測試。
後台顯示兩倍就一定錯誤嗎？
不能只依倍數判斷。先確認應用是否只計算下載，而服務計算雙向和全部嘗試，再以線路計數進行受控比較。
應向客服提供什麼？
提供 UTC 時段、產品、閘道、去識別化工作階段標籤、請求數及三組位元組資料。不要傳送密碼、Cookie、驗證標頭或可用代理網址。
合規說明
只對自有或獲准系統執行頻寬測試，限制流量、遵守速率要求，並將日誌最小化與去識別化。計費稽核是測量流程，不是製造人為負載或繞過目標網站存取決定的理由。