切流那周我把两份报表叠在一起看：左边是免费代理池，7天平均请求成功率58.4%，舆情监控那条链路凌晨2点到5点的可用率直接掉到31%；右边是换完专业代理的第三天，同一个监控任务成功率99.2%，全天最低点也有97.6%。差别大到我不需要做任何统计检验。这篇文章就是这两份报表之间的那半个月。
两条业务线，栽在同一个免费池上
我的工作室规模不大，一台机器挂20多个游戏账号多开，靠的是长时间稳定在线，代理断了就得重登，重登频繁就触发风控。同时朋友介绍了个舆情监控的单子给我，7×24小时盯几个社交平台的关键词，每天大概跑18万次请求，这种活儿对IP可用率的要求基本是变态级别——漏抓一次可能就是一个舆论事件的黄金响应窗口。
一开始两条线共用一套免费代理池，图省钱。结果就是游戏端平均每两小时掉一次线，监控端每天固定丢15%~20%的抓取任务。我一度以为是代码写得烂，把重试逻辑改了四版，最后用日志一查，60%的失败是代理本身返回502或者直接超时。
说实话，那时候我还嘴硬，觉得换代理是“多花钱买心安”。真正让我下决心的是有次监控漏了一条负面舆情，客户第二天早上才看到，电话里的语气我到现在还记得。
选型阶段：三个硬指标筛掉九成供应商
市面上宣传“千万级IP池”的太多，光看这个数字没用。我最后只看三个能验证的东西：
- 有效可用率——不是池子多大，而是随机抽100个IP能通几个。免费池我实测只有30%~40%，低于50%的直接淘汰。
- 城市与运营商覆盖——舆情监控要模拟真实用户分布，至少得覆盖365+城市的三大运营商，否则某些地域的帖子根本抓不到。
- 接入方式是三种还是只有一种——API提取适合我的爬虫，隧道代理（服务端自动轮换IP，客户端只连一个固定入口）适合游戏这种长连接场景，白名单认证则省去鉴权开销。只有一种方式的供应商，说明架构灵活性有限。
下面是我当时整理的一张三档对比表，数据来自我自己跑了三天的抽检：
| 方案类型 | 实测可用率 | 平均延迟 | 人工维护成本 |
|---|
| 免费公开池 | 34.7% | 420ms | 每天约2小时排障 |
| 低价短效API（按量） | 87.3% | 85ms | 每天约20分钟 |
| 专业隧道代理 | 99.9% | 9.6ms | 几乎为零 |
这里有个我个人踩的坑：一开始我死磕按量付费，觉得动态代理0.0022元/IP看着便宜，但我18万请求一天下来其实并不省，还多出一堆调度代码要自己维护。后来算了一笔账，隧道代理16元/天封顶，省下的排障时间比差价值钱得多。
灰度切换：先动舆情，后动游戏
别一次性全切，我第一版就是全切，结果配置写错一个端口，两条线同时趴窝了四十分钟。正确顺序是先切对稳定性最敏感的那条：
- 先切舆情监控。它跑在容器里，改个环境变量就能生效，回滚成本最低。
- 加健康检查。每次取到IP先探活，不通的直接丢，不要等业务请求失败才发现。
- 游戏端最后切。游戏是长连接，IP中途变了会断线，必须用隧道代理而非短效提取。
- 保留旧方案24小时，作为回滚兜底。
健康检查这块我贴一下核心逻辑，这个片段帮我把无效请求砍掉了大概8%：
def get_alive_proxy():
for _ in range(5):
p = fetch_from_api() # 从API提取一个IP
try:
r = requests.get("http://httpbin.org/ip",
proxies={"http": p, "https": p},
timeout=3)
if r.status_code == 200:
return p
except Exception:
continue # 探活失败直接换下一个
return None
并发上我做了限制，监控端每个worker控制在50并发以内，超时设8秒，单次请求重试不超过3次。盲目拉高并发反而会让目标站更快识别出异常流量。
14天后的验收数据
切换满两周，我把两条线的数据拉出来对了一遍：
| 指标 | 免费池时期 | 迁移后 |
|---|
| 舆情监控请求成功率 | 58.4% | 99.2% |
| 游戏账号日均掉线次数 | 9次 | 0.3次 |
| 凌晨低峰可用率 | 31% | 97.6% |
| 每天排障耗时 | 约2小时 | 接近0 |
游戏端掉线从每天9次降到0.3次，这个提升其实比监控端更让我意外——我原本以为掉线主要是账号策略问题，换了代理才发现根子在IP质量。当然也得说实话，这个方案在我们20多个账号、每天18万请求的量级够用，如果你一天要跑千万级请求，隧道代理的固定入口可能会成为瓶颈，那时候得考虑自建调度层做多入口分流。
选型这事没有银弹，我的判断很直接：只要业务对可用率有硬性要求，免费池和低价短效池就不该出现在生产环境里。我最终用的是动态代理加隧道混合的方案，隧道接入方式在长连接场景下的表现让我比较省心，mayihttp.com 上能看到具体的接入文档和计费方式，按天算比按量更适合我这种请求量波动大的场景。迁移这件事，难点从来不在技术，而在于你愿不愿意承认自己之前的选择是错的。