无效IP：爬虫项目里最隐蔽的"杀手"
做爬虫的人大概率都遇到过这种场景：明明IP池里躺着几百个代理，实际跑起来却频繁超时、返回403、或者拿到一堆重复数据。你打开日志一看，30%甚至50%的IP根本连不上，或者响应慢得像在拨号上网。
这些"僵尸IP"如果不及时清掉，会带来三个致命问题：
第一，拖慢整体速度。你的调度器会把请求分给这些慢IP，等它们超时再重试，整个pipeline的吞吐量直接腰斩。一个本该10秒跑完的批次，硬生生拖到40秒。
第二，污染数据质量。失效IP返回的可能是缓存页面、错误页、或者干脆是空响应。如果下游没有严格校验，脏数据就混进了你的数据库。
第三，浪费预算。你按IP数量付费，但实际能用的可能只有一半。剩下的钱全打了水漂。
所以，一套可靠的IP健康度检测 + 自动剔除机制，不是"锦上添花"，而是爬虫基础设施的底线。
健康度检测：到底该看哪些指标？
很多团队刚做IP池管理时，检测逻辑就一行：ping一下，通了就算好的。这远远不够。一个IP"能通"不代表"能用"。真正有效的健康度检测需要综合以下四个维度：
| 指标 | 检测方式 | 健康阈值（参考） | 说明 |
|---|---|---|---|
| 连接延迟 | TCP握手 + 首次HTTP响应时间 | < 800ms | 超过2秒基本可以判定为"慢IP"，对爬虫效率影响极大 |
| 请求成功率 | 连续N次探测请求的200/非200比例 | > 90% | 成功率低于70%的IP应进入观察名单，低于50%直接剔除 |
| 超时率 | 探测请求中超过设定timeout的比例 | < 10% | 超时率高的IP会严重拖慢调度，必须优先处理 |
| IP存活时长 | 该IP最近一次成功使用的时间戳 | < 30分钟 | 长时间未使用的IP大概率已失效，需要重新验证 |
这里有个关键细节：探测请求一定要用真实业务场景，而不是随便GET一个首页。比如你的爬虫目标是电商详情页，那探测请求就应该模拟访问一个详情页，带上真实的UA和Headers。因为很多IP对"首页"能正常响应，但对"深层页面"会直接拒绝。
自动剔除机制：从"手动清理"到"零人工干预"
理想的状态是：IP池自己会"新陈代谢"——好的IP留下来，坏的IP被自动踢出去，空出来的位置由新IP补上。整个过程不需要人盯着。
下面是一套经过实战验证的剔除策略，分五个阶段：
阶段一：入池前预检
新IP进入池子之前，先做一轮快速验证。用3个不同目标URL发探测请求，要求全部在1秒内返回200。任何一项不通过，直接拒绝入池，不浪费后续资源。
阶段二：运行中实时打分
每个IP在池子里不是"静态"的，而是带一个动态健康分（0~100）。每次业务请求完成后，根据结果更新分数：
# 简化版健康分更新逻辑
def update_health_score(ip_record, result):
if result.status_code == 200:
latency = result.elapsed_time
if latency < 0.5:
ip_record.score += 2 # 快速成功，加分
elif latency < 1.0:
ip_record.score += 1 # 正常成功，小加分
else:
ip_record.score -= 1 # 慢成功，小扣分
elif result.status_code in (403, 429, 503):
ip_record.score -= 10 # 被拒绝/限流，重扣分
elif result.timeout:
ip_record.score -= 15 # 超时，最重扣分
else:
ip_record.score -= 5 # 其他错误
# 分数限制在 0~100
ip_record.score = max(0, min(100, ip_record.score))
# 记录最后活跃时间
ip_record.last_used = time.time()阶段三：定时批量巡检
除了实时打分，还要有一个定时任务（比如每5分钟）对全池IP做一次主动巡检。对于长时间没有被业务请求命中的"冷IP"，主动发探测包验证存活。这一步能抓住那些"分数还很高但实际已经挂了"的IP。
# 定时巡检伪代码
async def periodic_health_check(pool, interval=300):
while True:
await asyncio.sleep(interval)
for ip in pool.all_ips():
# 跳过最近60秒内刚被业务用过的IP
if time.time() - ip.last_used < 60:
continue
# 冷IP主动探测
result = await probe(ip, timeout=3)
if not result.ok:
ip.score = 0
pool.mark_for_removal(ip, reason="periodic_check_failed")阶段四：分级剔除，避免"一刀切"
不要一发现IP有问题就立刻踢掉。实战中更稳的做法是分级处理：
| 健康分区间 | 状态 | 处理方式 |
|---|---|---|
| 80 ~ 100 | 健康 | 正常使用，优先级最高 |
| 50 ~ 79 | 亚健康 | 正常使用，但降低调度优先级 |
| 20 ~ 49 | 观察期 | 暂停分配新任务，只允许当前请求完成 |
| 0 ~ 19 | 剔除 | 移入隔离区，触发替换流程 |
这个"观察期"设计很重要。有些IP是临时抖动（比如目标站点在做CDN切换），给它2~3分钟的缓冲，可能就恢复了，没必要直接浪费掉。
阶段五：自动补位
IP被剔除后，池子不能"缺人"。需要有一个补位策略：从备用IP储备中按健康分排序，取前N个补入。如果储备也不够了，就触发上游的IP获取接口拉取新IP。
整个流程跑起来之后，你会发现IP池的"有效利用率"能从60%~70%提升到90%以上，而人工干预基本归零。
一个容易踩的坑：探测频率与目标站的关系
做健康检测时最大的坑是把目标站"探"封了。
假设你的IP池有2000个IP，每5分钟全量巡检一次，每个IP发3个探测请求。那就是每分钟600个请求打向同一个目标站。很多站点的WAF/风控系统看到这种"规律性批量请求"，会直接把整个IP段拉黑。
实战中的解法：
① 探测请求打向"安全目标"。不要直接打你的业务目标站，而是打一个中性的、允许高频访问的页面（比如一个公开的API健康检查端点、或者目标站的robots.txt）。这只能验证"IP能不能上网"，不能验证"能不能访问目标"，但能过滤掉大部分死IP。
② 业务目标站的验证靠"真实流量"。让IP在实际业务请求中"自证"，通过健康分机制自然淘汰。不需要额外发探测包。
③ 控制巡检并发。2000个IP不要同时打，用信号量限制并发（比如同时最多50个），拉长巡检窗口到15~20分钟。
天启代理：让IP池维护这件事变简单
上面这套检测 + 剔除 + 补位的机制，自己搭当然可以，但说实话，维护一个稳定、高质量、持续可用的国内代理IP池，本身就是一个重活。IP的获取、清洗、去重、轮换，这些底层工作如果自己做，团队得专门养一两个人盯着。
这也是为什么很多爬虫团队会选择用天启代理的HTTP代理IP服务。天启代理专注于国内代理IP领域，提供的是经过筛选和清洗的高质量IP资源，你拿到的IP在入池前已经过了一轮基础可用性验证，省去了自己"大海捞针"的环节。
结合前面介绍的健康度检测机制，实际使用体验会非常顺滑：
入池即高可用。天启代理提供的IP本身质量有保障，你的健康分初始值可以设得比较高，减少"观察期"的等待时间。
配合自动轮换。天启代理支持灵活的IP轮换策略，你可以设定使用N次后自动更换，从源头降低单个IP被目标站标记的风险。你的健康分系统只需要关注"当前这个IP还灵不灵"，不用操心"这个IP还能用多久"。
国内网络环境适配。因为天启代理的IP池就是面向国内网络环境构建的，延迟表现和连通性都针对国内目标站做了优化。你不需要额外处理DNS解析、路由绕路这类问题。
简单说，天启代理负责"给你好IP"，你的健康度系统负责"管好这些IP"，两边各司其职，整个爬虫基础设施的稳定性会上一个台阶。
常见问题
Q: 健康检测的探测请求会不会被目标站识别为"探测"而封IP？
不会，前提是探测请求的UA、Headers、请求频率要和真实业务流量保持一致。最稳妥的做法是：基础存活检测打中性目标，业务可用性靠真实流量验证，两者分开。
Q: IP池规模多大比较合理？
取决于你的并发量和目标站的限流策略。一般经验是：如果你的爬虫峰值并发是200 QPS，IP池至少要有500~1000个有效IP，留出足够的缓冲应对IP失效和轮换。IP池太小，一个IP被踢就明显影响吞吐；太大，管理成本和探测开销也会上去。
Q: 健康分要不要持久化？服务重启后分数会丢吗？
建议持久化到Redis或数据库里。服务重启后如果分数清零，所有IP都会从"满分"重新开始，短期内会出现大量"假健康"IP被分配出去的情况。持久化后，重启只是恢复状态，不影响调度连续性。
Q: 用天启代理还需要自己做健康检测吗？
需要。天启代理保证的是IP的"初始质量"和"持续供应"，但你的具体业务场景（目标站、请求频率、数据量）只有你自己清楚。健康度检测是"最后一公里"的适配，能帮你把IP池的有效利用率榨到最高。两者是互补关系，不是替代关系。
Q: 观察期设多长合适？
取决于你的业务节奏。如果目标站的风控比较敏感，观察期设短一些（2~3分钟），快速淘汰；如果目标站比较宽松，可以放宽到5~10分钟，给IP更多恢复机会。建议先跑一周数据，看"观察期内恢复率"是多少，再调整窗口大小。
