上周有个做电商价格监测的朋友问我一句话：花三千多买的代理，跑了两天，成功率从 90% 掉到 20%，找客服只回"高峰期正常"。他合同签得很爽快，付款也走的对私转账，现在连个能追责的主体都找不到。
这种事在数据采集圈子里一点都不新鲜。代理IP这个东西看不见摸不着，你付钱之前能拿到的信息极其有限，所以"买得安不安全"，本质上是两件事：付钱前你有没有验过，付钱后合同有没有兜住你。下面这份清单，是我带团队这几年踩出来的顺序，照着走一遍，至少不会吃暗亏。
一、先别急着比价，先想清楚你要"哪种池子"
很多团队翻车，不是被骗，而是买错了品类。你去搜"代理IP"，跳出来的报价能差十倍：一百块一千个IP的有，一千块十万个IP的也有。差价往往不在服务好坏，而在于池子的性质完全不同。
简单分三种。第一种是共享池，几百上千人轮流用同一批出口IP，便宜，但目标站点早就把这批IP标红了。第二种是独享或半独享，IP分配给你一段时间内不回收，价格高一些，稳定性明显不同。第三种是长效静态，一个IP给你挂几天甚至更久，适合要保持登录态的采集任务。
采集量小、目标站点宽松，共享池凑合能用；做过反爬的站点、要跑长期任务、要对结果负责的，基本只能往后两种走。这一条想不明白，后面验什么都没意义。
二、付费前的四步验真，别跳过任何一步
正规服务商都愿意给你一个试用额度或者最小套餐，不愿意给的，直接跳过。拿到额度后按这个顺序测：
第一步，小样提取。不要一上来就买最高档。先用最小套餐连续提取三四次，每次提 20 到 50 个 IP，看看返回格式稳不稳定、返回速度是不是忽快忽慢。
第二步，去重核验。把几次提取的结果合在一起算独立IP占比。正常情况下，一个新池子连续提取 200 个，重复的应该很少；如果两次提出来一半以上是同一批 IP，那这个池子的真实规模大概率远小于宣传。
第三步，连通测试。拿这些 IP 去连一个稳定的公开站点，统计失败率。注意要在不同时间段各测一轮，上午、下午、晚上各一遍，因为很多池子白天好看，晚上崩。
第四步，存活打点。给每个 IP 记一个首次可用时间和失效时间，算出中位存活时长。短效动态IP本来就是分钟级，但如果你发现大量 IP 活不过 30 秒，那说明池子在被反复压榨。
下面这段是我常用的验真脚本，改一下提取链接就能跑，跑完直接出三个数：去重率、请求成功率、存活中位数。
import requests, time, statistics
API = "你的API提取链接" # 换取最小套餐的提取接口
def fetch(num=50):
r = requests.get(API, params={"num": num}, timeout=10)
r.raise_for_status()
return [x.strip() for x in r.text.splitlines() if x.strip()]
# 1. 连续提取三次，看去重率
all_ips, batches = [], []
for _ in range(3):
ips = fetch(50)
batches.append(len(ips))
all_ips += ips
time.sleep(2)
uniq = len(set(all_ips))
print(f"共提取 {len(all_ips)} 个，去重后 {uniq} 个，去重率 {uniq/len(all_ips):.1%}")
# 2. 抽样测连通率与存活时长
alive, life = 0, []
for ip in list(set(all_ips))[:30]:
start = time.time()
ok = False
for _ in range(3):
try:
p = {"http": f"http://{ip}", "https": f"http://{ip}"}
r = requests.get("https://www.example.com", proxies=p, timeout=8)
if r.status_code == 200:
ok = True
break
except Exception:
pass
time.sleep(1)
if ok:
alive += 1
life.append(time.time() - start)
print(f"抽样 30 个，可用 {alive} 个，成功率 {alive/30:.1%}")
if life:
print(f"存活时长中位数约 {statistics.median(life):.0f} 秒")
跑完你手里就有三个硬数字了，拿去和销售报的参数对一对。对不上不是问题，对不上还解释不清楚才是问题。
三、把"可用率 99.9%"拆成三个能测的数
几乎所有服务商都会写可用率，但极少有人告诉你这个数怎么算出来的。谈的时候直接问三句：是提取成功率还是请求成功率？统计周期是一天还是一小时？低于承诺怎么补？
一个成熟的采集任务，实际会碰到三个指标，含义完全不同：
| 指标 | 算什么 | 合理预期 | 掉下来意味着 |
|---|---|---|---|
| 提取成功率 | 请求提取接口拿到IP的比例 | 99% 以上 | 接口不稳，任务会卡在取IP这一步 |
| 请求成功率 | 拿到的IP能正常访问目标站的比例 | 90%~98%（看站点） | 池子被大量使用，或被目标站识别 |
| 有效存活时长 | 一个IP从拿来到失效的时间 | 短效 1~5 分钟 | 池子小、复用快，重试成本飙升 |
顺带提醒一句：请求成功率跟你采集的目标站点强相关，同一个池子跑宽松站点能做到 98%，跑风控严格的站点可能只有 70%。所以别拿服务商给的通用数字直接套自己的业务，自己测那一次才算数。
四、合同里必须写死的五项
验真解决的是"这批IP行不行"，合同解决的是"它不行的时候你怎么办"。这两件事缺一不可。签字之前，把下面五项逐条找出来，找不到就要求补。
1. 授权来源。正规服务商的IP资源来自运营商正规授权，这件事应该是能说清楚、写在合同或服务说明里的。含糊其辞说"自有资源"又说不出授权链条的，谨慎。
2. 可用率口径与补偿方式。写清楚指标定义、统计周期，以及没达标的处理方式——是补时长、补量，还是按比例退费。只写"尽力保障"等于没写。
3. 终止与剩余额度。项目中途停了，剩下的钱或额度能不能退、怎么退、多久到账。这一条在团队预算收紧的年份格外重要。
4. 合规责任边界。合同里应该明确用途限于合法的公开数据采集，同时写清楚双方在数据合规上的责任划分。这条看着像官话，真出事的时候是唯一的挡箭牌。
5. 服务响应。有没有明确的技术支持渠道、响应时限，7×24 还是工作日。半夜任务挂了没人应，等于没有支持。
五、付款和开票，别在这一步栽跟头
我见过最可惜的一单：产品没问题，测试也过了，结果打款打到了个人账户，后面要发票、要合同盖章、要走公司报销，全卡住。
三件小事，付钱之前确认掉：收款主体名称和合同主体、营业执照是不是同一个；发票类型和税率能不能开、多久能开；试用期产生的数据能不能延续到正式套餐里，别让测试白跑。金额大一点的，尽量走对公，留痕。
六、为什么不少采集团队最后落在神龙HTTP
说回实际选型。我们团队最后固定用的是神龙HTTP，最直接的原因是授权链条能说清楚——国内三大运营商正规授权，3000万+的代理IP储备，IP纯度 99.8%，可用率 99.9%，这些数字不是嘴上说说，测试期自己跑一遍对得上。
另一个让工程同学省心的是接入方式。API 兼容主流爬虫编程语言，文档和示例代码都给全了，改两行配置就能接进现有任务里；短效动态、长效静态、固定IP代理都在一个后台，不用为了一个任务去开三个账号。个人中心里有可视化的用量统计和实时监控，哪段时间失败率往上走了、哪个城市节点消耗快，一眼能看出来，排查比翻日志快得多。
再加上 300+ 城市级精准定位和低延迟高并发提取，跑全国门店价格监测这类任务时，按城市取IP不用自己维护映射表。技术支持是 7×24 的，半夜接口有波动，至少有人在。
七、一份可以照着执行的检查表
把上面的内容压缩成一张清单，签合同前打开对照，勾完再付款：
· 明确任务类型，选定共享/独享/静态哪一类
· 拿到试用或最小套餐，跑够三轮不同时段的测试
· 记录去重率、请求成功率、存活中位数三个数
· 要求书面说明可用率的计算口径与补偿方式
· 核对授权来源、合同主体、营业执照三者是否一致
· 确认退费规则、剩余额度处理、发票类型
· 确认技术支持渠道与响应时限
常见问题
Q：代理IP这么便宜，真的有必要花时间做这些都验吗？
看你拿它干什么。偶尔跑个小脚本，随便买买无妨；但如果采集结果要进报表、进模型训练、影响业务决策，一次错误的数据成本远高于省下的那点钱。验真的时间成本大概是半天，值。
Q：服务商说可用率99.9%，可我实测只有80%，是不是被骗了？
先分清是哪个指标。提取接口成功率 99.9% 和请求成功率 99.9% 是两回事，前者容易做到，后者跟你的目标站点关系很大。如果你测的是请求成功率且明显偏低，把测试日志发给技术支持，让他们看具体是哪批IP、哪个时间段，正常服务商会去查节点。完全不回应或者只说"正常波动"的，就要警惕了。
Q：合同里最容易被忽略但又最该写的是哪条？
剩余额度和终止条款。大多数人签约时只盯着单价和规格，真到项目缩编、任务停止的时候才发现钱退不回来、额度不能转。这条谈起来不难，但一定要落在纸面上。
Q：先买短效动态，后面能换成静态吗？
只要你选的服务商产品线齐全，通常可以在同一个账号下切换或叠加使用，短效跑通用采集、静态跑需要保持会话的任务，是很常见的组合。签约前问清楚切换规则和额度是否共用就行。
Q：测试期表现不错，上线后却变差，怎么排查？
先看自己的并发和重试策略，很多时候是代码里失败重试太猛，把同一批IP反复打到同一个站点上。排除了自身原因，再拿小样本单独测一次池子，把数据给到技术支持。有条件的话，把用量统计和实时监控打开，能省掉大半排查时间。
