在发送任何一字节 HTTP 之前，你的 TLS 握手就已标识了你的客户端。做这件事的指纹变了——从 JA3 到 JA4——如果你的工具还在玩旧游戏，你早已被标记。
JA3 对顺序敏感的 TLS Client Hello 字段列表做哈希。当 Chrome 开始随机化 TLS 扩展顺序，每个 Chrome 请求都产生不同的 JA3——对世界上最常见的浏览器失效。JA4/JA4+ 取而代之：哈希前对顺序可变字段排序、可读、跨 TLS/HTTP/TCP 模块化。它稳定且更难伪造——2026 年若你的指纹与所声称浏览器不符，正是它屏蔽你。 修复办法是在真实 移动 IP 上看起来像真实浏览器。
JA3 的做法是把 TLS Client Hello 中的字段——版本、密码套件、扩展、椭圆曲线、点格式——按出现顺序拼接再哈希。多年来该顺序在每个浏览器中稳定，所以哈希是可靠签名。
随后 Chrome 作为抗僵化措施开始在每次连接随机化 TLS 扩展顺序。由于 JA3 顺序敏感，同一个 Chrome 现在产生不断变化的 JA3——使该指纹对最重要的浏览器失去用处。反爬厂商无法再依赖它。
| JA3 | JA4 / JA4+ | |
|---|---|---|
| 扩展顺序 | 顺序敏感（随机化即崩） | 对顺序可变字段排序 → 稳定 |
| 可读性 | 不透明 MD5 哈希 | 可读、结构化 |
| 范围 | 仅 TLS | 模块化：TLS、HTTP、TCP、延迟（JA4+ 套件） |
| 后量子感知 | 否 | 反映握手中的 PQ 密钥共享 |
| 伪造难度 | 中等 | 高——必须匹配真实、当前客户端 |
JA4 是更广的 2026 指纹识别栈的一层，现在还携带 后量子密钥共享信息——所以过时的 TLS 画像会双重失败。
两者都对 TLS Client Hello 做指纹，但 JA3 对一个固定、顺序敏感的字段列表做哈希。当 Chrome 开始随机化 TLS 扩展顺序，每个 Chrome 请求都产生不同的 JA3——使其无法用于识别 Chrome。JA4 通过在哈希前对顺序可变字段排序、并且可读、模块化（JA4+ 覆盖 TLS、HTTP、TCP 等）解决了这点，得到稳定且更难伪造的指纹。
作为主信号已很少。Chrome 的扩展顺序随机化破坏了 JA3 对最常见浏览器的可用性，反爬厂商转向 JA4/JA4+。出于历史原因你可能仍会看到 JA3 被记录，但 2026 年的屏蔽决策倚重 JA4 及相关信号。
最可靠的方式是真正成为真实、最新的浏览器引擎而非原始 HTTP 客户端——这样你的 JA4 在构造上就正确，包括后量子密钥共享。若使用 TLS 模拟库，保持其画像最新。无论哪种方式，都要把匹配的指纹与真实移动 IP 配对，让网络层一致；数据中心 IP 上完美的 JA4 仍然可疑。