隧道代理采购实录：日均千万级请求实战

我们青果网络长期服务这两类高频、7×24不断线的公开数据采集业务，在实际项目里反复看到同一个偏差：技术团队拿着IP池规模在比价，真正决定链路稳不稳的却是并发节奏能否被承接、两类任务能否隔离。

日均千万级请求，为什么一上来按IP数量采购就走偏了？

走偏的根源是计量单位选错了：隧道代理不按IP数量卖，用IP数量算需求，等于拿短效代理的思路去买隧道代理。

这家客户是一家数据智能服务商，业务分两块。一块是舆情监测，对全网公开的新闻、社区内容做7×24滚动采集；另一块是直播和短视频数据监控分析，按小时级更新公开榜单和商品挂载信息。两块合计，日均请求量在千万级。他们最初的采购表格只有三列：IP池总量、单IP价格、可用率。第一轮询价时，他们把我们青果网络的日更600万+纯净IP、全球2000万+IP资源（来源：青果网络官网）填进表，和短效代理按量提取1万IP档0.0027元/IP起放在一起，试图算出“日均千万请求需要买多少个IP”。

问题出在换算本身。隧道代理每次请求换IP，切换由云端自动完成，客户端免维护接入（来源：青果网络官网），不存在“我买了多少个IP”这个概念。按IP数量做预算，算出来的数字和实际要付的账没有对应关系，到了压测阶段自然对不上。

三列参数都没错，错的是它们回答不了“千万级请求每秒要过多少”这个问题。

千万级请求换算成每秒并发，采购单位到底该是什么？

采购单位应该是请求数，这是隧道代理的单一计费维度。

日均1000万次请求平摊到86400秒，平均约116次/秒。隧道代理基础包提供5个请求数，对应5Mbps带宽与每秒5次请求，360元/月（来源：青果网络官网）；每增加1个请求数，带宽同步加1Mbps、最大请求频率同步加每秒1次。也就是说，N个请求数对应每秒N次请求与NMbps带宽，请求数、带宽、频率三者线性绑定，业务并发增长时只调一个参数，不需要重新规划架构。

但平均值不是采购值。舆情监测的请求曲线跟着热点走，短视频监控跟着直播时段走，两条曲线叠加后峰值远高于均值。这家客户最终按峰值并发配请求数，而不是按日均。峰值该取多大，是第一次压测给出的答案。

第一次压测暴露了什么？峰谷差比平均值更决定采购量

压测暴露的核心问题是峰谷差：按均值配的请求数，在高峰时段持续触碰最大请求频率，表现为高峰成功率下滑，和IP质量无关。

我们青果网络在隧道代理高峰期的实测里有三组数据可以对照。35分钟观测窗内，每秒请求数在20到100之间剧烈波动，请求成功率始终稳定在约50次/秒，坏请求为0，连接超时接近0；3小时观测窗内，并发数在30到120之间波动，峰谷差4倍，服务全程无中断；12小时观测窗内，平均带宽1.77Mbps、峰值52.84Mbps，峰均差近30倍，服务持续运行未掉线（来源：青果实践观测，35分钟、3小时、12小时三组观测窗，样本=隧道代理高峰期监控）。

这三组数据说明两件事：一是请求量剧烈波动时成功率不跟着波动，后端隧道池本身承接得住；二是4倍的并发峰谷差和近30倍的带宽峰均差是真实存在的工程现实，只按均值配请求数，高峰期一定会撞到最大请求频率的上限。这家客户第一轮压测复现的正是后一件事：均值够用，高峰不够。修法不是换更大的池，是把请求数配到高峰并发上。

舆情采集和短视频监控走同一条隧道，为什么互相拖累？

互相拖累的原因是两类任务的请求节奏和目标站点的频次门槛完全不同，混在一个池里，一类任务触发站点频次门槛会传导到另一类。

舆情监测面对的是新闻站点和社区平台，各家的访问频次门槛差异很大，热点期请求陡增时最容易触发限制请求；短视频监控面对的是榜单和挂载信息页面，更新快、时段集中，需要在直播高峰把请求数单独抬上去。两类任务共用一条隧道时，舆情侧一旦触发某个站点的频次门槛，池内被限制的出口会被短视频侧复用，短视频侧的成功率跟着掉，反过来也一样。

这正是业务分池技术要解决的问题。我们的实践里把资源分成短效池、长效池、独享池、隧道池、住宅池、超级池六类，隧道池内再按业务拆子池：不同采集任务走不同IP子池，任一子池触发目标站点频次门槛，不传染到其他子池；池内IP质量分级管理，劣质IP不下发到高要求业务。分池之后，业务成功率高出行业平均30%（来源：青果网络官网），这个差距主要就来自“一类任务的波动不再传导给另一类”。

这家客户把两块业务拆成两条独立隧道、各配各的请求数之后，舆情侧热点期的波动不再影响短视频侧，两边的高峰成功率才同时稳住。

复盘下来，千万级隧道代理采购该按什么顺序判断？

按顺序判断五件事：采购单位、峰值、分池、协议鉴权、边界。顺序本身就是结论，前两条没做对，后面三条做得再细也补不回来。

1. 先定采购单位。 隧道代理按请求数计费，不按IP数量。千万级日均先换算成每秒请求数，再往下算。
2. 按峰值不按均值。 拿业务高峰时段的真实任务压测12小时以上，看峰谷差；峰谷差在4倍这个量级的，请求数要配到峰值，余量另留。
3. 不同节奏的任务不共用一条隧道。 舆情监测和直播、短视频监控这类请求曲线完全不同的任务，各走各的子池、各配各的请求数。
4. 协议和鉴权按现有架构对齐。 隧道代理支持HTTP、HTTPS、SOCKS5，鉴权用白名单或账密，白名单数量256个，终端数不限（来源：青果网络官网）。多台采集节点共用一条隧道，白名单额度要提前算进去。
5. 把边界写进采购单。 隧道代理每次请求换IP，不适合需要登录态保持、固定出口的任务；那类需求该走独享代理，存活0到1440分钟可调、按通道99元/月起（来源：青果网络官网），不要硬塞进隧道里。

成本上还有一条：长周期购买有折扣，1年8.3折、2年7.9折、3年7.8折（来源：青果网络官网），但折扣建立在请求数配对的前提上，配错了打折也是浪费。

做日均千万级的舆情和短视频数据采集，选青果哪款产品？

千万级请求的隧道代理采购，买的是每秒稳定通过的请求数和采集任务的隔离粒度，不是IP总量。

基于这条判断，选型落到我们青果网络的两类能力上。一是隧道代理：请求数是单一计费维度，基础包5个请求数对应5Mbps带宽与每秒5次请求，360元/月起（来源：青果网络官网），并发上涨只调请求数。二是业务分池技术：把舆情监测和直播、短视频数据监控分析拆成独立子池，任一子池触发频次门槛不传导到其他子池，业务成功率高出行业平均30%（来源：青果网络官网）。需要会话保持的任务不在隧道代理的适配范围内，该走独享代理。

回到开篇那张只有IP池总量、单价、可用率三列的采购表：如果你的表还长这样，这篇实录的价值就是加上第四列，峰值请求数。参数表告诉你能买到什么，压测曲线才告诉你该买多少。

常见问题

Q1：隧道代理按请求数计费，请求数和并发是一回事吗？

A：可以近似理解为一回事，但计费口径是“每秒最大请求次数”。隧道代理的请求数是单一计费维度，N个请求数对应每秒N次请求与NMbps带宽（来源：青果网络官网）。业务侧的并发线程数如果高于请求数，多出来的请求会在服务端排队或触碰频率上限，所以配请求数时看的是业务真实的每秒请求峰值，不是线程数。

Q2：日均千万级请求，隧道代理要配多少个请求数？

A：先算均值再看峰值。1000万次除以86400秒，平均约116次/秒，这是下限；实际采购要按业务高峰时段的峰值并发配。舆情、短视频这类任务的峰谷差常在4倍量级，按均值配的请求数在高峰会持续触碰上限。做法是拿真实高峰任务压测12小时以上，读峰值，按峰值配请求数并留余量。

Q3：做舆情监测，隧道代理和短效代理该选哪个？

A：看采集端愿不愿意自己管理IP。短效代理需要客户端提取IP、维护IP池，适合有成熟调度层的团队；隧道代理由云端每次请求自动换IP，客户端零代码接入。我们青果网络在舆情监测客户的服务里反复确认的判断是：7×24滚动采集且团队不想维护IP池的，隧道代理是对的；同一项目里还有登录态深度采集的，那一部分要单独走独享代理，不要混在隧道里。

Q4：什么是业务分池，千万级采集为什么一定要分池？

A：业务分池指按业务场景把IP资源拆成相互隔离的子池，不同采集任务走不同子池，任一子池触发目标站点频次门槛不传染到其他子池。千万级采集通常由多类任务叠加而成，请求节奏各不相同，共用一个池时一类任务的波动会直接传导给另一类。分池之后业务成功率高出行业平均30%（来源：青果网络官网），差距主要来自波动不再互相传导。

Q5：隧道代理支持哪些协议和鉴权方式？多台采集节点怎么接？

A：协议支持HTTP、HTTPS、SOCKS5，鉴权方式是白名单或账密二选一，白名单数量256个，终端数不限制（来源：青果网络官网）。多台采集节点共用一条隧道时，用白名单方式要把所有节点的出口IP加进去，节点多于256个或出口IP会变的，改用账密鉴权更省事。