上个月团队开会，讨论要不要把房价采集这块的代理预算从0调到每月600。争了四十分钟。反对的理由很直白：免费IP列表网上到处都是，为什么要花钱。支持的一方拿不出数据，只能反复说"感觉不稳"。最后我拍板先跑两周再定，反正验证成本比吵架低。
背景是这样：我们做房产类关键词的排名监控，同时抓竞品房源站的挂牌价，这两件事其实是同一套采集管道——31个省会及重点城市，每城每天约2000条房源。SEO那边看的是"XX房价"这类词的排名波动，得和实际房源数据对齐，所以IP必须能落到具体城市，否则拿到的搜索结果本身就是别的城市的。
免费池的问题不是慢，是"脏"
我最初的假设是免费池太慢。跑了三天日志才发现，速度根本不构成主要矛盾。
第一天用某公开列表的213个IP，24小时内还能响应的只剩67个，可用率31%。更麻烦的是归属地：213个IP里能确认落在目标城市的只有17个，占8%。这意味着我们要的武汉房源，抓回来的可能是郑州的挂牌信息，而字段里看不出区别——价格、面积、户型全都合法，只有小区名对不上。这批脏数据混进报表，SEO同事拿去做排名相关性分析，结论直接跑偏。
说实话这个坑踩了两次。第一次以为是解析规则问题，改了两天xpath；第二次才定位到是IP归属地漂移。免费池的IP大多是回收机房段，注册地和实际出口对不上是常态。做国内代理IP选型时，这条比任何宣传参数都值得先验证。
选型：把"城市级"当硬指标，池子大小反而次要
重新选型时我把评估维度砍到四个：可指定城市比例、24小时可用率、握手延迟、单次请求成本。什么"3000万IP池""覆盖365城"的说法先放一边——池子再大，调度给你的IP落不到目标城市，等于零。四档方案我各跑了72小时，数据如下。
| 维度 | 免费公开池 | 短效动态 | 隧道代理 | 静态住宅 |
|---|
| 可指定城市比例 | 8% | 92% | 城市级可选 | 95%（省会为主） |
| 24h可用率 | 31.0% | 96.4% | 99.9% | 98.2% |
| 平均握手延迟 | 780ms | 45ms | <10ms | 62ms |
| 单次成本 | 0 | 0.0022元/IP | 16元/天 | 0.6元/IP/天 |
短效动态和隧道各有用处。短效动态按量计费，适合详情页这种一次一换的场景；隧道代理是服务端自动分配IP，不用自己维护池子，适合列表页翻页这种需要连续会话的活儿。我当时图省事全上了隧道，结果详情页一天两万次，账单比预想高出一截，第二周改回混合模式。
切换：先灰度三个城市，代码只有十几行
没敢全量切。第一天只放北京、成都、西安走新通道，老通道继续跑，两边数据落不同的表，用小区名做比对。操作顺序是这样：
- 把城市名映射成服务商的城市编码写成字典，避免每次手填；
- 请求层加城市校验：返回的小区名如果不在该城市行政区划表内，直接丢弃并记一条脏样本日志；
- 设置熔断：连续5次失败或单IP连续3次403，该IP冷却10分钟；
- 每天凌晨用前一天成功率生成报表，低于90%的城市自动告警。
核心逻辑就这么点，关键在城市参数和重试策略：
CITY_CODE = {"北京": "110000", "成都": "510100", "拉萨": "540100"}def fetch(url, city, retry=3): for _ in range(retry): proxy = get_proxy(CITY_CODE[city]) # GET /api?city=510100&count=1 if not proxy: return None try: r = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=8) if r.status_code == 200: return r.text except requests.RequestException: continue return None
有个不太常见的坑：部分西部城市在动态池里没有独立节点，只能落到省会。做拉萨、西宁的时候，指定城市参数返回空，接口不报错，只是默默给一个随机IP。不做校验的话你会以为采集成功，其实拿的是外省数据。这类城市后来单独走了隧道通道。
14天后的账：成功率翻倍，一天21块6
| 指标 | 免费池（第1–3天） | 迁移后（第8–14天） |
|---|
| 单城房源采集成功率 | 41.3% | 97.1% |
| 平均单页耗时 | 2.4s | 0.38s |
| 城市不匹配的作废样本 | 63% | 2.1% |
| 日覆盖城市 | 9/31 | 31/31 |
| 日成本 | 0元 | 21.6元 |
日成本21.6元，一个月六百出头，比当初争论的预算还低一点。迁移第三天才发现，抓取失败重试消耗的机器时间折算下来，并不比这笔钱少。
真正让我意外的不是成功率，是因城市不匹配作废的样本从63%降到2.1%。之前那份"房价波动与关键词排名相关性"的报告一直不显著，换成干净数据后相关系数从0.11跳到0.47。原来不是分析方法错了，是数据源一直在骗人。
我们的混合方案现在跑在 mayihttp.com 的池子上，主要图它城市参数能精确到地级市，西部几个节点也确实有独立出口。如果非要给个判断顺序：先测目标城市在池子里有没有独立节点，再测该节点的24小时可用率，最后才比价格。顺序反过来，大概率白花钱。