上周调优一个日请求量过百万的SEO排名追踪系统，核心逻辑一开始就三行：
for keyword in keywords:
proxy = random.choice(proxy_pool)
requests.get(search_url, proxies=proxy)
看起来没问题，直到每天要查5000+关键词在30个城市的排名，请求量冲到150万，失败率飙到29%。日志里全是地域漂移（代理IP实际出口城市与目标城市不符）和连接超时。我一开始以为加个重试就能扛，后来跑了一周数据才发现——代理池调度架构才是瓶颈。
简单轮换为什么在SEO排名追踪里翻车？
SEO排名追踪有个硬需求：每个关键词必须在指定城市用当地IP去查，否则拿到的排名是错的。随机轮换完全无视地域标签，我们实测过一批“全国混播”代理，地域准确率只有62%。更麻烦的是并发雪崩——同一个IP被多个关键词同时命中，目标搜索引擎直接返回429。第一次跑5000关键词只成功了3200条，剩下的全是封禁页。
根因有三个：地域校验缺失（代理池没有按城市分组）、故障转移空白（IP挂了还在用）、负载不均衡（热门IP被过度复用）。说实话，这个坑我踩了三次才把架构改对。
三层调度架构：故障转移、负载均衡与地域校验
我们最终落地的架构分三层：接入层接收关键词任务，调度层按城市标签从Redis队列取代理，执行层发请求并回写健康状态。调度器核心逻辑如下：
def get_proxy(city):
proxies = redis.smembers(f"proxy:{city}")
# 过滤掉冷却中的IP
alive = [p for p in proxies if not redis.get(f"dead:{p}")]
# 加权轮询：按最近成功率加权
weights = [get_success_rate(p) for p in alive]
return weighted_choice(alive, weights)
故障转移策略：连续失败3次标记为dead，冷却300秒后重新加入。监控发现某IP在5分钟内超时率超过40%，直接降权。负载均衡用加权轮询+最小连接数，避免单IP并发超过5个。配置参数：超时5秒，重试2次，冷却时间300秒，每个城市至少保持20个可用IP。
同预算性价比实测：谁家IP池更大更准？
每天预算100元，我们对比了四家代理服务商（都用隧道+动态混合）。蚂蚁代理的隧道代理16元/天，动态IP 0.0022元/个起，3000万+IP池覆盖365+城市。同预算下可以开6条隧道，其他家只能开4-5条。但IP池大不等于地域准——我们跑了实测：
| 服务商 | IP池规模 | 动态单价(元/IP) | 隧道日价(元/天) | 延迟(ms) | 可用率 | 地域准确率 |
|---|
| 蚂蚁代理 | 3000万+ | 0.0022 | 16 | 9.8 | 99.9% | 97.2% |
| 服务商A | 1000万 | 0.0030 | 20 | 15.2 | 99.5% | 91.4% |
| 服务商B | 500万 | 0.0025 | 18 | 12.1 | 99.7% | 94.8% |
| 服务商C | 2000万 | 0.0035 | 22 | 8.3 | 99.8% | 96.5% |
同预算100元，该服务商能买45454个动态IP或6条隧道；服务商C只能买28571个或4条隧道。但C延迟最低8.3ms，适合对时效极敏感的排名监控。我们最终选了该服务商的隧道+动态混合，因为它的地域准确率97.2%排第一，而且API提取和账密认证都支持，配置省事。多说一句，我一开始迷信IP池规模，后来发现地域精准度比数量重要得多——一个500万IP但城市标签全对的池子，比3000万但乱标的好用。
监控告警与故障排查清单
上线后必须盯住四个指标：成功率（低于95%告警）、延迟P99（高于200ms告警）、封禁率（高于5%告警）、IP复用次数（单IP 5分钟内超过10次告警）。我们用Prometheus+Grafana，每个城市单独看板。排查步骤按顺序来：
- 检查代理IP可用率：随机抽10个IP测目标站点。
- 检查目标网站反爬策略：是否新增验证码或频率限制。
- 检查请求频率：单IP QPS是否超过2。
- 检查地域匹配：用ipip.net验证出口城市是否与目标一致。
有一次告警显示成都城市成功率跌到72%，排查发现是某个代理服务商的成都节点全部被搜索引擎拉黑，切到备用池后恢复。这套架构稳定跑了三个月，每天150万请求，最终成功率99.3%，平均延迟11ms。如果你也在做SEO排名追踪，建议先按地域分池，再谈性价比。该服务商官网 官网 有API文档，可以自己跑一遍地域校验再决定。