之前发过一篇代理IP接入的帖子，评论区有人问怎么选服务商。正好最近帮团队做了一轮选型，把思路整理一下。
先说结论：别看参数表排序选。IP池3000万和100万，对大多数业务来说体感差距为零。真正影响你日常使用的是可用率、协议支持、计费方式和接入成本这几个维度。
为什么参数表选型容易翻车
大部分人选代理IP的流程是：打开几家服务商官网，把IP总量、城市覆盖、可用率、价格列个表格，按某个指标排序，选前几名。
问题在于，参数表展示的是最理想情况下的数据。我见过不少团队选完型半年内就换了服务商，原因不是参数造假，而是参数和自己的业务场景对不上。
举个例子：你的业务是物流信息查询，日均采集量2万次。这时候IP池3000万和100万对你的采集成功率没有任何可感知的差异。反而可用率差2个百分点、响应慢200ms这些"不起眼"的指标，天天在影响你的任务效率。
所以我的做法是：先用一个框架缩小候选范围到2-3家，再用实测做最终决策。
维度一：IP可用率
这是最核心的指标，也是最容易被误读的。
先厘清概念：IP可用率 ≠ 请求成功率。IP可用率衡量的是代理服务本身的质量（分配给你的IP里有多少是能用的），请求成功率还受目标网站反爬策略的影响。评估服务商的时候，要看的是前者。
我自己的经验基准：
- 99%以上：基本不用操心重试逻辑，大规模持续任务放心跑
- 95%-99%：每百次请求有几次要重试，可以接受但能感知到开销
- 90%-95%：重试成本开始明显上升，日均10万次请求的话，每天多出几千次无效请求
- 90%以下：不建议用于正式项目
一个直观的算法：可用率每掉1个百分点，重试开销大概增加8%-12%。日均10万次请求的场景下，99%和95%的差距意味着每天多4000次废请求，算上带宽和计算资源，一个月下来也是一笔钱。
官网标称值参考就好，最终以实测为准（后面会讲怎么测）。
维度二：协议覆盖
这个维度是门槛型的——有就行，不是越多越好。但如果缺了你需要的协议，后面全白搭。
三种常见协议的适用场景：
- HTTP：标准网页采集，几乎所有场景都用得到
- HTTPS：现在大多数网站都是HTTPS了，这个必须有
- SOCKS5：APP接口采集、非标准协议通信时需要
我踩过一个坑：选型时只拿网页采集场景做测试，上线后发现有几个APP接口需要走SOCKS5，结果当时选的服务商不支持，临时换服务商折腾了好几天。这种情况在航空、酒旅数据采集里特别常见，因为部分航司的数据接口用的是非标准协议。
评估方法很简单：把你当前和可预见的所有采集任务列出来，看用到哪些协议，然后确认候选服务商都覆盖。
维度三：计费灵活度
计费方式选错了，长期成本会比理论最优高出不少。
常见的三种计费模式：
按IP数量/天：按每天提取的IP总数计费，适合批量提取、短周期任务。风险是预估过高会浪费。
按时间包月/包年：固定周期费用，适合7×24持续稳定的采集任务。风险是任务中断期照样扣费。
按请求量：按实际请求次数计费，适合请求量波动大的业务。风险是量太大时单价可能阶梯上涨。
怎么选？我的做法是拉过去30天的实际采集数据（请求次数、IP用量、峰谷比），按三种模式分别估算月成本，选最低的那个。
这里有个关键指标：峰谷比。如果你的任务白天峰值是夜间的5倍以上，按请求量计费可能更划算。如果任务是均匀运行的，包月更稳定。
很多团队首次选型时直接选了服务商推荐的套餐，没做过这个对比测算，最后实际成本高出15%-30%的情况很普遍。
维度四：接入成本
这里说的不是钱，是你要花多少时间和精力把代理接进你的系统。
几个需要评估的点：
首次接入工时：从注册到跑通第一个请求要多久。隧道代理一般半天搞定，短效代理API提取的方式1-3天。
运维负担：短效代理需要你自己维护IP池、写轮换逻辑、处理异常，运维负担中等。隧道代理这些都在服务端，运维负担低。
文档质量：API文档是否清晰，有没有接入示例和FAQ。文档烂的服务商，首次接入时间可能翻倍。
技术支持：出了问题能不能快速找到人。尤其是晚上和周末跑任务时出故障的情况。
还有一个经常被忽略的隐性成本：代理层耦合度。如果你的采集代码里代理调用逻辑没做抽象，换服务商的时候就要到处改代码。建议首次接入时就把代理配置（入口地址、鉴权信息、轮换策略）封装成独立模块。我现在的项目都会做一层简单的代理抽象层，换服务商只改配置文件，不动业务代码。
怎么用这4个维度
我一般会给候选服务商打个分，1-5分，加权算总分：
- IP可用率（权重30%）：99%以上给5分，95%-99%给3分，90%以下给1分
- 协议覆盖（权重15%）：HTTP+HTTPS+SOCKS5全有给5分，缺SOCKS5给3分
- 计费灵活度（权重25%）：支持三种以上计费方式给5分，只有一种给1分
- 接入成本（权重30%）：半天跑通+文档完整给5分，三天以上+文档残缺给1分
权重可以根据业务调整。持续监控类的业务（舆情、版权保护），可用率权重往上调。短期项目或临时任务，计费灵活度的权重拉高。有多协议需求的，协议覆盖权重加大。
但不管怎么调，任何一个维度低于2分的，我会直接排除。
这个打分只是筛选工具，帮你从5-6家缩到2-3家。最终拍板还是要靠实测。
三步实测
第一步：连通性测试（10分钟）
向 httpbin.org/ip 之类的公开接口发50次请求，确认三件事：每次返回的IP不一样（轮换正常）、成功率100%（基本连通没问题）、响应时间记录一下平均值和P95。
这一步过不了的直接淘汰，没必要往下测了。
第二步：可用率实测（1-2小时）
用目标网站的真实URL发500-1000次请求。强调一下，一定要用你实际要采集的网站测，别用httpbin。代理IP在不同目标网站上的表现差异可能很大。
关注这几个数字：
- IP可用率 ≥ 95%
- 响应时间中位数 ≤ 500ms
- P95响应时间 ≤ 2s
- 403/429/503等异常状态码占比 ≤ 5%
第三步：场景实测（半天到一天）
模拟真实业务跑4-8小时，这一步主要看持续表现：
- 可用率有没有随时间衰减（有些服务商短期数据漂亮，跑久了就不行）
- 峰值并发下响应是否稳定
- IP切换过程中有没有断档影响采集连续性
- 实际计费消耗跟你的预估差多少
只有跑完这一步的数据，才能真正支撑采购决策。大部分服务商都有免费试用，拿来跑这个测试正好。
三个容易犯的错
只比单价不算总成本。 单价便宜但可用率低5个百分点的服务商，重试带来的带宽和时间成本可能把价格优势吃掉。正确的比法是算"完成1万次成功请求的总成本"，而不是"买1万个IP的单价"。
拿测试环境的数据做决策。 测试环境请求量少、并发低，代理IP的表现天然比生产环境好。实测阶段尽量模拟生产环境的量级和并发度，不然上线之后数据不一样。
不考虑切换成本。 选型时只想着"怎么选进来"，没想过"以后怎么换出去"。如果代理调用逻辑和业务代码深度耦合，将来换服务商的开发成本可能比一年的费用差异还大。所以前面说的代理抽象层，值得在第一天就做。
最后说一句：不存在"全场景最优"的代理IP服务商。同一家服务商在物流采集场景下表现很好，换到航空酒旅场景可能就一般。选型的本质是找"在你的场景下最适配的方案"，不是找"参数表上最强的那个"。
有问题评论区聊。
