JA3 / JA4 TLS 指纹检测原理详解（附免费自测工具）

你的爬虫发送了完美的 Chrome 请求头，跑在一个干净的住宅 IP 上，可第一个请求就吃了个 403。没有验证码，没有质询页面，什么需要解的东西都没有。网站在一个 HTTP 字节都还没交换之前就认出了你——就在 TLS 握手阶段。

这篇文章讲清楚 JA3 和 JA4 指纹到底是怎么工作的，为什么它们是 2026 年每一套主流反爬系统背后默默干活的主力，以及如何在十秒内看到你自己的指纹。如果你更想先要绕过工具，我们在 用 curl_cffi 和 tls-client 绕过 TLS 指纹 里讲过——本篇是它的姊妹篇，专讲检测一侧是怎么运作的。

十秒测试

在讲理论之前，先看看你自己的握手。打开我们免费的 JA3/JA4 检测工具——它会把你的客户端刚刚呈现的 TLS 指纹原样回显给你，并告诉你它匹配上了什么：

# 在终端里 - 看看 curl 的 TLS 长什么样：
curl https://check.jibaoproxy.com/api/fingerprint

# 然后在 Chrome 里打开同一个 URL 做对比。

两个都跑一遍，你就会明白整篇文章的要点：curl 和 Chrome 产生的指纹完全不同，无论你把 User-Agent 头设成什么都一样。

TLS 握手里发生了什么

每一个 HTTPS 连接都从一条 ClientHello 消息开始，它在任何加密开始之前以明文发送。在这条消息里，你的客户端会声明：

• 它支持的 TLS 版本
• 一份有序的、它接受的密码套件（cipher suites）清单
• 一份有序的扩展（extensions）清单（SNI、ALPN、key share、session tickets……）
• 支持的椭圆曲线（elliptic curves）和点格式

检测的精髓在这里：这些清单以及它们的精确顺序，是被烧死在你客户端编译时所链接的那个 TLS 库里的。Chrome 的 BoringSSL 声明的是一种特定组合，Python 的 OpenSSL 声明的是另一种，Go 的 crypto/tls 又是第三种。你没法用请求头改变它——它是在 HTTP 层之下、由库本身协商出来的。

JA3：给握手算哈希

JA3（Salesforce，2017）把 ClientHello 的五个字段——TLS 版本、密码套件、扩展、曲线、点格式——拼接成一个字符串，再做 MD5 哈希：

771,4865-4866-4867-49195-49199,0-23-65281-10-11-35-16,29-23-24,0
              |
              v  MD5
        cd08e31494f9531f560d64c695473da9

每一种 TLS 栈对应一个哈希。每一份运行在 Windows 上的 Chrome 137 产生的 JA3（几乎）都一样；每一个跑在 OpenSSL 3.x 上的 python-requests 产生的也是同一个、但不同的 JA3。防守方维护着查找表：哈希 X = Chrome，哈希 Y = requests，哈希 Z = Go bot。如果你的 User-Agent 说自己是 Chrome、而你的 JA3 却说是 OpenSSL，你就会被拦——瞬间、无声、还很省成本。

JA4：2026 年的标准

JA3 有它的问题：Chrome 从 2023 年开始随机化扩展顺序（这破坏了天真的 JA3），而且 MD5 是无结构的——一个哈希压根说不清两个客户端为什么不同。JA4（FoxIO，2023）把这两点都修了，也是如今正经厂商在跑的东西：

JA4 = t13d1516h2_8daaf6152771_b0da82dd1658
       |            |             |
       a: protocol  b: ciphers    c: extensions
       (TLS 1.3, 16 ciphers,      (sorted, truncated
        h2 ALPN, domain SNI)       SHA256)

• 排序后再哈希，而非按顺序对密码套件/扩展做哈希——天然免疫 Chrome 的随机化。
• 三段可读的片段——防守方可以基于部分指纹匹配（"任何只带 ALPN h1 的 TLS 1.2 客户端"）。
• 一整个家族：JA4H（HTTP 请求头）、JA4T（TCP 选项）、JA4X（证书）——跨层一致性校验。一个 Chrome 的 JA4 配上一个 curl 的 JA4H，本身就是个危险信号。

谁在拿它对付你

所有重要的系统都在用：Cloudflare 在它的 bot 管理规则里直接暴露 JA3/JA4；DataDome 和 PerimeterX 把它喂进网络层的评分（见我们的 DataDome/PerimeterX 指南）；Akamai 跑 TLS 指纹的历史比谁都长。它之所以流行，是因为它计算免费、在 HTTP 层无法伪造、还能抓住 90% 的天真自动化——每一个曾经写出来的 requests/httpx/axios/Go-http 脚本——在任何 JavaScript 需要运行之前就抓住。

为什么光靠代理没用

这一点常让人意外：代理换的是你的 IP，但你的 TLS 握手是原封不动地穿过去的。CONNECT 隧道（或 SOCKS5 流）会把你的 ClientHello 字节一字不差地带到目标。住宅 IP + requests 库的 JA3 = "一个跑在住宅 IP 上的 bot"。是比数据中心 IP 强，但仍然是个 bot。

IP 和 TLS 指纹是相互独立的信号，两个你都得弄干净：

IP	TLS 指纹	2026 年的裁决
数据中心	库（requests/Go）	所有在意这事的地方都拦
住宅	库	在检查 JA4 的网站被拦
数据中心	浏览器仿冒	因 IP 信誉被拦
住宅	浏览器仿冒	通过网络层检查

让你的指纹和你的说辞对上

两条路，按工具划分：

HTTP 客户端——用一个能重新实现浏览器精确 ClientHello 的仿冒库：curl_cffi（Python）、tls-client（Python/Go）、got-scraping（Node）。完整可运行代码见 curl_cffi 指南：

from curl_cffi import requests

r = requests.get(
    "https://target.example",
    impersonate="chrome",
    proxies={"https": "socks5h://USERNAME:[email protected]:913"},
)

真实浏览器（Playwright、浏览器 agent、anti-detect 浏览器）——在 TLS 层无事可做；指纹货真价实就是 Chrome 的。你的风险在别处：IP 信誉和 CDP 检测。

然后要验证，而不是假设。版本会漂移——一个被钉死在 Chrome 120 握手上的仿冒库，在 2026 年读出来就是"可疑的过时浏览器"。每次依赖更新后都重新测一遍：

小结

• JA3/JA4 指纹化的是 TLS 库，而不是请求头——检测发生在 HTTP 存在之前。
• JA4 是 2026 年的标准：抗随机化、可读、跨层（JA4H/JA4T/JA4X）。
• 代理碰不到你的 TLS 指纹；IP 和握手是独立信号——两个都要弄干净。
• HTTP 客户端用 curl_cffi/tls-client 做仿冒；真实浏览器天生就是干净的。
• 每次更新后都在 check.jibaoproxy.com 验证一遍。