如何检查浏览器指纹：分步进行配置文件审计并查找关键不匹配项

浏览器指纹（browser fingerprint）并不只是一个 User-Agent 字符串，也不只是一个 IP 地址。它是网络、HTTP 和 JavaScript 信号的组合：IP / GEO / ASN、DNS、WebRTC、timezone、language / locale、screen resolution、Canvas fingerprint、WebGL fingerprint、AudioContext、fonts、Client Hints，以及像 navigator.webdriver 这样的 automation indicators。网站不会单独看这些数据：它会将它们彼此对照，并评估这个配置文件看起来是否完整且可信。

因此，检查浏览器指纹并不是“运行一个检查器然后看到一个绿色勾号”这么简单。正常的审计是一个简短的 workflow：先看网络，再看 browser environment，然后看 consistency，最后才是修复。BrowserLeaks 强在深度模块化诊断，Pixelscan 强在快速输出 consistency 的 all-in-one 报告，AmIUnique 适合看 uniqueness/history，而 Cover Your Tracks 会展示 privacy 和 tracking 层，并解释为什么单次测试几乎总是不够的。

下面是一个实用的检查顺序，适合在首次启动配置文件之前，以及在账号预热之前执行。此类审计的主要目标并不是“100% 匿名”，而是消除那些服务和网站最先注意到的粗糙不匹配（mismatch / consistency issue）。EFF 也单独强调，不存在完美防护，而某些“隐私增强”本身反而会让浏览器更加显眼。

5 个要点的简短回答

1. 先检查网络： IP、GEO、ASN、DNS 和 WebRTC。如果这里已经有 leak 或 mismatch，那么 Canvas/WebGL 的检查暂时就是次要的。
2. 然后检查 consistency： User-Agent、Client Hints、操作系统、timezone、language / locale 和 screen。如今单靠 User-Agent 已经不够，因为浏览器会精简 UA，并通过 Client Hints 提供一部分细节。
3. 再看 high-entropy signals： Canvas、WebGL、fonts 和 AudioContext。不仅要看“唯一性”，还要看这个配置文件是否显得损坏或被过度伪装。
4. Automation/headless red flags 要单独检查： navigator.webdriver、CDP、Headless indicators 以及“伪装过的” Navigator，往往比罕见的 Canvas hash 更重要。
5. 每次修改后都重新跑审计： 一个服务里的绿色结果，并不等于另一个服务中的“理想配置文件”。

什么是浏览器指纹，为什么单次测试不够

如果你需要理论基础，可以另外看看这篇材料：什么是数字指纹。下面这里讲的是 operational 方式：如何读取信号，以及先修什么。

浏览器指纹 vs cookie vs IP

Cookie 是网站保存在浏览器中的数据。它们可以被删除、限制或阻止。Fingerprint 则是网站通过 headers、JavaScript 和 Web APIs 收集的一组浏览器和设备特征。EFF 明确将 cookie tracking 和 browser fingerprinting 区分为两种不同机制：cookie 会在用户删除后“失效”，而 fingerprint 则依赖更稳定的特征，例如设置、语言、字体、屏幕和硬件。

IP 也不能和 fingerprint 混为一谈。IP 是网络地址，而不是配置文件完整的数字身份。而且，基于 IP 的地理定位本身也是近似值：MaxMind 建议关注 accuracy radius，而不要把 city-level GEO 当作地图上的精确点。除此之外，浏览器还存在独立的 Geolocation API：它通过 navigator.geolocation 工作，需要用户 permission，并且可以使用更精确的设备信号，包括 GPS 或 Wi-Fi。

为什么不仅是唯一性，consistency 也很重要

在实际审计中，重要的不只是这个配置文件有多独特，还包括它有多一致。Pixelscan 明确将自己的检查描述为对 consistency 和 detectability 的分析：它会看 User-Agent integrity、OS consistency、hardware parameters、timezone/language alignment 以及 automation indicators。一个配置文件可能并不稀有，但仍然会因为内部自相矛盾而失败。

User-Agent reduction 让情况变得更复杂。MDN 写道，支持该机制的浏览器会从 UA 中移除精确的平台/OS 版本、设备型号和次级浏览器版本，而更详细的数据则通过 Sec-CH-UA-* Client Hints 提供。因此，如今需要检查的不是单一的 User-Agent，而是 User-Agent + Client Hints + JavaScript signals 的组合。

网站会把哪些信号互相对照

在实践中，网站会将常规 HTTP headers（User-Agent、Accept-Language）、JavaScript signals（navigator.language、navigator.languages、通过 Intl.DateTimeFormat().resolvedOptions() 获取的 timezone）、screen resolution、Canvas/WebGL rendering、AudioContext、fonts、WebRTC IP、地理定位 permission/data，以及像 navigator.webdriver 这样的 automation indicators 结合起来分析。AmIUnique、BrowserLeaks、Cover Your Tracks 和 BrowserScan 对这些层的检查深度不同，但它们涉及的实体集合在很大程度上是重叠的。

5 分钟快速审计：按什么顺序检查配置文件

下面是一个基础顺序，用最少时间获得最大收益。核心思路是：如果你在第一步就已经有 DNS 泄漏，就不要浪费 20 分钟去折腾 Canvas。

第 1 步：检查 IP、GEO、ASN、DNS 和 WebRTC

从 IP 层开始。在 BrowserLeaks 的 IP 页面中，你会立即看到 IP、country/state/city、ISP、organization、ASN/network、usage type、timezone，以及下面的 WebRTC、DNS、TCP/IP、TLS 和 HTTP/2 模块。这是一种快速理解“网络本身在讲述怎样的故事”的方法，而不是看浏览器 UI 告诉你什么。

接下来查看 DNS 和 WebRTC。BrowserLeaks 解释说，当网络配置错误或 VPN/proxy 有问题时，DNS 请求可能会直接发往运营商的 DNS 服务器，从而产生 DNS leak。而它的 WebRTC test 则会显示，STUN 请求是否暴露了你的 local/public IP。Whoer 也将这点放在检查重点中：该服务会比对 IP country 与 DNS、time zone/locale 以及 tunneling signs。这个阶段很适合使用 BrowserLeaks checker、Whoer checker 以及关于 WebRTC leaks 的单独解析。

不要把 IP GEO 和 browser geolocation 混为一谈。IP location 来自 GeoIP 数据库，因此始终是近似值，而 Geolocation API 是另一个独立机制，它会请求 permission，并且可以使用更精确的设备信号。因此，IP 显示了一个“奇怪的城市”并不一定是致命问题，但如果国家、ASN、时区和 DNS 路由彼此不一致，那就已经需要修复了。

第 2 步：检查 User-Agent、操作系统、timezone、language、screen

下一层是 browser environment check：User-Agent、OS/platform、timezone、language / locale 以及 screen resolution。这里要记住 UA reduction：MDN 单独展示了，现代 UA strings 可能会以更概括的形式出现，而一部分细节会迁移到 Sec-CH-UA-* hints 中。BrowserLeaks 的 Client Hints test 正好可以帮助查看哪些数据通过 HTTP 和 JavaScript API 返回。

要彼此核对：User-Agent、navigator.platform、Client Hints、Intl.DateTimeFormat().resolvedOptions().timeZone、navigator.language / navigator.languages 以及 Accept-Language。MDN 指出，navigator.languages 和 Accept-Language 通常反映的是同一组 locales，而 resolvedOptions() 返回的是用户当前的 time zone。如果 UA 显示“Windows”，但 platform 和 high-entropy hints 却倾向于 macOS，或者语言与 timezone 明显与 IP 所在地区不匹配，那这已经是实际不一致，而不是“表面问题”。

还要单独关注浏览器内核的新鲜度。Multilogin 明确指出，outdated browser core 会让配置文件更显眼，而 browser version 与 emulated OS 不匹配也可能触发 warnings。因此，在任何 engine update 或手动修改 UA 之后，这一步最好重新执行。

第 3 步：检查 Canvas、WebGL、fonts、AudioContext

现在再进入 high-entropy signals：Canvas fingerprint、WebGL fingerprint、fonts 和 AudioContext。BrowserLeaks 展示了 Canvas 如何由渲染差异形成，以及 WebGL 如何暴露 GPU/renderer 数据。AmIUnique 会收集 Canvas、WebGL、audio info、fonts、screen 以及其他特征，用于评估浏览器的可识别性。

但这里重要的不只是“罕见度”。EFF 警告说，如果孤立地修改指纹中的某一个元素，浏览器反而可能变得更显眼，因为这些指标彼此紧密相关。Multilogin 也给出类似建议：只有在真正理解后果时，才应该深度修改 fingerprint settings。关于这一层，更有帮助的背景材料是关于 Canvas fingerprinting 的单独文章。

第 4 步：查看 automation/headless red flags

如果配置文件会配合 automation 使用，或者看起来像自动化环境，那么要单独运行 bot-detection 层。MDN 将 navigator.webdriver 描述为 document 受 WebDriver 控制的标准标志；在 Chrome 中，如果使用 --enable-automation 或 --headless，它会变成 true。BrowserScan 还会额外检查 WebDriver、CDP、Headless Chrome 和 deceptive Navigator，而 Pixelscan 也会将 automation indicators 单独列为一个模块。

实际意味着很简单：先修 network problems，再修 automation flags，然后才是那些“看起来漂亮”的 uniqueness 指标。在大多数真实检查中，网站更容易因为 webdriver、DNS leak 或 UA/OS mismatch 而绊倒，而不是因为你的 Canvas hash “和别人不一样”。这就是从服务对问题的排序和标注方式中得出的实践结论。

第 5 步：修改后重新测试

每次修改后，都要按同样顺序重新跑审计：network → fingerprint → consistency → fixes。这不是形式主义。MDN 提到，Client Hints 可以通过 Accept-CH 请求，然后在当前 browsing session 内为特定 origin 保留。再加上 Cover Your Tracks 和 AmIUnique 会使用 research cookies，将重复访问关联起来，以研究 fingerprint 随时间的变化。因此，重复测试最好在重启配置文件之后进行，并且在需要时放在 clean environment 中完成。

用哪些服务来检查浏览器指纹

一个服务不等于完整检查。正常的审计通常至少要结合两类工具：一个 network-oriented，一个 consistency-oriented。BrowserLeaks 提供底层模块，Pixelscan 提供统一的 consistency 报告，AmIUnique 负责 uniqueness/history，Cover Your Tracks 提供 tracker/privacy 视角，而 iphey、Whoer 和 BrowserScan 则非常适合作为额外的快速检查层。

表 1. 服务对比

BrowserLeaks —— 用于深度模块化诊断

当你需要弄清楚配置文件到底在哪一层出问题时：network、JavaScript、rendering 还是 transport，BrowserLeaks 是最佳首选。它会显示 IP/GEO/ASN/usage type、DNS、WebRTC、Canvas、WebGL、fonts、Client Hints，甚至还有 TLS/HTTP2/TCP/IP fingerprints。如果你想在 Undetectable 生态中使用类似场景，可以从 BrowserLeaks checker 开始。

Pixelscan —— 用于快速 all-in-one 审计

Pixelscan 适合作为快速 first pass，或者在 BrowserLeaks 之后作为第二视角。该服务在自己的 manifest 中写明，它会分析 user-agent integrity、operating system consistency、Canvas/WebGL and rendering signals、hardware parameters、timezone/language alignment、proxy/DNS behavior 以及 automation indicators；像“Windows UA，但同时出现 macOS signals”这样的 mismatch，它会立刻标出来。对于这一场景，请使用 Pixelscan checker。

AmIUnique —— 用于评估 fingerprint 的唯一性和历史变化

当问题变成“我有多容易被识别？”而不是“为什么我的 DNS 在泄漏？”时，AmIUnique 就很有用。这个项目研究 browser fingerprints 的多样性，会收集大量 headers 和 JS signals，并通过 research cookie 将重复访问关联起来，以展示 fingerprint 随时间变化的历史。为了快速开始，你可以直接使用 AmIUnique checker。

Cover Your Tracks（前身 Panopticlick）—— 用于 privacy/fingerprint 教育

Cover Your Tracks 是历史服务 Panopticlick 的现名：EFF 在 2020 年将其改名，并把重点从简单展示“fingerprinting 确实存在”转向更易理解的 tracking/privacy trade-offs 解释。该服务会展示 trackers 如何看待你的浏览器，而在 detailed view 中还会 раскрывает 像 System Fonts、Language 和 AudioContext 这样的指标。在 Undetectable 内部运行时，请使用 Panopticlick / Cover Your Tracks checker。

补充工具：iphey、Whoer、BrowserScan

在额外工具中，建议随手备好 iphey checker，当你需要根据 browser、location、IP、hardware 和 software 快速得到 “trustworthy / suspicious / unreliable” 的 heuristic score 时很有用；以及 Whoer checker，如果你需要 instant IP/DNS/privacy-check，并想同时对照 time zone 和 locale。BrowserScan 则适合作为单独的 bot-detection 层：它会分析 WebDriver、CDP、Headless Chrome 和 deceptive Navigator properties。

如何解读结果：哪些 red flags 真正关键

下面是一个实用的问题层级。这是从 BrowserLeaks、Pixelscan、AmIUnique、Cover Your Tracks、Whoer 以及 Multilogin 的建议中总结出的编辑工作框架：先修复会破坏 consistency 和 network trust 的问题，而不是那些只是提高 uniqueness score 的问题。

表 2. 问题诊断

IP/GEO mismatch

IP mismatch 不只是“城市不对”。在 BrowserLeaks 的 IP 页面上，更重要的是 country、ISP、ASN/network 和 usage type；Whoer 还会进一步将 IP country 与 DNS、time zone/locale 以及 tunneling signs 进行比较。在实际中，精确到城市的 GEO 往往没有 国家 + ASN + timezone + 网络类型 这组组合更重要。

第一优先的 fix 几乎总是在网络侧：更换 proxy 或 proxy type，而不是在浏览器里掩盖后果。如果任务对 IP 类型和 ASN reputation 很敏感，可以另外参考这篇关于 mobile vs residential proxies 的材料。而且不要从手动伪造 geolocation 开始：Multilogin 明确警告，custom geolocation 可能会制造 geolocation/IP mismatch。

DNS/WebRTC leaks

DNS/WebRTC leaks 是非常关键的 red flag，因为即使外部 IP 看起来“正常”，它们依然可能泄露真实路由。BrowserLeaks 写道，在错误配置下，DNS 请求可能会直接发送到 ISP DNS，而它的 WebRTC test 会显示通过 STUN 暴露的 local/public IP。Whoer 同样把 DNS、WebRTC 和 IP leaks 视为基础隐私/伪装问题。

这里的修复顺序始终只有一个：DNS path → WebRTC mode → 重新测试。如果 WebRTC 或 DNS 仍然不过关，就不要进入实际工作会话，更不要去做预热。先把 connection layer 处理到位；详细说明可以看这篇关于如何防护 WebRTC leaks 的解析。

User-Agent 与操作系统不匹配

UA/OS mismatch 是最常见的 operational 问题之一。Pixelscan 直接举例说明，Windows user-agent 会与 macOS signals 发生冲突。Multilogin 也单独写到，过时的内核会让配置文件更显眼，而 browser version 与 emulated OS 之间的 mismatch 会引发 warnings。考虑到 UA reduction，现在必须检查的不只是 UA 字符串本身，还包括 Client Hints。

Timezone/language mismatch

Timezone 和 language 本身是较小的信号，但一旦与其他部分矛盾，就会变得非常明显。MDN 指出，resolvedOptions() 返回当前的 time zone，而 navigator.languages 和 Accept-Language 通常反映的是同一组 locales。Multilogin 也提到，网站经常会对比 IP-derived timezone 与 JavaScript-derived regional settings。

第一个 fix 取决于“哪个来源更可信”。如果 proxy 选对了，而浏览器的 locale/timezone 不对，那就去对齐浏览器。反之，如果 locale 是你有意且稳定设置的，而 IP 区域却异常，那就换 proxy。为了达到 best results，languages 通常应该匹配 proxy/task locale，而不是随便挂着一个随机语言组合。

Canvas/WebGL anomalies

Canvas/WebGL anomalies 不能忽略，但它们很少是最先导致问题的原因。BrowserLeaks 展示了 Canvas 和 WebGL fingerprints 如何基于渲染差异构建，而 MDN 指出，WEBGL_debug_renderer_info 可能会暴露图形栈的 vendor/renderer。与此同时，EFF 警告说，孤立地更改一个 fingerprint signal 反而可能让浏览器更显眼。

因此，比起“一个稀有 hash”，真正更危险的是完全关闭的、损坏的或者被噪声污染过头的 rendering。Multilogin 直接写道，很多主流网站对 totally unique or altered graphics fingerprints 反应很差，而真实的 Canvas/AudioContext outputs 往往只是融入大量相似设备之中。

过于“随机”的配置文件和 automation flags

Automation indicators 的解释更直接：如果存在 navigator.webdriver，或者 BrowserScan/Pixelscan 捕捉到了 CDP/headless/deceptive Navigator traces，那就是一个真实的 red flag，而不是表面问题。MDN 直接把 navigator.webdriver 与 automation/headless launch flags 关联起来。

而 TCP/IP fingerprint 在第一轮检查中则不值得被高估。Multilogin 提到，proxy 会重新打包 network data，因此 passive OS fingerprint 可能不会与真实 OS 匹配，大多数网站也会忽略这一点，因为这类差异很常见。把它当作 second-pass nuance 来检查，而不要作为第一理由去重建配置文件。

为什么不同服务会显示不同结果

检查深度不同

第一个解释是深度不同。BrowserLeaks 是一组独立模块，Pixelscan 试图把多个层打包成一个 actionable report，AmIUnique 专注于 identifiability 和 history，Cover Your Tracks 专注于 tracker/privacy 视角，而 BrowserScan 则给 bot-detection signals 更高权重。如果工具问的问题不同，答案自然也不同。

方法和启发式不同

第二个原因是方法不同。MDN 将 Client Hints 分为 low-entropy 和 high-entropy；其中一部分 hints 需要通过 Accept-CH 明确 opt-in。AmIUnique 会将 fingerprint 与研究数据集比较，Cover Your Tracks 评估对 tracking/fingerprinting 的防护，而 Pixelscan 则强调内部 consistency。因此，两个服务可能会看同一个配置文件，但分析的风险切面并不一样。

为什么一个服务中“绿色”不等于“理想配置文件”

在一个 checker 中的绿色结果，并不意味着配置文件在所有地方都理想。一个配置文件可能在 uniqueness-oriented 服务中表现正常，但同时存在 DNS/WebRTC 泄漏；也可能获得不错的 privacy feedback，但在 automation-技术栈下表现很差；或者在 all-in-one scan 中看起来干净，却仍有低优先级的传输层 oddity。因此，最基础的工作流至少应该包含：一个 network-oriented checker + 一个 consistency-oriented checker。

如果配置文件没有通过审计，应该先修什么

如果配置文件没有通过 audit，不要试图一次修好所有东西。最快的方法是自上而下：connection layer → consistency layer → high-entropy layer → rebuild。这个顺序既符合 structured checkers 展示问题的方式，也符合关于 mismatch 的实践建议。

代理和 sticky sessions

先从 proxy quality 和 session stability 开始。如果 proxy IP 在工作会话中途发生变化，timezone/geolocation/WebRTC alignment 可能就会“漂移”，你最终追着症状跑，而不是解决原因。Multilogin 描述过一种场景：系统必须在 mid-session proxy IP change 之后重新调整 WebRTC 和 geolocation；BrowserLeaks 和 Whoer 也同样展示了，IP/DNS leak 行为是基础问题，而不是细节。因此，在 first run 和账号预热开始阶段，最好让每个 session 保持一个稳定的网络故事，并在每次更换 proxy 后重新测试配置文件。如果问题恰恰卡在网络类型和 ASN 上，可以参考这篇关于 mobile vs residential proxies 的材料。

配置文件隔离

要在隔离状态下审计配置文件：不装多余扩展、不带旧实验残留，并且 permissions 可预测。EFF 单独写到，privacy add-ons 和不常见的防护措施本身也可能成为 fingerprint 的一部分。Multilogin 则提醒了 same-origin policy：网站看不到其他域名的 cookies。实践结论非常简单——独立配置文件、最少额外组件、可重复的配置。

浏览器内核版本和 headers

如果 network layer 干净了，再转向 browser core 和 headers。过时的内核、手动伪造 UA 的残留、browser version 与 emulated OS 之间的冲突，比那些奇怪的 Canvas 问题更容易触发 warnings。这里的建议很直接：保持内核最新，并确保 User-Agent 与真实浏览器版本及声明的操作系统一致。

不要过度随机化

不要在 randomization 上做得太过。EFF 明确不建议脱离其他信号去单独修改某一个 fingerprint element，因为这些指标是互相关联的。Multilogin 也警告说，在不了解后果的情况下，最好不要动深层 fingerprint settings。在实践中，稳定且一致的 defaults，几乎总是比激进的手动“伪装”更好。

什么时候需要从零重建配置文件

当结构性矛盾在基础修复后仍然反复出现时，就应该考虑重建配置文件：proxy 已经干净了，但 UA/OS 仍然冲突；timezone/language 仍然需要手动打补丁；permissions 和 extensions 继续污染结果；automation flags 在 relaunch 后又出现。这是一个实践结论，但它与 EFF 和 vendor docs 所强调的同一逻辑完全一致：fingerprint metrics 彼此相关，一旦“配置文件讲述的故事”不再完整，rebuild 往往比无止尽的 patching 更快。

配置文件投入使用前的检查清单

下面是一个简短列表，适合保存在 first run 之前，或者在账号预热之前使用。

配置文件启动前检查清单

• IP country、ASN 和 usage type 适合当前任务；不要把 city-level GEO 当作精确地理位置。
• DNS servers 不会暴露经由 ISP 的路由，WebRTC 也不会显示真实 local/public IP。
• User-Agent、Client Hints 和 OS/platform 讲述的是同一个故事。
• Accept-Language、navigator.language(s) 和 timezone 与 proxy/task locale 一致。
• Screen resolution 对于设备和团队场景来说看起来真实。
• Canvas/WebGL/AudioContext 没有损坏，没有无故被禁用，也没有表现得过度“加噪”。
• 如果 automation 不是场景的一部分，则 navigator.webdriver、CDP 和 headless flags 应该不存在。
• Browser core 是最新的，并且 version 与 OS 之间的 mismatch 已被消除。
• Geolocation API 的行为是有意设置的：prompt/allow/block 不应与 IP-story 冲突。
• 每次修改后，至少重新运行一个 network checker 和一个 consistency checker。

什么时候普通浏览器够用，什么时候需要 anti-detect

如果任务很简单，普通浏览器通常就够了：查看自己的 IP/DNS/WebRTC、了解网站能在 headers 中看到什么、快速对比几个 browser signals，或者只是想弄明白 fingerprinting 是如何工作的。对于这类 one-off 检查，BrowserLeaks、Cover Your Tracks、AmIUnique、iphey 和 Whoer 就已经足够。

而 anti-detect 真正有意义的时候，是当你需要的已经不是一次性测试，而是可重复的工作流程：多个彼此隔离的配置文件，每个都有自己的 cookies、language、timezone、proxy 和 launch parameters，以及用于创建、启动、更新和关闭配置文件的 API/automation。Undetectable API 文档中明确描述了 lifecycle 方法，以及像 proxy、language、cookies 和 timezone 这样的参数；在产品更新中，也会单独提到配置文件启动前的 proxy checks 以及 headless/background operation。

实践路线通常是这样的：先在 BrowserLeaks checker、Pixelscan checker、AmIUnique checker、Panopticlick / Cover Your Tracks checker 中检查你的 setup，必要时再补上 iphey 和 Whoer。如果你需要的不再是一次性测试，而是带有 profiles、cookies、proxy 和 automation 的长期 workflow，那么就转向下载 Undetectable，然后再看价格方案。但即便如此，审计依然是必需的：任何产品本身都不能保证不会出现 mismatch。

FAQ

1. 什么是 browser fingerprint？

Browser fingerprint 是网站通过 HTTP headers、JavaScript 和 Web APIs 收集的一组浏览器与设备特征，用来区分不同浏览器。它包括 UA、语言、timezone、screen、fonts、Canvas/WebGL、audio 等其他信号。它既不同于 cookie，也不同于 IP。

2. 为什么 BrowserLeaks 和 Pixelscan 可能会显示不同结果？

因为它们解决的问题不同。BrowserLeaks 是模块化的底层测试集合，Pixelscan 是一个 all-in-one consistency report，重点放在 detectability、internal mismatch 和 automation indicators 上。它们不必对同一个配置文件给出完全相同的评价，因为它们关注的是不同层，并且使用的启发式方法也不同。

3. 清理 cookie 会改变浏览器指纹吗？

通常不会。Cookies 和 fingerprint 是两种不同机制。删除 cookie 只会移除网站保存的标识符，但不会改变你的 language、timezone、screen、fonts、GPU 或 WebRTC behavior。不过，一些服务，比如 Cover Your Tracks 和 AmIUnique，会自己使用 research cookies 来关联重复测试，并研究 fingerprint 随时间如何变化。

4. proxy 和 fingerprint，哪个更重要？

应该从 proxy 和 network layer 开始。如果你存在 DNS leak、WebRTC leak、奇怪的 ASN 或 IP/timezone mismatch，那么对 Canvas/WebGL 做再细的调整也救不了这个配置文件。先处理网络，再处理 consistency browser fingerprint。

5. 应该多久重新检查一次配置文件？

最低频率是：首次启动前、每次更换 proxy 后、每次更新 browser core 后、每次手动修改 UA/language/timezone/geolocation 后，以及每次 automation/headless 配置变更后。另外，也建议定期重新进行审计，因为服务和指标本身在发展，而有些 signals 又取决于当前 session 和具体 origin。

6. 如果 WebRTC 或 DNS leak 一直过不了怎么办？

先停下来，修 connection layer：DNS route、WebRTC mode、proxy quality 和 session stability。只有在这之后，再重新测试。BrowserLeaks 和 Whoer 都明确把 DNS/WebRTC leaks 列为基础问题，Multilogin 也单独展示了同步 WebRTC 和 IP-story 有多重要。

7. 为什么配置文件通过了一个测试，却在另一个测试中失败？

因为不同的 checkers 检查的深度不同，而且优先级也不同。一个可能看 uniqueness/history，另一个看 privacy protection，第三个看 internal consistency，第四个看 automation traces。这是正常情况；也正因如此，完整审计总是由多个服务组成。

Undetectable Team 反侦测专家