Selenium 总是被 Cloudflare 阻止?这就是指纹实际捕获的内容(以及如何停止触发它)
Source: Dev.to
请提供您希望翻译的具体文本内容(文章正文),我将为您翻译成简体中文,并保留原有的格式、Markdown 语法以及代码块和链接不变。谢谢!
Cloudflare 实际检测的内容
Selenium 的 ChromeDriver 至少以三种可观察的方式泄露自动化标志:
navigator.webdriver === true— 设计上即暴露,WebDriver 规范要求如此- CDP 客户端签名 — ChromeDriver 使用特定的 RPC 模式包装 Chrome 的 DevTools 协议,可通过
Target.*调用的时序和顺序检测到 - 缺失的浏览器 UI 信号 — Selenium 启动 Chrome 时没有生成真实用户始终会产生的某些可访问性/窗口事件
Reddit 线程中一条热门评论对其做了很好的概括:
“Selenium 通过 ChromeDriver 或 GeckoDriver 二进制文件运行,任何不想让机器人访问其网站的正规公司都可以对其进行指纹识别。这并不意味着 Selenium 有问题——它只是并非为你想要的用途而设计。Selenium 的目的在于自动化测试。”
评论推荐的方案(以及实际可行的方案)
| 工具 | 功能 | 注意点 |
|---|---|---|
undetected-chromedriver | 修补 WebDriver 标志 + CDP 字符串 | Cloudflare 会定期推送更新,每隔几个月就会重新检测它 |
SeleniumBase CDP mode | 跳过 ChromeDriver,直接使用 CDP 与 Chrome 通信 | 在大多数 Cloudflare 网站上有效;每个浏览器仍然占用一个进程 |
curl_cffi | 冒充浏览器的 TLS JA3 指纹 | 不执行 JS —— 在使用 React 水合的站点上会失效 |
nodriver / zendriver | 无无头的 Chrome,使用修补的 CDP | 适合小规模;在 100 万页时资源消耗大 |
| Real Chrome + stealth profile | 实际的 Chrome 可执行文件,持久化配置文件,Cookie 能保存 | 大多数反机器人服务的假设 |
下面我将展示的就是最后一行所列的方案——也是我一直在使用的。
实际结果
这两个捕获来自 相同的浏览器进程,相同的机器,相同的 IP。唯一的变量是指纹配置。
我现在是这样做的
我一直在使用 browser-act —— 一个使用持久隐身配置文件驱动真实 Chrome 的 CLI。一个命令:
# Install (uses the skills package registry):
npx skills add browser-act/skills --skill browser-act
# Open a Cloudflare‑protected page in a stealth session:
browser-act --session scrape browser open https://target.site
browser-act --session scrape get markdown > out.md
该配置文件在运行之间会保留 cookie 和存储,因此“预热浏览器”的信号(历史记录、localStorage、之前的 CF cookie)看起来像真人。对于 r/webscraping 提问者的规模问题(约 1 M 页面),你可以使用一组配置文件 ID 并轮换使用——但那是另一个帖子的话题。
值得争论的事项
- 如果你的目标是 Cloudflare Turnstile(而不是完整的 JS 挑战),情况就不同了——
curl_cffi加上注入的 widget 可以工作,正如 r/webscraping 的某个回复所示。 - 如果你已经有 Selenium 代码且流量不大,
undetected-chromedriver是最便宜的入门方案。 - 住宅代理几乎和浏览器指纹同等重要。如果你的 IP 属于数据中心 ASN,浏览器层面的一切都救不了你。
如果你现在正面临这个问题,欢迎告诉我你在访问哪个站点以及被拒绝的情况——我很乐意交流经验。完整讨论请见 r/webscraping 原始帖子。