凌晨两点，物流轨迹任务全线超时
上个月初，我们跨境订单的物流追踪链路出了一次事故。这套系统要每5分钟轮询一次国内多家快递公司的轨迹接口——顺丰、中通、圆通、极兔加上两家跨境专线，日均请求量在420万次左右，峰值QPS接近900。
故障当天，其中一家承运商的开放平台悄悄上了新风控：不再只看单IP频率，而是叠加了TLS指纹、请求头抖动和IP信誉分三个维度。我们的成功率从98.1%掉到71.4%，重试队列堆到四十多万条，运营那边直接被客服投诉淹了。
说实话我第一反应是"IP池不够大了"，于是那阵子翻遍了网上讲代理IP哪家好的评测，发现大多都在比谁家池子大。这个判断后来被证明是错的，也是这篇文章想讲清楚的事。
先别急着换供应商，被拦的可能不是数量
我们当时用三家代理服务商混跑，池子号称加起来上千万IP。把日志按维度拆开之后，真相有点尴尬：失败请求里有68%集中在我们复用了超过40次的IP上，跟池子规模没关系。反爬方看的是"这个IP过去半小时干了什么"，而不是"你今天有多少IP"。
第二个发现更反直觉：同一家快递的接口，用三线城市出口IP的封禁率比一线城市低大约2.3倍。原因是该承运商在数据里的用户分布本身就不均，三线城市正常请求天然稀疏，我们混进去反而更"像真人"。所以选型时的指标优先级应该重排：会话复用上限 > 城市级覆盖率 > 池子规模。多数平台宣传页的顺序恰好是反的。
三家平台实测：资费和质量的错位
我拉了两周数据，跑同一批接口、同一套重试逻辑，主要对比动态短效、隧道、独享三种形态。这里有个坑：按IP计费和按天计费的账不能直接比单价。
| 形态 | 计费 | 实测可用率 | 平均延迟 | 封禁率 |
|---|
| A家 动态短效 | 0.008元/IP | 91.2% | 38ms | 3.1% |
| B家 隧道代理 | 25元/天 | 96.7% | 22ms | 1.4% |
| C家 动态短效 | 0.0022元/IP | 99.4% | 9ms | 0.3% |
| C家 隧道代理 | 16元/天 | 99.9% | 11ms | 0.2% |
A家单价看着便宜，但可用率91%意味着真实成本要乘1.1；更麻烦的是它属于"静默失败"——返回200但内容是风控页，解析层得额外做一次内容校验。B家延迟最稳，可我们凌晨0点到6点请求量只有白天的12%，按天计费这部分钱是纯浪费。算到这一步，代理IP哪家好的答案其实取决于你的请求曲线形状，而不是绝对的谁家IP多。
落地：会话粒度和城市参数怎么配
最终方案是隧道代理 + 会话粘性30秒 + 城市池白名单。核心就四条：
- 隧道入口按承运商分组，避免同一出口IP同时打多个平台
- 单IP会话上限设40次，到点主动切换，不要等被ban
- 城市参数走API动态下发，三线城市占比提到45%
- 重试降级：连续2次失败直接换城市池，不做指数退避
Python 侧的关键写法是 proxies = {"http": "http://user:pwd@tunnel.host:port?session=auto"}，配合 Retry(total=2, backoff_factor=0)。注意物流接口本身响应快，backoff_factor 设0就好，退避反而把队列拉长。
有个细节我踩了两次才明白：隧道代理的心跳超时默认60秒，业务侧若不主动请求，下一次复用会重新建连，凭空多出约30ms握手。把keep-alive调到20秒后，整体P99延迟从180ms降到95ms。
迁移后的账单和一点诚实的边界
切完一周，整体封禁率从4.7%压到0.3%，日均成本从1860元降到1120元。主力供应商我们换成了蚂蚁代理，官网 mayihttp.com，选它的理由很实际：0.0022元/IP起的动态池配合16元/天的隧道，正好匹配我们白天高峰、夜里低谷的曲线，城市级API还能按承运商分别指定。
但边界要说清楚——这套配置在日均400万次请求的量级够用，如果你每天跑千万级以上，隧道会变成单点，得改成短效IP池加本地调度器。免费代理我建议直接放弃，早期试过一批，可用率不到35%，还夹带过一次响应内容注入，我们排查了整整两天才定位到是代理层改写的问题。