TLS 指纹：比浏览器指纹更难伪装的那一层

提到"指纹检测"，大多数人想到的是 Canvas、WebGL、字体这些浏览器特征——它们都在 JavaScript 的势力范围内，伪装工具改得动。但在整个指纹体系里，有一层藏得更深：TLS 握手指纹。它位于 HTTPS 连接的第一个报文里，先于任何网页内容、任何脚本执行就暴露了"你是什么软件"。

ClientHello：暴露身份的第一句话

浏览器与服务器建立 HTTPS 连接的第一步，是发送一条叫 ClientHello 的明文报文，内容包括：

• 支持的 TLS 协议版本（1.0 / 1.1 / 1.2 / 1.3）
• 支持的密码套件清单及顺序
• 椭圆曲线（supported_groups）与签名算法清单
• 扩展列表及顺序（SNI、ALPN、key_share……）

不同软件写死的这些清单完全不同：Chrome 的清单是它自己的组合与排序，Safari 是另一套，Python 的 requests、Go 的 net/http、curl 也各不相同——而且这些清单由各软件的 TLS 库写死在代码里，用户和网页脚本都无法修改。

JA3 与 JA4：把"第一句话"变成指纹

JA3（2017，Salesforce）的算法很直接：把上述五个字段按固定格式拼接成字符串，取 MD5。比如一个典型 curl 客户端的 JA3 串形如：

769,4867-4866-4865-...,43-51-11-10-13-16,29-23-24-25,0

服务器只要完成一次握手，就能得到这个指纹并入库比对。

JA4（2023，FoxIO）针对 JA3 的弱点做了升级：JA3 对扩展顺序敏感，新式客户端故意打乱顺序就能让 JA3 失效。JA4 把指纹拆成三段：

• A 段（可读）：t13d1516h2 = TLS 1.3 + 带 SNI + 15 个密码套件 + 16 个扩展 + HTTP/2——人眼就能读出客户端轮廓
• B 段：密码套件排序后哈希——抗顺序混淆
• C 段：扩展、签名算法与 ALPN 的组合哈希

今天主流风控系统两套都在用：JA3 看历史库命中，JA4 做更强的身份归类。

为什么这层指纹"难伪装"

浏览器的三层特征，伪装难度完全不同：

层	代表特征	伪装难度
JS 层	Canvas、WebGL、字体、UA	低——伪装浏览器随便改
HTTP 层	请求头顺序、H2 设置帧	中——需要深度改造客户端
TLS 层	ClientHello 清单与顺序	高——改它等于重写 TLS 栈

风控逻辑因此很简单：如果自报身份和 TLS 指纹对不上，就是伪装。一个声称 Chrome 的会话，TLS 握手却呈现 Python 的特征，不需要任何人工判断即可拦截。大量"明明什么都改了还是被封"的案例，根因都在这一层——代理链路直接透传了客户端原始的 TLS 握手。

实战：怎么检测与修复

检测很简单：访问 TLS 指纹检测工具，服务器直读你与它握手时的 ClientHello，几秒内给出 JA3、JA4、协议版本和 ALPN。

判断标准：

• 日常浏览器直连检测：JA4 应呈现正常浏览器特征（t13d…h2/h1）。没问题就说明你的浏览器本身特征正常
• 挂上代理再测：如果 JA4 变成了 curl / Go / Python 的特征，说明这条链路在 TLS 层"裸奔"——风控一眼可辨
• 修复：换用支持 TLS 伪装的客户端（基于 uTLS 的方案可以把握手伪装成指定浏览器特征），并注意保持与 HTTP/2 指纹、时区、语言等维度的一致性，理由见伪装度的本质

要注意的另一面是：TLS 指纹稳定本身不是罪。同一台电脑上它长期不变，这正是风控把它当"环境锚点"的原因——配合 IP 信息（见 IP 归属地查询）交叉验证，才能既识别脚本又不误伤真人。

一个常见的误解

"我用指纹浏览器改了所有参数，TLS 指纹也会跟着变吧？"——不会。绝大多数指纹浏览器修改的是 JS 可见特征；TLS 层要么原样透传（暴露真实软件），要么整体套用某个浏览器的模板。模板与真实环境其他维度的错配（TLS 是 Chrome 120 的特征、Canvas 却是另一版本的），反而制造新的矛盾信号。这也是我们始终强调"一致性比单点伪装更重要"的原因。

小结

TLS 指纹是风控体系里离身份最近、离伪装最远的一层。理解它，你就理解了为什么"改 UA 没用"、为什么有些代理"怎么用都被识别"。花三十秒在 TLS 指纹检测上看看自己的握手特征，是理解这套体系的最好起点。