那次跑到一半全挂掉的采集任务
去年双十一前一周，帮一个做数码配件的朋友盯竞品价格。任务是三百多个商品详情页，每半小时跑一轮，连着跑三天。脚本本身不复杂，requests 加个解析，本地测的时候一路绿灯。
真正上量之后问题来了：前一百多个页面顺顺当当，从第两三百个请求开始，返回的 HTML 里验证码框、空白页、跳转中间页混着来。当时脚本写得很随意，抓到什么就解析什么，没做细分判断，最后导出的价格表缺了将近四成，还有几个 SKU 的字段直接是空字符串。等我反应过来回头补，那天的价格曲线已经断了。
排查下来，解析逻辑一个字没错，问题出在IP上——手里那批IP被目标站点反复识别，前面用得太密了。这件事之后我才真正理解，代理IP的稳定性，从来不是"能不能连上"这么一层意思，而是"连着跑八小时之后还能不能连上"。
别只看连通率，这四个数字才是重点
很多人挑代理，第一步就是打开测速页，点一下"检测"，看到绿油油一片就下单了。那一刻测出来的连通率意义不大——你测的是五十个IP各请求一次，而你的任务是一千个IP各请求五十次。这两件事完全不是一回事。
我判断一个付费代理稳不稳，会盯下面四个东西：
第一是可用率，但要拉长时间看。宣传页上写的可用率，通常是瞬时抽样。我习惯自己跑四小时以上的连续探测，记录每个时间窗口的成功请求占比。有些资源第一小时 99%，第四小时掉到 70%，这种曲线比一个漂亮的平均值有用得多。
第二是延迟的波动幅度。平均 300ms 听着还行，但如果抖动是从 80ms 到 3000ms，你的任务节奏会被拖得很乱——超时设置短了误杀，设置长了整轮被卡住。看 P95 那个数字，比看均值靠谱。
第三是IP纯度。同一个IP池里，有多少是干净没被标记过的。纯度低的池子，你会遇到一种很烦的现象：刚提取的IP，第一次请求就被拦了。这不是你用法有问题，是这IP之前被别人用废了。
第四是高并发下的衰减。20 个线程跑得飞起，不代表 200 个线程也能跑。我一般会做阶梯测试，把并发从 20 加到 50、100、200，看成功率在哪一档开始明显滑坡。这条曲线决定了你实际能跑多大的任务量。
| 观察维度 | 看什么 | 不达标时的典型表现 | 电商比价场景的参考线 |
|---|---|---|---|
| 可用率 | 连续 4 小时以上的成功请求占比 | 前一小时正常，后面大量超时 | 持续保持在 99% 以上 |
| 延迟波动 | P95 响应时间与均值的差距 | 忽快忽慢，任务节奏被打乱 | P95 与均值不超过 3 倍 |
| IP纯度 | 首次请求即被拦截的比例 | 新提取的IP一上来就返回验证页 | 首次请求通过率接近全量 |
| 并发衰减 | 线程数翻倍时成功率的变化 | 过了 60 线程就大面积失败 | 200 线程下仍能稳定出数 |
三步自测，半小时就能看出大概
纸上说的都不算数，自己动手测一遍最实在。这套流程我用了两年多，不需要什么工具，一段脚本加一张表格就够了。
第一步，抽样长跑。从接口里取 50 个IP，别用完就换，就这 50 个反复请求同一个商品页，每隔 5 分钟打一次，跑足 4 小时。记状态码、耗时、返回体长度。返回体长度这个字段特别有用——长度突然砍半，八成是被塞了验证页面。
import time, requests
PROXY = "http://你的账号:你的密码@代理地址:端口"
TARGET = "https://目标站的某个商品详情页"
for i in range(10):
t0 = time.time()
try:
r = requests.get(
TARGET,
proxies={"http": PROXY, "https": PROXY},
timeout=10,
headers={"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"}
)
cost = round((time.time() - t0) * 1000)
print(i, r.status_code, f"{cost}ms", len(r.text))
except Exception as e:
print(i, "fail", type(e).__name__)
time.sleep(5)
把打印结果存成表格，跑完之后算两列：成功率、耗时的 95 分位值。这两个数字一出来，池子的成色基本就摆在那儿了。
第二步，并发阶梯。写个简单的线程池，把并发分别设成 20、50、100、200，每一档跑 100 个请求，记录成功率。如果 100 线程还能稳在 98% 以上，日常的比价任务就够用了；200 线程直接掉到六成，那说明这个套餐的上限比你想的低。
第三步，核对归属地。电商比价最怕的就是"以为换了城市其实没换"。请求一次返回自身出口地址的接口，看返回的城市字段，跟你参数里指定的城市对不对得上。我见过不少资源说支持城市级定位，实际给定的还是几个大区的IP，参数填了等于白填。
电商价格监测这类活，对IP有几个额外要求
不是所有"稳定"都长一个样。同样是跑采集，比价任务有它自己的脾气。
同一个 SKU，你今天要看、明天还要看、大促当天一小时要看三遍。这意味着池子必须经得起反复回访同一个目标，IP得换得开，不能今天用的和明天用的是一个段。
再一个是地域。同一件商品，不同地区的标价、库存、满减门槛、配送时效，差别可能不小。想看到真实的页面效果，就得让请求从目标城市发出去，靠一个外地IP拿回来的数据，参考价值要打折扣。
还有时段性。大促前两小时和平时凌晨的站点校验强度完全不同，池子要能扛住这种短时的压力峰值，而不是在被加压的第一分钟就露出破绽。
这几个要求叠在一起，其实就指向两件事：IP得干净且量大池深，定位要细到城市这一层。
后来换的神龙HTTP，稳在哪
朋友那边的项目最后迁到了神龙HTTP。选它的原因不算复杂，主要是几项硬指标对得上我们测出来的需求。
一个是规模。3000万+正规授权代理IP储备，国内三大运营商正规授权，池子够深意味着同一批目标反复回访时，同一类IP被重复消耗的概率低得多，配合官方公布的IP纯度 99.8%，那种"新IP一上来就被拦"的糟心情况明显少了。协议上 HTTP / HTTPS / SOCKS5 都支持，脚本里改个参数就能切过去，不用重写代码。
另一个是定位。300+城市级精准定位对我们太关键了——参数里指定哪个城市，回来的就是哪个城市的出口，本地价格、库存、配送时效这些字段才有意义。实测下来这一点是对得上的，这也是当初决定迁过去的主要原因。
还有个小细节挺省心：个人中心里有可视化的用量统计和实时监控，哪个时段请求量冲高、异常集中在哪类目标上，一眼能看出来。以前全靠自己写日志拼表，现在打开页面就有大概的判断。API 也兼容主流的爬虫编程语言，官方给了文档和示例代码，接进去差不多半天的事；技术团队 7×24 小时在线，遇到回调异常的问题时找得到人。
常见问题
Q：代理测出来可用率 99%，为什么我实际跑起来还是经常失败？
先看你的失败是不是集中在某一个时间点。如果是任务刚开始的十分钟内就大面积报错，多半是IP纯度的锅，新提取的IP本身已经被污染了。如果是跑了一两小时后开始恶化，那更可能是你的请求频率超过了目标站的容忍度，需要降低单IP的请求密度，或者换一批新鲜IP接着跑。还有一种容易忽略的情况：超时设置得太短，把正常但稍慢的请求也判成失败了，回头看一眼超时的分布再下结论。
Q：短效动态IP、长效静态IP、固定IP代理，比价任务该用哪个？
大部分比价场景用短效动态IP就够，请求完就换，池子轮转得快，适合大规模地反复看同一个页面。如果需要对某个店铺做长时间、跨整点的连续观察，比如盯一个秒杀价从预告到开抢的全过程，长效静态IP更合适，连接不会中途断掉。固定IP代理更多是用在需要长期稳定的白名单类对接上。神龙HTTP这三条产品线都有，可以先各拿一点做对比测试，用不着一次定死。
Q：自己写脚本测稳定性，要跑多久才有参考价值？
四小时起步，最好跨过一次流量高峰。只测十分钟，你测的是运气不是稳定性。我一般会选在下午两点到六点这段跑，这个时间段目标站点的访问压力比较真实。另外记得把结果存下来，别只盯着屏幕上滚过去的日志，回头对比才有意义。
Q：怎么判断一个代理服务是不是真的能定位到城市？
不看宣传话术，看返回值。发一次请求到能显示出口地址的接口上，看返回的省市字段跟你参数里指定的城市是否一致，连测二十次统计一致的比例。一致率低于八成，说明所谓城市级定位更多是个说法。神龙HTTP这块我们在项目里连续核过多次，参数指定城市后出口基本落在同一个城市，这是我们最终选择它的关键原因之一。
