BrowserLeaks 代理检测教程：四步确认代理是否生效
简答：打开 BrowserLeaks 的 IP、DNS 和 WebRTC 检测页面，在启用代理前后各测试一次：出口 IP 应发生变化，DNS 服务器应符合当前网络配置，WebRTC 不应暴露本地或运营商地址，IPv6 结果也不能绕过当前代理路径。单项显示异常不一定代表代理完全失效，需要结合四项结果和客户端模式综合判断。
定义：BrowserLeaks 代理检测是通过对比出口 IP、DNS 解析服务器、WebRTC 候选地址和 IPv6 地址，判断浏览器流量是否仍直接使用本地网络的一种排查方法。
一、开始检测前先建立“未启用代理”基线
不要只在代理已经开启的状态下打开 BrowserLeaks。更可靠的做法是先记录一次未启用代理时的结果，再启用客户端或系统代理后重新测试。这样可以区分“代理出口本来就和本地接近”和“代理根本没有接管流量”这两种情况。
- 暂时关闭代理客户端、系统代理或浏览器代理扩展。
- 打开BrowserLeaks IP 检测，记录公网 IPv4、IPv6、网络组织或 ISP、国家/地区等信息。
- 打开BrowserLeaks DNS Leak Test，点击开始测试，记录 DNS 服务器的地址、组织和所在地区。
- 打开BrowserLeaks WebRTC Leak Test，记录 WebRTC Public IP、Local IP 和页面显示的候选地址。
- 保留结果后，再开启代理并重复上述测试。测试期间尽量不要切换网络、浏览器或客户端模式。
BrowserLeaks 的 DNS 测试会尝试解析随机域名，并据此显示浏览器实际使用的 DNS 服务器；因此，DNS 结果应与“代理是否接管解析”一起判断，而不能只看网页上的国家或城市。
二、四项结果分别应该怎么看
| 检测项目 | 重点看什么 | 常见正常表现 | 异常时说明什么 |
|---|---|---|---|
| IP Address | IPv4、IPv6、ISP、组织和地区 | 启用代理后，出口地址或归属与基线不同，并符合所选节点的大致位置 | 仍显示本地运营商地址，通常表示浏览器没有走代理，或只代理了部分应用 |
| DNS Leak Test | DNS 服务器的运营商、地址和地区 | 结果符合客户端的 DNS 配置或代理侧解析路径 | 仍显示本地宽带或运营商 DNS，可能是系统 DNS 直连、浏览器 DoH 或客户端规则未接管 |
| WebRTC | Public IP、Local IP 和 ICE 候选地址 | 没有暴露不应出现的本地地址或本地运营商公网地址 | 浏览器的 WebRTC 连接路径可能绕过了代理；这不等于普通 HTTP 请求一定也绕过 |
| IPv6 | 是否存在 IPv6 地址，以及地址归属 | IPv6 未启用，或显示的 IPv6 与当前代理路径一致 | 启用代理后仍显示本地运营商 IPv6，说明 IPv6 可能没有被当前配置接管 |
“国家/地区变化”只能作为线索，不能单独证明代理已经完整生效。云主机、数据中心和 CDN 地址的地理定位可能不精确；同一个节点也可能同时提供 IPv4 和 IPv6，因此应优先比较地址、ISP/组织和 DNS 服务器，而不是只看地图位置。
三、BrowserLeaks 显示异常时的排查顺序
1. IP 没变：先检查代理范围
- 确认客户端状态确实为已连接，而不是只有订阅已导入。
- 检查当前模式是系统代理、规则模式还是全局模式。规则模式下，部分域名可能按规则直连。
- 检查浏览器是否单独设置了代理，避免浏览器代理与系统代理指向不同端口。
- 关闭浏览器中的其他代理扩展，再完全退出并重新打开浏览器。
- 重新访问 BrowserLeaks IP 页面，确认不是浏览器缓存或旧标签页中的结果。
如果系统代理只接管支持 HTTP 或 SOCKS 的应用，某些基于独立网络栈的程序可能不会跟随；这时要在客户端支持的前提下检查 TUN 或虚拟网卡模式，但开启 TUN 可能影响局域网访问、游戏、虚拟机和其他网络软件。
2. DNS 仍是本地运营商：检查解析路径
- 确认客户端的 DNS 模式、监听地址和上游服务器设置没有冲突。
- 检查浏览器是否启用了 DNS over HTTPS。Chrome 的管理策略中，DoH 可以设置为关闭、失败时回退到普通 DNS，或不允许回退；浏览器自己的解析设置可能与客户端 DNS 接管方式不同。
- 如果客户端使用 fake-ip 或 TUN，BrowserLeaks 通常应显示客户端配置的上游解析器、代理侧解析器或远端链路中的 DNS 服务，而不是固定显示本地宽带 DNS。具体显示内容取决于客户端的 DNS 模式、规则和上游服务器。
- 修改 DNS 后清理浏览器 DNS 缓存，重启客户端，再进行一次完整测试。
DNS 服务器所在地与出口 IP 所在地不一定相同，所以“DNS 国家不同”不必然是泄漏；更重要的是确认它是否属于本地网络、是否符合你的客户端配置。
3. WebRTC 暴露地址：不要寻找 Chrome 中不存在的开关
Chrome 桌面版没有一个普通设置页面中的“关闭 WebRTC”按钮。Chrome 官方策略提供 WebRTC IP handling 等管理项，用于控制 WebRTC 使用哪些地址和网络接口；BrowserLeaks 也建议使用能够限制 WebRTC IP 暴露范围的扩展。实际操作时，应选择来源可信、权限范围明确的扩展，并在 Chrome 的“扩展程序→详情”中检查其站点访问权限。
- 先记录 WebRTC 页面中的 Public IP、Local IP 和 ICE 候选结果。
- 如果不需要浏览器的实时音视频功能，可使用限制 WebRTC IP 暴露范围的方案，并了解它可能影响视频会议、语音通话或点对点连接。
- 如果代理客户端提供 TUN 模式，可在确认其 DNS 和路由设置后测试 TUN；不要把“开启 TUN”当作必然修复 WebRTC 的保证。
- 重新加载 BrowserLeaks WebRTC 页面，比较启用前后的地址，而不是只看是否出现某一行文字。
4. IPv6 显示本地地址：先对比归属，再决定是否处理
正确的判断是：先记录关闭代理时的 IPv6 归属，再开启代理测试。如果开启代理后仍显示同一个本地运营商 IPv6，才说明 IPv6 可能绕过了当前代理路径；如果关闭 IPv6 后页面显示 n/a，这只能说明测试时没有可用 IPv6，不能反向证明原来的 IPv6 路径已经被代理接管。
Windows 可在“控制面板→网络和 Internet→网络连接→当前适配器→属性”中查看“Internet Protocol Version 6 (TCP/IPv6)”绑定。微软不建议在没有明确理由时解除 IPv6 绑定，因为部分 Windows 组件和功能依赖 IPv6；如确需排障，应先记录原设置，并在测试后恢复。macOS 和 Linux 不建议直接套用 Windows 的适配器步骤，应使用各自系统的网络设置或客户端文档。
四、一次完整复测应该怎么做
- 关闭代理，记录 IP、DNS、WebRTC、IPv6 四项结果。
- 开启代理，确认客户端显示已连接，并记录当前模式、节点或配置名称。
- 用同一个浏览器、同一网络和同一 BrowserLeaks 页面重新测试。
- 先看 IP 是否变化，再看 DNS 是否仍属于本地网络，最后检查 WebRTC 与 IPv6 是否出现本地地址。
- 每次只修改一个设置，例如只切换 DNS 模式或只切换 TUN，再重新测试。
- 把每次结果按时间保存，避免同时修改代理模式、DNS、浏览器扩展和系统 IPv6 后无法判断哪个设置产生了影响。
推荐的判断顺序是“出口 IP→DNS→WebRTC→IPv6”。如果只有 WebRTC 异常，优先处理浏览器的 WebRTC 地址暴露；如果 IP 和 DNS 都没有变化，应优先检查代理是否真正接管浏览器流量；如果只有 IPv6 异常，则重点检查客户端是否支持 IPv6、TUN 路由是否覆盖 IPv6，以及本地网络是否分配了公网 IPv6。
五、结论：什么结果才算基本通过
BrowserLeaks 没有一个适用于所有代理类型的“通过”按钮。对普通浏览器代理来说，比较可靠的基本标准是：启用代理后出口 IP 与基线有明确差异；DNS 测试不再显示本地运营商解析器，或与客户端配置一致；WebRTC 没有暴露不应出现的本地或运营商地址；IPv6 没有显示未被当前代理路径接管的本地地址。
如果四项结果互相矛盾，不要只依据某一项下结论。例如 IP 已变化但 DNS 仍是本地服务器，可能是浏览器 DoH 或系统 DNS 未被接管；IP 和 DNS 都变化但 WebRTC 暴露本地地址，可能只是浏览器实时通信路径使用了独立接口。排查时应回到基线，逐项修改并复测。
常见问题
BrowserLeaks 显示的 IP 一定是真实代理出口吗？
它显示的是当前浏览器请求可见的公网地址，但不能仅凭地址证明某个服务商、节点或客户端一定可靠。还要结合 ISP/组织、DNS、WebRTC 和 IPv6 结果，以及启用前后的对比。
DNS 显示本地服务器，就代表代理完全失效吗？
不一定。可能只有 DNS 没有被代理接管，而网页请求已经经过代理；也可能是浏览器 DoH、系统解析器或客户端 DNS 规则产生了分流。应先确认 IP，再检查浏览器和客户端的 DNS 设置。
WebRTC 显示 Local IP 是不是一定泄漏公网 IP？
不是。Local IP 通常指设备内网地址，是否构成需要处理的问题取决于页面同时显示的 Public IP、ICE 候选和你的使用场景。重点是确认是否出现了不应暴露的本地运营商公网地址。
IPv6 显示 n/a 就代表代理一定安全了吗？
不是。n/a 通常只说明当前测试没有检测到可用 IPv6，不能证明 IPv4、DNS 或 WebRTC 没有泄漏。仍需完成 IP、DNS 和 WebRTC 检测。
为什么切换节点后 BrowserLeaks 结果没有变化？
可能是客户端没有真正切换成功、浏览器仍使用旧连接、当前规则让该网站直连，或不同节点使用了相同的出口网络。完全退出并重启浏览器与客户端后，再用基线结果进行对比。
常见问题
BrowserLeaks 能直接判断代理是否安全吗？
不能。它能帮助检查浏览器可见的出口 IP、DNS、WebRTC 和 IPv6 路径，但不能替代对客户端权限、服务商记录政策和具体应用流量的完整审查。
IP 已经变化，但 DNS 没变化怎么办？
先检查客户端 DNS 模式和浏览器 DNS over HTTPS 设置，再确认是否存在规则分流。每次只改一个设置，重启客户端和浏览器后复测。
Windows 是否应该直接关闭 IPv6？
不建议把关闭 IPv6 当作首选修复方案。微软提示解除 IPv6 绑定可能影响部分 Windows 组件；应先对比代理开启前后的 IPv6 归属，再根据客户端和网络情况排查。