组里那台跑了两年采集任务的机器，日志里开始出现这种东西：
GET /api/price?sku=xxx → proxy 103.xx.xx.xx:8080 ConnectTimeout(3s) → retry 3/3 → give up，漏采
我们做的是跨境电商比价，每天要抓10万+ SKU 的价格、库存和促销标签，竞品分布在六个站点。这套系统从立项起就用一份免费代理列表加自建轮换脚本，没花过一分钱代理费。前一年半它确实能用，直到今年二季度，业务方半夜在群里甩了张截图：某个竞品三小时前就降价了，我们页面上还是旧价，客服被用户投诉了两轮。
先别急着换服务商，先算清楚漏在哪
我一开始的判断是“IP不够用”，准备直接加预算买池子。后来花了两天把采集日志按小时拆开，才发现方向错了——免费池的问题不是数量，是延迟方差。同一批请求里，P50 只有120ms，P99 却飙到3.2秒；我们的超时设的是3秒，等于每次批量跑都有一小撮请求注定失败，而且失败集中在早10点和晚8点两个抓取高峰。
第二个坑更隐蔽：可用率按小时看只有62%，但脚本是随机抽IP、失败重试三次，实际表现被“重试”掩盖了，表面上成功率还有92%，代价是整体耗时翻倍。第三个是我最没想到的——免费池的IP基本没有会话粘性（同一会话内保持同一个出口IP），登录态一断就得重新握手，某些站点直接判定异常。比价还需要城市级定位，免费池给的IP归属地漂移得厉害，抓到的区域价根本对不上。
说到底，免费代理在几千请求/天的量级是“能用”，到了10万量级，它把你所有的不确定性都放大成了业务事故。
三档候选方案，在64并发下跑了一周
我没有直接拍板买贵的，而是拿同一份2万 SKU 的任务，在64并发、超时1.5秒、重试2次的统一配置下，把三档方案各跑了一周。测试脚本没改采集逻辑，只换了出口层。
| 方案 | 中位延迟 | P99延迟 | 可用率 | 漏采率 | 单请求成本 |
|---|
| A：自建免费池 | 120ms | 3200ms | 62.3% | 8.1% | 0元（人力另计） |
| B：低价数据中心代理 | 95ms | 780ms | 91.5% | 2.7% | 0.0009元/IP |
| C：商业动态+隧道混合 | 8ms | 210ms | 99.9% | 0.4% | 0.0022元/IP起 |
B 档看着便宜，但跑到第三天就露馅了：数据中心IP段被目标站批量标记，可用率从前两天的95%掉到78%，而且城市级切换只有十几个大城市可选，区域价比对直接失真。C 档贵了两倍多，可用率稳在99.9%，延迟基本贴着机房内网。我的判断很简单：漏采率从8.1%压到0.4%，等于每天多拿回7700条有效价格，这个价值远超那点代理费。
改造本身不复杂，出口从“读本地文件随机取”改成“API提取+账密认证”两条通道并行，隧道代理承接高频的列表页，动态短效IP承接详情页。这里有个细节值得说：把超时从3秒降到1.5秒，配合P99 210ms的池子，重试次数从2次降到1次就够，整体吞吐反而涨了约30%。
切换别一把梭，熔断阈值要先定死
灰度按5%→30%→100%走了三天。中间出过一次事：第二档灰度时我把熔断阈值设成“连续失败5次切换通道”，结果详情页在某个站点被限流，连续失败触发了频繁切换，通道来回抖动，反而把延迟打高了。后来改成失败率口径：滑动窗口200次请求内失败率超15%才熔断，冷却60秒，抖动就没了。这个参数在我们这个量级够用，再往上到百万级请求，窗口就得按通道分桶算了。
- 先切列表页（无登录态，容错高），观察48小时漏采率
- 再切详情页，同时把并发从64压到48跑一轮，确认不是池子撑不住而是脚本卡住
- 最后关掉旧通道，但保留脚本开关，出问题能10分钟内回滚
迁移后一周的数据：漏采率0.4%，平均单SKU采集耗时从410ms降到96ms，早高峰没再出现过批量超时。业务方那边最直观的感受是价格延迟从3小时缩到20分钟以内。我们现在的配置是隧道代理16元/天起承接主力，动态IP按量补充，接入用的是API提取加白名单双通道——这部分是在 mayihttp.com 上做的，选它主要是因为城市级切换能精确到区，比价必须用得上。
回头说句实话：这两年省下的代理费，大约等于我这次迁移花掉的人力成本的三分之一。免费方案不是不能用，是它把成本从账单挪到了你看不见的地方——重试、漏采、客服投诉，还有凌晨三点被叫起来看日志。