有段时间我池子里躺着四千多条IP，前一天跑得好好的，第二天成功率掉到六成出头。翻了半天日志才想明白：失效的IP根本没被剔出去，调度器还在把它们一轮一轮往外发。给池子加了一层健康检查之后，同样的目标站，成功率回到九成以上，重试次数少了一大半。这篇把健康检查该怎么写讲清楚。

先弄清楚成功率掉在哪

很多人一上来就怀疑是供应商的问题，其实先做一步统计更省时间：把失败按类型分开数。我一般分四类——连接超时、连上但被目标站拒绝（403/429）、连上但返回内容不对、以及代理压根连不上。

前两类通常是目标站的风控或频率问题，第三类多半是自己代码的解析问题，只有第四类才是IP本身失效。如果第四类占比超过两成，那就该做剔除了，不用再猜。

探针地址别拿业务目标站

这是我最先踩的坑。一开始图省事，直接拿要采集的站当探针，几百个并发一打，目标站当天就把我这批IP拉黑了，成功率反而更低。

探针的目标得满足三个条件：响应快、允许高频访问、返回体小。我通常选一个 HTTP 状态探测页或者一个几十字节的静态文件。判断标准也别只看"连没连上"——代理能连上但被目标站挡回来，这条IP对你就没用，所以要看 HTTP 状态码和返回的关键字段。

超时和并发怎么定

超时我设的是5秒。设太短，网络抖一下就被误判成失效；设太长，一条坏IP能拖住一个检查线程十几秒，检查一轮下来半天过去了，池子里的IP都以经换了一批。

并发要按自己的出口带宽算，不是越高越好。我的经验值是把检查并发控制在业务并发的三分之一左右，剩下的留给正常采集。曾经我为了"检查得快"开到300并发，结果把自己的出口带宽打满，业务请求全在排队。

剔除规则：别一刀切

检查失败一次就丢掉是不划算的，短效IP本来就有波动。我的做法是记失败次数：连续两次失败先降权（排在队尾），连续三次失败才剔除。反过来，连续成功两次的把权重提回来，让好IP多干活。

还有一种情况要单独处理：代理连得上、但目标站返回429。这是我们自己请求太密造成的，不是IP的错，把这类IP直接丢掉纯属浪费。遇到429我一般是整体降速，而不是怪到IP头上。

补货节奏比检查频率更重要

短效IP是按分钟计时的，检查再勤也留不住本来就该过期的IP。所以我更关注补货：本地池子水位低于三分之一就补，一次补20到30条，让它始终维持在一个小水位上滚动。

这样接口侧的调用曲线是平的，不会被自己顶到限流；池子里的IP也都是"新鲜"的，检查通过率自然也高。我现在用的星月代理支持 API 实时批量提取，短效IP自动轮换，池子覆盖全国300多个城市，可用率标的是90%以上，取回来的IP直接进本地池按上面的规则检查补货就行。

一份可以直接照抄的检查清单

两个容易漏的细节

一是检查用的帐号别和业务共用。如果你的提取方式是账号密码授权，检查线程和业务线程用同一个帐号，一旦触发限流会互相牵连。白名单直连的方式没这个问题，我现在取IP这一步就走白名单直连。

二是把检查结果落库。光在内存里记失败次数，程序一重启记录就没了，坏IP又活过来。我每天会把连续失败的IP写一份日志，周末扫一眼，能看出是哪一批线路在退化。

池子这东西，不用天天盯着，但检查、剔除、补货这三件事搭起来之后，它就是能自己维持在一个稳定水位上。剩下的精力花在业务逻辑上，比天天救火划算得多。

健康检查要点：先用失败类型统计判断是不是IP的问题，探针选轻量且不拉黑的地址，超时5秒、并发取业务的三分之一，连败两次降权三次剔除，按水位滚动补货，检查结果落库避免重启后失效。