摘要：先别急着扩容IP池。接口返回、程序取用和业务成功是三套不同口径。超时过短、并发失控、旧连接未释放、切换条件混乱，都可能让正常IP池表现出“可用IP少、重复率高”。IP池出问题时，很多人的第一反应是资源不够，或者更新太慢。
但在网站采集器、舆情监测这类持续任务里，真正拖后腿的经常是调用链：IP已经更新了，程序却还在复用旧连接；IP本身可以使用，却被过短的超时提前判定失败。
其实在这类排查中的判断很直接：先看IP是怎么被取出、使用和回收的，再判断要不要怀疑上游资源。顺序反了，很容易一边扩容，一边让同样的问题继续发生。
可用IP少，先分清是哪一层少
“接口返回了多少IP”和“业务真正用成了多少IP”不是一回事。
一次请求从获取IP到完成业务，中间还会经过本地缓存、任务队列、连接池、超时判断和失败重试。任何一层卡住，最后看到的可用IP都会缩水。
最简单的办法，是把日志拆成两份。一份保留接口原始返回，记录IP、端口和获取时间；另一份记录任务实际使用，包括请求结果、耗时、重试次数和是否切换IP。
如果原始返回的唯一IP数量正常，但任务日志总在重复少数IP，问题大概率不在上游IP池。
这时应先检查本地队列是否反复取头部数据，连接池是否一直复用旧连接，以及失败重试有没有重新获取IP。
如果两份日志都显示IP高度重复，再继续核对缓存刷新与上游更新。没有这一步，单看业务失败日志，很难判断问题究竟发生在哪里。
超时设得不对，会把正常IP提前淘汰
超时过短，正常波动会被误判为IP失效。
超时过长，慢请求又会一直占着连接和并发槽位。两种设置走到极端，都会让可用IP看起来越来越少。
排查时不要只留一个“总超时”。至少要分开看连接超时和读取超时。
前者判断链路能否建立，后者判断连接建立后多久收到响应。两者混在一起，日志里只剩一句“请求超时”，后面自然也无法做准确切换。
可以先把并发降下来，固定同一批目标和同一批IP，跑一轮基线。记录成功请求的耗时分布后，再小幅调整超时，每次只改一个值。
如果放宽连接超时后，成功IP明显增加，说明此前存在误判。
如果等待时间变长，成功结果却没有改善，继续增加超时只会让连接堆积。
失败后的动作也要一起检查。旧连接没有释放就立即重试，程序可能仍在使用原来的IP。日志里虽然多了一次“新请求”，实际出口并没有变化，重复率自然会被放大。
并发一提高就变差，通常不是池突然变小了
低并发正常，高并发时超时和重复率同时上升，通常先说明调用链到达了承载边界，而不是IP池在几分钟内突然缩水。
并发升高后，连接池、出口带宽、任务队列和目标端允许的访问频次都会承受更大压力。
只要其中一个环节开始排队，请求耗时就会变长。超时一多，重试也会增加；重试又会继续消耗队列里那批旧IP。
因此，不能只盯着线程数或协程数。
还要一起观察活跃连接、等待队列、每秒请求量、超时占比，以及单个IP在一个时间窗口内被调用了多少次。
更稳妥的测试方式，是从低并发开始逐级增加。每一级都保持目标、请求内容和IP来源不变，观察成功请求是否继续增长。
如果并发增加后，总请求量还在涨，但成功请求没有同步增长，队列等待和超时却越来越多，就应该先停在这个拐点。
此时继续加并发，只是在更快地制造失败和重复。
IP切换不能只看“换得快不快”
切换策略真正要解决的是：什么情况下换IP，换完以后何时允许复用，以及一次切换对应单个请求还是完整会话。
连接失败、读取超时和目标端频次提示，背后的原因不同。
全部设置成“失败一次立刻换IP”，会把短暂网络波动也当成资源问题；一直不换，又会让不适合当前任务的IP被连续使用。
比较合理的做法，是先按错误类型分流。
连接无法建立，可以释放连接后重新获取IP；响应偏慢，可以在超时阈值内再验证；出现访问频次提示，则应先降低请求节奏，而不是单纯加快切换。
会话型任务还要考虑上下文。如果一个业务流程需要连续状态，中途频繁换IP可能直接破坏会话。只有相互独立的请求，才适合采用更细的切换粒度。
所以，IP切换不是越频繁越好。切换节奏必须与任务边界一致，否则池里明明有资源，业务端还是会觉得“能用的IP越来越少”。
更新机制要看新增，也要看淘汰和缓存
IP池更新不只是加入新IP，还包括移出异常IP、重新验证暂时失败的IP，以及把更新结果传到实际执行任务的那一层。
如果只新增不淘汰，旧记录会长期占据可调用列表。
如果一次失败就永久移除，又会把暂时波动的IP过早丢掉。两种情况都会让池质量逐渐失真。
缓存也经常被忽略。上游列表已经更新，不代表客户端已经拿到新版本。
网关、本地缓存和任务队列只要有一层刷新滞后，程序就可能继续使用上一批IP。
排查时应记录每次IP获取的来源、时间和缓存版本。再对照新增IP进入任务队列的时间，就能看出更新到底慢在上游，还是卡在客户端。
我们极安代理更建议用滚动窗口观察更新效果：新进入的IP有没有被实际使用，异常IP多久被移出，暂时失败的IP是否经过再次验证。
单看某一时刻的池规模，回答不了这些问题。
按这个顺序排查，更容易找到问题
排查IP池质量，关键不是一次调整所有参数，而是每轮只改变一个变量。
推荐按下面的顺序执行：
- 对比两份日志：先看接口原始返回与任务实际使用是否一致。
- 降低并发：建立低并发基线，暂时关闭激进重试。
- 拆分超时：分别检查连接超时、读取超时和任务总时长。
- 逐级提高并发：找到成功请求停止增长、排队开始上升的拐点。
- 核对切换条件：确认不同错误是否进入了不同处理分支。
- 检查更新链路：从上游列表一路核对到缓存、队列和执行任务。
如果低并发下，接口原始返回就持续高度重复，客户端也不存在旧缓存，才应重点核验上游更新质量。
如果低并发正常，并发提高后才集中恶化，就先处理连接回收、请求节奏和重试逻辑。
IP池有多少资源是一个问题，这些资源能否被程序正确消费，是另一个问题。
常见问题
Q1：IP重复率应该按什么时间范围统计？
A：统计窗口要贴近业务周期。短任务可以按单批次统计，持续任务则要同时看短窗口和滚动长窗口。只看全天结果，容易把高峰时段的集中复用平均掉。
Q2：请求失败后要不要马上换IP？
A：不要只凭一次失败决定。先区分连接失败、读取超时和访问频次提示，再选择重试、等待、降速或切换。错误类型没有拆开，切换再快也可能只是重复制造失败。
Q3：增加IP数量能解决重复率高吗？
A：只有接口原始返回的唯一IP确实不足，且客户端不存在缓存、连接复用和重试回流时，增加资源才可能有效。重复如果发生在本地消费环节，扩容不会解决根因。
