使用 Playwright 进行网页抓取的开发者发现，即使脚本启动了完整的 Chromium 实例、设置了真实的 User-Agent 并加入了类人的延迟，其首次请求仍会被拒绝。服务器在 TLS 握手阶段拦截了请求，这种技术被称为 TLS 指纹识别 (TLS fingerprinting)。
TLS 指纹识别详解
当浏览器建立 HTTPS 连接时，会发送一个 ClientHello 消息。该数据包列出了 TLS 版本、支持的密码套件、一组扩展（椭圆曲线、签名算法）以及其他几个字段。这种精确的组合能够唯一标识该网络栈。
研究人员将这些原始字段哈希处理成一个紧凑的标识符，称为 JA3（或其更新的变体 JA4）。真实的 Chrome 浏览器会生成一个哈希值，而 Python HTTP 库则会生成另一个。如果服务器生成的哈希值与声明的 User-Agent 不匹配，它就会将该请求标记为脚本行为。
为什么原生的 Playwright 浏览器仍会被标记
Playwright 默认的 Chromium 构建版本通常会发出正确的 Chrome 指纹，但许多抓取程序添加的操作破坏了这种一致性：
- 混合请求策略 —— 开发者通常让 Playwright 渲染复杂的页面，同时使用轻量级的 HTTP 客户端获取辅助资源（JSON、图像等）。这些快速调用携带的是库的指纹，而非 Chrome 的指纹，服务器会立即发现这种不匹配。
- 终止 TLS 的代理 —— 一些代理服务会解密 TLS 流，检查或修改流量，然后重新加密。服务器最终看到的是代理的指纹，并可能将其作为非浏览器客户端进行拦截。
- 其他协议层 —— 反爬虫系统还会比较 HTTP/2 设置、标头顺序和 IP 声誉。任何层面的差异都可能触发拦截。
从 JA3 到 JA4：军备竞赛
JA3 是第一个被广泛采用的 TLS 指纹。Chrome 现在在每次启动时都会随机化其扩展程序的顺序，这使得真实浏览器的 JA3 哈希值变得不稳定。JA4 通过在哈希处理前对扩展列表进行排序解决了这个问题，即使 Chrome 打乱了顺序，也能产生稳定的标识符。采用 JA4 的检测工具可以可靠地将真实的 Chrome 实例与仅仅复制静态 JA3 哈希值的脚本客户端区分开来。
开发者目前可以采取的措施
没有能够永远欺骗服务器的“魔法字符串”。可靠的方法是让请求的每一层都讲述同一个故事：
- 使 User-Agent、TLS 握手、HTTP/2 设置和标头顺序与相同的浏览器版本和操作系统保持一致。
- 停止将完整的浏览器自动化工具与独立的 HTTP 客户端混合使用。如果速度很重要，请让 Playwright 处理所有的网络调用，即使是微不足道的调用。
- 选择能够透传 TLS 而不终止连接的代理，或者配置它们以原封不动地转发原始 TLS 握手。
- 监控 IP 声誉服务；干净的 IP 池可以降低因历史滥用而被拦截的概率。
忽视指纹一致性的代价
当抓取程序在握手阶段被拦截时，它永远无法到达页面逻辑层，因此既无法采集数据，也不会浪费时间执行 JavaScript。依赖大规模数据采集的企业会发现，随着重试循环的启动，云计算成本也会随之上升。反复的拦截还可能导致 IP 被封禁，从而影响来自同一网络的其他合法流量。
反方观点：网站为何采用 TLS 指纹识别
网站所有者将 TLS 指纹识别视为一种正当的防御手段。自动化抓取可能会使服务器过载、绕过付费墙或大规模采集个人数据。通过检查 TLS 指纹是否与声明的浏览器匹配，网站可以在不伤害真实用户的情况下，过滤掉一大类低成本的机器人。这种技术比 CAPTCHA（验证码）侵入性更低，能够保留用户体验。
后续关注点
- JA4 的采用 —— 预计在未来几个月内，会有更多的安全厂商和 CDN 提供商推出基于 JA4 的检测功能。
- 浏览器层面的随机化 —— Chrome 和其他浏览器可能会不断改变 TLS 参数，这将迫使指纹识别工具转向更复杂的信号，例如流量时序或 JavaScript 执行模式。
- 代理市场的响应 —— 可能会出现承诺“TLS 透明”路由的服务，以满足抓取社区对保持握手不变的需求。
总结
如果你的 Playwright 爬虫在页面加载之前就被拦截，罪魁祸首几乎可以肯定是 TLS 指纹不匹配。这并非一个可以通过简单补丁解决的问题；它需要确保每一个协议层都与声明的浏览器特征保持严谨的一致。只有在 User-Agent、TLS 握手、HTTP/2 设置、请求头顺序以及代理行为上保持高度一致，才是避开现代反爬虫防御检测的唯一可靠方法。