上个月我一个人坐在电脑前，把第三张免费代理来源的表格删了。物流追踪这个项目是我接的私活，实时查8家快递公司的轨迹接口，按单号轮询，一天大概8万次请求。前两个月用免费代理扛着，第三次全线被封之后，我知道该重新算账了。
说实话我之前一直觉得付费代理是“智商税”，免费池子换勤快点不就行了。真正跑了一周数据才发现，免费代理的综合成本比我预想的高得多——不是钱，是每天花在切换和维护上的时间。
先拆需求：物流查询到底要什么
在选型之前我列了三条硬指标，依据是前两个月的失败日志。
- 并发量：8家快递接口并行查询，峰值需要40-60个并发连接。低于这个数，轮询队列会积压，轨迹数据延迟到分钟级就没意义了。
- 单IP请求频率：多数快递公司接口对单IP的容忍度在每分钟120-200次之间，超了就返回403或者直接空数据。我实测某通系接口在150次/分钟后开始风控。
- 会话保持：查询一个单号的完整轨迹需要连续3-5次请求，如果中途换IP，有些接口会校验会话一致性，直接报错。
这三条一摆出来，免费代理基本出局了——免费池子能同时满足并发和会话保持的概率，我测下来不到5%。
三档付费方案实测：从0.0022元到16元/天
我按预算分了三个档位跑对照测试，每档跑48小时，每天固定8万次请求，记录成功率和延迟。测试时用的是同一份查询脚本，只换代理接入方式。
| 方案档位 | 接入方式 | 平均延迟 | 可用率 | 单请求成本 | 封禁后恢复 |
|---|
| 按量动态代理 | API提取 | 180ms | 99.2% | 0.0022元 | 秒级换IP |
| 隧道代理 | 固定入口+账密 | 95ms | 99.9% | 16元/天 | 自动轮换 |
| 独享静态IP | 白名单绑定 | 60ms | 99.5% | 按IP月付 | 不可换 |
注意这张表里的延迟数字，隧道代理的95ms比我预想的低不少。我一开始以为API提取的按量方案会更轻快，毕竟IP是现拿现用，结果跑下来反而是隧道代理稳定。原因后面会讲。
独享静态IP延迟最低，但我没选——因为物流接口的风控是按IP累计频率算的，静态IP跑满两天就被盯上了，换IP的成本比省下来的延迟值钱。
最终方案和两个没料到的坑
我选了隧道代理打底，按量动态代理做备用池。配置上用的是账密认证，把并发控制在50，单IP每分钟请求压在130次以下，留了安全余量。接入代码核心就几行：
proxies = {
"http": "http://user:pass@tunnel-host:port",
"https": "http://user:pass@tunnel-host:port"
}
resp = requests.get(url, proxies=proxies, timeout=8)
第一个坑：隧道代理的并发上限。我买的档位标称支持100并发，实测跑到65左右就开始出现连接排队，延迟从95ms飙到400ms以上。后来把并发压到50才稳定下来——这个数字商家页面不会写，得自己压测。
第二个坑更隐蔽：城市级IP反而拖累了成功率。物流接口多数不校验地域，我一开始贪心开了城市切换，想让请求看起来更“自然”，结果不同城市的IP段质量参差不齐，成功率从99.9%掉到97%。关掉城市切换、只用运营商级轮换之后才恢复。这个教训是：不是所有场景都需要精细地域，物流查询这种业务，IP干净比IP像真人更重要。
上线两周后的账
现在跑了14天，日均8.2万次请求，整体成功率99.7%，平均延迟108ms。成本算下来每天16元的隧道费加上少量按量补充，折合单次请求约0.0025元，比纯按量方案贵了12%，但省掉了我每天手动换IP的一个多小时。
回头看我之前对免费代理的执念，本质是没把维护时间折算成钱。在线代理IP这个东西，选型的核心不是池子多大，而是你的业务曲线能不能被稳定兜住。物流查询这种高频、会话敏感的场景，隧道代理的固定入口反而比动态提取更合适。我目前在用的服务商里，mayihttp.com的隧道方案在延迟和可用率这个维度上表现最稳，3000万+IP池和全国365+城市的覆盖对物流这种全国性业务也够用。如果你也在跑类似的查询项目，建议先压测并发上限再决定档位，别信标称值。