当你的自动化脚本突然开始触发 CAPTCHA 挑战时, 诱惑就是去寻找你上次没有尝试过和希望的隐形库。这就是为什么人们最终在六个月内通过五个不同的隐形插件进行循环, 并且仍然不知道实际的变化。
更好的方法是诊断:找出七种信号中哪一种正在标记你的会话,修复信号,并飞船。这个指南在顺序检测系统中穿过七种信号,首先对信号进行加权——最可能说明问题——并指示你们如何孤立地测试每一个信号。目标是在生产CAPTCHA的速率猛增时,在15分钟内给大家一个清单。
检测系统为何提出CAPTCHA挑战
CAPTCHA 挑战在于输出,而不是原因. CAPTCHA 检测系统(Cloudflare Bot Management, DataDome, Akamai, hCaptcha 的风险引擎, reCAPTCHA Enterprise, 或针对供应商的堆)读取您的会话信号矢量, 并判定风险分数超过一个阈值. CAPTCHA 发布概率基于信心,而不是基于单一规则的确定性.
涉及两个方面:
- 同样的代码可以在星期一传递,在星期五失效 因为模型进化了 或者另一个使用你隐形签名的舰队被标记了
- 如果关闭两个信号, 处理一个信号是不够的。 检测系统将信号组合起来。 一个带有标记的IP 的干净指纹仍然触发; 一个带有标记的IP 的干净指纹仍然触发。
诊断方法是相继的:确定哪些信号是当前对你的加权最高的,先固定这些信号,然后重新验证。下面的信号是根据公共反机器人研究中观察到的重量模式和生产故障排除中最常报告的故障模式,按照对风险分数的典型贡献来排序的。
7 个要检查的信号, 按顺序
信号 1: 语言 × 时区 × IP 地理不匹配
这是信号#1,因为它是最常见的无声故障,也是最容易验证的. 侦测系统交叉引用三个值:
- 浏览器
Accept-Language标题和navigator.languages - 浏览器报告的时区( Q) :
Intl.DateTimeFormat().resolvedOptions().timeZone) - 连接的IP地理( 数据中心、 居民、 国家、 地区)
柏林一个真正的用户 de-DE 或 en-DE, Europe/Berlin一个通过法兰克福住宅代理的美国英国Chrome 送来 en-US, America/New_York,以及德国的IP——一种检测系统专门寻找的连贯性故障.
如何检查:
打开您的自动浏览器并访问一个像 browserleaks.com/ip 和 browserleaks.com/javascript。比较三个值:IP位置、时区和语言。它们应该描述一个一致的地理。
如何纠正:
如果将代理和指纹分开配置,则每次必须手动对齐所有三个。结构定律是配置带的代理路由——在提供时间将代理与指纹捆绑在一起的运行时间,因此地理自动保持连贯。请见我们 浏览器运行时间指南 为什么这层很重要
信号2: Canvas, WebGL, 音频指纹再利用
这是信号#2,因为即使单个会话看起来很干净,也会破坏多账户机队。同一机器上的两场会话会产生相同的帆布回读,相同的WebGL渲染器字符串,以及相同的音频上下文输出。对于一个检测系统来说,“1,000个与帆布相同的散列和旋转的用户代理”是一个试图看起来像许多的特性。
如何检查:
运行 creepjs (或任何开源指纹检查) 在两个不同的会话中比较画布、 WebGL 和音频散列。如果两个会话产生相同的散列,您的机队会遇到指纹重复使用的问题。
如何纠正:
每个会话都需要在引擎级别上生成一个独特的,内部一致的指纹描述文件. Page级补丁(stealth 插件)可以添加噪声来画布回读,但通常不能在规模上产生完全不同的,连贯的描述文件. 完整目录中的表面问题在我们 浏览器指纹指南.
信号3:TLS / JA3 / JA4指纹
这是信号 #3,因为它运行在您的应用程序代码之下. 在每次HTTPS连接开始时发送的TLS Client Hello有一个可指纹的形状——密码顺序,扩展列表,支持的曲线——生成一个JA3或JA4散列. 不同的Chromium版本产生不同的散列;建立TLS手握自己的自动化库(而不是通过Chromium)产生不匹配任何真实浏览器的散列.
如何检查:
访问 tls.peet.ws 从您的自动浏览器中返回连接的 JA3 和 JA4 散列。 与同一OS 上的香草色素的 JA3/JA4 相比, 它们应该匹配。 如果您的自动化库正在生成自己的散列, 则失败就是了 。
如何纠正:
使用一个浏览器运行时间,使用基础的Chromium TLS堆栈而不是单独的HTTP客户端。如果您使用绕过浏览器的HTTP/scraping库,则这最为相关;通过CDP,完全基于浏览器的自动化通常会正确继承Chromium的本土TLS指纹.
信号4: navigator.webdriver 和其他自动化旗帜
这是4号信号,因为它是最基本和最常用的处理方式——但也是一种已经可探测到的patchs本身。默认 Playwright/Puppeteer Chromium会设置 navigator.webdriver = true。隐形插件覆盖到 false. 精密的检测系统已经开始读取超载的manner(定义非可定义,在原型链上呈现等)本身作为信号.
如何检查:
在您的自动浏览器控制台中,运行:
console.log(navigator.webdriver);
console.log(Object.getOwnPropertyDescriptor(navigator, 'webdriver'));第一个应该是 false (或 减 减 ) undefined );第二个应该匹配真实浏览器的描述图案。
如何纠正:
引擎级补丁(在 Chromium 二进制内部的修改) 会产生无法与真实浏览器区分的属性描述符. 通过 JavaScript 注入的 Page级补丁具有特征模式。 这是基于插件的二进制运行时间超标的隐形的几个原因之一 。
信号 5: 页面加载后的行为模式
这是信号 # 5 , 因为它只在指纹阶段过后才会被踢入。 一旦页面加载, 行为检查就会开始: 鼠标移动 entropy, 滚动图案, 动作之间的时间, 窗体输入上的键盘键盘。 用鼠标零路径按精确坐标单击的自动化, 每个字符的键盘为50ms, 并在表单出现后提交200ms, 单从行为即可检测出来 。
如何检查:
将自动化的动作跟踪与手动交互的动作跟踪进行比较。 差异通常很明显: 真正的运动有曲线、 加速、 短暂的暂停、 偶尔的误击。 自动化有直线和统一的时间。
如何纠正:
添加行为差异: 鼠标路径比齐尔曲线、 时间紧张、 翻转速度和减速速度, 点击前偶尔在页面元素上暂停。 库 playwright-extra 等效的工具有帮助者来做这个。现实的天花板是“看起来像一个细心但有点匆忙的人”——而不是“从任何随机用户那里都看不到的”。
信号6:WebRTC IP泄漏和DNS泄漏
这是6号信号,因为它是代用自动化的无声杀手,具体来说. WebRTC的STUN协议即使浏览器在代理机后面,也可以透露本地IP地址——没有明确的处理,你的"法兰克福住宅"会话通过ICE候选人泄露其真实的旧金山数据中心IP. DNS分辨率可以同样做到,如果浏览器的DNS通过本地解析器而HTTP通过代理机.
如何检查:
访问 browserleaks.com/webrtc。该页面报告本地和公开的 IP WebRTC 披露。两者都应该与您的代理匹配。如果本地 IP 显示您真实的机器网络,则您会发现 WebRTC 漏水。 请检查 browserleaks.com/dns DNS 等价货币。
如何纠正:
标准缓解正在迫使WebRTC进入仅中继模式——但这本身是作为隐私意识或自动化配置而观察到的. 更清洁的固定是运行时间,通过HTTP流量的同一代理处理WebRTC和DNS的路由,默认情况下不需要操作员配置.
信号 7: 无头模式告诉
这是信号 #7,因为它只在无头部署中相关——但是它是单个最大的"在dev中的工作,在生产中失败"失败. 无头 Chrome在指纹上与头部有额外的差异:缺少插件(零插件可疑),音频输出不同,默认视图不同,某些渲染路径产生潜移不同的输出,以及(直到最近)一个字节 HeadlessChrome 在用户代理中表示符号。
如何检查:
在本地和无头生产环境中进行同样的指纹检查。 比较每个表面。 您发现的区别是生产检测系统所看到的。
如何纠正:
使用一个运行时间来显示无头/无头的等效设计 —— 无论模式如何, 指纹值都是一样的, 插件列表都包含在内, 并且报告的 Chrome 版本是一致的。 如果您的堆栈使用无头的 Chromium 和隐形插件, 请计划逐个调试每个表面 。
15分钟诊断工作流量
当CAPTCHA升分时, 按顺序处理。 大多数失败都以前三个信号之一解决 。
-
打开自动浏览器,访问
browserleaks.com/ip和browserleaks.com/javascript比较IP地理、时区和Accept-Language。如果它们不描述一个一致的国家,那么你的问题是信号 #1. 确定一致性,并重新确认一致性,然后继续前进。 -
在您“ 不同” 的两次会话中运行同样的指纹检查。 比较画布、 WebGL 和音频散列。 如果它们匹配, 您的问题就是信号 # 2 —— 指纹重复使用。 机队是单一的身份, 直到您修复它 。
-
访问
tls.peet.ws并将JA3/JA4与同一OS上的香草色素比较。 错配是信号#3。 -
单机检查
navigator.webdriver及其财产描述符。 一个非标准描述符是信号#4。 -
跟踪自动交互。 直线鼠标路径和统一时间是信号 # 5. 添加行为差异 。
-
访问
browserleaks.com/webrtc和browserleaks.com/dns. 与您的代理不匹配的本地IP是信号#6. -
如果无头:将所有6个信号在头(局部)和无头(生产)之间进行比较。 差异是信号#7。
如果你已经通过所有7个工作,并且CAPTCHA的费率仍然很高,剩下的原因通常是整个机队的行为关联性(例如,跨会话的同步动作)或与费率相关——也就是说,你从太短的窗口里从太少的IP发送过多的流量,这些是操作问题,而不是堆栈问题.
关于更深层的Cloudflare特定故障模式,见 为什么剧本被Cloudflare屏蔽。关于评估哪个浏览器工具最能处理这一层,请参见我们对 AI代理自动化的7个最佳浏览器.
CAPTCHA 诊断中常见的错误
依次尝试每个隐形插件
通过隐形插件进行循环,而不测量每个容器的信号。运行诊断,识别失败的信号,然后选择专门处理这些信号的固定。“尝试不同的隐形库”不是一个诊断策略。
假设脚本已更改
如果您的代码没有改变, 回归是环境 : 目标站点更新检测规则 , 您的IP 池被列入黑名单 , 您的隐形库得到模式匹配 , 或者您的容器的无头建筑漂移 。 将环境分解, 而不是代码 。
将每个CAPTCHA作为检测失败处理
一些网站作为政策向每届新会话发布一个基线CAPTCHA,无论信号如何。如果你的CAPTCHA率是非零但稳定且适中,这也许是合法的——问题在于该率是否与真正的用户所看到的一致,而不是是否为零.
解决CAPTCHA 而不是阻止它
CAPTCHA-溶解服务存在并有合法用途,但大规模解决CAPTCHA是缓慢和昂贵的。通过确定身份一致性来防止触发对大多数工作流程来说是更快和便宜的。溶解器适合诊断后不可减少的残留率,而不是替代诊断。
数周内忽略CAPTCHA率
在一个月中从5%升至15%至30%的CAPTCHA率是一个缓慢的漏泄 — — 通常是指纹或行为模式随着检测模型的演进而逐渐更加突出。 通过作为衡量标准来尽早捕捉到这个速度,而不仅仅是在会话中断时的反应。
常问问题
为什么我的剧本会在当地工作 但会触发CAPTCHA的制作?
最常见的原因是环境漂移:本地开发使用您的住宅IP,您的实时时区,以及您的开发者-机器指纹,而生产则运行在一个Linux 容器中,其数据中心代用符后面,可能具有不同的时区,地方和指纹表面。固定是一个运行时间,在两种环境中都会产生相同的身份——信号#1,#2和#7通常都涉及其中.
有没有办法能绕过CAPTCHA?
没有。 没有浏览器配置、 插件或运行时间可以普遍绕过 CAPTCHA 。 现实的目标是通过修复导致 CAPTCHA 的上游信号来降低 CAPTCHA 的触发速度。 之后仍然收到 CAPTCHA 的会话需要退役或解决 。
我应该使用CAPTCHA解析服务吗?
对于CAPTCHA是稀有残基且每个解码只有几分钱可以接受的低容量案例,是的。 对于CAPTCHA出现在大多数会话中的高容量自动化,答案是首先固定诊断信号 — — 高速解决CAPTCHA是昂贵和缓慢的,通常会打破工作流程的经济学.
住宅代管人单独解决CAPTCHA触发吗?
不. 住宅代理部分修补信号 # 1 (IP 地理块) , 但留下指纹, TLS, 行为, 和无头语的信号没有被更改 。 住宅代理对于一些站点是必要的, 并且对于大多数站点来说是不足的 。
检测模型更新的速度有多快?
持续地,在实践中,主要的反机器人供应商至少每周更新模型,有时每天更新,这就是为什么"半年前奏效"不是一个可靠的基线——每堆都需要不断测量诊断信号,而不是一次性设置.
结论:诊断胜过审判和错误
CAPTCHA 失败感觉像一个单一的问题,因为症状无论原因如何都是相同的。现实是需要单独诊断的七个不同的原因。处理这个井的团队将堆积像一个具有可测量信号的工程系统一样处理;挣扎的团队将堆积像一个谜一样通过尝试随机修正来解决。
结构模式在所有7个信号中都是相同的:最高的杠杆固定是浏览器二进制的特性一致性,每个会话都有指纹配置和存储的代理绑定,该模式同时处理信号1,2,4,6和7,只留下3(TLS,通常从Chromium继承)和5(行为,需要管弦系统的工作).
Clawbrowser 用于处理结构层。引擎级指纹生成、配置图封装的住宅代理,以及命名区隔离在一个设计选择中处理大部分诊断。关于完整的集成模式,请参见 Clawbrowser文档.
继续阅读
