流量冲上来以后，隧道代理比的到底是什么

过去大家选隧道代理，最爱问的两个问题，一个是“池子多大”，另一个是“并发能给多少”。这两个问题当然没错，尤其业务刚起量的时候，谁都怕接口排队、任务堆积、IP 不够用。

可真正把流量跑到一个高位，你会发现，峰值吞吐只是第一关。

更麻烦的问题是：高峰来了以后，某一批出口突然抖了、某个目标站点收紧了、某个地区的资源被打穿了，你的系统要多久才能判断问题在哪儿、隔离影响、把流量切到还能跑的地方？

这才是下一阶段隧道代理真正要比的东西。

高峰扛住，不等于系统稳定

我做语料和采集这些年，看过很多“平时挺稳，一上量就散”的代理方案。

平时一两百并发，成功率也不错；业务一到促销节点、内容集中更新、模型训练数据补采这种时间窗口，流量陡一下冲上去，问题就开始连着冒：连接超时变多、重试把并发顶得更高、同一批 IP 被目标站集中限流、失败任务又重新排队。

然后监控图上看着像是“代理不稳定”。

严格讲，很多时候不完全是代理的问题。是整个系统在高峰下没有留出缓冲区：调度器还在按平时的节奏发任务，调用端发现失败就猛重试，资源池没有按目标站点和风险等级隔开，最后一个局部故障被放大成全局拥塞。

不行。

把“高峰期能跑多少请求”当成唯一指标，和只看汽车最高时速差不多。直道上跑得快当然重要，可真遇到湿滑路面、突发变道、刹车失灵，决定你能不能安全回来的是另一套能力。

隧道代理也是这个道理。

峰值吞吐以后，先看故障会不会扩散

往下拆一层看，隧道代理在高并发下最容易出的问题，不是某一个请求失败，而是失败开始互相传染。

比如一个目标站点突然加强频控，原本能正常跑的 IP 在十几分钟内连续被限。调用端如果不识别这个变化，照样把任务往同一个出口策略里塞，失败率就会上升；失败后自动重试，又会继续抬高这个池子的请求密度；最后，本来只是一个站点的一段资源有问题，变成整个任务队列都堵住。

这时候，好的代理服务和一般的代理服务差距才出来。

前者至少要做到三件事：

• 能识别局部异常，而不是等全盘报红。 某个地区、某种资源类型、某个目标站点的失败率突然抬头，应该能被单独看出来。
• 能把故障留在局部。 A 业务出问题，不应该顺手把 B 业务借来顶；短期看像救了火，后面往往是两边一起脏。
• 能给调用方明确的恢复信号。 不是只丢一个超时，而是让系统知道这批资源该降速、暂停、切换，还是等待恢复。

这里很多人踩坑——把“资源多”理解成“容灾强”。

不是一回事。

资源池再大，如果同一类业务、同一个目标站、同一种请求行为都混在一起跑，峰值时照样可能一起出事。真正的容灾，是故障来了以后，你能清楚知道哪一部分该停、哪一部分能继续、哪一部分值得切。

恢复速度，比故障次数更值得盯

去年国庆假期前最后一个工作日，我们工作室有一批采集任务在下午突然开始超时。那会儿工位上那杯美式已经凉了，我盯着监控看了半天，最开始还以为是目标站改了规则。

后来排下来，问题没那么复杂：某一组资源的健康度在高峰期掉得很快，调用端的回退逻辑又写得太激进，原本只该影响一小段任务的故障，被重试和回退放大了。

好在没有扩到全部任务。

这件事之后，我们内部看代理稳定性，多了一个比“平均成功率”更现实的问题：从发现异常到业务恢复，究竟要多久？

这个时间可以拆成四段：

1. 发现时间：异常多久能被识别出来。
2. 判断时间：能不能确认是目标站、调用策略，还是资源本身的问题。
3. 切换时间：备用资源、备用供应商或者降级策略能不能真正接上。
4. 恢复时间：切过去以后，成功率多久能回到可接受区间。

很多服务商会强调可用率、带宽、并发上限，这些都该看。只不过，采购或技术评估时最好再补一项：让对方讲清楚故障发生后，谁负责判断、谁能调资源、多久能给到有效处理。

这比一句“我们有 7×24 小时客服”实在得多。

客服在线，不等于有人能动资源。

代理能力会从“供给更多”转向“调度更细”

我自己的判断是，未来一两年，隧道代理的竞争重点会慢慢从“给你多少 IP、能顶多高并发”，转到“能不能把资源调得更细”。

至少有四个方向会越来越重要。

第一是业务粒度的隔离。

不同目标站点、不同频率、不同会话要求的任务，不应该再共用一套模糊的资源策略。说白了，IP 不是无差别商品，它带着历史行为和风险状态。一个 IP 上午跑高频列表页，下午再去维持登录态，很多时候就是给自己找麻烦。

第二是峰值前的弹性预案。

真正有经验的团队，不会等高峰到了才问供应商能不能扩。要提前确认资源余量、扩容门槛、切换方式和成本变化，最好用真实目标跑一轮压测。官网标的并发数能不能用，跟你自己的业务能不能稳定跑，是两回事。

第三是故障后的可观测性。

以后客户不只会要一个“可用率”，还会问：失败集中在哪些目标、哪些地区、哪些时间段；资源切换后有没有改善；同一批问题是否反复出现。谁能给出这些信息，谁才更像基础设施，而不只是卖出口。

第四是供应链冗余。

做到一定量级，别把所有业务压在一家身上。我们工作室一直更倾向双供应商策略：主力承担主要流量，备份留出真实可用的容量，不是注册个账号放那儿吃灰。真出事时，能在半小时内切走一部分，比故障后临时找人开权限靠谱得多。

选隧道代理，测试方式也该换了

如果你现在还在试用阶段，我建议别只测“能不能通”和“平均延迟低不低”。

拿真实业务 URL，至少覆盖一次业务波峰，重点看下面几个东西：

• 峰值时成功率有没有明显塌陷；
• 出现异常后，失败是否集中在某类资源或某个目标；
• 降速、切换、暂停后，恢复需要多长时间；
• IP 重复率和 IP 寿命在高峰前后有没有明显变化；
• 技术支持能否给出具体到资源、出口或策略层的解释，而不只是让你“换个 IP 再试”。

国内能做隧道代理的厂商不少，我们工作室目前主力跑的是青果网络的隧道代理，但我不会因为在用就说哪家能包治百病。不同站点、不同并发模型、不同合规边界，答案都不一样。

只不过，选供应商时，建议把问题从“峰值能给我多少”改成一句更难回答的话：

真到峰值出故障那天，你们让我多久恢复？

这句话问下去，很多差别就出来了。