全部文章

JA4 与后量子 TLS 击垮了基础爬虫

您的 User-Agent header 已经不再重要。在读取 header 之前,JA4 指纹就能以 98.6% 的准确率识别出 bot。以下是 2026 年发生的变化。

TLS 握手是 Bot 检测的最低门槛

98.6%。

这是 CatBoost 模型仅使用 JA4 特征达到的分类准确率。没有 header。没有 IP。没有行为分析。仅仅依靠 TLS 握手的特征。arXiv 论文于 2026 年 2 月发表,这一结果并非特例。Cloudflare、AWS、VirusTotal 和 Akamai 都在生产环境中运行 JA4(或其早期的兄弟版本 JA3)。如果您在 2026 年仍在使用普通的 HTTP 客户端进行爬取,那么在您的 request 到达应用层之前,判决就已经做出了。

这是 bot 检测教程中经常忽略的部分。大多数关于绕过反爬(anti-bot)的文章仍围绕着 User-Agent 轮换、cookie 和 CAPTCHA 展开。这些都是简单的层级。但 TLS 层是您无法通过伪造 header 来蒙混过关的。

JA4 到底在检测什么

JA4 是 TLS ClientHello 的指纹。它对协议(TCP 或 QUIC)、TLS 版本、SNI 存在性、有序密码套件、扩展、签名算法以及 ALPN 进行编码。输出是一个紧凑的字符串,例如 t13d1516h2_8daaf6152771_e5627906d626。两个声称是同一浏览器的客户端会生成相同的 JA4 哈希值。而一个声称是 Chrome 的 Python requests 脚本所生成的 JA4 指纹,除了在爬虫中,在世界上任何其他地方都不存在。

JA4 系列(由 FoxIO 开发,也是 JA3 背后的团队)解决了 JA3 的最大弱点:扩展排列(extension permutation),这是 Chromium 在 2023 年引入的,旨在打破简易的指纹识别。JA4 对扩展进行排序并计数,因此随机化毫无用处。这里没有简单的逃生通道。

Akamai 透露,通过跨层分析,bot 分类准确率达到了 92% 至 98%。跨层部分至关重要。虽然仅 TLS 就是主导信号,但将其与 HTTP/2 帧顺序、header 顺序以及 request 耗时相结合,可将误报率降至远低于大多数爬虫所能容忍的水平。

后量子时代的转折

这是谁也没料到的部分。2026 年 1 月 31 日,Akamai 将后量子密钥交换设为了所有连接的默认配置。到 2026 年初,57.4% 的真实浏览器发起连接都包含了 X25519MLKEM768 密钥共享。Chrome 支持 PQ 的比例在 93% 左右。Firefox 132 为 85%。Safari 正在逐步推广。

PQ 密钥共享非常庞大。经典 X25519 为 36 字节,而它需要 1,124 字节。ClientHello 从 300-500 字节增加到了 1,400 字节以上。这种增长体现在 JA4、数据包捕获以及 WAF 的被动观察中。

如果您的爬取客户端不包含 PQ 密钥共享,那么您声称的身份是任何当前的 Chrome 或 Firefox 都不会表现出来的。2026 年第一季度的两个 CVE 正好标记了这种不匹配:CVE-2026-26995(填充扩展)每次 request 带来 25% 至 50% 的检测概率,而 CVE-2026-27017(ECH 和 GREASE 不匹配)的检测概率在 50% 左右。在整个会话中叠加起来,暴露的概率将趋近于 100%。

这是一个原本有 12 个月缓冲期、如今却缩短至 3 个月的问题。大多数开源爬取技术栈尚未支持兼容 PQ 的 TLS。而那些已经支持的,也比真实的 Chromium 滞后数周。

为什么 proxy 无法解决这个问题

坊间流传着一个令人宽慰的说法:更大的 proxy 池可以解决现代 bot 检测问题。其实不然。Security Boulevard 报道的 2026 年 1 月黄牛抢购事件中,攻击者在 390 万个独立 IP 上发起了 1600 万次 request。基于单 IP 的封禁毫无用处。真正起作用的防御手段主要是 TLS 和行为指纹识别。

住宅 proxy 的经济模型也在本季度宣告破裂。Help Net Security 在 2026 年 4 月报道,1 月份 IPIDEA 网络的瘫痪导致行业住宅网络容量一夜之间缩减了约 40%。与这一容量打击相比,Bright Data 与 Oxylabs 的专利战(最高法院于 2026 年 2 月 23 日驳回了 Bright Data 的申请,审判原定于 5 月 18 日进行)与这一容量打击相比,不过是个小插曲。购买住宅 IP 以防御指纹识别的买家,正在为 WAF 根本不在乎的解决方案支付更高的溢价。

Proxy 依然重要,但原因并非大多数人所想的那样。地理分布和 ISP 类型决定了路由决策和 rate limit 配置文件。但它们无法帮您在握手阶段存活下来。

这对数据团队意味着什么

如果您在 2026 年构建或购买爬取基础设施,有三件事将会发生改变。

首先,TLS 技术栈现在是硬性要求。任何未能模拟真实浏览器 TLS 握手(PQ 密钥共享、扩展排序、ALPN、签名算法)的客户端,其生成的指纹都会被高置信度地归类为 bot。在 Python requests 外层套上更好的 header 解决不了任何问题。传输层才是破绽所在。

其次,headless 浏览器检测变得更加严苛,而非更宽松。Browserless 的《2026 年网页爬取现状报告》指出,headless 与 headed Chromium 之间的差距正在拉大。Anti-bot 厂商已经对指纹差异进行了分类,并在客户网站之间近乎实时地共享威胁情报。一个在 12 月份还能正常工作的 headless 实例,到了 5 月份可能就会被归类为 bot。行为信号叠加在 TLS 之上,且两者都是动态变化的目标。

第三,自研与购买的性价比天平发生了倾斜。维护一个与动态目标相匹配的 TLS 指纹(Chromium 每隔几周就会发布 PQ 更新,扩展顺序在微版本之间发生变化,密码套件偏好不断漂移)现在成了一项全职工作。在 2024 年,团队可能只需投入 20% 的工程师精力来维护爬虫,而到了 2026 年,这一投入已超过半个全职人力。我们之前曾写过关于为什么爬虫会不断失效的文章。在 2026 年,答案更常是“TLS”,而非“DOM”。

最便宜的爬虫是那些未被识别分类的爬虫

值得关注的预测并不是 anti-bot 厂商是否会继续提高门槛。他们肯定会。值得关注的预测是,在 98% 准确率已成为准入门槛的市场中,哪些爬取工具能够存活下来。

大多数都无法存活。但那些存活下来的工具会将 TLS 握手视为 request 的一部分,而不仅仅是一个传输细节。买家也将开始向供应商提出一个在 12 个月前还不在评估清单上的问题:你们提供什么样的 TLS 指纹,更新频率有多快?

在 request 甚至还没来得及表明身份之前,握手就已经决定了一切。