在一个按 GB 的住宅代理套餐上，带宽是你所购买的单位，所以选对套餐归结为一个问题：一个月里你实际会用掉多少吉字节？估得太低，你会在月中撞上超量或限流；估得太高，你就为一份自己从不触碰的余量多付钱。好消息是，带宽是可估算的，不是一个谜。有了一个公式、一些真实的每页大小，以及一次五分钟的测量，你就能有把握地给套餐定档。
这份指南是给规划代理用量的团队的。我们会一步步搭起这个估算、把它锚定在一次真实测量上，并对常见工作负载走一遍算例。
公式
一切都归结为这个：
每月 GB ≈ (每月请求数 × 平均响应大小 × 开销系数) / 每 GB 字节数四个输入，其中一个占主导。我们按影响力的顺序来看。
第 1 步：平均响应大小（大头驱动因素）
每个请求回来多少字节，是估算成败之所在，而它会因你如何抓取而波动超过 10 倍。典型范围：
| 你抓取的是什么 | 每个请求的典型大小 |
|---|---|
| 精简的 JSON API 响应 | 5 到 50 KB |
| 仅 HTML 页面（不含资源） | 100 到 500 KB |
| 无头浏览器里的完整页面（图片、CSS、JS、字体） | 1 到 5 MB+ |
你账单上单条最大的因素，是你渲染一个完整浏览器、还是直接抓取 HTML/JSON。浏览器会下载页面上的一切；一个简单的 HTTP 请求只拉取其中的一小部分。如果你能从 HTML 或一个 API 里取到数据，你的每请求大小，以及你的带宽，就会下降一个数量级。（那一点，加上拦掉资源，正是如何削减代理带宽成本的核心。）
如果能测量，就别去猜这个数字，见第 4 步。
第 2 步：每月请求数
这通常是页数（或记录数）乘以频率：
每月请求数 = 条目数 × 每天检查次数 × 30一个每天检查一次、追踪 10,000 个产品的价格监测器，是 10,000 × 1 × 30 = 300,000 每月请求。一次性的数据集构建就只是总页数，没有频率乘子。把翻页算进去：如果每个”条目”横跨三页结果，就相应地乘。
第 3 步：开销系数
真实的爬取不是 100% 高效的。重试、重定向和失败的尝试都会穿过代理、也都会花掉带宽，一个被封或超时的请求照样花了字节。在你干净的估算之上加一个开销系数：
- 简单、开放的目标： ~1.1（10% 开销）
- 典型站点： ~1.2（20%）
- 防守森严的目标（频繁封锁/重试）：~1.3 或更高
目标越难，重试越多，系数就越高。降低你的封锁率（更好的 IP 质量、明智的节奏）会直接把它缩小，见如何避免被封。
第 4 步：测量你真实的每页大小（别猜）
通往一个可信估算的最快路径，是经由代理抓取一份你真实目标的有代表性样本，并测量字节数。以字节计的响应大小就是 len(response.content)：
import os, requests, statistics
USER, PASS = os.environ["SHIFTER_USER"], os.environ["SHIFTER_PASS"]proxy_url = f"http://{USER}-country-us:{PASS}@p.shifter.io:443"proxies = {"http": proxy_url, "https": proxy_url}
sample_urls = [ ... ] # 20-50 个有代表性的目标 URLsizes_kb = []for url in sample_urls: r = requests.get(url, proxies=proxies, timeout=30) sizes_kb.append(len(r.content) / 1024)
avg_kb = statistics.mean(sizes_kb)print(f"avg {avg_kb:.0f} KB/request (n={len(sizes_kb)})")对着 20 到 50 个真实 URL 跑一遍，你就有了一个有根据的平均大小，而不是一次猜测。注意这测的是真正穿过代理的压缩后字节（保持 Accept-Encoding 开启），而那正是你被计费的部分。完整的客户端配置见用 Python 使用住宅代理。
算例
使用 每月 GB = 请求数 × 平均大小 × 开销 / 1,000,000（KB 到 GB，十进制）：
价格监测，仅 HTML。 10,000 个产品，每日，~200 KB/页，开销 1.15。
300,000 × 200 KB × 1.15 = 69,000,000 KB ≈ 69 GB/月。
同样的任务，但用完整浏览器渲染。 ~2 MB/页，而不是 200 KB。
300,000 × 2,000 KB × 1.15 = 690,000,000 KB ≈ 690 GB/月。
同样的数据，10 倍的带宽，这就是在你本不需要时去渲染的代价（若必须渲染，见用 Playwright 拦掉资源）。
搜索/排名监测，精简响应。 500 个查询，每天 4 次，各 ~30 KB，开销 1.2。
500 × 4 × 30 × 30 KB × 1.2 = 2,160,000 KB ≈ 2.2 GB/月。 又小又便宜。
一次性数据集构建。 2,000,000 个页面，~300 KB HTML，开销 1.2。
2,000,000 × 300 KB × 1.2 = 720,000,000 KB ≈ 720 GB，一次性，不是每月。
规律很清楚：响应大小和渲染选择占主导；请求数线性增长；开销是一个不大的乘子。
从估算到套餐
用一点纪律把这个数字变成一个套餐：
- 加一个缓冲。 把套餐定到你的估算再加 20 到 30%，用于月内的增长和估算误差。在周期中途用光，比留一点余量更具破坏性。
- 搞清超量条款。 查一下你的供应商如何处理超量，额外的按 GB、限流，还是硬性中止，好让一个繁忙的月份不至于让你措手不及。
- 每周对账。 在周期早期就把实际用量与你的估算相比较并调整。真实用量教会你自己真正的每页大小和封锁率，比任何猜测都快。
- 在买更多之前先缩小这个数字。 往往最便宜的吉字节就是你不花的那个，能不渲染就不渲染、拦掉资源、别重新抓取未变化的页面（削减代理带宽成本），再去把套餐加大。这就是让效率有回报的按 GB 模型（按端口计费的时代已经过去）。
常见问题
如果我从没跑过这个任务，怎么估算带宽？ 经由代理测量一份你目标页面的有代表性样本（第 4 步），得到一个真实的每请求大小，然后把它连同你的请求数和一个开销系数代入公式。一份测过的样本，胜过任何通用估算。
什么最耗带宽？ 完整的浏览器渲染，遥遥领先，它会下载每一张图片、字体和脚本。直接抓取 HTML 或一个 JSON API，可以把每请求大小削减 10 倍。渲染的选择，是你账单上最大的杠杆。
失败和重试的请求会算进我的带宽吗？ 会。任何穿过代理的请求都会用掉带宽，包括封锁、重定向和重试。这正是为什么估算里包含一个开销系数，也是为什么降低你的封锁率能降低成本。
1 GB 是 1,000 MB 还是 1,024 MB？ 这取决于供应商的计费定义，十进制（1,000）还是二进制（1,024）。差别大约是 7%，用来估算没问题，但当你定档接近某个套餐边界时，确认一下你的供应商用的是哪种。
我该加多少缓冲？ 按你的估算再加 20 到 30% 来规划，以吸收月内的增长和估算误差。然后对着真实用量对账并调整，而不是一开始就买太多。
底线
估算住宅代理带宽不是靠猜：把请求数乘以一个测量得来的平均响应大小和一个开销系数，换算成 GB，再加一个缓冲。最能左右这个数字的两件事，是你如何抓取（HTML/JSON 大约以 10 倍胜过完整浏览器）和你重试得多频繁（更好的 IP 质量意味着更少浪费的字节），所以在承诺之前先测量一份真实样本，并在买更多之前先把这个数字压下来。
一旦你有了估算，定价页面列出了按 GB 的套餐，让你能把一个档位对上你的数字加缓冲，并把一个调优良好的抓取器指向住宅 gateway，好让实际用量贴近套餐。