无头浏览器检测：网站如何精准识别自动化 Bot

```html

你是否已经更换代理，并为每个配置文件设置了独立的浏览器指纹，却仍然遇到验证页面或网站访问限制？这说明浏览器环境管理并不只是修改几个设置那么简单。在每次访问过程中，网站都可能分析多种类型的数据，以判断访问者是真实用户还是机器人。

那么，机器人检测技术是如何运作的？反检测浏览器是否也会被检测出来？本文将介绍这些检测机制，以及影响网站识别自动化浏览器活动的因素。

1. 什么是无头浏览器？它与普通浏览器有什么区别？

无头浏览器是一种在没有可见图形界面的情况下运行的浏览器，通常通过 Puppeteer、Playwright 或 Selenium 等工具使用代码进行控制。它仍然能够像普通浏览器一样加载网页、执行 JavaScript 和发送请求。因此，网站需要检查浏览器环境及其运行方式的差异，才能识别自动化流量。

1.1. 无头模式、有头模式和自动化有什么区别？

要了解网站如何检测无头浏览器，首先需要区分两个概念：显示模式和浏览器控制方式。无头模式描述浏览器是否显示可见窗口，而自动化则指通过脚本控制浏览器。

以下是三种常见场景之间的区别：

关键在于，无头模式并不等同于自动化。即使浏览器显示可见界面，也可以通过 Puppeteer 或 Playwright 自动执行操作。反过来，没有可见窗口也不能直接证明浏览器正在执行机器人活动。

例如，以有头模式运行 Puppeteer 时，Chrome 仍然会打开普通浏览器窗口，但其中的操作可以由脚本执行。因此，网站不会只检查浏览器是否具有图形界面，还可能分析与浏览器控制方式有关的信号。

1.2. 新版无头 Chrome 与 chrome-headless-shell 有什么区别？

无头 Chrome 在不同版本中经历了几次重要变化。过去，无头模式采用独立的实现方式，并未与普通 Chrome 完全共享源代码。因此，无头环境存在一些差异，机器人检测工具可以利用这些差异作为判断依据。

如今，新版无头模式已经与普通有头模式统一实现。具体来说，从 Chrome 112 开始，无头模式使用与普通 Chrome 相同的浏览器代码，但不会创建可见窗口。在 Chrome 132 中，旧版无头模式被移至一个名为 chrome-headless-shell 的独立可执行文件，并通过 Chrome for Testing 分发。

使用 Puppeteer 时，你可能会遇到以下两种选项：

• headless: true：以新版无头模式运行 Chrome。
• headless: 'shell'：使用旧版无头实现运行 chrome-headless-shell 可执行文件。

在研究无头浏览器检测时，这一区别非常重要。一些在旧版无头模式时期编写的教程，可能依赖于某些特征，而这些特征已无法准确反映当前 Chrome 版本的情况。因此，在查看测试结果或技术文档时，应先确认所使用的 Chrome 版本和配置。

网站检测无头浏览器，主要是为了区分正常用户与自动化流量，例如大规模数据采集、批量尝试密码登录或虚假广告点击。不过，检测到异常并不意味着网站一定会立即阻止访问。反机器人系统可能会先评估其他信号，再要求用户完成 CAPTCHA 验证码验证或采取相应的限制措施。

2. 网站通过哪些信号检测无头浏览器？

网站通常会结合多组信号检测无头浏览器，而不是依靠某个单一特征。这些数据可能来自 HTTP 标头、JavaScript 属性、浏览器控制协议、设备环境、用户交互行为以及网络连接。

每组信号都能反映浏览环境的不同方面。例如，User-Agent 提供浏览器声明的信息，而 navigator.webdriver 则用于指示浏览器是否正在通过自动化方式受到控制。当多项信息之间存在不匹配时，网站就有更多依据判断此次访问是否异常。

2.1. HTTP 层面的信号

访问网站时，浏览器会发送 HTTP 标头，向服务器提供有关设备和浏览环境的部分信息。网站可以在通过 JavaScript 进行更详细的检查之前，先分析这些数据。

常见的检测信号包括：

• User-Agent 中包含 HeadlessChrome：某些无头 Chrome 配置可能会在 User-Agent 字符串中包含 HeadlessChrome。网站可以直接从服务器端请求中读取该值，也可以通过浏览器中的 navigator.userAgent 属性获取。不过，并非所有无头配置都会出现这一字符串，因此不能仅凭这一点得出结论。
• Client Hints 与 User-Agent 不一致：Client Hints 会通过 Sec-CH-UA 和 Sec-CH-UA-Platform 等标头提供有关浏览器品牌、版本、操作系统和设备的更多信息。如果 User-Agent 声明的 Chrome 版本与 Client Hints 提供的信息不相关，网站可能会记录这种不一致。
• 标头缺失或异常：Accept-Language 等标头可以表明浏览器的首选语言。如果缺少这些信息，或者它们与其他数据不一致，系统可能会将其视为需要进一步调查的信号。

需要注意的是，HTTP 标头可能因浏览器、版本和配置而异。因此，网站通常需要将其与其他信号进行比较，而不是把某个单独的值视为确凿证据。Chrome 还提供了 User-Agent Client Hints 机制，以更结构化的方式传递浏览器信息。

2.2. JavaScript 属性信号

网页加载后，JavaScript 可以访问各种浏览器属性，以检查当前运行环境。这是反机器人系统寻找自动化迹象的常见方式之一。

值得关注的属性包括：

• navigator.webdriver：该属性用于指示浏览器是否正在通过 WebDriver 机制受到自动化控制。根据 W3C 标准，当 WebDriver 标志处于激活状态时，该属性会返回 true。在 Chrome 中，如果浏览器使用某些启动参数，例如 --enable-automation、--headless，或将 --remote-debugging-port 设置为端口 0，该属性也可能返回 true。需要区分 navigator.webdriver 和无头模式，因为前者反映的是浏览器的自动化状态，而不只是无头运行状态。
  W3C+1
• WebGL 渲染器：WebGL 允许网站获取与设备图形处理能力有关的信息。在缺少合适 GPU 的某些环境中，浏览器可能会使用 SwiftShader 等软件图形渲染器。如果这些信息与声明的操作系统或设备配置不一致，网站可能会记录这一差异。
• 屏幕和窗口尺寸：screen.width、screen.height、window.innerWidth 和 window.outerWidth 等值可以反映可用的显示区域。某些自动化配置可能会产生默认尺寸，或导致这些属性之间出现不一致。

你可以打开浏览器的开发者工具，并在 Console 中输入相应的 JavaScript 命令，检查部分基础信息。不过，这些结果只反映当前时刻的运行环境，无法准确判断其他网站会如何评估你的浏览器。

你可以使用以下代码快速检查几个属性：

console.log("WebDriver:", navigator.webdriver);

console.log("Screen size:", screen.width, "x", screen.height);

console.log("Window size:", window.innerWidth, "x", window.innerHeight);

const canvas = document.createElement("canvas");
const gl = canvas.getContext("webgl");

if (gl) {
  const debugInfo = gl.getExtension("WEBGL_debug_renderer_info");

  console.log(
    "WebGL renderer:",
    debugInfo
      ? gl.getParameter(debugInfo.UNMASKED_RENDERER_WEBGL)
      : "Renderer information unavailable"
  );
}

2.3. Chrome DevTools Protocol 的相关痕迹

除了直接通过 JavaScript 访问的属性外，网站还可能检查外部工具控制浏览器时产生的痕迹。其中一种与此过程相关的机制是 Chrome DevTools Protocol（CDP）。

CDP 是一种允许外部工具与 Chrome 通信并控制浏览器的协议。Chrome DevTools 本身也使用该协议，Puppeteer 和 Playwright 等浏览器自动化工具同样支持 CDP。

连接到 Chrome 后，自动化工具可以发送 CDP 命令，以启用所需功能。例如，Runtime.enable 允许工具接收与 JavaScript 环境有关的事件。某些通过 CDP 执行的操作可能会改变浏览器处理或显示 Console 信息的方式，从而产生网站可以检查的信号。

如果这些信号与普通浏览器中通常观察到的行为不同，反机器人系统可能会将其视为浏览器正在受到自动化控制的证据。不过，CDP 痕迹并不总是意味着机器人活动。用户打开 Chrome DevTools 检查网站时，也可能产生一些类似的效果。因此，检测系统需要结合其他信号才能得出结论。

此外，基于 CDP 和 Console 的检测技术可能会随着浏览器版本变化而改变。一些曾经广泛使用的方法已经被修改或修复。因此，不应依赖过时的检测脚本来判断浏览器当前是否正在执行自动化操作。

2.4. 浏览器环境被修改的迹象

浏览器可以暴露各种有关操作系统、设备和硬件能力的信息。如果某些属性被修改，而相关数据仍然保持不变，网站就可能发现其中的不一致。

值得关注的信号主要有两组：

• 被覆盖的属性与原生实现不匹配：某些脚本可能会修改 navigator.webdriver 或其他浏览器信息的值。不过，不恰当的修改也可能影响 getter、原型或属性的访问方式。网站可以检查这些特征，以识别经过篡改的数据。
• 设备信息相互冲突：例如，User-Agent 声明使用 Windows，但某些平台信息、字体或 WebGL 属性却与之不匹配。同样，如果没有考虑实际使用环境，时区与 IP 地址所在地也可能形成不一致的组合。

这些数据通常会在浏览器指纹分析过程中受到检查。你可以阅读我们的 浏览器指纹文章，进一步了解网站如何收集和比较设备信息。

2.5. 用户交互信号

并非所有机器人检测方法都关注浏览器的技术属性。网站还可能分析用户与页面的交互方式，包括鼠标移动、滚动、输入内容以及操作之间的时间间隔。

以下行为可能引起系统注意：

• 鼠标移动轨迹过于笔直，或始终遵循相同的路径。
• 页面加载后几乎立即填写并提交表单。
• 用户连续执行多项操作，而且每次操作之间的时间间隔完全相同。
• 多个访问过程中，页面滚动或点击的顺序始终一致。

不过，不应仅仅因为用户操作速度很快，或没有移动鼠标，就自动认定其为机器人。真实用户也可能使用键盘快捷键、辅助工具，或直接与页面上需要的元素进行交互。因此，行为信号需要结合具体情境和其他活动进行评估。

2.6. 网络信号

除了浏览器特征和用户交互之外，网络信息也有助于网站评估流量来源。某些反机器人系统会检查 IP 信誉、网络类型和连接特征，以判断访问是否异常。

常见的检测数据主要有两组：

• IP 信誉：网站可能会评估 IP 地址的历史记录和信誉。例如，曾与多次可疑登录尝试或大量请求相关联的 IP，可能会被归类为高风险地址。根据不同平台的政策，数据中心 IP 也可能与住宅 IP 受到不同的评估。
• TLS 指纹：TLS 指纹反映了加密连接建立过程中的某些特征。如果这些信息与声明的浏览器或环境不匹配，系统可能会记录这一不一致。

网络信号无法直接揭示浏览器是否处于无头模式，而是提供有关 IP 地址、连接特征和流量来源信誉的补充信息，帮助网站判断访问是否存在异常活动迹象。

检测信号快速对比

每组信号提供的信息各不相同。下表可以帮助你了解网站可能检查的内容，以及每种情况下误判正常用户的可能性。

网站通常不会依靠单一信号评估一次访问，而是结合浏览器、用户交互和网络连接等方面的数据。某个指标异常，并不足以证明用户正在运行无头浏览器。不过，当多个信号同时出现时，系统可能会认为此次访问具有更高的风险。

2.7. 哪些旧版无头浏览器检测方法需要重新检查？

研究无头浏览器检测时，你可能会看到许多教程将 navigator.plugins、navigator.languages、window.chrome 和 WebRTC 等属性列为识别无头浏览器的方法。这些指标经常出现在介绍旧版本 Headless Chrome 的文档中。

不过，从 Chrome 112 开始，Chrome 改变了无头模式的实现方式。新版无头模式与普通 Chrome 共享源代码，而旧版实现则从 Chrome 132 开始被分离到 chrome-headless-shell 中。因此，过去被视为常见检测指标的特征，不一定能够准确反映当前无头环境。

对于以下属性，应将其视为需要结合相应浏览器版本进行检查的项目，而不是判断浏览器处于无头模式的确凿证据。

为了获得更准确的评估，你应该在普通 Chrome 和正在使用的无头配置中运行相同的测试。如果同时记录 Chrome 版本、操作系统和具体框架，测试结果会更有参考价值。你也可以参考第 5.2 节中的自测流程。

需要注意的是，navigator.webdriver 和 User-Agent 中包含 HeadlessChrome 是两种独立的信号，不应与需要重新检查的旧版检测方法归为一类。这两项指标仍然需要根据具体浏览器配置和版本进行评估。

3. 网站如何检测 Puppeteer、Playwright 和 Selenium？

每种浏览器自动化框架都有自己的运行机制和技术特征。Puppeteer 和 Playwright 在控制 Chromium 时通常使用 Chrome DevTools Protocol，而 Selenium 则使用 WebDriver。这些差异可能产生一些信号，供网站识别自动化活动。

不过，不应将任何单一指标视为每个版本中都会出现的固定特征。检测结果还取决于浏览器、框架和启动配置。

3.1. 检测 Puppeteer

Puppeteer 是一个 Node.js 库，允许用户通过代码控制 Chrome 或 Chromium。它常用于界面测试、网页截图、数据采集以及浏览器任务自动化。

运行时，Puppeteer 可能留下以下几种信号：

• CDP 连接：Puppeteer 使用 Chrome DevTools Protocol 向浏览器发送命令并接收数据。与该协议相关的某些操作可能会产生网站能够观察到的痕迹。
• 注入页面的脚本：Puppeteer 可以向网页环境注入脚本，以支持浏览器控制和活动监控。在某些情况下，这些脚本的痕迹可能出现在堆栈跟踪中，例如 pptr: 字符串。不过，这并不是所有版本中都会出现的固定指标。
• 默认无头模式：Puppeteer 目前默认使用新版无头模式。如果希望使用可见界面运行 Chrome，可以设置 headless: false。改变显示模式并不会改变该框架的自动化性质。
  Puppeteer+1

例如，你可以在个人电脑上使用 Puppeteer 自动打开商品页面并截图。当你将同一个脚本转移到 VPS 上运行时，网站可能开始要求 CAPTCHA 验证或限制访问。原因可能与 IP 地址、浏览器环境或网站检测到的自动化信号有关。

3.2. 检测 Playwright

Playwright 是一个支持 Chromium、Firefox 和 WebKit 的浏览器自动化框架。它常用于界面测试、用户流程检查以及网站任务自动化。

分析 Playwright 活动时，网站可能会检查以下指标：

• 内置 Chromium 版本：根据 Playwright 文档，每个框架版本都会使用相应的浏览器版本。默认情况下，Playwright 可能运行其内置的 Chromium 版本，而不是带有 Google Chrome 品牌标识的浏览器。浏览器版本和信息的差异，可能导致 Client Hints 与普通 Chrome 配置中的信息不同。
• 初始化脚本和全局变量：Playwright 可以在创建浏览器上下文或初始化环境时向页面注入脚本。网站可能通过 JavaScript 检查与这一过程有关的部分痕迹。

不过，这些指标需要结合具体的 Playwright 和 Chromium 版本进行检查。不能仅仅因为使用了 Playwright，就认定网站一定会检测到自动化活动。

3.3. 检测 Selenium

Selenium 是一套广泛用于软件测试的浏览器自动化工具。与 Puppeteer 和 Playwright 不同，Selenium 通过 WebDriver 运行。这是一项允许外部程序控制浏览器的标准。

网站可能会关注以下相关指标：

• WebDriver：Selenium 使用 WebDriver 机制发送浏览器控制命令。navigator.webdriver 属性可能表明浏览器正在通过这一机制受到自动化控制。
• ChromeDriver 痕迹：在某些 ChromeDriver 配置中，以 cdc_ 为前缀的变量过去曾被识别为与 Selenium 有关的指标。不过，这些变量是否出现取决于具体版本和实现方式，因此不能将其视为始终存在的特征。

因此，由于使用的是 WebDriver 控制通道，Selenium 可能会留下与 Puppeteer 和 Playwright 不同的痕迹。你可以参考 W3C WebDriver 标准，进一步了解这一机制。

自动化框架对比

你可以参考以下摘要，更直观地了解不同框架之间的区别：

表中的信号仅供参考，并不是每种框架都必然具有的固定特征。调查具体情况时，应检查相关浏览器版本、框架和技术资料。

4. Chrome 远程调试与自动化检测有什么关系？

Chrome 远程调试是一种允许外部工具连接 Chrome、检查和控制浏览器的机制。Chrome DevTools Protocol（CDP）则是用于实现这一通信的协议。

需要明确区分以下三个概念：

• 远程调试端口：当 Chrome 使用 --remote-debugging-port 选项启动时，会开放一个连接端口。
• Chrome DevTools Protocol（CDP）：一种允许工具向 Chrome 发送命令并接收数据的协议。
• CDP 痕迹：工具通过 CDP 控制浏览器时，页面环境中可能出现的变化或副作用。

关键在于，网站观察到页面中的 CDP 痕迹，并不意味着它可以直接访问你电脑上的远程调试端口。

从 Chrome 136 开始，Chrome 也改变了远程调试选项的工作方式。根据 Google 于 2025 年 3 月 17 日发布的公告，如果 --remote-debugging-port 和 --remote-debugging-pipe 选项与 Chrome 默认数据目录一起使用，将不再被接受。用户需要通过 --user-data-dir 指定一个独立目录，才能继续使用这一机制。此项调整旨在加强对 Cookie 和登录信息的保护。Chrome for Testing 不受这一调整影响。

如果你在开发或测试过程中使用远程调试，应遵循以下几项安全原则：

• 除非确有必要，否则不要将调试端口暴露给外部网络。
• 不要使用包含个人账户登录会话的主要 Chrome 配置文件进行调试。
• 使用独立的数据目录，将测试环境与日常浏览数据隔离。

5. 如何检查自动化浏览器暴露了哪些信号？

你可以使用一些浏览器指纹测试网站，检查浏览器对外暴露的信息。这种方法有助于识别普通 Chrome 与通过 Puppeteer、Playwright 或 Selenium 运行的配置之间的差异。

不过，没有任何一个测试网站能够代表完整的反机器人系统。每种工具关注的信号类别不同，因此你应该结合多个来源的测试结果进行判断。

5.1. 推荐的测试网站

以下是几个可以用来检查浏览器属性和环境一致性的工具。

• bot.sannysoft.com：Bot Sannysoft 提供多项与 navigator.webdriver、插件、权限及其他浏览器属性有关的测试。结果会直接显示在页面上，方便你识别哪些检测项目出现了异常指标。

• CreepJS：CreepJS 会分析多种浏览器属性，以识别环境不一致或被修改的迹象。该工具还提供与无头浏览器和指纹识别有关的评估，帮助你进一步了解浏览器暴露的数据。

• BrowserLeaks：BrowserLeaks 提供针对 WebGL、Canvas、WebRTC 以及其他多种属性的独立测试。该网站不会对自动化情况给出笼统结论，而是帮助你逐项检查浏览器暴露的信息。

• Pixelscan：Pixelscan 会检查与浏览器指纹、IP 地址以及这些数据之间的一致性有关的信息。其结果可以帮助你发现浏览器配置中的某些不一致之处。

需要注意的是，通过这些测试并不意味着真实网站一定会接受你的访问。反机器人系统可能还会使用行为数据、IP 历史记录以及公共测试工具无法完全模拟的服务器端分析模型。

5.2. 五步自测流程

为了让测试结果具有参考价值，你应该在相同条件下测试普通 Chrome 和自动化浏览器。以下流程可以帮助你系统地识别两种环境之间的差异。

1. 记录配置信息：确认正在使用的 Chrome 版本、框架、操作系统和浏览器启动参数。
2. 测试普通 Chrome：在不使用自动化工具的情况下，通过 Chrome 打开指纹测试网站，收集基准结果。
3. 运行自动化配置：使用脚本访问相同的网站，分别在无头模式和有头模式下收集测试结果。
4. 比较数据：比较不同测试会话中的各项属性，并记录存在的差异。
5. 保存结果：截取屏幕、记录测试日期并保存浏览器版本，以便在每次更新后进行比较。

测试期间，应尽量保持其他因素不变，包括操作系统、网络连接和设备。如果一次修改过多设置，就很难判断测试结果出现差异的具体原因。

5.3. Hidemyacc 能提供哪些帮助？又有哪些局限？

Antidetect browser Hidemyacc 是一款支持创建和管理浏览器配置文件的工具，可以为不同配置文件设置独立指纹，并结合代理管理浏览环境。使用 Hidemyacc 时，每个配置文件都有独立的 Cookie、代理和浏览器指纹，有助于保持第 2.4 节所述环境信息的一致性。不过，Hidemyacc 不会改变自动化本身的性质。与脚本通过 CDP 控制浏览器，或用户与网站交互方式有关的信号，仍然可能被检测到。

如果你需要集成自动化工具，也可以参考 Hidemyacc 官方文档，了解 Profile API 的相关信息。

6. 结论

网站并不是通过检查浏览器是否具有可见界面来检测无头浏览器的。相反，反机器人系统可能会结合 HTTP 标头、JavaScript、CDP、浏览器指纹、网络连接以及用户交互行为等信息来评估一次访问。

这也解释了为什么从无头模式切换到有头模式，或只是更改 User-Agent，并不一定能解决问题。浏览器仍然可能通过脚本控制方式或环境信息之间的不一致暴露自动化信号。

如果你正在开发或测试应用程序，可以使用第 5 节中的工具检查普通浏览器与自动化环境之间的差异。如果你需要管理多个账户，则应关注各个配置文件中指纹、代理和数据的一致性，同时遵守所使用平台的相关政策。

了解网站如何检测机器人，有助于你更有效地选择和管理浏览器环境，而不是孤立地修改某个设置。

相关阅读：网页抓取反检测浏览器：2026 年热门工具

7. FAQ

1. navigator.webdriver 返回 true 是否意味着账户会被封禁？

不一定。navigator.webdriver 只是一个指标，表示浏览器正在通过 WebDriver 机制受到自动化控制。网站可能会结合浏览器指纹、行为和访问历史来评估风险。账户是否需要进行身份验证或受到限制，取决于各个平台的政策。

2. 浏览网页时打开 DevTools，会不会导致用户被误判为机器人？

有这种可能。某些基于 CDP 的自动化检测技术，可能会记录 Chrome DevTools 打开时产生的副作用。不过，这并不足以证明用户是机器人。反机器人系统通常需要检查其他信号后才能作出判断。

3. 使用有头模式运行 Puppeteer，仍然属于自动化吗？

是的。无头模式和有头模式只表示浏览器是否显示可见窗口，而自动化则指通过脚本控制浏览器。因此，以有头模式运行的 Puppeteer 仍然可能暴露与 CDP 或自动化浏览器控制有关的信号。

4. 网站能否看到 Chrome 是否开放了远程调试端口？

网站通常能够观察到浏览器受到控制时在页面内产生的影响，而不是直接访问远程调试端口。CDP 痕迹并不意味着网站可以访问你电脑上的调试端口。网页是否能够检查本地端口，需要根据具体情况单独验证。

5. Hidemyacc 能防止自动化脚本被检测到吗？

无法保证 Hidemyacc 能够防止自动化脚本被检测。该工具支持管理具有独立指纹、Cookie 和代理的配置文件，有助于保持浏览器环境的一致性。不过，与 CDP、脚本控制浏览器的方式以及用户交互行为有关的信号，仍然可能被网站检测到。