一、JA4 的由来
JA3 自 2017 年发布后被大量采用，但它有两个明显短板：一是输出是 MD5 哈希，完全不可读，运维排查困难；二是 TLS 1.3 普及后，ClientHello 里的很多字段被简化，JA3 的区分度下降。2023 年，JA3 的原作者 John Althouse 发布了继任者 JA4，专门解决这些问题。
二、两者最核心的差异
2.1 输出形式：哈希 vs 结构化
JA3 把结果压成一个 MD5，比如 a0e9f5d64349fb13191bc781f81f42e1。你只能拿它做比对，看不出任何含义。JA4 则输出类似这样的字符串：
t13d1516h2_8daaf6152771_02713d6af862
拆解含义：
t → TCP 传输
13 → TLS 1.3
d → 域名类型（Domain）
1516 → 加密套件数量 15，扩展数量 16
h2 → ALPN 协商结果为 HTTP/2这种设计让运维一眼就能看出客户端特征，排查异常流量效率大幅提升。
2.2 对 TLS 1.3 的支持
TLS 1.3 中，加密套件的差异被大幅削弱，JA3 依赖的很多字段趋同，导致大量不同客户端算出同一个 JA3。JA4 重新选择了区分度更高的字段组合（版本、SNI 类型、套件数、扩展数、ALPN），在 TLS 1.3 下依然保持很高的区分能力。
2.3 支持 QUIC
随着 HTTP/3 和 QUIC 普及，基于 TCP 的 JA3 无能为力。JA4 体系里专门有 JA4Q 用于 QUIC 指纹，覆盖了新一代传输协议。
2.4 区分方向与多维度
JA4 用 a/b 前缀区分客户端指纹（JA4）和服务端指纹（JA4S），还能配合 JA4H（HTTP 头）、JA4L（延迟）等形成一套完整的指纹体系，而不是单一指标。
三、对比速览
| 对比项 | JA3 | JA4 |
|---|---|---|
| 可读性 | 不可读哈希 | 结构化可读 |
| TLS 1.3 区分度 | 下降明显 | 保持良好 |
| QUIC/HTTP3 | 不支持 | 支持（JA4Q） |
| 实现复杂度 | 简单，生态成熟 | 稍复杂，生态在完善 |
| 工具支持 | 几乎所有 WAF/CDN | 新版本 WAF 逐步支持 |
四、现阶段该用哪个
结论很务实：两者不是二选一，而是互补。
- 存量环境以 TLS 1.2 为主：JA3 生态成熟、库丰富，继续用 JA3 完全够用
- TLS 1.3 / HTTP/3 流量占比高：优先 JA4，避免指纹碰撞导致的误判
- 最好的做法：WAF 同时提取 JA3 和 JA4，任一命中黑名单即拦截
- 做业务白名单时：用 JA4 更稳，因为它跨版本的一致性更好
五、对站长的实际意义
你不需要自己实现指纹算法。选 WAF 时，注意看两个点：一是是否支持 TLS 指纹识别功能，二是是否已跟进 JA4。像百度云防护这类云 WAF，已经在控制台里把 JA3/JA4 识别做成了可勾选的防护项，开启后自动生效。
# 自测：用 curl 模拟脚本访问，观察是否被拦
curl -I https://你的域名/
# 用真实浏览器访问同一地址对比
# 若脚本请求被 403/验证码拦截，说明 TLS 指纹已生效六、小结
JA4 是 JA3 的全面升级，解决了可读性、TLS 1.3 区分度和 QUIC 支持三大问题。当前阶段，能同时支持 JA3 + JA4 的 WAF 是最稳妥的选择；若只能选一个，TLS 1.3 流量大的站点选 JA4，其余场景 JA3 依旧够用。
