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