你的网站正在被“看不见的人”偷数据
故障定位思路
CDN JA3看似简单，真正落地时却很容易踩坑。想象一下：有人开着脚本，用一台没有屏幕的浏览器（无头浏览器）24小时不停地访问你的网站，抓取文章、商品价格、用户信息，甚至模拟登录撞库。你查日志，发现IP五花八门，User-Agent看起来和Chrome一模一样，服务器CPU却一直在报警。你设置频率限制（CC防护），对方换IP；你屏蔽某些UA，对方改UA。传统手段就像打地鼠，永远慢半拍。
真相是：爬虫和正常用户的区别，不只在行为上，还在底层的通讯细节里。而这个细节，就是TLS握手时的指纹——JA3和JA4。
进阶阅读：此处可内链到“CDN JA3性能优化”指南。
JA3/JA4指纹：浏览器在握手时就暴露了身份
从TLS握手说起
当你用浏览器访问一个HTTPS网站，浏览器和服务器会先握个手（TLS握手），商量用什么加密套件、支持什么协议版本、要不要会话复用。每个浏览器（Chrome、Firefox、Safari）甚至每个版本，在握手时发出的“Hello”包都带有独特的参数组合——支持的密码套件列表、椭圆曲线、扩展字段等。
2015年，安全研究员John Althouse提出了JA3指纹：将握手包中几个关键字段（SSLVersion、Ciphers、Extensions、EllipticCurves、EllipticCurvePointFormats）拼接起来，再取MD5哈希，得到一个32位的字符串。这个字符串就像浏览器的“基因片段”——同一个浏览器同一版本，JA3指纹基本一致；不同浏览器或不同实现（比如Selenium驱动的无头Chrome），指纹往往不同。
2023年，JA3升级到了JA4。JA4不再用MD5，而是把TLS握手的前几个字节（如协议版本、密码套件数、扩展数、ALPN等）转成可读的字符串格式，比JA3更精细、更易调试，而且能区分同款浏览器的细微差异（比如是否启用了某些实验性功能）。
无头浏览器的指纹“马脚”在哪里？
普通的无头浏览器（Headless Chrome、Puppeteer、Playwright）为了伪装，往往会设置一个固定的User-Agent，甚至模拟鼠标轨迹。但是它们的TLS指纹却常常“穿帮”。因为很多爬虫框架底层调用了操作系统的TLS库（比如Python的requests库，或者Node.js的http模块），而非完整的Chromium内核。即使是Puppeteer控制的Headless Chrome，其TLS指纹也可能和桌面版Chrome有细微差别（例如缺少某些扩展标记）。
此外，爬虫经常使用较老的加密套件（比如TLS 1.0/1.1）或者关闭了SNI扩展，这些都会导致JA3/JA4指纹异常。总结就是：每个正常浏览器都有一个相对固定的指纹，而绝大多数爬虫的指纹要么来自非浏览器库，要么与正常指纹“长得不像”。
CDN边缘节点：部署指纹拦截的最佳位置
为什么不在源站做？
当然可以在源站服务器上提取TLS握手信息并计算指纹，但这样做会消耗CPU资源，而且复杂。更关键的是：源站只能看到经过CDN代理后的连接。如果CDN开启了HTTPS回源，源站收到的请求来自CDN节点，而不是客户端，根本拿不到客户端的原始TLS信息。
正确做法是在CDN边缘节点（离用户最近的反向代理）上，在客户端与CDN建立TLS连接的那一刻就提取指纹。CDN节点可以将指纹附加到请求头中发送给源站，或者直接在边缘节点上根据指纹规则拦截请求。
CDN是如何采集JA3/JA4的？
以常见的CDN平台（如Cloudflare、Akamai、以及国内的一些服务商）为例，它们会在反向代理层做如下动作：
- 当客户端发起TLS ClientHello时，CDN节点解析出SSLVersion、Ciphers、Extensions等字段；
- 根据JA3算法计算MD5值，或根据JA4算法生成可读字符串；
- 将指纹以HTTP头（如
X-JA3-Fingerprint）的形式透传给源站，或者直接与安全策略比对。
有些CDN还支持自定义规则：如果指纹匹配某个已知恶意指纹列表，可以直接返回403、499甚至重置连接，完全不会进入源站，对服务器零压力。
关联教程：此处可内链到“CDN JA3部署与验证”内容。
精细化阻断配置指南（以某CDN为例）与CDN JA3
注意：不同CDN的配置界面和语法不同，但逻辑通用。下面给出一个典型步骤，你可以在自己的CDN控制台寻找类似的“WAF自定义规则”或“边缘函数”功能。
第一步：获取正常用户指纹
你需要先收集自己网站的正常用户指纹。方法：在CDN中开启“记录JA3指纹”的日志字段（一般叫ja3_hash或ja4_signature），然后访问你的网站（用Chrome、Edge、手机浏览器等），观察日志中出现的指纹。把这些指纹记下来，作为白名单。
第二步：采集爬虫指纹
你可以自己写一个简单的爬虫脚本（比如用Python+requests），模拟无头浏览器访问你的网站，观察它产生的JA3指纹。用Selenium驱动Headless Chrome也会产生一个指纹。记录这些指纹，作为黑名单候选。
常见爬虫指纹示例（非真实值，仅示意）：
- Python requests库（非浏览器）：
51c64c77e60f3980eea90869b8cb58c4 - Puppeteer headless Chrome：
5033c230f1663026a80add8e325a9435 - 正常Chrome 120：
c3c9e4b4c2f3b1a0d5e6f7a8b9c0d1e2
第三步：配置阻断规则
在CDN的WAF或自定义规则中，添加一条规则：
条件：客户端JA3指纹等于（或属于）某个黑名单列表。
动作：拦截（返回403或429）。
高级用法：你可以设置“如果指纹不在白名单中则验证码挑战”，因为爬虫通常无法通过JS挑战。或者针对特定路径（如登录API、搜索接口）单独启用JA3检查。
第四步：验证与回滚
部署后一定要小心：有些人可能使用小众浏览器（比如旧版Safari、火狐开发者版），它们的指纹可能不在你的白名单里，导致误拦。所以第一步要观察几天，收集足够多的正常指纹。即使如此，也可能漏掉某些正常用户的指纹。建议先设置为“仅记录不拦截”模式，观察日志确认没有误杀后再改为拦截。
万一发生误拦，你可以通过CDN的“临时白名单”功能，将该用户的IP或指纹加入例外。也可以配合回滚策略：将规则优先级调低，或直接禁用该规则。
CDN JA3：JA4相比JA3的改进与注意事项
先看关键判断
JA4解决了JA3的一个痛点：JA3的MD5哈希存在哈希冲突的可能性（虽然极低），且不同CDN实现的计算方式可能不一致。JA4采用结构化字符串（如t13d1710h2_8daaf6152771_02713d6af862），每个部分都对应TLS握手中的具体参数，更易于人工分析和跨平台共享。
但JA4也有局限性：它同样依赖于TLS库的实现。例如，Google Chrome和Microsoft Edge都基于Chromium，但Edge可能启用了一些额外的实验性特性，导致JA4指纹不同。所以，你仍然需要持续更新自己的指纹库。
相关阅读：此处可内链到“CDN JA3常见问题”专题。
风险提示：指纹会被绕过吗？
故障定位思路
是的，高级爬虫可以修改底层的TLS参数（如使用curl的--tls13-ciphers选项，或者替换OpenSSL的密码套件），从而伪造任意JA3/JA4指纹。不过，这需要爬虫开发者对TLS有深入理解，大多数商业爬虫和脚本不会这样做。另外，如果爬虫伪造的指纹恰好和你网站的正常用户指纹相同，就会误杀。因此，JA3/JA4指纹只是精细化阻断的一个维度的参考，通常需要结合行为分析（频率、路径、点击流）才能达到最佳效果。
想继续深入：此处可内链到“CDN JA3优化清单”文章。
总结：给小白的三个核心认知
先看关键判断
- JA3/JA4是浏览器TLS握手的“身份证”，无头浏览器和普通浏览器在握手细节上有差异，这些差异可以被提取和利用。
- CDN边缘节点是实现指纹拦截的理想位置，因为它能获取客户端原始TLS信息，且不影响源站性能。
- 配置时要谨慎，先收集、再观察、最后拦截，务必保留回滚手段。指纹阻断是爬虫防护的有力补充，但非万能，还需配合其他策略。
如果你已经厌烦了频繁调整IP黑名单却依然被爬虫消耗资源，试试CDN的JA3/JA4指纹阻断吧。让那些“看不见的人”在握手阶段就被请出大门。后续只要定期检查关键指标，CDN JA3就不会变成维护负担。
延伸阅读