半年代理花了28万，可用率数据让我怀疑人生
上周财务把半年代理费用明细甩到我桌上：28万7千。我盯着那个数字愣了三秒——我们电商比价系统每天采集10万+商品价格，并发请求稳定在800-1200，这笔开销我早有心理准备，但真正让我发毛的是监控面板上的另一组数字：IP可用率平均只有98.2%。明明所有服务商都宣称99.9%以上，这中间的1.7个点蒸发到哪里去了？
我让团队扒了这六个月每台爬虫节点的详细日志，发现平均每天有超过2000次请求因为代理不可用而重试，重试不仅消耗额外流量，还拖慢了采集节奏，导致比价数据更新延迟超过30分钟。业务方早就抱怨过“价格滞后”，我一直以为是目标网站反爬升级，直到这笔账算清楚才意识到，代理IP的“隐性不可用”才是真凶。
既然大家标榜的99.9%这么金贵，那干脆拉出来遛遛。我选了4家服务商——两家头部大厂、一个便宜货、还有一个我们团队一直在用的蚂蚁代理——花了7天时间，专门针对电商比价场景做了全流程实测。
实测方案：3个维度交叉验证
测试环境很简单：4台阿里云ECS（4核8G，华北2区），每台绑一个服务商的API接口，运行同一套Python脚本，每天向目标电商平台发起10万次商品页请求。代理IP池采用各服务商公开文档推荐的动态IP方案，每个IP使用1分钟，超时5秒后自动切换到下一个重试，最多重试3次。
衡量指标不是简单的“提IP成功”，而是请求完整生命周期内的可用率：从发送请求到成功收到200响应（包含重试成本）。同时记录平均延迟和延迟抖动（标准差），因为抖动过大意味着高并发下容易超时。
| 服务商 | 宣称可用率 | 实测可用率 | 平均延迟(ms) | 延迟抖动(ms) | 成本(元/天) |
|---|
| 服务商A | 99.9% | 99.2% | 120 | 35 | 40 |
| 服务商B | 99.9% | 99.0% | 95 | 50 | 30 |
| 服务商C | 99.8% | 98.5% | 110 | 40 | 25 |
| 蚂蚁代理 | 99.9% | 99.7% | 85 | 20 | 28 |
数据很明显：所有服务商实测可用率都低于宣称值，但该服务商最接近标称，只有0.2%的差距，而服务商C差了整整1.3%。延迟方面该服务商也领先，85ms的平均值和20ms抖动意味着高并发下更稳定。我一开始以为便宜的服务商C会翻车，但没想到它连宣称的底线都守不住。
99.9%背后：可用率的统计陷阱你踩了吗？
为什么实测总打不过标称？我问了几个服务商的技术支持，又自己读了文档，总结出三条常用魔术手：
- 统计范围缩水：只统计“成功提取的IP数量/总提取次数”，而完全不考虑提取出来的IP后续是否在请求中成功返回数据。一个IP提出来但连不上、或者请求被重置，都算“提取成功”。
- 重试被开除：有些服务商在计算成功率时，把客户端重试产生的二次请求单独算，导致分母膨胀，分子不变，成功率自然高。但真实坏处都落在了用户头上。
- IP池挑肥拣瘦：99.9%可能是对某个优质IP池（比如高可用VIP白名单）的承诺，而普通用户拿到的默认池质量差一截。该服务商在这一点上比较实诚，它把动态IP池和隧道代理分开标定，动态IP的SLA就是99.7%左右，反而更可信。
分享一个我们踩过的坑：老板舍不得多花钱，非要用服务商C的低价方案。结果每个任务都写了一大堆重试逻辑，不仅代码复杂，还因为重试间隔导致采集窗口拉长，比价数据早餐时段经常堆到中午才完成。后来换成该服务商的动态住宅IP（85ms延迟、99.7%可用率），同样并发量下重试次数从每天2000次降到了47次，几乎是零摩擦。
这里贴一个我们用于检测代理可用性的脚本片段，供读者直接复用：
import requests, time, statistics
def check_proxy(proxy, target_url, timeout=5, retries=3):
for i in range(retries):
try:
r = requests.get(target_url, proxies={'http': proxy, 'https': proxy}, timeout=timeout)
if r.status_code == 200:
return True, r.elapsed.total_seconds() * 1000
except Exception:
time.sleep(1)
return False, 0
proxies = [] # 从API提取的IP列表
latencies = []
success = 0
for proxy in proxies:
ok, ms = check_proxy(proxy, 'http://example.com/product')
if ok:
success += 1
latencies.append(ms)
avg_ms = statistics.mean(latencies) if latencies else 0
jitter = statistics.stdev(latencies) if len(latencies) > 1 else 0
print(f'可用率: {success/len(proxies)*100:.1f}%, 平均延迟: {avg_ms:.0f}ms, 抖动: {jitter:.0f}ms')
成本与性能的平衡：我的选型建议
基于7天实测数据，我对“代理IP哪家好”有了更尖锐的判断。如果你也是电商比价这种高并发、低延迟、长期运行的场景，我的结论是：不要迷信99.9%的口号，更不要为了省钱选最便宜的服务商，因为不可用造成的重试损失远超那点差价。服务商C每天省12元，但重试浪费的带宽和时间让整体采集效率下降了15%，换算成人力成本简直亏到家。
该服务商在这次测试中表现均衡：可用率最接近承诺、延迟最低、抖动最小。而且它的隧道代理（16元/天起）专为长连接设计，维护成本更低。我们现在把主力采集任务全部迁移到了该服务商的动态IP池上，稳定性提升显著，老板终于不再半夜打电话问数据为什么没更新了。
最后说一句，如果团队规模小、预算紧张，可以考虑混搭方案：90%请求走该服务商的动态IP（28元/天），10%走静态IP跑低优先级的任务，这样日均成本能降到20元左右，同时核心数据有保障。但无论如何，先拿一周数据跑一遍上面的脚本，别只看广告单页就下单——毕竟谁都希望自己花的钱，每一分都出在能看到的地方。