BrowserLeaks指纹检测王牌网站 · 技术架构

最值得称道的是它的分层完整性。绝大多数检测站只做浏览器层，能测 Canvas 与 WebGL 就算合格，而 BrowserLeaks 把检测点铺满了整条协议栈。最底层是 TCP/IP Fingerprint，通过被动分析握手包的窗口大小、选项排列、最大报文段长度等参数，推断出操作系统为 Windows、MTU 为 1500、链路类型为 Ethernet or modem、与服务器相距 21 Hops，并压缩成 JA4T 值 65535_2-1-1-4-1-3_1460_10。这一层的关键意义在于：它完全脱离浏览器控制，指纹浏览器再怎么改 JavaScript 环境也影响不了 TCP 握手，只有代理软件的实现方式和中间链路才决定这里的输出。卖家如果发现浏览器层声称是 macOS 而这里判定为 Windows，那就是致命矛盾。

往上一层是 TLS。/tls 页覆盖协议版本、ClientHello 结构、cipher suites 列表、TLS extensions 以及 ECH 支持情况，同时测试混合内容处理；/ip 页的 TLS Fingerprint 模块直接输出 JA4 与 JA3 Hash 两套值。JA3 通过对握手参数排序拼接后取哈希来识别客户端，JA4 则改进了排序与 GREASE 处理，抗干扰能力更强。对做多账号的人来说，这一层是分水岭：真实 Chrome 的 JA3 值是有限几种，而很多自动化工具、二次开发的内核、老旧代理客户端会产生在真实用户中几乎不存在的握手特征，平台只要维护一张常见 JA3 白名单，就能低成本识别出非常规客户端，这比查 Cookie 或 IP 有效得多。

第三层是 HTTP。站点用 Akamai Hash 表达 HTTP/2 指纹，把 SETTINGS 帧参数、窗口更新值、优先级设置与伪头顺序编码成一串可比对的字符串。HTTP Headers 模块则把每一个请求头摊开：Sec-CH-UA 为 “Not_A Brand”;v=“99”, “Chromium”;v=“142”，Sec-CH-UA-Mobile 为 ?0，Sec-CH-UA-Platform 为 “Windows”，User-Agent 为 Mozilla/5.0 (Windows NT 10.0; Win64; x64) 加 Chrome/142.0.0.0 Safari/537.36，Accept-Language 为 en-US,en;q=0.9，Accept-Encoding 为 gzip, deflate, br, zstd，Priority 为 u=0, i，还有完整的 Sec-Fetch-Site、Mode、User、Dest。头字段的顺序、大小写和取值组合本身就是指纹，很多改机工具只改了 User-Agent 字符串，却把 Sec-CH-UA 里的 Chromium 版本号留在原处，两者版本对不上就是明显破绽。

第四层是浏览器与图形层。Canvas 检测的实现深度尤其突出：它不只输出 Signature 062284bbd0ab00fb76e4bf6e18fef42a 与 Uniqueness 100%，还把生成的图像解剖开来，给出 File Size 6840 bytes、Number of Colors 1023，并逐块列出 PNG 的 IHDR、IDAT、IEND 区块的 Length 与 CRC 校验值，图像规格标注为 220×30、8 bits/sample、truecolor+alpha、noninterlaced，同时说明指纹可由 toDataURL 输出的 base64 取 MD5 得到，也可直接取文件末尾倒数第 16 到第 12 字节处 IDAT 区块的 CRC。能做到字节级解析，说明后端不是简单调用现成库，而是自己实现了 PNG 结构解析。WebGL 侧则暴露显卡型号与图形能力，Font 侧通过枚举字体、测量文本与 Unicode 字形尺寸、比对渲染差异来构造指纹。

第五是数据侧的支撑能力。IP 归属判定不是简单查一张免费库：实测对 202.181.17.57 这样一条冷门线路，站点仍能给出 Bangladesh、Dhaka Division、Dhaka 市 Motijheel、ISP 为 Level3 Carrier Limited、Organization 为 Level3 Network AS58682 LEVEL3 CARRIER LIMITED (CARRIER)、Usage Type 为 Corporate / Business、时区 Asia/Dhaka (BST)、坐标 23.7322 与 90.4108 这样一整套字段，Whois 模块还能返回 Source Registry 为 APNIC、Net Range 为 202.181.17.0 至 202.181.17.255、CIDR 为 /24、Net Type 为 ALLOCATED NON-PORTABLE 以及注册时间与滥用举报联系人。此外还实时判定 Tor Relay 状态，本次返回 This IP is not identified to be a Tor Relay。这背后是注册局数据、路由数据与线路类型库的多源整合。

架构上的代价也很清楚：整套检测重度依赖客户端脚本。禁用 JavaScript 时，地图返回 Failed to load the map – JavaScript Disabled，WebRTC 与 DNS 检测项显示 n/a (no js)，意味着浏览器层与泄漏层的能力会整体失效，只剩服务端可见的网络层与头字段。另外站点不提供可编程接口，无法把检测嵌入自动化流水线，管理数百个环境的团队只能靠人工逐个打开页面；Uniqueness 的判定依赖站点自有签名库，而库的规模与更新周期从未对外披露，同一个签名在不同时间可能得到不同的唯一性结论，这个数值只适合当相对参考而不宜作为绝对指标。

把实现链路拆开看，会发现它同时维护着两条性质完全不同的采集通道。第一条是服务端被动采集：TCP 握手参数、TLS 的 ClientHello 与扩展列表、HTTP/2 的帧设置与伪头顺序，这些数据只能在连接建立的瞬间从底层抓取，需要在协议栈层面做定制，普通的应用框架根本拿不到。第二条是客户端主动采集：画布绘制结果、显卡型号、字体枚举、各类 Web 接口返回值，必须由脚本在浏览器里执行后上报。两条通道的数据要拼接成同一次检测的完整画像，还得保证拼接过程本身不引入额外的会话标识，这个工程复杂度远超一般的信息展示型站点。

外部依赖的组织同样体现工程能力。WebRTC 泄漏检测需要可用的会话穿透服务器，才能在存在网络地址转换的情况下把内网与公网地址逼出来；DNS 泄漏检测需要一套能统计解析来源的域名基础设施，否则无法知道请求最终由哪些服务器发出；归属判定要整合路由数据与线路类型库，才能给出城市级定位与线路用途标注；Whois 要实时对接各地区注册局，本次实测返回的注册局为 APNIC 并附带完整的滥用举报联系人信息；中继节点判定还需要维护一份持续更新的节点名单。这些子系统任何一个失效，对应模块就会静默降级，而站点并不区分展示。

最后要提精度边界，这直接关系到卖家怎么读数。被动式的网络层指纹在多层转发场景下会失真：实测给出的 21 Hops 表示的是从检测服务器视角看到的跳数，经过代理隧道后这个数字反映的是出口节点到服务器的距离，而不是卖家真实机器的位置；MTU 显示 1500 属于以太网默认值，但某些隧道协议会改写这个数值，出现非典型的 MTU 反而是使用隧道的信号；链路类型判定为以太网或调制解调器是一个粗粒度分类，参考价值有限。同理，画布唯一性百分比依赖站点自有样本库，样本量随时间增长，同一签名的判定会漂移。理解这些边界之后再看数据，才能避免把工具的推断当成事实，也才能明白为什么需要多个来源交叉验证。