代理已经连上，查 IP 也显示预期地区，为什么另一个网站还能看到不同地址？DNS 结果不是代理服务商，是否说明泄漏？Canvas 每次都生成一个指纹，又是不是一定不安全？
这些问题背后，既有网络路径，也有浏览器本身的行为。继续查询地址是不是住宅、风险分有多低，往往解释不了原因。BrowserLeaks 的价值，正是把这些观察拆成模块，保留足够细的输出，让排查可以继续进行。
我会把它推荐给需要认真核对配置的人，尤其是已经发现异常、需要向技术支持说明的人。它的长处不是给一份漂亮的环境总分，而是让你从“有问题”走到“哪一项、在哪条路径、在什么条件下有问题”。 使用门槛也来自同一处：原始信息很多，不能把所有看见的细节都当成泄漏证据。
第一次打开该选哪个模块？先按问题走，不必把侧栏全测一遍
BrowserLeaks提供 IP、JavaScript、WebRTC、DNS、Canvas、WebGL、字体、定位与 TLS 等入口。它不是按一条固定验收流程排列的，而是一套可以按症状选用的工具。
如果不知道先做什么，我会这样分配注意力：地址不对，先确认普通请求出口；担心实时通信绕过代理，查 WebRTC；怀疑解析路径，查 DNS；已经确认连接正常，再研究指纹与浏览器特征。只有相关模块，才值得投入理解起来的难度。
| 当前问题 | 优先看什么 | 不要混为一谈的事 |
|---|---|---|
| 网页看到的出口不符合预期 | IP 与请求信息 | 手动查询某个地址，不等于验证当前浏览器 |
| 某些场景出现额外地址 | WebRTC 候选、类型与 SDP | 本地名称不一定是公网泄漏 |
| 解析器位置或归属异常 | DNS 测试与解析设置 | 解析器不属于代理商，不自动等于泄漏 |
| 不同环境仍被关联 | Canvas、WebGL、字体、TLS 等线索 | 指纹存在不等于已经证明平台关联方式 |
这套结构对技术用户很实用，因为可以直接定位模块，也能对比同类输出；对运营同事，则容易显得零散。它不会主动告诉你每一项对当前任务有多重要，因此正确入口比“检测项目多”更重要。
WebRTC 页：摘要可以快速看，真正的价值在候选和原始记录
WebRTC 检测页区分远端看到的 IP、浏览器支持情况、WebRTC 地址与 SDP 内容，还展示媒体设备及权限状态。这个布局比只给一个红绿判断更有用，因为可以把摘要与底层资料对照。
WebRTC 是浏览器用于实时音视频和数据通信的一组技术。为了找到双方可以连接的路径，浏览器会收集 ICE candidates，也就是连接候选。候选不等于已经发生泄漏，它只是浏览器提出的可能路径；需要看类型、地址范围，以及是否超出预期。
先读懂三类常见候选，再看地址
MDN 的候选类型说明区分 host、srflx、relay 等类型。普通用户无需背完整协议，但至少应理解它们为什么会不同。
host：来自本机网络接口的候选
它与设备或本地网络有关，现代浏览器可能用 mDNS 名称保护部分本地信息。本次 2026 年 10 月 21 日的页面观察中，能够看到 .local 形式的候选。一个这样的名字，不是第二条公网出口，也不能单凭名称就宣称真实公网 IP 已经暴露。
若出现私网地址，也要分清含义。家庭网络中的私网地址与公网地址不是一回事，可能对网络特征有信息价值，但不应自动被写成“网站获得了家庭公网出口”。
srflx：外部服务器观察到的映射
这类候选通常来自 STUN 等机制对外部地址的观察。它更值得与期望出口核对：如果普通网页请求走代理，实时通信相关观察却出现不应公开的另一个公网地址，就有必要继续查路由和策略。
不能只看地区。两个地址被地理库放在同一个国家，也不表示它们就是同一条路径；反过来，一个解析或中继服务被标在其他地区，也需要先确定它的角色。
relay：通过中继服务提供的路径
中继候选的地址属于中继路径，不一定是用户直接公网地址。遇到陌生地址，先识别它是不是中继，再判断是否异常。否则，保护连接的中继也可能被误当成“额外泄漏”。
我认可 BrowserLeaks 把原始候选留下来的做法。它允许使用者解释差异，而不是只能相信一个汇总结论。代价是，没有理解类型就复制整页，很容易向客服提出错误问题。
SDP 中的地址，并不是每一个都应算作泄漏
SDP 是描述会话与连接能力的一种文本格式。里面可能包含候选、占位、回环或其他字段。0.0.0.0、127.0.0.1 等内容需要按所在位置理解，不能用“出现了多个 IP 字符串”来计数风险。
它适合做证据，恰好因为可以核对具体字段，而不是因为越长越专业。若摘要显示正常、原始候选却有疑点，应该保存候选类型、协议与必要地址信息，说明与预期有什么差别。
完整原文还可能包含临时凭据与会话信息。向支持人员提交时，只保留定位问题所需的部分；把整段未经处理的日志公开到文章或群聊，不会让结论更可靠。
现代研究为什么仍然建议检查 WebRTC？
Nibert 等人的《Preventing WebRTC IP Address Leaks》在 Linux、macOS 与 Windows 环境研究了浏览器、VPN 及 HTTP/S、SOCKS 代理条件。作者发现，在其音视频通信测试中，敏感公网信息仍可能暴露，尤其需要注意非 NAT 的企业网络。
这是作者公开的已接收论文版本，不是本文的实验，也不是 BrowserLeaks 准确率比较。其价值是说明，不能因为普通网页 IP 正确，就假定所有实时通信路径也符合预期；具体结果仍受浏览器、网络和权限等条件影响。
我据此更重视按业务场景检查。只做网页读取，与实际参加会议、使用音视频功能，可能触发不同能力。简单检测页的结果可以作为线索，却未必覆盖应用在获得权限后的全部行为。
同样，不应把旧研究中的浏览器版本结论直接当成今天的通用排名。研究告诉我们该观察哪些条件，当前配置是否存在问题，仍需在对应环境中验证。BrowserLeaks 的详细输出适合支持这个过程，而不是取代过程。
DNS 页：它告诉你谁在解析，不会自动替你决定是否符合预期
DNS 负责把域名转换成可连接的地址。浏览网页时，应用既要决定请求走哪条连接，也要决定域名由谁解析。如果预期所有相关活动都经过指定路径，而解析请求仍走了不希望使用的网络，就需要排查。
这个 DNS 测试的好处，是用一批新的域名寻找解析服务，避免只列出你设置过的服务器名称。测试包含 50 个随机域名：25 个只有 IPv4 记录，25 个只有 IPv6 记录。这里说的是“域名返回哪类地址”，不是已经证明 DNS 请求分别经过了 IPv4 和 IPv6 两条线路。
看到 Google、Cloudflare 或其他公共解析器，先问配置是什么
解析器属于不同公司不构成充分的泄漏证据。浏览器可能启用了加密 DNS，系统可能指定公共解析服务，代理或企业网络也可能使用转发。应先确定希望 DNS 由谁处理，再与结果对照。
解析器的地理位置同样不是用户设备位置的直接证明。服务可能分布式部署，地理库对解析节点的定位也可能不同。仅凭“DNS 在另一个国家”，还不足以解释完整路径。
我认为这个模块的优点是提供观察，不强迫用户接受单一供应商方案。缺点则是结果需要配置背景；没有预期路径的人，即使看完也可能只记住一个陌生组织名。测评推荐它时，应该把这一步说明补上。
DNS 结果为空，是否更安全？
不是。脚本没运行、请求被拦、网络等待、模块未完成，都可能让页面没有取得结果。未知不等于没有泄漏。若关闭 JavaScript 后大部分模块空白，更不能把“检测不到”改写成环境已经通过。
对实际排查，我会保留模块是否完成、测试时的加密 DNS 设置、代理作用范围与浏览器版本。只保存几个解析器名称，往往不足以让别人复现问题。
Canvas、WebGL、字体：为什么换 IP 后，这些结果可能还一样？
代理改变的是网络出口，不会自动改变浏览器使用的图形栈、字体或系统环境。BrowserLeaks 将这些资料单独展示，对理解“换了代理还被关联”的疑问很有帮助。
Canvas 模块让浏览器绘制特定内容，再从像素等输出形成签名；WebGL 模块观察图形能力与渲染信息；字体模块研究文字尺寸、字形与可用字体特征。它们都可能提供区分环境的线索，但不是同一项检测。
有哈希，不等于已经证明全球唯一
哈希可以理解为根据一组输出生成的短标识。它适合比较两次输出是否相同，但唯一性需要样本与统计语境。网站展示一个签名或某种相对稀有程度，不等于已经证明世界上只有你这一台设备。
Canvas 页面给出代码和示例，有助于理解结果从哪里来，这是透明度上的优点。反过来，示例中不同用户的图像差异，也不能被扩大成全部浏览器的识别成功率。
我会把这些模块用于研究配置变化：同一环境是否稳定、某个设置是否改变了输出、不同模块是否存在难以解释的冲突。至于某个平台到底用了哪些特征，需要另有证据，不能从 BrowserLeaks 的字段清单反推。
不要为了“每次不一样”，不断制造更多不一致
随机化可以改变部分输出，但效果需要结合实现、可检测性和稳定性判断。只追求一个签名不停变化，并不证明更难关联；如果其他特征保持、某项异常波动，反而需要解释这种组合。
这也是我对“指纹全绿”口号的保留。BrowserLeaks 提供技术输出，未必给每项定义统一的最佳状态。对正常工作环境，更有用的目标是可理解、符合需求、变化有原因，而不是所有模块都看起来最特别或最普通。
TLS 模块让诊断更完整，但不是另一种 IP 纯净分
TLS Client Test展示连接所用的协议、密码套件、扩展与 JA3、JA4 等指纹。TLS 是建立加密连接的一层能力，这类指纹关注握手特征，观察对象与地理位置、住宅属性不同。
它有助于研究浏览器宣称的信息与连接实际表现是否一致，也能提示旧或不理想的协议配置。对于只改请求中的 User-Agent，却没有改变实际客户端的情况，这种模块比单看文字声明更有解释空间。
但代理如何转发、是否终止或重新建立连接，会影响远端观察。不能简单规定“使用 SOCKS5 就一定隐藏 TLS 指纹”，也不能因为 TLS 标签正常，就说浏览器没有其他识别面。需要理解客户端与连接方式，再讨论结果。
我认为加入 TLS 是 BrowserLeaks 比简单泄漏页更有深度的原因之一：它能把问题从 IP 延伸到客户端连接特征。对普通运营用户，这部分可以按需阅读，不必为了项目齐全就强行配置所有选项。
实际上手的难点：原始资料丰富，却没有替你排好优先级
BrowserLeaks 的模块划分清楚，结果与解释常放在一起，有些页面还提供代码或参考资料。对技术支持、开发与需要复核的人，这比单一百分比更方便沟通。
不足是术语多、页面之间需要切换，也没有一份针对每种代理任务的现成结论。第一次使用时，很容易把支持某功能理解为已经执行了某功能，把权限未授予理解为不存在风险，把一个正常模块扩大成整个环境通过。
帮助内容还需要核对时效。比如 WebRTC 页仍介绍历史上的浏览器扩展方案，而浏览器支持、扩展状态和策略会变化。实际修复应回到当前版本设置，不应把旧帮助文本照搬成通用操作。
我因此会给出分层推荐：新手先从 IP、DNS、WebRTC 的相关症状开始；配置人员保留候选和原始字段；研究指纹时再进入图形、字体与 TLS。这个网站适合深入，但不要求每个人一次把全部内容读完。
一轮可执行的排查：让每次修改都有原因
下面是建议流程，不是本文完成过的商业代理实验。目标是避免同时改太多条件，最后不知道哪个设置起了作用。
1. 写清楚你希望它怎样连接
代理用于哪个程序？哪些请求应该经过它？网站应该看到哪个出口？先写下这些，后面才知道某项结果是不是异常。只在浏览器设置代理，其他应用不一定会跟着使用。
2. 只查与问题有关的模块
网页出口不对，先查接入；WebRTC 出现不希望暴露的公网地址，再查实时通信设置；DNS 不符合预期，再查解析设置。字体和图形信息可以之后再看，不必一开始就改。
3. 每次只改一项，再重新连接
保留修改前后相同的结果，确认 IP、权限和完成状态。旧连接与缓存可能还在使用旧设置，因此应建立新连接复查。这样结果变了，才更容易知道是哪项修改起了作用。
4. 再做一次真正的工作
如果问题出在会议，就检查通话；如果问题出在某个应用，就回到该应用。检测页正常是有用的线索，但不表示它已经替所有程序做完检查。
如果使用 PuraRoute 接入浏览器，可以先按其 DICloak 配置指南或对应客户端文档完成连接，再用 BrowserLeaks 核对实际出口与相关模块。配置指南解决怎样接入，检测页帮助看接入后发生了什么，这样比买到地址后只查资源标签更完整。
需要注意，产品支持 HTTP(S) 或 SOCKS5，不意味着所有应用、解析和实时通信都自动受同一设置控制。异常出现时，先确定是哪条路径，才知道应该调整客户端、网络策略还是向供应商反馈。
我会怎样写一份让客服看得懂的报告？
我会把“浏览器泄漏了”改成具体描述：普通请求显示哪个预期出口，哪个模块出现什么不一致，在什么浏览器、代理模式和权限条件下复现。附上必要字段，比传十张没有顺序的截图更有用。
如果结果只包含 .local 名称，就说明观察到了本地候选保护形式，不直接称公网泄漏；如果实际出现预期外公网候选，就记录类型与条件；如果模块没有完成，就保留未知，不替它下结论。
对 Canvas 或 TLS 这样的模块，也应说明正在比较什么变化，而不是笼统要求“把指纹修好”。不同任务没有统一指纹答案，支持人员需要知道你的预期与实际冲突在哪里。
这也是 BrowserLeaks 的实际价值：它提供足够信息，把泛泛的“环境有问题”变成能继续处理的线索。只要读者愿意按范围解释，它比追一个总分更有帮助。
三个常见情境，怎样从页面走到解决办法？
以下通过三个情境说明怎样选模块、读结果和决定下一步，帮助判断 BrowserLeaks 是否适合你面对的问题。
网页出口正确，WebRTC 却出现预期外的公网候选
这时首先要核对候选类型、地址范围和浏览器配置，而不是继续查“是不是住宅”。如果地址确实不应公开，说明普通网页请求与实时通信需要分别排查。应确认代理作用范围、相关网络能力与当前浏览器策略，再做同条件复查。
如果只是 .local 名称或中继地址，结论又不同：先解释它的角色，不要为消除一个看起来陌生的字符串而盲目关闭功能。BrowserLeaks 的优势是原始字段能区分这些情况，而不只是让你看到第二个地址。
DNS 看起来在别的地区，但没有其他异常
先看解析器是谁、是否使用公共服务，以及地区是怎样推断的。如果当前明确配置了浏览器加密 DNS，那么这条路径可能本来就在预期内。是否需要调整，应由隐私目标与任务要求决定。
如果期望解析也经指定路径，实际却由不希望使用的网络处理，才进入配置修复。两种情况表面都可能是“公司或国家不同”，行动却不一样。单看地理图标，很难完成这个判断。
更换代理后指纹没变，平台问题也仍在
这并不足以说明新代理无效。地址、浏览器特征、已有登录状态和任务行为是不同信息。先确认出口是否变化，再检查具体问题与哪些条件有关。把所有结果都归因于 IP，会让人反复换资源，却保留真正的故障条件。
BrowserLeaks 可以把浏览器暴露的技术特征列出来，帮助缩小范围，但不能替目标平台解释内部规则。如果没有对应证据，就应记录为尚不确定，不能把某个签名相同直接写成平台关联账号的事实。
这三个情境共同说明，诊断的目标是得到可解释的下一步。修复以后，应确认原来的异常是否消失、实际任务是否恢复，而不是只看页面字段是不是比之前少。功能被关闭、请求被拦截，也可能让结果减少，未必代表工作环境整体变好。
我的取舍：排障时值得优先用，采购时需要与资源资料配合
如果问题是 IP 是否来自符合要求的网络，IPinfo、Ping0 等资源查询更直接；如果问题是浏览器在代理之外暴露了什么，BrowserLeaks 更贴近原因。与 Whoer 的概览相比，它不那么轻便，却提供了更多原始证据；与 IPLeak 相比，它对浏览器能力和指纹的模块研究更细。
我愿意推荐它，是因为发现问题后还能往下查。需要留意的是，新手要花时间看懂结果，部分帮助内容也需要核对是否适用于当前版本。查到一项 No Leak 很有帮助，但之后改了浏览器、权限或接入方式，仍应重新检查相关项目。
一个好的泄漏检测工具，不应让使用者只知道自己害怕什么，还应该帮助他们知道下一步查什么。按这个标准，BrowserLeaks 是有深度、也值得耐心使用的工具；把所有页面打开再数异常项，则很难发挥它的长处。
关于BrowserLeaks的常见问题
BrowserLeaks 能认证住宅代理质量吗？
它主要检查浏览器与连接行为。住宅类型、交付地区、历史信誉和代理性能仍需要对应资料与测试，不能由一项正常结果替代。
WebRTC 出现 .local 名称，是不是已经泄漏真实公网 IP？
不能这样判断。先确认候选类型和内容，mDNS 本地名称不等于额外公网出口。
No Leak 是否意味着所有模块都没问题？
不是。它属于具体检测范围，DNS、指纹、权限和其他应用需要分别解释。
DNS 解析器与代理不是同一公司，是否一定要更换代理？
不一定。先核对预期解析方式、加密 DNS 与客户端配置，组织名称不同本身不足以证明泄漏。
换 IP 后 Canvas 指纹不变，是代理没生效吗？
不一定。Canvas 主要反映浏览器与渲染环境，代理出口变化不会自动改变它。是否经过代理应看实际连接与出口。
关闭 JavaScript 后模块空白，是不是更安全？
空白可能表示测试无法执行，不能当成通过。是否应该限制脚本，需要结合实际业务和隐私目标判断。
TLS 或 JA4 正常，可以保证平台不会限制吗？
不能。它只提供连接特征的一部分信息，平台决策和账号状态仍是另外的问题。
