请求失败一次，就应该淘汰IP吗？
单次请求失败不足以确认IP失效。代理链路中的连接超时、连接重置和目标服务错误发生在不同环节，异常检测需要区分本地连接问题与上游返回的业务错误。
在舆情监测任务中，某条请求失败，可能意味着代理连接中断，也可能意味着目标服务暂时无法处理请求。若系统只记录“失败”，随后直接删除IP，就丢失了判断所需的上下文。
建议先保留以下信息，再决定是否调整代理状态：
| 记录项 | 需要回答的问题 |
|---|---|
| 失败阶段 | 连接尚未建立，还是已经收到响应？ |
| 目标范围 | 只在一个目标发生，还是多个目标都有异常？ |
| 时间范围 | 偶发一次，还是在观察窗口内持续出现？ |
| 对照表现 | 同期其他代理是否也出现类似异常？ |
| 任务结果 | 请求完成后，是否得到任务需要的数据？ |
这里的IP淘汰，指代理池管理中的调度处置。实际被管理的对象宜包含代理地址、端口及相关配置，不能仅凭相同IP就认定所有接入方式具有相同状态。
系统通过什么信号发现异常IP？
异常信号可以来自主动探测，也可以来自实际请求反馈。主动健康检查与被动异常检测可以配合使用；被动检测中的连续失败、窗口成功率等指标，能帮助识别持续异常的节点。
下面是适用于代理池的检查设计，而非统一产品规格：
| 检查方式 | 观察内容 | 适用价值 | 判断边界 |
|---|---|---|---|
| 主动探测 | 指定探测请求能否完成 | 补充低流量时段的信息 | 探测成功不代表实际任务成功 |
| 请求反馈 | 连接失败、超时、重置 | 发现真实链路异常 | 需要区分客户端、代理和目标环节 |
| 窗口统计 | 成功数、失败数、样本量 | 识别一段时间内的质量变化 | 样本不足时不宜仅看比例 |
| 业务校验 | 所需字段是否完整 | 判断任务是否完成 | 数据缺失未必由代理造成 |
例如，招投标数据任务需要获取公告正文。探测地址返回正常，只能说明该探测路径可用；若公告页面的实际请求持续失败，仍需要检查业务链路。
健康检查应该尽量接近实际流量。公开实现文档也指出，探测与真实流量不一致时，可能出现探测通过、业务仍失败，却过早恢复节点的情况。
发现异常后，怎样判断是否移出代理池？
移出决策应结合异常类型、持续性和影响范围。连续失败与窗口统计是不同的判断方法：前者关注连续异常，后者观察一段时间内的整体表现。
可以按以下顺序组织判断：
- 分类异常。连接失败与目标返回错误分开记录，避免所有失败共用一个计数器。
- 核对范围。同一目标下大量代理同时异常，应先排查目标或共享链路；只有个别代理持续异常时，再重点检查对应端点。
- 确认样本。统计失败率时同时查看请求数量，避免低样本造成比例剧烈变化。
- 选择动作。证据不足时继续观察；持续异常可临时隔离；确认资源不可继续使用时，再退出当前资源集合。
以HTTP429为例，它表示一定时间内请求过多，响应可能提供Retry-After等待时间。限流的识别依据也可能是认证凭据或Cookie，而非单独依据IP。
因此，收到429时应先降低请求频率并按响应要求等待，不能直接推导出“这个IP已经失效”。换地址也不能替代对请求速率的管理。
从可用到隔离，再到恢复，状态怎样流转？
状态流转的作用，是把发现异常与永久退出分开。下面是一套便于理解的代理池设计示意；具体系统可能合并状态，或使用不同命名。
| 状态 | 进入条件示意 | 调度动作 | 后续去向 |
|---|---|---|---|
| 可用 | 当前检查满足要求 | 正常接收任务 | 异常时进入观察 |
| 观察 | 出现可疑失败，证据尚不足 | 增加观测，必要时减少分配 | 恢复正常或进入隔离 |
| 隔离 | 持续异常达到配置条件 | 暂停分配新任务 | 等待冷却或人工处理 |
| 复检 | 满足重新检查条件 | 使用受控探测或少量任务验证 | 恢复或继续隔离 |
| 退出 | 确认不可继续使用 | 移出当前可调度集合 | 由资源管理流程处理 |
“移出代理池”不一定意味着删除数据库记录。为了追踪原因，可以保留历史状态与事件日志，仅停止调度。公开异常检测实现也提供移出事件日志，用于解释哪些节点因何被移出。
恢复方式需要写清楚。有的实现隔离时间到期后自动恢复，有的会结合主动健康检查。因此，“冷却到期”与“已经证明业务恢复”并不是同一个判断。
怎样避免大量IP被误淘汰？
防止误淘汰，需要同时约束异常归因和移出规模。公开实现中，最小请求样本量、统计窗口与最大移出比例等配置，分别用于约束统计判断和节点移出范围。[1]
代理池设计可以围绕以下问题检查规则：
| 检查点 | 需要避免的情况 | 设计建议 |
|---|---|---|
| 样本量 | 少量请求决定长期状态 | 为统计判断设置最低样本要求 |
| 异常分类 | 目标服务故障被记成代理故障 | 分开记录连接错误与服务响应 |
| 共同故障 | 大量代理在同一时段被移出 | 查看目标、客户端及共享网络情况 |
| 恢复验证 | 反复进入、退出可用集合 | 设置冷却期与恢复观察条件 |
| 可用容量 | 移出后剩余代理无法承接任务 | 配合限流、排队或暂停任务 |
移出比例上限只能控制处置规模，不能证明剩余代理质量正常。如果实际可用容量不足，继续提高剩余节点负载，可能让故障进一步扩大。此时应优先调整任务量。
具体失败次数、观察时长和恢复条件，应根据业务日志与测试结果配置，不能把单一实现的默认参数当成行业标准。
总结
IP淘汰机制通过异常检测、原因判断和状态管理调整代理调度资格；把临时隔离、恢复验证与最终退出分开，才能减少误判并保留故障排查依据。
FAQ
Q：IP淘汰与IP轮换有什么区别？
IP淘汰关注某个代理端点是否继续参与调度；IP轮换关注任务何时切换出口。轮换可以由时间或任务边界触发，不必以故障为前提。设计日志时应分别记录两类原因，避免把正常切换统计成质量异常。
Q：被隔离的IP还能重新使用吗？
可以，但要看系统的恢复策略和资源状态。临时网络异常消失后，端点可能重新满足使用条件；恢复时宜结合实际业务验证。仅仅过去了一段时间，并不足以证明原来的异常已经消失。
Q：连续失败多少次才需要淘汰？
不存在可直接套用到所有代理池的次数。阈值需要结合请求频率、超时设置、失败类型和任务容忍度确定。配置中还应区分临时隔离条件与最终退出条件，避免一次规则同时承担两种决策。
Q：主动探测成功，为什么任务仍会失败？
探测与业务请求可能访问不同地址、使用不同路径或检查不同内容。探测成功只能证明相应检查通过。若任务仍持续失败，应补充接近真实请求的验证，并检查目标响应与业务数据完整性。
Q：淘汰后是否应该立即重试原请求？
节点状态变化与请求重试应分别管理。重试前需要判断失败原因、等待要求及操作是否适合重复执行。对于限流响应，应遵守等待要求；对于可能产生重复提交的操作，应先确认执行结果。
