专题：Cloudflare 机器人检测专题第 1 篇（原理篇）

难度：⭐⭐☆☆☆ 不需要写代码，建立认知为主

适合谁：想搞清楚 Cloudflare 检测机制底层逻辑的开发者、站长、对网络安全感兴趣的人

先从一个现象说起

你用 Python 的 requests 库访问一个网站，直接被 403 拒绝或者弹出验证码。换成 Chrome 浏览器手动访问，完全正常。

代码里的 User-Agent 已经改成了 Chrome 的字符串，为什么还是被识别？

答案是：Cloudflare 的检测远不止看 User-Agent 这一层。它在请求到达服务器之前，就已经在多个维度上给这个请求打了标签。

本文从底层讲清楚 Cloudflare 是怎么一层一层识别机器人的。

检测体系全景

Cloudflare 的机器人检测是一个多层次的系统，大致可以分为五层：

第一层：网络层指纹（TLS 握手，请求到达前）
↓
第二层：HTTP 层特征（请求头、HTTP/2参数）
↓
第三层：IP 信誉与网络情报
↓
第四层：JavaScript质询（浏览器环境检测）
↓
第五层：行为分析（机器学习模型）

越靠前的层越快、越轻量；越靠后的层越准确、越耗资源。Cloudflare 通常从前往后逐层过滤，早早拦截的就不需要走后面的层。

第一层：TLS 指纹——在你说第一个字之前

HTTPS 连接建立时，客户端（浏览器或脚本）要先和服务器完成一次 TLS 握手。握手的第一步是客户端发送一个 ClientHello 消息，里面包含：

• 支持的 TLS 版本
• 支持的密码套件（Cipher Suites）列表
• 支持的 TLS 扩展（Extensions）
• 椭圆曲线组（Elliptic Curve Groups）
• 签名算法

关键点：不同的客户端，这些参数的组合是不一样的。Chrome 浏览器、Firefox、Python requests、Go 的 net/http，各自有各自的「指纹」。

JA3：第一代 TLS 指纹

2017 年，Salesforce 的研究团队发布了 JA3 算法：把 ClientHello 里的几个关键字段提取出来，拼成字符串，取 MD5 哈希，就得到一个 32 位的指纹字符串。

JA3 = MD5(TLS版本+密码套件+扩展列表+椭圆曲线+点格式)
Chrome的 JA3:579ccef312d18482fc42e2b822ca2430
Python requests:769e8ca3f4c05fc5e50426f8a50800de
curl:771,49196-...-256→对应特定哈希

Cloudflare 维护了一个庞大的 JA3 数据库：哪些哈希对应真实浏览器，哪些对应已知的爬虫工具。 python-requests、 curl、 Gonet/http、各种扫描器的 JA3 哈希都在黑名单里。

即使你把 User-Agent 改成 Chrome，JA3 哈希还是 Python requests 的值——TLS 指纹和 HTTP 头是两个独立的层，改了 User-Agent 改不了 JA3。

JA4：第二代，更稳定

2023 年，FoxIO 发布了 JA4，解决了 JA3 的一个根本缺陷。

Chrome 108 开始，浏览器会随机打乱 TLS 扩展的顺序（这是隐私保护措施）。同一个 Chrome 浏览器，每次握手的扩展顺序不同，JA3 哈希也不同，导致 JA3 产生大量不同的值，难以维护。

JA4 的解决方案是：先排序再哈希。扩展先按固定顺序排好，再计算哈希，输出是一个三段式结构：

JA4 格式：{协议}_{版本}{SNI}{密码数}{扩展数}_{密码哈希}_{扩展哈希}
Chrome131的 JA4 示例：t13d1516h2_8daaf6152771_b0da82dd1658

三段结构让 JA4 同时具备机器可读性（用于自动匹配）和人类可读性（能从字段直接看出客户端特征）。

2026 年的新维度：后量子密钥交换

Chrome 从 2024 年开始默认在 TLS 握手中加入后量子密钥交换（X25519MLKEM768），Firefox、Safari 随后跟进。到 2026 年初，超过 57% 的真实浏览器流量包含这个字段。

这成了一个强力的检测信号：声称自己是 Chrome 131，但 TLS 握手里没有后量子密钥交换——这两个信息互相矛盾，是明显的机器人特征。

第二层：HTTP 层特征

TLS 握手完成后，客户端开始发送 HTTP 请求。这一层也有丰富的指纹信息。

HTTP/2 指纹

HTTP/2 相比 HTTP/1.1 多了很多协议层参数，比如：

• SETTINGS 帧（窗口大小、最大并发流、头部压缩表大小等）
• 流的优先级设置
• 头部字段的顺序和大小写

真实 Chrome 浏览器发出的 HTTP/2 SETTINGS 帧有固定的参数组合。Python 的 httpx、Go 的 net/http 等库的 HTTP/2 实现与浏览器的参数不同。

把 TLS 指纹和 HTTP/2 指纹结合起来，准确率大幅提升。

请求头特征

除了 User-Agent，请求头的整体特征也是信号：

头部顺序：真实 Chrome 发送请求时，各个头部字段的顺序是固定的（ Host → Connection → sec-ch-ua → sec-ch-ua-mobile → ...）。自动化脚本通常用任意顺序或者缺失某些字段。

缺失字段：Chrome 浏览器发送的请求包含一系列 Sec-Fetch-* 头（ Sec-Fetch-Site、 Sec-Fetch-Mode、 Sec-Fetch-Dest），这些是浏览器规范要求加的字段。Python requests 默认不带这些头，缺失即是特征。

User-Agent 与 TLS 的一致性：如果 User-Agent 声称是 Chrome 131，但 TLS 指纹却是 Python requests 的，这种不一致会直接触发拦截。

第三层：IP 信誉与网络情报

Cloudflare 的网络覆盖全球 33% 以上的互联网流量，积累了海量的 IP 信誉数据。

IP 分类：每个 IP 都有对应的 ASN（自治系统号），Cloudflare 知道某个 IP 属于：

• 住宅宽带（真实用户，高信誉）
• 数据中心（AWS、GCP、Azure、阿里云……高度可疑）
• VPN / 代理服务（可疑）
• Tor 出口节点（直接拦截）
• 已知恶意 IP（直接拦截）

从 AWS 或腾讯云的 IP 发出的请求，即使其他一切都完美，也会得到更严格的审查——因为真实用户几乎不会从数据中心 IP 浏览网页。

历史行为：Cloudflare 维护各 IP 的历史攻击记录。曾经发动过 DDoS、扫描漏洞的 IP，即使换了用途也会受到额外审查。

cf.threat_score：这是 Cloudflare 综合 IP 信誉计算出的威胁分数，0-100，越高越危险。免费版可以在 WAF 规则里直接使用这个字段。

第四层：JavaScript 质询——浏览器环境检测

如果前三层没有明确拦截，Cloudflare 可能会下发一个 JavaScript 质询（就是那个「等待 5 秒」的页面）。

这个质询在后台运行大量 JavaScript 检测代码，探测浏览器环境的真实性：

检测项目举例

navigator.webdriver：浏览器被自动化驱动时，这个属性为 true。Puppeteer、Selenium 默认会暴露这个标志。Stealth 插件的工作之一就是把它改成 false。

Canvas 指纹：在 <canvas> 上绘制相同的图形，不同的显卡、操作系统、字体渲染引擎会产生细微的像素差异，这个差异可以作为设备指纹。无头浏览器（Headless Chrome）默认使用软件渲染，产生的 Canvas 指纹与真实设备不同。

WebGL 指纹：通过 WebGL API 获取显卡信息（渲染器、厂商字符串）。无头浏览器通常报告 SwiftShader 或 Mesa，而真实设备报告 NVIDIAGeForceRTX XXX 这类字符串。

字体列表：通过 CSS 测量不同字体渲染宽度，可以枚举出系统安装的字体列表。不同操作系统的字体集合不同，Docker 容器里的 Chromium 字体列表和真实的 macOS/Windows 系统差异明显。

时区与语言一致性： navigator.language 声称是 zh-CN，但系统时区是 UTC？或者语言是 en-US 但 IP 地理位置在中国？这类不一致会被记录。

事件监听：真实用户会触发各种浏览器事件（鼠标移动、滚动、焦点变化），而自动化脚本通常跳过这些，直接访问目标元素。

Turnstile：无感质询

Cloudflare 自家的 Turnstile 是这一层的现代实现。大多数情况下，质询在后台静默完成（0.5 秒内），用户完全感知不到。只有当后台检测发现异常，才会展示明显的验证码。

第五层：行为分析与机器学习

前四层主要处理单次请求的特征，第五层关注的是请求序列的模式。

请求频率与间隔

真实用户浏览网页时，请求之间有不规则的时间间隔（读文字需要时间），而爬虫通常以固定间隔（甚至并发）发出请求。

Cloudflare 会分析：

• 同一 IP 的请求频率是否异常
• 请求路径是否呈现系统性扫描特征（按字母顺序访问、遍历 ID）
• 是否缺少正常用户会产生的伴随请求（CSS、字体、图片通常和主页面一起加载）

cf.client.bot：已验证的合法爬虫

Cloudflare 维护一个已验证合法机器人的列表：Googlebot、Bingbot、Applebot、Twitter 爬虫等。

验证机制：Cloudflare 会反向 DNS 查询爬虫 IP，确认它确实属于声称的服务（比如 Googlebot 的 IP 必须属于 Google 的 ASN），然后标记为 cf.client.bot=true。

在 WAF 规则里， cf.client.bot 是放行合法爬虫的标准做法——不依赖容易伪造的 User-Agent，而是依赖 Cloudflare 自己验证过的爬虫身份。

机器学习评分

Cloudflare Bot Management（付费版）会给每个请求打一个 0-99 的Bot Score：

• 1：几乎确定是机器人
• 99：几乎确定是人类

这个分数综合了前面所有层的信号，以及 Cloudflare 从全网流量中训练的机器学习模型。这个模型能识别出人类难以发现的模式，比如「这批请求的 TLS 指纹没问题，HTTP 头也没问题，但它们的请求时序与已知 Headless Chrome 集群的时序高度相似」。

各层检测能力汇总

为什么「改 User-Agent」没用？

现在可以回答开头的问题了：

改 User-Agent 只能骗过第二层里最粗糙的一个检查。但：

• 第一层（TLS 指纹）：Python requests 的 TLS 指纹和 Chrome 完全不同，改 UA 改不了
• 第二层（请求头完整性）：缺失 Sec-Fetch-* 等头部，或者头部顺序不对
• 第三层（IP 信誉）：从数据中心 IP 发出的请求天然可疑
• 第四层（JS 质询）：Python requests 根本无法执行 JavaScript，质询直接失败

Cloudflare 的检测是多维度的，任何单一维度的伪装都不够，需要在每一层都做到与真实浏览器一致，才能通过完整检测。

小结

Cloudflare 机器人检测的核心设计思路是：建立多层独立的检测维度，任何一层异常都是信号，多层叠加形成综合判断。

五层检测依次是：

1. TLS 指纹（JA3/JA4）：握手时识别客户端软件
2. HTTP 层特征：请求头完整性、HTTP/2 参数
3. IP 信誉：来源 IP 的历史和类型
4. JS 质询：浏览器环境的真实性检测
5. 行为分析：请求序列模式 + 机器学习评分

这个体系对普通开发者的实际意义：

• 站长：了解这些层次，才能配置出真正有效的防护规则（下一篇详细讲）
• 开发者：写自动化脚本时，知道哪些维度会被检测，才能做出合规的设计
• 产品决策：知道免费版能覆盖哪些层，付费版多了什么能力，选型才有依据

下一篇：《接入 Cloudflare Turnstile：用无感验证替换掉 reCAPTCHA》（专题第 2 篇）

专题目录：

• 第 1 篇：原理篇（本篇）
• 第 2 篇：Turnstile 实战篇
• 第 3 篇：防护配置篇
• 第 4 篇：爬虫工程篇

参考链接

• Cloudflare Bot Management 文档：https://developers.cloudflare.com/bots/
• Bot Management 变量参考（cf.bot_management.*）：https://developers.cloudflare.com/bots/reference/bot-management-variables/
• JA3/JA4 指纹文档：https://developers.cloudflare.com/bots/additional-configurations/ja3-ja4-fingerprint/
• Cloudflare 博客：JA4 信号发布：https://blog.cloudflare.com/ja4-signals/
• JA4 开源项目（FoxIO）：https://github.com/FoxIO-LLC/ja4
• JA3 开源项目（Salesforce）：https://github.com/salesforce/ja3
• Cloudflare 已验证机器人列表：https://developers.cloudflare.com/bots/reference/verified-bots-list/
• cf.client.bot 字段说明：https://developers.cloudflare.com/ruleset-engine/rules-language/fields/dynamic-fields/

阅读原文：https://mp.weixin.qq.com/s/Pjloi98WUVbUPxfsrarn4g