目标网站的成功率下降,验证页面开始出现,合理的第一反应是你的IP被封了。有时候确实如此。但很多时候并非如此,而这个区别很重要,因为应对方式截然相反:一个需要更换地址,另一个需要放慢速度而不改变其他任何东西。
还有一个结构性的问题会重新定义整个局面。在轮换的住宅IP池上,你并不拥有这些地址,所以没有地址可以”修复”。所谓恢复,意味着让下一个请求被接受,而实现这一点唯一持久的方法,是找出上一个请求被拒绝的原因。
首先,确认这确实是封禁
有四种情况从外部看起来相似,但含义各不相同。
速率限制是暂时的,与请求节奏有关。它通常以429状态码宣告自己,有时附带Retry-After,只要你放慢速度,它就会自行解除。用更换地址来应对这种情况是典型的错误做法,因为以相同的节奏从全新的地址持续发送请求,正是把限流变成更持久问题的做法。
封禁是针对地址或会话的拒绝:验证页面、持续出现的403、插页式页面。这才是换用全新身份真正有帮助的情况。
软封禁是最危险的一种,因为它返回200状态码。验证页面、通用结果、被截断的列表、或跳转到落地页,这些都可能被解析成看起来像数据的内容,而一个只统计状态码的流水线会报告”健康”,实际上却什么也没采集到。如果你没有验证响应内容本身,你根本无法把这种情况与真正成功区分开来,详见检测被封禁或伪造的内容。
自身的程序错误值得尽早排除。格式错误的用户名标志会返回407,过于狭窄的过滤条件会返回502,解析器的变更也可能让正常页面看起来是空的。这些都不是封禁。
快速测试方法:用一条完全不同的线路请求同一个URL,最好是不同的国家,并且用普通连接。如果全部都失败,说明目标网站本身有问题,或者你的请求形态有误。如果只有你的生产线路失败,那你就确实遇到了身份问题。
然后确定问题的范围
问题的规模能告诉你原因有多深。
单个会话失败而其他会话成功,这是正常现象。淘汰这个会话,换一个新的标识符,继续运行即可。在轮换池上这种情况持续发生,除了构建代理管理器中描述的自动淘汰机制外,不需要任何额外干预。
单条线路退化,意味着某个目标网站和国家的组合的成功率下降了,而其他线路保持正常,这指向你接触该目标网站的方式出了问题。这是常见且有意思的情况,也是本文接下来要讨论的重点。
某个目标网站的所有线路都失败意味着该目标网站更改了防护措施,或者正在发生事故,无论怎么轮换都无济于事,除非你改变观察方式,而不是改变来源。
所有目标网站同时失败几乎从来都不是封禁。在考虑其他因素之前,先检查你自己的部署、凭证和网络。
线路级别的健康状况正是让这种诊断变得快速而非靠猜测的关键,这也是大规模监控代理健康状况一文的论点所在。
即时应对
当一条线路确实被封禁时,本能反应是加大力度。应该反其道而行之。
**停止向该线路发送请求。**继续猛攻一个正在拒绝你的目标网站,只会加深问题,浪费带宽在你无法使用的响应上,而且你接触的每一个新地址也会被标记,从而扩大损害范围。断路器应该自动执行这一步骤,而不是等人来处理。
**不要激进地重试。**对一个正在封禁你的目标网站发起重试风暴,是把局部问题变成全局问题最快的方式,这就是为什么重试需要预算和分类,而不是一个循环,详见重试与退避。
**等待。**大多数封禁是有时限的。几十分钟到几小时的冷却期通常就能完全解除状态,而在冷却期内恢复请求会重新启动计时。
**更换身份,而不仅仅是地址。**如果封禁是由你的表现方式而非来源地址造成的,单单更换地址并不能改变任何真正重要的东西。
找出真正的原因
封禁来自四个方面,按大致出现频率的顺序来检查是值得的。
**节奏。**请求过多、过于规律,而来源地址又太少。完全均匀的间隔本身就是一种信号,因为人类流量本就是突发且不规律的。解决方法是降低单个地址的请求速率、加入抖动、扩大分布范围,详见速率限制与请求节流以及你到底需要多少代理IP中的分布数学计算。
**请求形态。**头信息与你声称使用的浏览器不符、缺少客户端提示、Accept-Language与你的出口国家矛盾、或者TLS指纹显示是Python而User-Agent却显示Chrome。这些是矛盾而非缺失,而且很容易被检测出来,详见设置正确的请求头以及匹配地理位置、时区和语言环境。
**行为。**以任何人都不会采用的顺序访问端点、从不加载浏览器本该加载的内容、在流程中途更换身份、或以机器速度爬取分页序列。只有脚本才会采用的操作序列,往往会被识别为脚本。
**地址质量。**有时候问题确实出在IP池本身:信誉不佳的地址无论你的行为如何都会招致验证挑战,而一个被数据中心IP稀释、号称住宅IP的池,表现起来就和数据中心IP一模一样,详见识别被当作住宅IP出售的数据中心IP。
如果一条线路被封禁,而你的节奏和请求形态都站得住脚,这时地址质量才应该成为主要的假设,而不是最先假设的原因。
恢复而不重蹈覆辙
以糟糕的方式恢复,正是一个已解决的封禁变成反复出现问题的原因。
从金丝雀测试开始,而不是直接恢复完整任务:通过一个全新会话发送少量请求,并妥善验证,以确认目标网站是否再次接受你的请求。如果通过了,逐步提升速率而不是立即恢复到之前的水平,因为立刻回到导致问题的那个节奏本身就是一种可识别的模式。在恢复之前先改变一些东西,无论是节奏、请求头、会话策略,还是地理位置,因为原样恢复相当于赌这次封禁是随机的。并且在提速过程中持续观察经过验证的成功率,这样你能在最初几分钟内发现问题,而不是等到第二天早上。
如果经过这一切之后,某个目标网站仍然持续表现出敌意,那么诚实的选择是降低对它的期望、换一种方式接触它,或者接受它不值得付出这个代价,这正是爬取防护严密的网站一文中的升级逻辑。
结论
首先区分这四种容易混淆的情况,因为用轮换应对速率限制只会让情况变得更糟,而把软封禁当作成功来统计则完全无法察觉。确定问题范围,因为单个会话失败是正常现象,单条线路退化是值得找出原因的问题,而所有情况同时失败通常是你自己的部署问题。当一条线路确实被封禁时,应该停止而不是硬推,不要对着它重试,等待冷却期,并更换身份而不仅仅是地址。然后按可能性顺序找出原因:节奏、请求形态、行为,最后才是IP池质量。用金丝雀测试和逐步提速来恢复,同时改变一些东西,并在此过程中观察经过验证的成功率。在轮换池上,地址从来都不是资产;真正的资产是访问权,而访问权是靠表现得普通来赢得的。
拥有一个干净的地方来恢复运行,正是住宅代理所提供的:一个由真实家庭级地址组成的庞大IP池,支持国家和城市级定位,让被淘汰的会话得到替换而非重复使用,配合按GB计费的定价方式,让规范的恢复流程比固执的重试更划算。