反机器人系统是位于网站前端的软件，它针对每个请求估算其来自自动化而非真实用户的可能性，并根据该估算采取行动——放行、限速、验证或阻止。 该估算并非基于任何单一事实，而是由四个层面综合得出的评分：请求来源（IP）、连接建立方式（TLS 和 HTTP 指纹）、浏览器自身信息（JavaScript 指纹）以及访问者随时间的行为（行为）。理解这些层面有助于解释 proxy 用户最困惑的两点：为什么“完美”的住宅 IP 仍会收到验证码，以及为什么相同的设置在某个网站上有效而在另一个网站上却失败。

供应商与产品

大多数受保护的网站使用少数几种产品之一：Cloudflare Bot Management（及其 Turnstile 验证）、DataDome、Akamai Bot Manager、HUMAN（原 PerimeterX）、Imperva（Incapsula）、Kasada 和 AWS WAF Bot Control。它们在侧重点和默认策略的激进程度上有所不同，但都基于相同的四个层面，本文重点讨论这些层面。以下内容在不同程度上适用于所有产品。

第一层：IP 信誉

这是第一道也是最廉价的检查。在解析请求之前，系统会先查询 IP：

  • ASN 和类型 —— 这是托管公司（数据中心）、消费者 ISP（住宅）还是移动运营商？在大多数网站上，托管 ASN 会带有初始惩罚；相关原因在住宅 vs 数据中心 vs 移动 proxy 中有详细说明。
  • 威胁情报 —— 该 IP 是否在滥用列表中，是否已知为 VPN/proxy 出口，或是否曾攻击过同一供应商的其他客户？供应商会整合其整个客户群的信号，因此在一个受 DataDome 保护的网站上被标记的 IP，在其他所有网站上也会被怀疑。
  • 速度 —— 该 IP 最近向此网站发送了多少请求，访问了多少不同路径？按 IP 计数是最古老的机器人信号，至今仍是最有效的信号之一。
  • 地理位置 —— 国家是否与网站受众匹配？是否与浏览器稍后报告的语言和时区匹配？

这是 proxy 唯一能直接控制的层面。一个在目标网站上没有历史的住宅或移动 IP 可以通过此检查。但通过第一层仅意味着请求以中性评分进入第二至四层，而非获得良好评分。

第二层：网络指纹（TLS、HTTP/2、TCP）

在提供任何页面内容之前，服务器已经看到了连接是如何建立的，而建立方式会识别客户端软件：

  • TLS 指纹（JA3/JA4）—— ClientHello 揭示了 TLS 库：Chrome、Firefox、Python 中的 OpenSSL、Go。详见TLS 指纹识别。
  • HTTP/2 指纹 —— SETTINGS 帧值、初始窗口大小、优先级帧以及头部和伪头部的顺序。浏览器具有特征性的稳定模式；HTTP 库则不同。Akamai 的研究使这项技术闻名。
  • TCP/IP 指纹 —— 窗口大小、TTL、选项；可区分操作系统，而“Windows” User-Agent 与 Linux TCP 栈不匹配。

此处的评分逻辑是一致性：网络层身份是否与 HTTP 头声称的一致？proxy 不会触碰这些指纹——它只是转发——因此，即使使用住宅 IP，脚本在此层也会被识别为脚本，无论 IP 质量如何。这就是大多数“为什么我的干净 proxy 被阻止？”问题的答案所在。

第三层：浏览器指纹和 JavaScript 验证

如果请求到达提供 HTML 的阶段，供应商的 JavaScript 会在访问者的浏览器中运行并回报结果。这里会发生两类事情。

指纹识别

脚本收集与反检测浏览器旨在控制的相同属性：canvas 和 WebGL 哈希、字体、屏幕和窗口尺寸、硬件并发数、时区、语言、音频上下文、WebRTC 可见 IP、插件列表以及数十个较小的信号。它还会探测自动化痕迹：navigator.webdriver 设置为 true、缺少或不一致的 Chrome 特定对象、无头模式渲染怪癖、某些 API 被覆盖的异常数量（表明隐身插件修补了浏览器）。并检查一致性：JavaScript 报告的平台是否与 TCP 指纹的操作系统匹配？时区是否与 IP 的国家匹配？参见反检测浏览器控制什么。

验证

供应商还会发出工作量证明或人类证明任务。Cloudflare 的 Turnstile 和“正在检查您的浏览器”插页运行一个 JavaScript 工作负载，其结果必须回传；无法执行 JavaScript 的客户端——所有纯 HTTP 库——都会直接失败，永远看不到页面。可见的 CAPTCHA 是最后手段，当评分不佳但不足以直接阻止时显示。通过验证通常会获得一个cookie 或 token，有效期一段时间；每次请求都清除 cookie 的自动化将每次都面临验证，这本身就是一个信号。

第四层：行为

在一个会话中——以及跨会话（供应商可通过指纹或 IP 关联）——系统会观察访问者的行为：

  • 请求模式：每分钟页面数，是否获取页面引用的图片和脚本（人类浏览器会获取；简单的爬虫不会），导航是跟随链接还是直接跳到深层 URL，是否每次会话以相同顺序访问相同路径。
  • 时间：请求之间的均匀间隔是机器特征；人类是突发且不规则的。
  • 交互：鼠标移动、滚动、按键事件——它们的存在及其形状（真实鼠标路径有曲线和过冲；脚本化的则是直线或完美弧线）。
  • 会话形态：登录后立即进行批量操作；没有浏览就结账；从昨天创建了五个账户的指纹创建账户。

行为是为什么技术上完美的设置——真实浏览器、匹配的 proxy、干净的指纹——如果行为像机器，仍可能被抓住。这也是累积信誉所在的层面：一个行为正常数周的身份会获得宽容，而新身份则没有。这就是“预热”在实践中的含义。

各层面如何结合：评分

每个层面提供证据；产品将其组合成机器人评分（Cloudflare 公开其 1–99 的评分；其他产品则保密），网站所有者配置阈值：高于 X 则允许；介于 X 和 Y 之间则验证；低于 Y 则阻止或提供诱饵。此设计的两个特性对使用 proxy 的人很重要：

  1. 各层面必须一致。 评分不是独立好成绩的总和；矛盾会被重点加权。住宅 IP（好）加上 Python TLS 指纹（坏）加上 Chrome User-Agent（矛盾）的评分，比数据中心 IP 加上诚实的 python-requests UA 更差，因为后者至少是一致的。
  2. 没有什么是孤立检查的。 通过 IP 信誉只让你进入下一项检查，而不是通过。你做出的每一个声明——通过 IP、握手、头部、JavaScript、行为——都会与其他声明交叉验证。

这对 proxy 选择意味着什么

层面决定因素proxy 能修复吗？
1. IP 信誉IP 类型、历史、速度、地理位置能 —— 这正是 proxy 的全部工作
2. 网络指纹你的 HTTP 客户端 / 浏览器不能 —— 原样转发
3. 浏览器指纹 / JS 验证你的浏览器及其配置不能 —— 但地理位置/时区必须与 proxy 匹配
4. 行为你的自动化逻辑和节奏不能 —— 尽管轮换会影响每 IP 速度

因此：根据目标的第一层策略选择 proxy 类型（在允许的地方使用数据中心，否则使用住宅或移动），然后将精力投入到第二至四层，这些层是 proxy 无法触及的。实际上，这意味着对于受保护的目标，使用真实或模拟的浏览器，保持每个身份指纹一致，地理位置/时区与 IP 匹配，以及人类形态的节奏。轮换策略同时影响第一层速度和第四层会话形态——参见选择轮换间隔。

如何判断哪一层在阻止你

  • 立即被阻止，没有 HTML，即使使用同一 IP 的真实浏览器 → 第一层：IP 或 ASN 是问题。更换 proxy 类型或提供商。
  • 浏览器通过，但同一 IP 上的脚本不通过 → 第二层：TLS/HTTP 指纹。改用真实浏览器或模拟客户端。
  • 插页永不消失，或每次访问都出现 CAPTCHA → 第三层：JavaScript 验证失败或指纹不一致。检查自动化标志、WebRTC、时区与 IP 的匹配。
  • 一开始有效，然后性能下降；或账户在操作后死亡 → 第四层：行为或速度。放慢速度，改变模式，预热身份。

供应商会返回独特的响应（Cloudflare 的 403 页面、DataDome 的 x-datadome 头和 CAPTCHA 端点、Akamai 的 _abck cookie），因此识别网站使用哪个产品通常只需查看头和 cookie——而知道产品就能告诉你它强调哪些层面。

常见问题

什么是机器人评分？

针对每个请求的估算，结合 IP 信誉、网络和浏览器指纹以及行为信号，评估请求自动化的可能性。网站所有者设置阈值来决定允许、验证或阻止。

为什么住宅 proxy 仍会收到 CAPTCHA？

因为 IP 信誉只是四个层面之一。如果 TLS/HTTP 指纹显示“脚本”，浏览器失败或缺少 JavaScript 验证，或行为像机器，那么无论 IP 如何，评分都会很差。

反机器人系统会在网站之间共享数据吗？

在供应商内部，是的：在一个客户网站上被标记的 IP 或指纹会提高其在其他客户网站上的风险。这就是为什么一个被大量用于攻击某个 Cloudflare 保护目标的 proxy 池，在无关的 Cloudflare 保护目标上可能表现不佳。

纯 HTTP 库能通过 JavaScript 验证吗？

不能。验证需要在类似浏览器的环境中执行 JavaScript。选项是使用真实的自动化浏览器，或使用验证码解决服务，该服务为你运行验证并返回生成的 cookie/token——这本身有成本和检测风险。

验证和 CAPTCHA 有什么区别？

验证通常是不可见的——浏览器自动完成的 JavaScript 工作负载或证明。CAPTCHA 是给人类看的可见谜题，当评分足够差以至于系统需要明确证明时显示。

是否可能完全不可检测？

不能保证。检测是概率性的，供应商不断更新。可实现的是在所有四个层面保持一致，加上人类形态的行为，这会使评分大部分时间保持在“允许”范围内。任何仅凭 proxy 就承诺不可检测的人，只是在销售第一层。