探索网站如何识别机器人：从 navigator.webdriver、行为分析，到密码学身份方案 Web Bot Auth，拆解检测原理与规避难点。
网站识别机器人和爬虫的方式，是把许多单独并不可靠的弱信号组合成一个可信的判断：自动化标志（如 navigator.webdriver）、无头浏览器泄露、行为模式（例如不像人类的鼠标轨迹和操作节奏）、浏览器指纹的不一致性、网络层的 TLS/HTTP-2 签名、IP 信誉，以及验证码等交互式挑战。任何单一检测都不足以下定论，因此现代检测系统会同时对几十个特征进行打分。本文将解释主要技术的工作原理，以及每种技术在什么情况下会失效。
这个判断过去只有两种结果——真人或机器人——但现在不再是这样了。如今需要区分的是四类访问者：真实的人类、能够以密码学方式声明并证明自己所属运营方的机器人、试图伪装成人类的未声明自动化，以及代表真实、已登录用户行动的 AI 智能体。下文的每一种技术依然是在回答"这是不是人类"这个问题的一部分，但一个会话最终落入这四类中的哪一类，越来越取决于它能否提供证明，而不只是能否躲过推断。
为什么自动化检测很重要
自动化流量本身并不一定是坏事。搜索引擎爬虫、可用性监控和无障碍工具都属于机器人，而大多数网站是欢迎它们的。真正的问题在于恶意自动化：撞库攻击、抢购囤货、绕过付费墙的内容抓取、广告欺诈以及批量注册虚假账号。自动化检测的目的，就是把正常用户和友好机器人，与滥用型自动化区分开来，并且尽量不用频繁的验证码去打扰真实用户。
由于攻击者会不断改进工具，让它看起来更像人，检测因此成了一场"猫鼠游戏"。防御方很少依赖单一手段，而是把客户端信号、行为分析和服务端网络情报层层叠加，这样攻破其中一层并不足以蒙混过关。
自动化标志：navigator.webdriver 及其同类
成本最低的信号，是浏览器自己"招供"。当浏览器由 WebDriver 协议（Selenium 等传统自动化方案）驱动时，标准属性 navigator.webdriver 会被设为 true。许多简陋的脚本忘记隐藏它，因此它仍然是一个有用的初筛信号。
除了这个属性之外，自动化框架往往会在全局作用域中留下痕迹：注入的对象、window 上异常的属性，或驱动特有的变量。检测脚本会主动探测这些已知特征。
// 客户端对常见自动化信号的最简检测。
function detectAutomationSignals() {
const signals = {
webdriver: navigator.webdriver === true,
// 无头 Chrome 早期会报告零个插件。
noPlugins: navigator.plugins.length === 0,
// 真实浏览器会暴露 languages 数组；部分机器人却为空。
noLanguages: !navigator.languages || navigator.languages.length === 0,
// 泄露到页面中的已知自动化痕迹。
cdpArtifacts: '__nightmare' in window || '_phantom' in window,
};
signals.suspicious = Object.values(signals).some(Boolean);
return signals;
}
这些检测都很容易被伪造。有经验的操作者可以修补
navigator.webdriver并注入伪造的插件，因此自动化标志最好只作为众多输入之一，绝不能单独作为证据。
这种脆弱性贯穿本文提到的每一个客户端信号，不只是这一个：它们都是从某种"可以被脚本最终伪造"的行为中推断出来的。这正是为什么业界要标准化一层完全不依赖推断的机制——见下文的"密码学机器人身份"。
无头浏览器检测
无头 Chrome 及类似运行时支撑着相当大一部分抓取和自动化任务。最明显的破绽其实一直都在——Chrome 的无头模式默认会在 User-Agent 里写上 HeadlessChrome——但改写 User-Agent 只是一行代码的事，凡是值得被检测的自动化早就改掉了。因此真正的检测转向了客户端没那么容易改写的、更隐蔽的不一致之处。
缺失或不一致的属性
无头环境渲染页面的方式往往与正常的桌面浏览器不同。常见的破绽包括：空的或异常的插件列表、缺失的媒体编解码器、返回相互矛盾状态的 permissions API（例如同时把通知报告为 denied 和 prompt），以及指向 SwiftShader 等软件光栅化器、而非真实 GPU 硬件的 WebGL 渲染器字符串。
渲染与功能异常
运行在真实硬件上的真实浏览器，会在 Canvas、WebGL 和音频 API 上给出一致的结果。无头或虚拟化的环境则经常出现矛盾——比如在 User-Agent 中自称高端 GPU，WebGL 却报告通用的软件渲染。这类矛盾是很强的机器人信号。我们关于Canvas 指纹如何识别你的设备和WebGL 指纹技术细节的深入文章，解释了这些相同的渲染信号在底层是如何运作的。
想深入了解 Selenium、Puppeteer、Playwright 各自泄露的具体信号——包括 CDP 全局变量、SwiftShader GPU 特征和隐身插件的局限性——请参阅无头浏览器检测：Selenium 与 Playwright 如何被识破。控制协议本身还有更底层的一面：我们关于检测 Chrome DevTools Protocol（CDP）自动化的文章讲解了 Runtime.enable 引发的控制台序列化旁路（side channel），它能独立于任何框架特有痕迹，暴露已连接的 Puppeteer 或 Playwright 客户端。
行为分析
当一个会话通过了静态检测后，防御方会继续观察它"如何"行动。人类的操作充满噪声、不够精确；脚本则干净而确定。行为分析正是把这种差异转化为分数。
- 鼠标移动——真实的光标沿着带抖动的曲线移动，速度时快时慢。机器人往往走直线，或直接"瞬移"到目标。
- 时序与节奏——人类会停顿、犹豫，打字节奏也会变化。完全均匀的击键间隔，或 100 毫秒以内就完成的表单提交，都显得像自动化。
- 交互熵——真实会话包含滚动、停顿和误点击。一个径直奔向目标、毫无多余动作的会话就很可疑。
- 导航模式——爬虫倾向于按广度优先或字母顺序请求页面，并忽略人类自然会触发的 JavaScript 渲染内容。
行为分析之所以强大，正是因为它在大规模场景下很难令人信服地伪造；但它需要足够的交互数据才能生效，并且可能对使用辅助技术或习惯特殊的用户产生误判。行业趋势——以 Cloudflare 2026 年推出的"Precursor"系统为例——是在整个会话中持续为这些信号打分，而不是只在某个检查点打一次分。参见我们关于行为机器人检测的深入文章，了解行为信号究竟是什么，以及为什么跨信号相关性正是抓住脚本化输入的机制。
同样的鼠标移动和按键遥测数据，也出现在网络行业的另一端——只是这次针对的是真人而非机器人：会话回放脚本（如 FullStory、Hotjar）会记录完全相同的信号，为用户体验研究重建真实访客会话的视觉回放。
用于识别机器人的指纹信号
浏览器指纹——我们在浏览器指纹完全指南中有深入介绍——同样是一种机器人检测工具。这里的目标不是跨站追踪某个用户，而是发现内部的不一致性和聚类。
不一致的指纹（Windows 的 User-Agent 却报告 macOS 的字体栈，或移动端 User-Agent 配桌面端屏幕分辨率）暗示着伪造。聚类则是另一半线索：当成千上万个"各不相同"的访客共享同一个罕见且完全一致的指纹时，它们几乎可以肯定是同一套自动化工具用同一模板批量生成的。
网络层指纹
有些最强的信号完全不经过 JavaScript。它们存在于客户端协商连接的方式中，因此从浏览器沙箱内部很难伪造。
| 层级 | 技术 | 揭示的信息 |
|---|---|---|
| TLS | JA3 / JA4 签名 | 握手中密码套件和扩展的顺序与组合；可识别底层 TLS 库 |
| HTTP/2 | 帧与头部指纹 | 流优先级、头部顺序及设置帧，真实浏览器与 HTTP 客户端在此存在差异 |
| HTTP 头部 | 头部顺序与大小写 | 自动化库发出的头部，其顺序或大小写与 Chrome、Firefox 不同 |
| IP | 信誉与 ASN | 数据中心网段、已知代理池及滥用历史，与住宅地址形成对比 |
如果一个请求的 User-Agent 自称是 Chrome，其 TLS 握手却与 Python requests 或 Go net/http 客户端相符，这就是一个刺眼的矛盾。JA3 式指纹正是专门捕捉这类"只精修了 JavaScript 层、却忽略网络层"的自动化。
IP 信誉与速率限制
IP 情报是最古老的防线，至今仍是最有效的手段之一。来自数据中心 ASN（云服务商、主机托管公司）的流量，在统计上远比来自住宅 ISP 的流量更可能是自动化，因此会受到额外审查。已知的代理与 VPN 出口节点、Tor 中继，以及有过滥用历史的地址，都会抬高风险分值。
速率限制是对信誉的补充：即便是一个干净的住宅 IP，如果每分钟请求上百个页面，也会变得可疑。把访问速度与信誉结合起来，防御方就能在不打扰正常浏览的前提下，限制明显的抓取行为。这也是为什么高级滥用会转向住宅代理网络——为的就是借用真实家庭网络的信誉。
验证码与挑战系统
当被动信号模棱两可时，网站会升级到主动挑战。传统的图片验证码要求用户直接证明自己是人，而现代系统（隐形挑战、工作量证明谜题和托管式挑战页面）则尽量在后台分析同样的行为与指纹信号，以最小的用户摩擦来验证合法性。
挑战是最后的手段，而非第一道防线，因为它会损害真实用户的体验，而且可以被人工打码服务大规模破解。最好的检测体系会谨慎使用挑战，仅在综合风险分超过阈值时才触发。
一种新兴的替代方案彻底绕开了验证码和指纹打分：密码学证明。匿名凭证能让客户端证明自己是合法真人，而不需要网站为了得出这个结论就建立可追踪的画像。机器人这边的对应方案——证明一个请求属于哪个运营方，而不是给它的"像不像人"打分——就是接下来要介绍的 Web Bot Auth。
移动应用其实已经拥有比浏览器强得多的密码学手段：设备认证。它不靠对数十种弱信号打分，而是由硬件信任根直接签发一枚令牌，证明设备和应用确实未被篡改——这也是为什么欺诈风险高的原生应用更依赖 Play Integrity 和 App Attest，而不是浏览器式的指纹打分。
密码学机器人身份：Web Bot Auth
上文所有技术本质上都是推断：防御方观察到一个信号，然后猜测它的成因。Web Bot Auth 则是完全不同性质的机制——它是一种密码学断言。机器人运营方持有一把私钥、公开对应的公钥，并用 HTTP 消息签名（RFC 9421）为每一个 HTTP 请求签名——IETF 的 Web Bot Auth 架构草案正是基于这一机制把该方案正式化的。网站用公开的公钥验证签名，就能以密码学级别的确定性得知是哪把密钥签署了这个请求——从而得知是哪个运营方对此负责。
这是一种与本文其他所有信号截然不同的信号。navigator.webdriver 标志、TLS 指纹或行为评分都是推断出来、且可被伪造的——只要攻击者投入足够资源，最终都可以伪造出来。而签名是断言且可验证的：在没有私钥的情况下伪造签名，是一个密码学问题，而不是浏览器自动化问题。Cloudflare 对 Web Bot Auth 的推行让已知的爬虫运营方——目前主要是 AI 公司和搜索引擎——可以为自己的请求签名，这样网站就能明确放行它们，而不必再靠猜测 User-Agent 字符串和 IP 段来判断，而后者正是本文其他部分反复说明的、最容易被伪造的那一层。
Web Bot Auth 并不会取代上文的这些技术——网站依然需要它们，去应对那一大批没有理由自证身份的自动化流量。它带来的是第三种、可被证明的结果：请求不再只能被归为"大概率是人"或"大概率是机器人"，而是可以直接标注为"经过验证、确属该运营方的机器人"——这正是把已声明的自动化和未声明的自动化区别对待，而不是用同一套可被伪造的信号给它们一起打分，所欠缺的那块拼图。
签名只是核实一个声明身份的众多方式之一，并非唯一——参见网站如何核实一个自称 Googlebot 的爬虫，了解正反双向确认的反向 DNS、公开的 IP 段以及运营方注册表各自如何回答同一个问题，以及一个伪造了 User-Agent 的攻击者，还要闯过另外三道检测。
新的变量：代表真实用户行动的 AI 智能体
以上所有技术都建立在一个前提上：自动化就是不受欢迎的。AI 浏览智能体打破了这个前提：它们驱动的是真实浏览器，使用的是真实、已登录用户的凭证，去完成这个用户明确要求的事情。这依然是自动化流量，但它并不是自动化检测本该拦截的对象，这就在"真人""经过验证的机器人"和"不受欢迎的自动化"之外，又多出了第四类。参见网站如何把 AI 智能体和机器人、真人区分开，了解上文这些客户端可观察信号，在"由自动化驱动"不再等同于"不受欢迎"之后还剩下多少效力；也可参见匿名凭证，了解这一变化在人类一侧对应的"证明自己是人"方案。
用 BrowserInsight 把信号综合起来
没有任何单一信号是可靠的，这正是真实系统要对它们进行综合打分的原因。你可以用 BrowserInsight 的机器人检测工具在自己身上查看许多此类客户端信号：它会展示你的 navigator.webdriver 状态、无头与自动化痕迹、指纹一致性以及其他指标，让你清楚地了解当你连接时，检测系统究竟看到了什么。
如果你想一次性看到这些单项检测的实际效果，bot.sannysoft.com 和 CreepJS 等公开测试页会运行许多同类探测并直接展示原始的通过/失败结果——参见机器人检测测试页解析：Sannysoft 与 CreepJS，了解如何解读这些结果，以及为什么通过一个静态测试页并不等于通过一套会打分的真实检测系统。
同样这种被动观察加载耗时、错误事件和响应行为、而非直接读取内容的手法，也支撑着另一类完全针对人类而非机器人的技术——参见跨站登录检测：网站如何知道你登录了哪些服务，了解一个页面如何在不触碰你 Cookie 的情况下，推断出你还登录了哪些其他网站。
常见问题
能依靠 navigator.webdriver 来检测机器人吗？
单独使用不行。它能抓到忘记隐藏它的简陋自动化，但这个属性极易被覆盖。应把它当作一个弱信号，只有与无头泄露、行为数据和网络指纹结合时才有意义。
如果 User-Agent 被伪造，网站怎么检测无头浏览器？
通过寻找 User-Agent 无法掩盖的不一致：纯软件的 WebGL 渲染、相互矛盾的权限状态、缺失的编解码器，以及 Canvas 或音频的异常渲染。一个与实际渲染环境相矛盾的伪造 User-Agent，本身就是很强的破绽。
自动化检测等于封禁所有机器人吗？
不是。检测负责对流量分类，策略才决定如何处置。网站通常会放行友好机器人（搜索爬虫、监控），限速激进的机器人，并对明显滥用的自动化发起挑战或封禁。目标是把恶意流量与正常用户及受欢迎的机器人区分开来。
为什么说自动化检测是一场猫鼠游戏？
因为每一种检测技术都会招来对策。网站检查 User-Agent，攻击者就伪造它；网站检查 navigator.webdriver，攻击者就修补它。防御方则以更难伪造的网络层和行为信号回应。双方谁都无法永远"获胜"。
Web Bot Auth 是什么，它和验证码有什么不同？
验证码要求访问者证明自己的行为或感知能力符合人类特征；Web Bot Auth 则要求机器人运营方用私钥为每个请求签名，让网站能验证是哪个运营方发出的请求。它并不试图判断某个请求"像不像人"，而是以密码学方式直接识别请求方的身份。这也是为什么它适用于经过验证的机器人（它没办法像人一样去解验证码），而不是要取代面向匿名人类流量的验证码。
