NexIP官方博客
两种模式的分界线其实很朴素：你的每次请求传多少字节，是不是可预估，跑得稳不稳定。
- 单请求体积小（几 KB 到几十 KB）、任务间歇性、峰谷差大 → 按流量（GB）计费更划算，不跑就不花钱。
- 单请求体积大（整页渲染、媒体资源）、7×24 持续吞吐、并发稳定 → 按带宽计费更划算，支出封顶，不会出现意外账单。
难的地方在于，很多人对"自己一次请求到底传了多少"的估计会偏低一到两个数量级。所以真正要做的不是比价格表，而是先把自己的负载量出来。
两种口径分别在算什么
按流量计费，计量单位是客户端和目标服务器之间经由代理传输的出入站总字节数。这里有几个容易被忽略的细节：
- 上行和下行通常都计。POST 大 body、上传文件同样吃额度。
- 失败的请求照样计。超时前已经传回的部分、403 页面、验证码页面，字节都走了代理。
- 重试是乘数。重试率 30% 意味着账单直接多三成。
按带宽计费，计量单位是分配给你的峰值传输速率（Mbps，或者以固定通道/并发数的形式给出），在约定周期内不限制总传输量。你买的是一条管子的粗细，不是一桶水的体积。管子多粗决定了你的天花板，桶里装多少不再收钱。
把这两句话换成成本表达：按流量计费的成本随业务量线性增长，边际成本恒定；按带宽计费是固定成本，业务量越大单位成本越低，但到了速率上限就是硬顶。
先测三个数：单请求体积、请求总数、重试率
月消耗流量的估算式很简单：
月流量 ≈ 单请求平均传输体积 × 预估月请求数 × (1 + 失败重试率)
三个数里，第一个最容易估错。
用 requests/httpx 直接拿 HTML，一个商品页可能就几十 KB；换成 Playwright 或 Puppeteer 做完整渲染，图片、字体、JS bundle、追踪脚本、广告位全都会被加载一遍，单页轻松到几 MB。同一个目标站，两种取数方式的流量差距可以是 50 倍以上。再乘上并发和重试，按 GB 计费的账单就是指数级往上走。
怎么测准：
- 浏览器 DevTools 打开 Network 面板，跑一次目标页面，看底部的 Transferred 总量（不是 Resources 的解压后大小）。这是最快的粗估。
- 脚本内统计，在代理会话上累加每次响应的实际字节数（含头部），跑 200～500 次真实请求取平均，比单次采样靠谱得多。
- 用服务商面板对账。开一个小额度，只跑这一类任务半天，拿面板显示的用量除以你日志里的请求数，得到的是"真实到手口径"，包含了你在代码里统计不到的那部分开销。
重试率这个数也要从真实日志里拿，不要拍脑袋填 5%。如果最近成功率在往下掉，重试率会悄悄把流量账单推高一截——这种情况下先别急着换套餐，先分清是出口的问题还是目标站的问题，否则换成带宽套餐只是把超支换成了排队超时。
三个数拿到之后，把折算出来的月流量成本和同等能力的带宽套餐成本放一起比。结论通常很干脆：如果流量折算成本明显高于固定带宽套餐，或者业务本身就是全天不停机的持续吞吐，带宽套餐更合适；如果任务是每天跑两小时、每周跑一次，或者有明显的活动期峰谷，流量套餐的灵活性更值钱。
选了流量计费，工程上要做流量瘦身
按 GB 付费的场景里，省钱是能写进代码的：
- 拦截非必要资源。用无头浏览器时，在路由层把 image、media、font、stylesheet 类型的请求直接 abort。对于只取文本和结构化数据的采集任务，这一步常常能砍掉大半流量。
- 能不渲染就不渲染。先判断目标数据是否藏在某个 XHR/JSON 接口里，能直接打接口就别整页加载。
- 开压缩。确保请求头带上
Accept-Encoding: gzip, br，文本类响应压缩后体积差别很大。 - 控制重试。给重试加指数退避和次数上限，对确定性失败（404、明确的封禁页）不重试。
- 区分任务类型走不同出口。轻量文本抓取和需要整页渲染的任务，没必要共用一套计费口径。
具体到各语言客户端怎么挂代理、怎么在 Playwright 里做资源拦截，可以参考住宅代理接入 Python 采集脚本的配置写法。
选了带宽计费，要提前处理并发和突发
不限流量不等于不限速度。带宽套餐的风险点在另一头：
- 峰值速率是硬约束。瞬时并发连接数拉太高，或者单个连接长时间占满管道，表现出来就是排队、丢包、延迟飙升、大量超时。超时又会触发重试，重试再挤占带宽，形成恶性循环。
- 工程端要主动限流。用队列控制在途请求数，用连接池复用连接，发压曲线尽量平滑而不是每小时整点一起冲。宁可把并发压在带宽上限的七八成，也不要跑满。
- 突发怎么处理要问清楚。超出分配带宽时是排队限速、直接拒绝连接，还是阶梯额外计费，各家策略并不一致，以你购买的套餐服务协议为准。这一条在下单前确认，比事后排查值钱得多。
有一类需求根本不在这道二选一里
如果你要做的是给店铺后台、社媒账号、广告账户配一个长期不变的出口，那么关心的重点既不是 GB 也不是 Mbps，而是这个 IP 是不是独占、会不会中途变、失效了怎么换。这类需求对应的是按 IP 和时长计费的静态资源：短效按小时或天，适合临时核验、短期任务；长效按月或年，适合需要稳定绑定的账号和后台。
静态住宅 IP 还要再分家宽原生、家宽广播和数据中心三种，风控侧看到的信息不一样，用途也不一样。TikTok 这类对出口敏感的运营场景，官方建议的是静态家宽原生 IP。绑定之前该验哪些字段，可以对着店铺后台绑定静态住宅IP前要验哪几项逐条过一遍。
换句话说，先定"轮换还是固定"，再定"流量还是带宽"。顺序反了会浪费时间——SERP 监控这类任务的完整选型顺序，这篇展开讲过。
到哪一步去选
把上面的判断收一下，到 NexIP 这边对应的是两个入口：
- 请求离散、体积可控、要按用量付费、需要轮换或粘性会话 → 动态流量套餐，按流量计费，会话可轮换也可保持粘性。
- 持续高并发、整页渲染或媒体资源占比高、要把支出做成固定成本 → 动态带宽套餐，按带宽计费，不限流量。
两类都支持 API 提取、账密、端口转发、进程代理接入，协议覆盖 HTTP/HTTPS 和 SOCKS5，认证可以用账密也可以用白名单。认证方式怎么挑，看账密认证和白名单认证怎么选。
到手之后怎么验
别直接把生产任务全量切过去。建议按这个顺序走：
- 小额度跑样本。用真实脚本、真实目标站跑几百到上千次请求，记录自己日志里的请求数和成功率。
- 和面板用量对账。用面板显示的消耗除以你的请求数，得到真实的"每请求平均流量"。这个数和你前面估的差多少，决定了套餐要不要重选。
- 设额度告警。流量套餐一定要配告警阈值，代码里的一个死循环或者重试风暴，能在几小时里烧掉一个月的量。
- 带宽套餐压一次峰值。把并发按阶梯往上加，记录延迟和超时率开始恶化的那个并发数，把生产并发设在它下面留出余量。
- 持续盯每千次请求流量。这个指标一旦异常上涨，通常意味着目标站改版加载了更多资源，或者你的拦截规则失效了。
最后提醒一句：代理只负责网络出口这一层。浏览器指纹、账号环境这些是另外的事，别把计费模式选对了当成整条链路都稳了。
评论(0)