别再“盲猜”代理 IP 能用，数据采集真正要看这几个指标

最近那档医学职场综艺里，一句“我盲猜，肯定是……”火了。

带教老师马上追问：证据呢？

我不评价节目里的人，但看到这段的时候，我第一反应是：这句话放进数据采集群里，也毫无违和感。

我们组排查任务故障时，经常听见类似的话：

“我感觉就是 IP 被封了。”

“刚才不是还能打开吗？”

“状态码正常，数据应该没问题吧？”

“我盲猜，是目标网站抽风。”

感觉来得很快，证据一个没有。

更麻烦的是，代理 IP 选错了，不一定会有人当场叫停你。

程序照样运行，任务也没有彻底报错，只是成功率一点点往下掉，验证码越来越多，采回来的字段越来越少。

等你发现，半天任务已经白跑了。

能打开网页，不等于能跑数据采集

很多人测试代理 IP，方法相当朴素。

拿到代理地址，配置进浏览器，随便打开一个网页。页面出来了，IP 地址也换了，于是得出结论：

能用。

这其实只证明了一件事：这条代理在刚才那个时间点，能够打开那个测试页面。

至于它能不能稳定访问你的目标站，能不能连续翻页，能不能进入详情页，能不能扛住真实并发，跑半小时以后会不会大量超时，一个都没证明。

这就像体检只量了个身高，然后盲猜身体挺健康。

我们组现在测试代理，第一步不会急着看“IP 池有多大”“每天能提取多少个”这些宣传数字。

这些数字可以看，但不能替你完成业务验证。

你采集电商公开数据，就拿实际的列表页和详情页测试；你做招投标信息整理，就按真实的查询、翻页和详情访问流程测试；你做舆情监测，就在对应内容平台的公开页面上跑。

代理服务商的测试页再顺畅，也不能替你的目标网站作证。

当然，前提还是合规采集公开信息或已获授权的数据。技术上能访问，不代表什么数据都可以随便拿。

最危险的不是报错，是“看起来还在跑”

彻底报错其实没那么可怕。

连接超时、认证失败、请求被拒绝，这些问题至少足够诚实。程序一红，大家知道该停下来排查。

我更怕另一种情况：

任务没有停，数据也在不断写入，但请求成功率从九成慢慢掉到六成；列表页还能访问，详情页已经开始失败；前几十次请求正常，后面不断出现验证码；返回状态码是正常的，页面内容却只剩一个空壳。

表面上看，采集任务还活着。

实际上，它已经开始偷偷交废数据了。

之前我们组就遇到过一次。任务日志里没有大面积报错，数据库记录数量也一直在增加，大家一开始都觉得问题不大。

后来抽样检查才发现，部分详情页只采到了标题，价格、规格和店铺信息全是空值。

程序确实“成功”了。

只是成功地保存了一批残缺数据。

从那以后，我再看代理质量，已经不只问“请求通不通”，而是会继续追几层：

• 目标网站的真实请求成功率是多少；
• 列表页和详情页的成功率是否一致；
• 返回的是正常内容，还是验证码、登录提示和空页面；
• 连续运行一段时间后，成功率有没有明显衰减；
• 关键字段的完整率有没有下降；
• 同一条会话里的出口 IP 是否按预期保持。

这些问题答不上来，就不适合直接说“这批 IP 能用”。

最多只能说，目前还没测出问题。

这两句话，听起来差不多，实际差得挺远。

状态码正常，数据也可能是假的

做数据采集久了，大家都知道不能只看请求有没有报错。

但真到排查时，还是很容易盯着状态码不放。

状态正常，只能说明服务器返回了一个页面。它没承诺这个页面就是你想要的内容。

目标网站可能返回验证码页、访问频繁提示、登录页面、降级页面，甚至是一份结构完整但没有真实数据的空模板。

如果程序只判断状态码，没有检查页面标题、关键字段和内容长度，这些异常页面就会被当成正常数据保存。

最麻烦的是，记录数量还会继续上涨。

老板看报表，以为今天又采了几十万条。你打开数据一看，其中一部分只有链接和采集时间，真正有用的字段全没了。

所以我们组现在会把请求成功和数据成功分开统计。

请求成功，只表示页面有响应。

数据成功，还要确认页面类型正确、关键字段存在、内容结构没有明显异常。

在数据采集里，后者才是真正的成功率。

平均响应时间，也很会骗人

代理测试里还有一个特别容易制造错觉的数字：平均响应时间。

比如两批节点，平均响应时间都在两秒左右。看起来差不多，价格便宜的那批甚至更划算。

但把请求记录拆开以后，可能完全不是一回事。

第一批大部分请求都稳定在一到三秒。

第二批平时确实很快，却隔一会儿冒出一个十几秒甚至几十秒的长尾请求。

单看平均值，差距被抹平了。真放进采集任务里，第二批节点会频繁拖慢线程、占着连接不释放，最后把整个任务节奏弄得忽快忽慢。

你盯着监控看，会觉得程序像在打嗝。

所以别只看平均值。

至少要一起看中位响应时间、高分位响应时间和超时率。说得直白一点，不仅要看它平常有多快，还要看它倒霉的时候能慢成什么样。

偶尔抖一下很正常。

如果每隔几十次请求就卡一次，那不叫偶发，那就是这批线路的真实表现。

单线程能跑，并不代表并发以后还能跑

还有一种特别常见的误判：

测试脚本跑了十几个请求，全都成功，于是直接把代理接进正式任务。

正式任务一开，几十个线程同时往上顶，成功率立刻开始掉。

这时候有人说目标网站风控严，有人说代码连接池有问题，还有人继续盲猜代理服务商临时调整了线路。

其实原因可能很简单：之前的测试条件，和正式任务根本不是一回事。

单线程测试像一个人安静地进店买东西。

正式采集则像几十个人同时冲进门，还都在反复问同一个问题。

两种情况下的访问特征完全不同。

因此，代理测试至少要分两轮。

第一轮低并发跑，确认基本连通性、响应速度和内容正确性。

第二轮按照实际任务的并发量、访问频率和持续时间再跑一遍，观察成功率、超时率和验证码比例有没有明显变化。

如果正式任务计划连续运行几小时，就别拿五分钟测试宣布胜利。

跑得久，很多问题才会露出来。

像这种需要程序持续运行的任务，我通常会优先考虑国内隧道，而不是让脚本不停提取、检测和替换短效 IP。之前试的极安代理国内隧道还算稳，如果遇见节点不通畅会自动切换可用链路，接入之后少了一大堆节点维护的活儿，不用总盯着 IP 有没有失效。

不过自动切换只是减少维护动作，不代表可以跳过测试。目标站能不能稳定访问、连续运行后的成功率如何，还是得拿自己的任务跑一遍才知道。

我现在怎么判断一批代理能不能上任务

我的方法不复杂，核心就一句话：

先别急着问“能不能用”，先问“证据够不够”。

正式接入前，我一般会做下面几件事。

第一，直接测试目标网站

不拿普通网页代替真实业务，更不会只测试 IP 查询页。

测试流程要尽量接近正式任务，包括搜索、翻页、进入详情页和提取关键字段。

第二，跑一段连续任务

单次成功没有太大意义。

至少要观察成功率会不会随时间下降，是否越跑验证码越多，节点质量有没有明显衰减。

第三，把失败原因拆开

连接超时、访问拒绝、验证码、空页面和字段缺失，不是同一种问题。

如果全都混成一个“失败率”，后面根本没法判断该换代理、调频率，还是修改解析逻辑。

第四，检查数据完整性

状态码正常不等于采集成功。

标题、价格、时间、来源和详情内容这些关键字段，该有的必须有。缺失比例突然上升，本身就是异常信号。

第五，观察会话稳定性

需要连续翻页、保持登录态或完成多步访问的任务，要确认出口 IP 是否按预期保持。

别第一页还是一个 IP，翻到第二页就换了，最后还怪网站不认会话。

第六，记录代理与请求的对应关系

哪次请求用了哪个节点，返回了什么页面，耗时多久，是否触发验证，都应该能查到。

不然出了问题，大家只剩一句“好像有一批不太行”，想追都追不到。

第七，在真实并发下复测

单线程表现好，不代表正式任务也能保持同样的成功率。

测试时温柔得像打招呼，上线后把并发拉满，这种结果当然没有参考价值。

最后

数据采集不是答题节目。

遇到问题，抢答没有加分。最先喊出“肯定是 IP 的问题”的人，也不一定最懂排查。

真正有用的，是把感觉拆成一项项可以验证的假设：

到底从什么时候开始失败？

列表页和详情页，哪一层先出问题？

状态码正常时，返回的内容到底是什么？

降低并发、调整频率、替换节点以后，结果有没有变化？

采集数量增加时，关键字段的完整率有没有下降？

证据走到哪里，结论就说到哪里。

所以以后再有人看见网页能打开，就拍着桌子说“这批代理肯定能用”，我大概还是会追问一句：

证据呢？