TLS 指纹检测(JA3 / JA4)

看看你的浏览器在 TLS 握手层长什么样——这层指纹在 JavaScript 之下,伪装浏览器改不到它。

直连采集,不经代理转发

TLS 指纹是什么

每个客户端在与服务器建立 HTTPS 连接时,第一个发出的报文叫 ClientHello:里面带着自己支持的协议版本、 密码套件列表、椭圆曲线、扩展清单、签名算法……不同软件(Chrome、Safari、Python、Go、curl) 的这些清单各不相同,而且顺序固定。把这些字段按规范拼起来做哈希,就得到 JA3(及升级版 JA4)指纹——它唯一标识"发起握手的软件种类",不依赖任何网页脚本。

为什么风控系统都在用它

反欺诈系统最关心的是"自报身份"和"底层特征"是否一致:一个声称自己是 Chrome 的客户端, 如果 TLS 握手呈现的是 Python requests 或 Go http.Client 的指纹,直接判定为脚本伪装。 浏览器指纹伪装工具(改 UA、改 Canvas、改字体)全部工作在 JS 与 HTTP 层之上,动不了 TLS 握手层——这就是它难以伪装、被广泛引用的原因。同理,大量爬虫框架和自动化工具 因为 TLS 指纹与真实浏览器不符而被识别,即使其他一切都伪装到位。

JA3 与 JA4 的区别

JA3 是 2017 年 Salesforce 提出的经典算法:把版本、密码套件、扩展、曲线、点格式五个字段拼接后取 MD5。 它的局限是扩展顺序敏感、不支持 GREASE 之外的新型指纹混淆。JA4 是 2023 年 FoxIO 提出的升级方案: 把"协议版本 + SNI 是否携带 + 各列表长度 + ALPN"编入可读性前缀(如 t13d1516h2 表示 TLS1.3、带 SNI、 15 个套件、16 个扩展、HTTP/2),哈希部分则对列表排序后计算,抗顺序混淆能力更强。 本工具同时给出两者,方便与各类风控报告对照。

本工具的采集方式

点击检测后,你的浏览器会直连本站的指纹采集服务(tls.ipchase.com,不经 Cloudflare 代理转发), 服务器在完成 TLS 握手前读取你发送的 ClientHello 报文并计算指纹——整个过程只握手一次, 不上传任何内容,也不会存储 Cookie。你在其他设备、其他网络(切换代理前后)分别测一次, 就能看出代理链路是否正确转发并伪装了 TLS 握手。

检测出"非浏览器指纹"怎么办

如果你在用带 TLS 伪装功能的代理客户端(如基于 uTLS 的工具),检测结果的 JA4 应与真实浏览器一致; 若显示 curl / Go / Python 特征,说明该链路直接透传了客户端的 TLS 握手,风控系统一眼可辨。 修复方向:换用支持 TLS 指纹伪装(uTLS / fingerprint 选项)的客户端,并把伪装目标设为与你日常 浏览器同版本的特征。

相关文章

更多内容见 博客列表

常见问题

为什么这个检测要直连,不能像其他检测一样走主站?

因为 JA3/JA4 的数据来源是 TLS 握手报文本身。主站流量经 Cloudflare 代理转发,我们只能看到 Cloudflare 与源站之间的握手,而不是你浏览器的握手。所以指纹采集必须放在一个直连的专用子域上。

TLS 指纹会暴露我的真实 IP 吗?

不会。ClientHello 报文里只有软件特征(协议版本、算法清单),不含 IP、Cookie 或设备信息。服务器本来就能看到你的 IP(这是 TCP 连接的基本属性),指纹检测不会额外增加暴露。

同一台电脑每次检测的指纹会变吗?

不会频繁变。同一浏览器版本的 JA3/JA4 是稳定的——这正是它的价值:风控把它当作"设备环境"的稳定信号。只有升级浏览器大版本、切换浏览器内核或启用特殊的 TLS 混淆工具时才会变化。

JA3 指纹可以伪造吗?

理论上可以(使用 uTLS 等库重放浏览器的 ClientHello),工程上难度高且容易顾此失彼——改了 TLS 层还要保证与 HTTP/2 指纹、行为特征一致,否则矛盾本身就是新的风控信号。这也是为什么风控系统把它当作高置信度信号。

检测显示的版本号和我的浏览器版本一致吗?

JA3/JA4 标识的是"TLS 栈特征"而不是浏览器版本号。同一浏览器大版本族(如近两年的 Chrome)共享相同的 TLS 栈特征,所以指纹相同不代表版本相同,但指纹不同几乎一定不是同一种软件。