一、背景JA3为什么走到了尽头TLS指纹识别作为服务端识别客户端类型的核心技术过去六年几乎是JA3的天下。通过对ClientHello报文中的TLS版本、密码套件、扩展列表、椭圆曲线、点格式五个字段按顺序拼接后计算MD5哈希JA3能够在不解密应用层数据的前提下快速区分浏览器、爬虫、自动化工具和恶意客户端。但从Chrome 110开始谷歌引入了扩展随机化机制——每次TLS握手时扩展列表的顺序都会被随机打乱。这一改动直接击穿了JA3的核心假设同一客户端的字段顺序保持不变。一夜之间同一个Chrome版本生成了上万个不同的JA3哈希指纹库彻底失效。与此同时TLS 1.3全面普及、QUIC协议大规模落地、GREASE值广泛部署JA3的设计局限被无限放大仅支持TCP上的TLS无法覆盖QUIC/DTLS场景单一MD5哈希碰撞风险高且完全不具备可读性依赖字段原始顺序任何浏览器更新都可能产生新指纹不包含ALPN等关键扩展信息识别维度不足2025年5月Salesforce正式归档JA3仓库标志着一个时代的终结。而它的继任者JA4在2023年由原作者John Althouse通过FoxIO推出后用了不到三年时间完成了全行业替代。二、JA4的核心设计思想JA4不是对JA3的简单修补而是从底层重新设计的指纹体系。它的核心突破可以概括为三点排序去随机化、结构化可读、多协议扩展。2.1 最关键的改进排序前哈希JA4解决扩展随机化问题的思路非常直接在计算哈希之前先把密码套件和扩展列表按数值从小到大排序。无论Chrome如何打乱扩展顺序排序后的列表永远是一致的最终哈希自然保持稳定。这一看似简单的改动从根本上解决了浏览器随机化带来的指纹爆炸问题。需要注意的是签名算法列表保持原始顺序不做排序因为顺序本身就是一个重要的识别特征。2.2 三段式结构化格式JA4摒弃了JA3单一哈希的设计采用a_b_c三段式结构每段都有明确的语义t13d1516h2_8daaf6152771_02713d6af862第一段A段人类可读元数据固定10个字符直接就能读出连接的核心属性第1位传输协议tTCPqQUICdDTLS第2-3位TLS主版本号13代表TLS 1.3第4位SNI状态d携带域名i直连IP无SNI第5-6位密码套件数量去GREASE后第7-8位扩展数量去GREASE后第9-10位首个ALPN协议h2HTTP/2h3HTTP/300无ALPN第二段B段密码套件哈希取排序后的密码套件列表SHA256哈希的前12位十六进制字符。只反映客户端支持哪些密码不反映顺序。第三段C段扩展签名算法哈希取排序后的扩展列表与原始顺序的签名算法列表合并后的SHA256哈希前12位。既保留了扩展集合信息又保留了签名算法的顺序特征。2.3 GREASE的显式处理GREASEGenerate Random Extensions And Sustain Extensibility是浏览器为了防止服务器僵化而引入的随机值会出现在密码套件、扩展、椭圆曲线等多个位置。JA3对GREASE的处理依赖各实现自行判断标准不统一导致相同客户端产生不同哈希。JA4则在规范中明确规定了所有GREASE值的范围和剔除规则从标准层面保证了不同实现的一致性。三、JA4完整计算流程下面拆解一个标准的TLS 1.3客户端握手的JA4计算全过程步骤1提取ClientHello字段从原始报文中解析出传输层协议类型TCP/QUICTLS版本号优先取supported_versions扩展SNI扩展是否存在完整的密码套件列表完整的扩展列表签名算法列表ALPN扩展列表步骤2清洗数据移除所有GREASE值密码套件、扩展中对密码套件去重对扩展ID去重步骤3计算A段按照固定格式拼接元数据传输协议首字母两位版本号SNI状态位两位密码套件数量不足补零两位扩展数量不足补零两位ALPN首个协议缩写步骤4计算B段将密码套件按十六进制数值升序排列用逗号拼接成字符串计算SHA256哈希取前12个字符步骤5计算C段将扩展ID按十六进制数值升序排列用逗号拼接扩展ID字符串拼接下划线按原始顺序拼接签名算法用逗号分隔对整个字符串计算SHA256哈希取前12个字符步骤6最终拼接用下划线连接A_B_C三段得到完整JA4指纹。四、JA3与JA4深度对比维度JA3JA4输出格式32位MD5哈希三段式结构化字符串字段顺序保留原始顺序密码和扩展排序签名算法保序协议支持仅TCP TLSTCP TLS / QUIC / DTLS可读性完全不透明A段直接可读核心属性抗随机化完全失效免疫扩展/密码顺序随机化哈希算法MD5SHA256截断12位ALPN信息不包含A段包含首个ALPNGREASE处理各实现自行处理规范明确定义维护状态已停止维护活跃迭代JA4全家桶这里特别说明截断哈希的设计12位十六进制字符相当于48位熵在指纹场景下碰撞概率极低同时大幅缩短了字符串长度便于日志存储和检索。五、2026年行业落地现状截至2026年JA4已经完成了主流安全厂商的全面覆盖CDN与WAF厂商CloudflareBot Management原生支持JA3/JA4双字段日均处理数十亿次指纹计算AkamaiBot Manager将JA4作为核心服务端信号之一华为云WAF提供JA4指纹标记配置支持精细化流量管控Imperva、F5均已在Bot Management产品中集成JA4套件反欺诈与身份安全DataDome将JA4与TCP指纹、HTTP/2帧分析结合构建动态信任评分Auth0将JA4信号集成到Bot Detection模型提升了对IP轮换攻击的识别率各大银行电商普遍将JA4作为设备指纹的补充校验维度工具与生态Wireshark 4.2原生支持JA4解析curl 8.5内置--ja4参数可打印自身指纹所有主流编程语言都有成熟的JA4计算库威胁情报平台普遍支持JA4检索和聚合六、实战常见客户端JA4特征实际环境中不同技术栈的JA4特征差异非常明显Chrome 120 on Linuxt13d1516h2_8daaf6152771_02713d6af862典型特征15个密码套件16个扩展ALPN优先h2扩展集合完整。Python requests urllib3t13d0911h2_53ff67ce45e7_9e5a79d2c9e1典型特征密码套件数量少通常9个扩展数量偏少缺少浏览器特有的扩展。Go标准库net/httpt13d1309h2_2b93ed2bf9a1_7b7370ce0d21典型特征扩展数量少9个签名算法顺序与浏览器明显不同。curl OpenSSLt13d1713h2_9a13ba00c917_3c27e0e81a9b典型特征密码套件多扩展顺序有自己的风格。Playwright无头浏览器未打补丁t13d1516h2_8daaf6152771_02713d6af862注意最新版Playwright已经能够完美模拟Chrome的JA4单靠TLS指纹无法区分需要结合HTTP行为和JS指纹。七、JA4的局限性与对抗JA4不是银弹它同样有自己的边界7.1 可以被伪造JA4本质是服务端被动观测的特征只要客户端完全模拟真实浏览器的TLS握手参数和顺序就能生成相同的JA4。curl_cffi、Playwright、Puppeteer等工具都已经实现了JA4级别的模拟。正确的认知是JA4的价值不在于匹配即合法而在于不匹配即可疑。如果一个请求UA写着Chrome 126JA4却对应Python requests那几乎可以肯定是伪造的。7.2 排序丢失信息排序虽然解决了随机化问题但也丢失了扩展顺序这个维度的信息。早期JA3能够通过扩展顺序区分不同Chrome小版本JA4做不到这一点。7.3 仅覆盖握手阶段JA4只看ClientHello不关心后续的TLS行为。更精细的识别还需要结合TCP/IP层指纹p0f风格HTTP/2帧顺序和流量控制参数TLS会话复用行为证书验证策略应用层行为特征八、JA4全家桶JA4只是整个JA4体系的一部分完整的套件还包括JA4STLS服务端指纹基于ServerHello计算JA4HHTTP客户端指纹基于请求头顺序和格式JA4SSHSSH客户端指纹JA4X509证书指纹这套体系的目标是建立一套跨协议、标准化、人类可读的网络指纹规范解决过去各厂商各自为政、指纹无法互通的问题。九、总结从JA3到JA4本质上是TLS指纹技术从简单粗暴到工程化设计的进化。排序机制解决了浏览器随机化的核心痛点结构化格式提升了可读性和可运维性多协议扩展适配了最新的网络环境。2026年的今天JA4已经从新技术变成了基础设施。对于安全从业者来说理解JA4的原理和局限合理运用到反爬、反欺诈、威胁狩猎场景中是一项必备的基础技能。但也要清醒认识到没有任何单一指纹是万能的。真正有效的客户端识别永远是多层信号的交叉验证——TCP层、TLS层、HTTP层、应用层行为多维度结合才能构建可靠的防御体系。合规提醒本文涉及的TLS指纹技术仅用于合法的安全防护与流量分析场景请遵守相关法律法规不得用于非法突破访问控制或侵害他人权益。