linux.do

弄了个过 Cloudflare Turnstile 验证码的插件

第一次在论坛分享技术贴，分享一下最近折腾 Cloudflare 验证码的经历，还请各位大佬多多包涵。

缘起

一切都源于前几天刷到了 jack 大佬（https://linux.do/u/jackzzs）
好几篇帖子。看着这个该死的验证码，我心里就燃起了一股无名火：我就非得点你一下吗？于是，一场折腾就此拉开序幕。

最开始，我只是简单修改了 DrissionPage 中关于 screenX 和 screenY 的代码，再配上一个简单的服务端，就能跑起来了。

现有插件的局限性

我平时爬虫需求不多，主要还是浏览器用得多。我调研了市面上的插件，如 Capsolver、YesCaptcha 等，发现它们几乎无一例外都是通过服务端计算 token 或 cf_clearance 来实现的。更关键的是，支持 cf_clearance 的插件寥寥无几。

科普一下： Cloudflare 的验证码主要分为两种：

1. Turnstile：嵌入在网页中的人机验证模块。
2. 五秒盾 (Challenge)：强制跳转的质询页面。

经过我的测试，五秒盾的风控等级要比嵌入式的 Turnstile 更高。市面上的这些付费插件，不仅价格不菲，实际体验也相当一般。

回合一：前端 JS Patch 的失败尝试

既然现成的不行，那就自己动手！

我最初的想法是直接 Patch 掉 Turnstile 的 turnstile.render 和 turnstile.reset 等关键函数。然而，当我使用 Object.defineProperty 进行 Patch 时，却发现 Cloudflare 的验证码根本无法正常加载。

深入研究 api.js 后，我才发现那个经过混淆的脚本，在最后会执行一个判断："turnstile" in window。这一下就让我的 Patch 方案彻底失效了。接着，我又尝试 Proxy 整个 window 对象，但这个方案显然也是不可行的（window 对象不可被代理）。最后，我只能尝试用 setInterval 来暴力轮询，期望能在它 render 之前完成 Patch，但每次都竞争不过 Cloudflare，屡战屡败。

回合二：注入 Injected.js 的困境

此路不通，另寻他法。

我想到可以直接将一个 injected.js 脚本注入到验证码的 iframe 内部，当判断是 Cloudflare 验证码时，就向我的服务器发送请求。但这个方案很快也遇到了瓶颈：除了 sitekey，我根本无法获取到其他必要的 extra data。这导致我的脚本只能通过一些最简单的验证码，体验极差。五秒盾的延迟非常明显，有那等待的时间，我自己早就点完了。

我想，为什么我要绕这么大一圈去处理 token 呢？为什么不直接模拟人的行为，自动点击那个复选框呢？

回合三：CDP 自动化点击

于是，我将目光转向了 CDP (Chrome DevTools Protocol)。

我参考 DrissionPage 的原理，利用 CDP 命令来模拟点击。理论上这完全可行。在经过一番 Prompt 和 Debug 后，一个基于 CDP 的点击脚本基本成型了。

但新的问题又来了：

1. event.isTrusted：简单的 JS 模拟点击会被 event.isTrusted 轻松识破，这个参数能明确区分出是真实用户操作还是脚本行为，直接堵死了纯前端 JS 注入的路。CDP 则可以绕过这个问题。
2. 加载时机：纯粹使用 CDP，我无法准确知道复选框（Checkbox）何时加载完成可以点击，只能靠延时等待或轮询，效率低下。
3. Shadow DOM：由于 Shadow DOM 的隔离机制，我无法从外部 JS 直接获取到 iframe 内部的元素，这让精确定位变得异常困难。

最终突破：Element.prototype.attachShadow 带来的胜利

如何才能精准监控元素的加载状态和位置？

最终，我找到了一个堪称完美的解决方案：Patch Element.prototype.attachShadow。

核心思路是：在目标 DOM 元素创建 Shadow DOM 的那一刻进行拦截，构建一个“假”的 iframe 并获取其引用。这样一来，即使后续 shadowRoot 的模式被设置为 closed，我们依然能持有其内部元素的引用。

通过这个方法，我成功实现了：

● 精确监控：实时获知复选框何时加载完毕。
● 精准定位：准确获取复选框的点击坐标。

至此，一个体验相当不错的自动化点击版本终于完成了！唯一的“缺点”可能就是需要用户授予 debugger 权限，这或许会带来一些安全风险，但对于自用来说，完全可以接受。

----------------------

一些未来的构想与终极方案

在折腾的过程中，我也思考了一些更根本的解决方案：

1. 编译定制版 Chromium 内核：

● 直接在源码层面修改 event.isTrusted 的判断逻辑、开放 shadowRoot 的访问权限等。但这种方法成本极高，而且谁也无法保证 Cloudflare 没有其他更奇特的检测手段。

1. 逆向 api.js 并进行中间人攻击 (MITM)：

● 这应该是最优雅、最强大的终极方案。通过 MITM 劫持对 challenges.cloudflare.com 的请求，然后用我们自己逆向分析后的逻辑直接返回验证结果，甚至可以做到让用户完全看不到验证码的出现。不过，这需要极高的逆向工程能力，开发成本巨大。

1. 截图 + AI 视觉模型：

● 将当前页面截图，发送给一个多模态大模型，让它识别并返回复选框在屏幕上的精确坐标，然后通过 CDP 进行点击。这个方案在技术上是完全可行的。目前没有采用的主要原因是，大模型的响应速度还不够快，而验证码的实时性非常重要，太慢了还不如自己动手点。

感谢能看到这里的各位！附上一张自动通过 Cloudflare 官网验证码的图片，给大家乐呵一下。

致谢 gemini-2.5-pro,gpt-5-high 🤣

后面先自用看看能维持多久不死，并且不知道还会不会有什么bug，再考虑给大伙用上，各位有什么其他过turnstile的好想法也欢迎交流！

8 posts - 6 participants

Read full topic

via LINUX DO - 最新话题 (author: tenacious)

Invalid media: image

57 views12:33