TLS 指纹测试

TLS 指纹是根据您浏览器的 ClientHello 生成的特征签名。ClientHello 包含浏览器在握手过程中按确切顺序声明的密码套件、扩展、椭圆曲线和 TLS 版本。由于不同的浏览器、操作系统和 HTTP 库组合这些参数的方式各不相同，指纹可以可靠地识别正在连接的客户端类型。反机器人系统会在读取您页面请求的第一个字节之前，就利用它来区分真实浏览器和自动化程序。

JA3 是最初的方法：它将 ClientHello 中的 TLS 版本、密码套件、扩展和曲线拼接起来，并哈希为一个 32 个字符的 MD5 值。JA4 是更现代的继任者：它便于人工阅读，包含更多字段（如 ALPN 和扩展数量），并且更能抵御新版浏览器引入的随机化。JA4 更难规避，并日益成为 Cloudflare 等厂商采用的标准，因此您经常会看到两者并列显示。

JA3N 是 JA3 的规范化变体。Chrome 等现代浏览器会在每次连接时打乱 TLS 扩展的顺序（这一特性称为 GREASE/扩展随机化），导致原始 JA3 哈希值在每次请求之间都会变化。JA3N 会在哈希之前将扩展按规范顺序排序，从而生成不会随每次握手而改变的稳定指纹。正是这种稳定性，让指纹识别系统更青睐规范化哈希。

如果您的原始 JA3 在多次检测之间发生变化，通常是扩展随机化所致。基于 Chromium 的浏览器会故意重新排列 TLS 扩展的顺序并注入 GREASE 值，使任何单一的静态哈希都无法锁定您。规范化形式（JA3N 和 JA4）会剔除这些干扰并保持一致，这正是反机器人厂商依赖它们而非原始 JA3 的原因。

可以，但这比更改 User-Agent 难得多。由于指纹来自 TLS 库本身，您无法通过 JavaScript 或浏览器设置来更改它，而是需要一个能逐字节模仿真实浏览器握手的客户端，例如 TLS 伪装库（curl-impersonate、utls），或基于真正 Chromium 内核构建的指纹浏览器。简单地修改请求头无济于事：握手发生在发送任何请求头之前。

这意味着您的两个层面给出了相互矛盾的信息。您的 User-Agent 请求头可能声称是“Windows 上的 Chrome 124”，但如果您的 TLS 握手与 Python 的 requests 库或 Go 的 http 客户端相符，服务器就会看到一种真实浏览器绝不会产生的矛盾。反机器人系统将这种不匹配视为最强的自动化信号之一，远比单独的 User-Agent 可靠，因为任何人都能用一行代码改写 User-Agent。

通常不会。VPN 或标准的 HTTP/SOCKS 代理只会转发您的流量，不会改动浏览器生成的 TLS 握手，因此您的 JA3/JA4 保持不变，改变的只有您的 IP。例外情况是终止 TLS 并自行重新建立连接的代理：它会换上代理自己的指纹，这可能是好事（干净的、类似浏览器的握手），也可能是坏事（明显的代理特征），具体取决于服务商。

您的指纹来自您的客户端，因此真正的解决办法是：将一致且与真实浏览器相符的 TLS 协议栈，与一个能印证这一身份的 IP 搭配使用。ProxyWing 的住宅代理和移动代理为您提供干净、可信的 IP，与真实的消费者网络连接相符，因此真实的浏览器握手加上住宅 IP，看起来就是普通用户，而不是数据中心的自动化程序。再配合能生成真实 ClientHello 的指纹浏览器，您的 TLS、IP 和 User-Agent 就能讲述同一个前后一致的故事。