Selenium 总是被 Cloudflare 阻止?这就是指纹实际捕获的内容(以及如何停止触发它)

发布: (2026年4月23日 GMT+8 11:32)
5 分钟阅读
原文: Dev.to

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 原始帖子

0 浏览
Back to Blog

相关文章

阅读更多 »