动态住宅流量套餐的用量怎么估：一个公式、三次采样、两条切换线

买按 GB 计费的动态住宅代理，最容易出错的一步不是选国家、选协议，而是估用量。多数人的做法是：打开目标页面看一眼「网页大小 1.2 MB」，乘以计划抓取的页数，得出一个数字，然后按这个数字买套餐。上线三天，额度见底。

差距不在算术，在于漏算的部分：上行的请求头和 Cookie、失败重试、重定向、无头浏览器加载的图片字体埋点、每次换 IP 的 TLS 握手。把这些补齐，估算值和账单才能对上。

先把公式立起来

可直接套用的模型是这样的：

总流量 = 目标任务数 × 单任务请求次数 ×（单次平均上行 + 单次平均下行）×（1 + 重试与重定向率）×（1 + 冗余系数）

几个要点：

代理计费统计的是通过代理通道的双向总字节，包括客户端发出的请求行、请求头、Cookie，以及服务端返回的响应头和响应体。只算「网页大小」等于只算了其中一半的一部分。
单任务请求次数常被低估。抓一个商品详情页，看起来是 1 次请求；实际可能是主文档 + 若干 XHR 接口 + 一次重定向 + 一次登录态校验。用无头浏览器时这个数字可能是几十上百。
冗余系数不是保险费，是必需项。payload 会随目标站改版波动，协议握手开销随会话策略变化，行业通行做法是留 20%~30%。

公式本身不难，难的是里面「单次平均上行/下行」这两个数你怎么拿到。

单次请求大小：量级差在几十倍

同样抓一个页面，请求方式不同，流量能差两个数量级。

纯接口 / 纯 HTML 抓取（Requests、cURL、Go 的 http 客户端）：只下载主文档或 JSON 响应，不执行 JavaScript、不加载子资源。价格监控、SERP 排名抓取、库存查询这类任务，单次下行常见落在 20 KB ~ 100 KB。搜索结果页这类 HTML 较重的会到 200~300 KB。

无头浏览器完整渲染（Playwright、Puppeteer 且未做资源拦截）：主文档只是开头，后面跟着 JS 依赖包、CSS、Web 字体、商品图、视频预览、第三方统计 SDK。单页流量普遍 1 MB ~ 3 MB，图片密集的电商详情页更高。

无头浏览器 + 资源拦截：在路由层面拦掉 image、media、font、stylesheet 和第三方埋点域名，通常能砍掉 70%~90% 的无效下行，单页回落到 100 KB ~ 300 KB 量级。

这条是流量控制里性价比最高的一步。前提是确认目标站的关键数据不是从被拦截的资源里来的——有些站点把价格渲染在 canvas 或背景图里，拦了图片就拿不到数据，这种情况只能放行特定域名的图片。

三种采集方式单次请求流量量级对比

上行也要算。 单次上行通常只有 1~5 KB（请求行、User-Agent、Accept 系列头、Cookie），看着不起眼，但带完整登录态 Cookie 的请求上行能到 10 KB 以上；如果任务是 POST 提交表单或上传，上行可能反超下行。请求密集但响应轻量的接口采集，上行占比会明显高于直觉。

压缩要打开。 客户端发 Accept-Encoding: gzip, br，服务端返回压缩内容，代理通道上跑的是压缩后的字节，HTML 和 JSON 的压缩率通常很可观。有些自写客户端默认不带这个头，或者拿到压缩响应处理不了就干脆关掉——这等于白白多花几倍流量。上线前用抓包确认一遍实际传输的是压缩流。

用基准采样拿真实数字，别用估的

拍脑袋填公式没有意义。正确顺序是先跑一轮基准采样：

用和生产完全一致的技术栈。生产用 Playwright 就用 Playwright 采样，别用 cURL 采样、上线换浏览器，两者差几十倍。会话策略（轮换还是粘性）、协议（HTTP/HTTPS/SOCKS5）、并发数也要对齐。
按页面类型分别采样。列表页、详情页、搜索页、接口，各自的体积分布完全不同，混在一起取平均会同时高估轻量任务、低估重页面。
每类采 50~100 次真实请求，不要只测三五个。目标站不同类目、不同商品的页面体积差异很大。
取中位数和 P90，用 P90 进公式。用平均值容易被少数超大页面拉偏，用 P90 做规划更贴近真实账单。
数据从代理侧读，不要只看客户端。以代理出口的双向字节统计为准，客户端自己算的 len(response.content) 不包含响应头、TLS 握手和被拦截前已经下载的部分。具体统计粒度（能否按会话、按域名看）各家面板不一样，采样前先确认你能拿到什么维度的数据。

采样跑完，你手里就有了每类页面的「单次上下行合计」，这是整个估算里唯一不能靠猜的输入。

两个容易吃掉预算的放大器

重试与重定向

遇到验证码页、限流响应、403 阻断时，客户端会重试。每一次重传都是一次完整的请求流量，而且失败页往往还带着一个几十 KB 的挑战页面响应体。更麻烦的是重试策略写得激进：没有指数退避、失败立刻重发、重试上限设成 5 次，一个持续失败的目标能在几分钟内烧掉可观的额度。

实操上，把失败率按 20% 计入，即公式里乘 1.2~1.3，是一个稳妥的起点。如果目标站防护较强，先跑一周把真实失败率测出来再定。同时建议：

重试用指数退避，并设硬上限；
对明确的 4xx（比如 404、410）不重试；
命中验证码或阻断时优先换出口、换会话，而不是原样重发。

会话策略带来的握手开销

每建立一条新的代理连接就有一次 TCP + TLS 握手，加上目标站可能重新下发 Cookie 或先返回一个校验页。高频轮换的单请求场景，握手和校验开销占比会比你想的高；而在粘性会话里连续跑多个请求，连接复用能把这部分摊薄。

这不意味着粘性一定更省——粘性会话适合需要保持登录态或多步流程的任务，纯并发抓取用轮换更合适。只是估算时要意识到：会话策略换了，单次平均流量也会跟着变，采样必须用最终要上线的那套策略。

关于接入方式对会话行为的影响，可以参考《API提取代理IP与账号绑定IP的具体区别？4点对照》。

两个算例

算例一：SERP 监控

每天 5000 个关键词，每个关键词抓 1 个结果页，纯 HTML 请求。采样得到下行 P90 约 250 KB，上行约 3 KB。目标站有验证码，实测失败重试率 25%，冗余取 20%。

5000 × 1 × (250 + 3) KB × 1.25 × 1.2 ≈ 1.9 GB / 天
月用量 ≈ 57 GB

算例二：电商详情页采集

每天 10000 个详情页，用无头浏览器。

未做资源拦截，单页 P90 约 2 MB：

10000 × 2 MB × 1.2 × 1.2 ≈ 28.8 GB / 天 ≈ 864 GB / 月

做了图片、字体、媒体、统计脚本拦截后，单页降到 300 KB：

10000 × 0.3 MB × 1.2 × 1.2 ≈ 4.3 GB / 天 ≈ 130 GB / 月

同一个业务，一行拦截规则的差别就是六倍多的账单。所以估算之前先做优化，再拿优化后的数字去买套餐，而不是反过来。

什么时候按流量就不划算了

估算做完，你会得到一个月用量数字。这个数字本身也是选型信号。

继续用按流量计费的动态套餐，如果你的任务符合这些特征：

单次 payload 小——JSON 接口、轻量 HTML、SERP 页面；
请求分散，跑跑停停，不是全天满负荷；
需要大量不同出口 IP，轮换频繁，单个 IP 上的请求量不大；
有明确的每日额度上限，希望成本可控可预测。

这类场景按 GB 付费的边际成本是划算的，用多少算多少。

该转向按带宽计费的不限流量方案，如果出现下面任一情况：

7×24 小时高并发持续跑，出口几乎不空闲；
采集对象是富媒体——图片批量下载、视频抓取、必须完整渲染且无法拦截资源的页面；
估算月用量已经大到按 GB 算不过账，或者用量波动大到无法预算；
单位时间吞吐才是瓶颈，你更关心并发能跑多少，而不是总共传了多少。

判断方法很直接：把估算出的月用量分别按两种计费口径折算成成本，看哪边低；同时看你的任务是「总量型」还是「吞吐型」。总量型看 GB，吞吐型看带宽。

NexIP 这两类都有：动态住宅流量套餐按流量计费，支持轮换和粘性会话，适合请求分散、payload 较轻的采集与监控；动态住宅带宽套餐按带宽计费、不限流量，适合长期高并发或富媒体传输。两者都支持 API、账密、端口转发、进程代理接入，HTTP/HTTPS/SOCKS5 与账密或白名单认证，采样阶段用哪种接入方式，上线就保持一致，避免会话行为变化导致估算失真。

注意：这两类都是共享出口的动态方案。如果你的任务需要独占固定 IP（比如店铺后台、社媒账号绑定），那是静态短效或长效 IP 的范畴，计费逻辑完全不同，不适用本文的流量估算模型。独享与共享的成本对比可以看《采集数据用独享IP还是共享IP划算？按任务类型分档》。