BrowserLeaks指纹检测王牌网站 · 产品迭代

先用可验证的特征清单反推迭代节奏。传统检测站大多停留在 JA3 时代，而 BrowserLeaks 的 /ip 页同时给出 TLS Fingerprint 的 JA4 与 JA3 Hash 两套值，并在 TCP/IP Fingerprint 区块额外输出 JA4T，实测值为 65535_2-1-1-4-1-3_1460_10。JA4 系列是近两年才逐步取代 JA3 的新一代握手指纹方案，能覆盖 JA3 在密码套件乱序、GREASE 扩展下失效的问题；JA4T 更是把指纹下沉到 TCP 层，用窗口大小、选项序列、最大报文段长度这些参数刻画操作系统与网络栈。一个不再维护的站点不可能主动接入这类新标准，这是判断其活跃度最可靠的证据。

第二组证据来自应用层。HTTP/2 Fingerprint 采用 Akamai Hash 这一业界通行的表达方式，把 SETTINGS 帧参数、窗口更新值、优先级信息与请求头顺序压成一个哈希。HTTP Headers 区块逐条展示的内容更能说明问题：Sec-CH-UA 的值为 “Not_A Brand”;v=“99”, “Chromium”;v=“142”，Sec-CH-UA-Mobile 为 ?0，Sec-CH-UA-Platform 为 “Windows”，Accept-Encoding 里已经带上 zstd，还有 Priority: u=0, i 这个较新的优先级请求头，以及 Sec-Fetch-Site、Sec-Fetch-Mode、Sec-Fetch-User、Sec-Fetch-Dest 这一整组元数据头。客户端提示取代 User-Agent 是 Chrome 近期推进的重点，站点把这些字段单列展示，意味着它的解析逻辑随着浏览器主线在改。

第三组证据在检测栈的横向扩张上。/tls 页的说明覆盖 SSL/TLS 协议版本、ClientHello、cipher suites、TLS extensions 与 ECH 支持，还测试混合内容处理；ECH 是为了隐藏 SNI 而设计的新机制，能识别它说明作者在跟踪 TLS 生态的前沿变化。/proxy 页专门识别 Tor Browser 与 AdBlocker 这类中间层内容过滤，/ip 页则单独有 Tor Relay Details 区块，实测给出 This IP is not identified to be a Tor Relay 的判定。这些都属于随外部生态变化而必须持续维护的检测项，不是一次性写完就能长期有效的静态功能。

从产品形态的稳定性看，BrowserLeaks 的迭代策略明显偏保守：核心的 Canvas 测试源码多年沿用同一段绘制逻辑，仍然是绘制 BrowserLeaks,com 1.0 文本、14px Arial 字体、#f60 矩形与 #069 文字、外加 rgba(102,204,0,0.7) 半透明叠加。这种保守是刻意的——一旦改动绘制逻辑，历史签名库全部作废，Uniqueness 这类基于自有数据库的统计也失去可比性。对卖家来说，这反而是好事：不同时间、不同环境测出的 Canvas 签名可以横向比较，指纹浏览器厂商也能长期用同一段代码校准自己的噪声算法。底层协议层快速跟进、上层算法层保持冻结，这种分层节奏是成熟的工程判断。

短板集中在迭代过程的不可见性。站点不提供更新日志、版本号或功能公告，卖家无法知道某个检测项是什么时候加上的、判定逻辑近期是否调整过。这在实战中会造成误判：如果某天大批环境突然在某一项上显示异常，运营者分不清是自己的指纹浏览器配置出了问题，还是检测站升级了规则。同样缺失的还有历史结果存档与结果对比功能，站点不提供任何形式的报告导出，也没有可供批量调用的接口，几百个环境的自检数据无法沉淀成时间序列，指纹漂移这种最需要纵向对比才能发现的问题就很难被及时捕捉。

另有两项与迭代相关的功能长期空缺。其一是缺乏综合风险评分，站点只输出原始数据，不告诉用户当前这套指纹组合在真实平台风控眼里是否可疑，这让新手很难把 JA4T、Akamai Hash 这类数值转换成决策。其二是缺乏一致性交叉校验，比如 HTTP Headers 声称 Sec-CH-UA-Platform 为 “Windows”，而 WebGL 报出的却是苹果显卡型号，这种自相矛盾才是平台风控最敏感的信号，站点却把各检测项彼此独立呈现，需要用户自行比对。补上这两项，产品价值会有一次台阶式提升。

把迭代路径再拆细，可以看出它采取的是跟随主线而非自创标准的策略。它没有发明自己的一套指纹命名体系，而是直接采用社区已经形成共识的表达方式：握手层用 JA3 与 JA4，TCP 层用 JA4T，HTTP/2 层用 Akamai 的哈希格式。这种做法的好处是结果可以被外部直接复用——风控团队拿到这里的哈希值，能与自己系统里的记录直接比对，不需要做格式转换。对卖家同样友好，在不同工具之间横向验证时不会因为口径差异产生歧义。代价是它必须持续追踪这些外部标准的演进，一旦社区推出新版本，站点就要跟着改，维护负担是长期的。

另一条不太显眼的迭代线索藏在数据积累里。/canvas 页给出的 Uniqueness 百分比以及 Signature Stats 反推浏览器与操作系统的能力，都建立在一个持续增长的签名数据库之上。这个库每天都在接收新样本，即便前端代码一行不改，判定结果也会随着样本量变化而演进：一个今天显示唯一的签名，随着更多相同配置的用户被记录，明天可能就不再唯一。这种数据侧的隐形迭代对卖家有实际含义——不能把某一次测出的唯一性数值当作永久结论，同一个环境隔一段时间复测，得到的判定可能不同，判读时要看趋势而不是单点。

基于以上特征，给运营团队的建议是把自检清单版本化管理。具体做法是在内部文档里明确记录当前采用的检查项与判定标准，例如出口地址与店铺资料所在时区必须一致、画布签名在同一环境的多次刷新之间必须保持稳定、握手层的哈希值需要与同版本真实浏览器一致、字体列表数量要落在常见办公电脑的区间内；然后每个季度打开站点通读一遍各子页，确认是否出现了新的检测模块。一旦发现新增指纹类型，立即评估现有指纹浏览器是否覆盖，并把新项补进交付验收清单。站点自己不发公告，这份主动巡检的责任只能由使用方承担。