先贴一段代码。这是我三个月前跑物流轨迹查询的主循环，现在回看，问题很明显：
while True:
ip = free_pool.pop()
r = requests.get(TRACK_API, params={"no": waybill},
proxies={"http": ip, "https": ip}, timeout=3)
if r.status_code != 200 or "验证" in r.text:
free_pool.append(ip) # 塞回去，下次接着用
continue
这段逻辑跑了两小时，成功312次，弹出5次滑块，其中一家快递的接口直接把我的出口IP也拉黑了。当时的判断特别朴素：池子不够大。于是我又爬了800条免费IP补进去，结果更糟，成功率反而掉到40%以下。问题根本不在数量上——这是我后来做了对照实验才确认的事。
一、实验怎么设计的：600个运单，四种代理源
场景是我自己维护的一个小工具，用户把运单号丢进来，后台定时轮询四家快递的轨迹接口（顺丰、中通、圆通、极兔），未签收的单号每1.5秒查一次。请求频率高、目标接口少、单号还带业务连续性——这三个特征叠在一起，对代理质量的要求比一般采集高得多。
实验设定：
- 样本：600个运单，四家快递各150个，6小时内累计约4800次请求
- 判定：HTTP 200 且响应体含“物流轨迹”关键词算成功，出现滑块或验证码页单独计数
- 分组：A 免费公开池1200条、B 低价数据中心代理0.008元/IP、C 按量动态代理0.0022元/IP起、D 隧道代理16元/天
- 四组使用完全相同的关键词、Header 和轮询间隔，只有出口不同
说实话，做这个实验之前我赌的是 B 组能赢——便宜、量大、延迟也还行，性价比看着最高。
二、6小时跑完的数据，和我想的不一样
| 代理源 | 成功率 | 平均延迟 | 验证码触发 | 单次成功成本 |
|---|
| A 免费公开池 | 41.2% | 820 ms | 187 次 | ≈0元（耗时3倍） |
| B 低价数据中心 | 76.5% | 310 ms | 64 次 | 0.0105 元 |
| C 按量动态 | 96.8% | 68 ms | 6 次 | 0.0023 元 |
| D 隧道代理 | 99.1% | 45 ms | 1 次 | 0.0034 元 |
B 组是这次实验里最反直觉的一组：单价只有 C 组的四分之一，但按“每次成功请求”折算，成本反而高出4.5倍。原因是失败请求也要计费，加上验证码要重试，实际消耗的IP数是名义上的3.2倍。
A 组更荒诞。看着零成本，但为了拿到312次成功，我额外跑了近3000次失败请求，还手动处理了两轮拉黑——按我自己的工时算，那天下午等于白干。
三、根因不在池子大小，在出口集中度
我把四组请求的响应头和代理来源都记了下来。A 组那1200条免费IP，去重后只落在63个C段、9个ASN里，而且大半来自三个已知的云厂商段。B 组500条IP更极端，挤在4个机房段内。
物流接口的风控并不傻，它不看单条IP，看的是IP段和ASN的聚合行为。63个C段意味着什么？意味着风控只要对一个段做速率限制，我这边就同时损失几十条“不同”的IP。你以为你在换IP，其实在同一个桶里舀水。
C 组的动态IP分布在365个城市、三大运营商的住宅和移动网络上，段位分散，单条IP用完即弃。这是它能跑到96.8%的核心原因，跟“池子有多大”关系不大——3000万这个数字对我这种日请求不到2万的小项目，根本用不满。
四、迁移后的配置：并发8是个分水岭
换到付费代理不等于万事大吉。我第一版迁移直接把并发从5提到20，结果429错误率飙到23%，比用免费代理还难看。压测后的拐点数据是这样的：
- 并发20 → 429率23%
- 并发12 → 429率9.6%
- 并发8 → 429率4.1%
- 并发5 → 429率3.9%（收益已经很小）
所以稳定配置最终定在并发8、超时3秒、重试2次、指数退避1s/3s。另外踩到一个坑：隧道代理默认3分钟换一次IP，而同一个运单的查询跨了IP会被接口当成两个会话，轨迹返回不完整。改成会话粘滞10分钟后，重复查询率从17%降到2%。
还有一个细节，不同快递的接口风控强度差异很大，顺丰和极兔明显更严。我给四家快递分配了独立的出口组，不让它们在同一个IP池里互相“污染”——这个做法在日志里能直接看出来，混用时的整体成功率比隔离低6个百分点左右。
五、成本账和我的选型结论
按每天4800次请求算：C 组按量动态约11元/天，D 组隧道代理16元/天，两者的差距没有想象中大。日请求低于2万、且运单不需要长会话的，按量提取更划算；超过2万或者需要保持同一出口做连续查询的，隧道代理的稳定性溢价是值得付的。
现在 C 组跑的是蚂蚁代理（mayihttp.com），API提取和隧道两种模式可以混着用，这点对物流这种“高频短查询+少量长会话”的混合场景很实用，实测延迟稳定在10ms以内。我不太关心它宣传的3000万IP池——真正留住我的是失败不计费的部分能对账清楚，这在小团队做成本核算时比什么都重要。
最后一句给同样从免费池迁出来的朋友：别先问哪家池子大，先算你自己的“单次成功成本”。我那次实验里，最贵的方案看起来是免费的。