
讲个我去年踩过的坑。
2025 年 7 月,我们工作室一套公开数据采集任务突然开始掉成功率。开发第一反应是资源不够,于是临时补了一批代理,又把重试次数从两次调到五次。
半小时后,积压更多了。
那天下午我盯着监控看了挺久,桌上那杯美式早就凉了。代理数量确实在增加,请求成功率却没有跟着恢复,失败任务还在不断换 IP、不断重试,像拿一群人去反复撞同一扇门。
后来把日志按业务拆开,原因才露出来:三类请求共用同一套 IP 池。
一类是低频公开页面,一类是高频搜索接口,还有一类需要保持会话。三个任务对 IP 的要求完全不同,却使用相同的轮换周期、并发上限和失败策略。
这不是 IP 不够,是池子没有真正建起来。
很多团队所谓的 IP 池,基本流程是这样的:
程序从数据库取一条代理,发起请求;失败后把它标记为不可用,再换下一条。
这个逻辑适合演示,不适合企业任务。
一次请求失败,可能是代理连接超时,也可能是目标站点限流、账号过期、Cookie 失效、页面结构变化,甚至只是解析代码写错了。
这些错误对应的处理方式完全不同。
连接失败,可以降低 IP 权重;站点限流,可以让节点进入冷却;账号失效,应该停止当前会话;解析错误,则跟 IP 没关系。
如果系统不区分原因,所有问题都会被翻译成“换个 IP 再试”。最后正常 IP 被大量淘汰,真正的程序故障反而被遮住。
问题恰恰出在这儿。
第一类是资源状态。
IP 来自哪里、支持什么协议、属于哪个地区、有效期多久、当前并发多少,这些是调度的基础信息。
第二类是质量状态。
连接成功率、业务成功率、响应时间、近期失败次数、上次检测时间,都要持续更新。它们不是永久标签,必须跟着真实业务变化。
第三类是业务状态。
某条 IP 访问站点 A 表现正常,不代表访问站点 B 也正常;适合短请求,也不代表适合保持登录态。
所以,企业级 IP 池不能只给 IP 打一个全局分数。至少要把目标站点和请求类型纳入判断。
一条 IP 到底好不好,没有脱离业务的标准答案。
我们那次故障里,最麻烦的不是第一次失败,而是错误的重试策略。
高频任务触发限制后,程序立刻换 IP 重试;新 IP 很快承接同样的请求模式,再次失败;重试次数增加后,单位任务产生的请求反而更多。
系统以为自己在恢复,实际是在加速消耗资源。
后来我们把处理逻辑拆开:连接层失败才允许快速换节点;目标站点出现限制特征时,任务降速并进入等待;会话失效则停止使用当前账号;内容校验失败先检查页面结构,不立即归因于代理。
请求量降下来后,成功率才慢慢恢复。
这地方很多人踩坑——重试不是免费的。每一次重试都会增加出口使用频率、目标站点压力和任务积压,还可能继续污染一批原本正常的 IP。
低频页面和高频搜索共用资源,相当于两个性格完全不同的租客共用一张门禁卡。
一个每天正常进出,另一个十分钟刷几百次门。门禁系统把卡锁了,不会因为第一次刷卡的人比较规矩,就只限制第二个人。
IP 也是一样。
同一出口在目标站点那里会留下历史状态:请求频率、行为特征、错误模式,以及持续累积的风险判断。业务之间共用 IP,也就共用了这些状态。
所以我们后来按目标站点和请求行为重新分池,而不是按项目组分。
低频公开页面用一套资源,高频短请求用另一套,需要登录态的任务单独处理;每个池有自己的并发、轮换、冷却和监控规则,池满后排队,不再自动借用其他业务的 IP。
改完之后,最明显的变化不是某个成功率数字突然变得多漂亮,而是故障范围变小了。一类任务出问题,不会把另外几类一起拖下水。
这才是业务分池真正的价值。
我们最后把 IP 状态从简单的“可用、不可用”改成了多阶段状态:
待检测、观察中、正式可用、降权、冷却、复检、淘汰。
新资源先接受小流量测试,稳定后进入正式池;偶发失败先降权,不立即删除;连续触发限制的进入冷却;冷却结束再复检,确定是临时异常还是彻底失效。
这么做看起来复杂,实际比粗暴删除省资源。
企业任务运行时间长,网络抖动和目标站点策略变化都很正常。如果每次失败都永久淘汰,池子会越跑越小;如果所有异常都继续放行,坏节点又会拖累任务。
中间状态就是用来解决这件事的。
IP 数量不足,确实可能导致任务失败。
只不过,在补资源之前,最好先看清楚:失败集中在哪类业务、出现了什么响应、重试是否放大请求、会话有没有被错误切换、不同任务是否在共用资源。
如果这些问题没解决,再增加 IP,也只是给错误的调度策略补充燃料。
那次故障后,我们把“换 IP”从默认动作改成了最后动作。
这个改动不复杂。只是早两年想明白的话,能少烧不少代理。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。