WebRTC、DNS、IPv6 泄漏怎么查？IP 已经变了，也要核对这三条路径

打开 IP 查询页，看到地址已经变成预期出口，很容易以为设置已经全部生效。实际上，这只能说明那次网页请求使用了这个地址。域名解析、WebRTC 通信和 IPv6 请求，未必走了同一条路径。

判断是否发生 IP 或 DNS 泄漏，关键不是“页面上出现了几个地址”，而是有没有信息或流量走出你预期保护的路径。 出现内网地址、公共 DNS 或与出口不同的地区名称，都不能单独作为泄漏结论。

这篇文章适合检查自己的设备、浏览器和网络设置。检测结果也只代表本次可观测的环境，不应被理解为对设备上所有应用的隐私保证。

先确定你希望哪些流量被保护

开始测试前，先回答一个简单问题：你配置的是浏览器代理、系统代理，还是接管网络路由的 VPN？

它们的覆盖范围可能不同。浏览器扩展不必然处理其他应用；系统代理也不代表每种协议都会遵循代理设置。VPN 是否覆盖 IPv6、DNS 和分流流量，同样取决于具体实现与配置。

如果你有意让某个应用直连，它走原来的出口不一定是故障。但如果你的预期是“所有外发流量都使用指定出口”，同样的现象就需要进一步排查。

建议先保留一份基线：未启用目标配置时的公网 IPv4、IPv6，以及 DNS 检测可观察到的解析器。基线用于前后比较，不需要公开发布；特别是企业网络，不应随意暴露内部地址和配置截图。

WebRTC：先区分候选地址，再判断是否暴露出口

WebRTC 让浏览器能够进行实时音视频和数据通信。为建立连接，它会收集可能可用的网络路径，也就是 ICE 候选。

MDN 的候选类型说明区分了 host、srflx、prflx 和 relay 等类型。对普通用户来说，最需要分清的是本地接口信息、经过地址转换观察到的信息，以及中继服务器的地址。候选是否向网页暴露，还会受到浏览器 WebRTC 隐私策略的影响。

WebRTC 暴露原网络地址并非凭空想象。RFC 8828讨论了分流 VPN、多网络接口和应用代理等情况下的 IP 信息暴露问题。但浏览器实现、权限和网络策略会影响实际表现，不能把旧浏览器上的测试结论直接套用到所有设备。

在 WebRTC 检测中，如果看到了不符合预期的公网地址，先与基线对照，再核实它属于哪个网络。不要仅凭“显示了第二个地址”就下结论，也不要把“没有收集到候选”直接等同于绝对安全——通信被阻止或测试未完成，也可能产生空结果。

DNS：看到运营商解析器，意味着什么？

浏览器访问一个域名之前，通常需要先得到它对应的地址。DNS 泄漏关注的是这一步有没有按照预期的解析策略执行，以及不应接触查询信息的一方是否可能接触到了它。

常见的 DNS 泄漏测试会让浏览器请求一组测试域名，再从权威 DNS 一侧观察查询来源。页面展示的通常是递归解析链路中的出口，而不是对你设备 DNS 配置的直接读取。

这意味着，检测到一个 DNS 地址后，还不能立即认定“本机 DNS 服务器就是它”。递归转发、公共解析服务和 Anycast 部署，都可能让结果比系统设置界面复杂。

尤其不要只看国家名称：DNS 出口的数据库定位与网页出口不同，不足以单独证明泄漏。应进一步核实解析器运营方、服务的路由方式，以及是否符合你的配置目标。

如果你的预期是仅使用 VPN 指定的解析路径，测试却持续观察到原网络运营商的解析出口，这是需要排查的信号。如果你主动配置了某家公共 DNS，检测到它本身则不一定是异常。

可以使用 DNS 泄漏检测前后对照。出现多家解析器时，优先检查浏览器“安全 DNS”、操作系统 DNS、VPN DNS 和分流设置之间是否存在覆盖或并用关系。

开启 DoH，是否就不会泄漏？

DoH 解决的是 DNS 查询传输加密问题，不自动解决全部路由与信任问题。Cloudflare 的说明介绍了将 DNS 查询封装在 HTTPS 中的方式，但“传输已加密”不等于“查询一定走了你指定的 VPN”。

解析服务仍会处理你的查询。某些部署还可能使用 EDNS Client Subnet，在递归查询中传递客户端网络前缀信息；这项机制及其隐私影响在 RFC 7871中有说明。普通 DNS 测试没有明确提供此项结果时，不要假设它已经检查过 ECS。

IPv6：IPv4 出口正确，不代表另一套地址也正确

许多网络同时提供 IPv4 和 IPv6。如果某个代理或 VPN 只处理了 IPv4，而设备仍能通过原网络直接使用 IPv6，那么支持 IPv6 的目标服务就可能观察到另一条出口路径。

不过，“IPv4 和 IPv6 地址不同”本来就是正常现象。它们属于不同的地址体系，不能通过地址文字是否相似来判断保护是否生效。

应该比较的是：两种协议的网络归属、实际路由是否符合预期，以及 IPv6 是否仍指向原网络。IPv6 临时地址自身的变化，也不自动表示发生了泄漏。

在网络环境检测中分别查看可用的 IPv4、IPv6 信息。若 IPv6 测试未完成，只能标记为未确认；这和“已确认 IPv6 不可用”不是一个结论。

一套可以重复执行的排查顺序

1. 在同一设备、同一浏览器中做前后对照

记录未启用目标配置时的出口信息，再启用配置重新检测。测试期间避免同时更换 Wi-Fi、浏览器代理和 DNS，否则很难判断是哪一步造成了变化。

2. 分别检查网页、WebRTC、DNS 和 IPv6

把四组结果分开记录：网页观察到的公网出口、WebRTC 候选、DNS 查询来源、IPv6 可达性与出口。不要用其中一项的绿色状态代替其他项目。

3. 按异常路径定位设置

WebRTC 暴露了原网络公网地址，检查代理覆盖范围、WebRTC 策略以及 VPN 是否采用分流。DNS 不符合预期，检查浏览器与系统解析设置，以及 VPN 断线后的 DNS 恢复行为。IPv6 仍走原网络，则检查 VPN 的 IPv6 支持和相关路由。

每次只修改一个相关选项，然后复测。需要处理长期业务问题时，保留时间、配置状态和结果摘要，通常比只截一张“红色警告”更利于定位。

4. 检查重新连接后的表现

网络重连、设备休眠唤醒和 VPN 重新连接，都可能改变路径。条件允许时，在这些正常使用场景后再次检查。一次测试通过，只能证明当时观察到的行为符合预期，不能替代后续的稳定性验证。

不建议一上来就禁用所有功能

直接禁用 WebRTC，可能影响浏览器通话和会议；直接关闭 IPv6，也可能掩盖配置问题。是否这样做，应取决于你的实际需要和可接受的功能损失，而不是只为了让检测页少显示几行。

更稳妥的做法是先明确保护范围，再修正对应的路由、解析或浏览器设置。企业设备还应遵循管理员策略，不应自行绕过既定的网络与安全配置。

无痕窗口可以防止这些泄漏吗？

不能把无痕模式当成网络隧道。它主要改变浏览记录、Cookie 等本地会话数据的处理方式，并不会天然接管 DNS、WebRTC 或 IPv6 路由。

检测不到原始 IP，就代表完全匿名吗？

不是。IP 路径只是隐私的一部分。账号登录、Cookie、浏览器特征以及主动提交的信息，都可能让服务识别或关联一次访问。

完成这套检查后，合理的结论应当是：“在当前配置和测试条件下，已观察到的网络路径符合预期。” 这比一句没有适用范围的“零泄漏、完全匿名”，更准确，也更能指导后续使用。

分流场景：同一设备出现四个不同结果该怎么读

假设你配置了按域名分流，或同时开着 VPN 与本地直连出口。一次检测中，HTTP 出口显示代理节点 A 的地址，DNS 检测显示递归服务器 B 的地址，WebRTC 候选里出现了原网络公网 C 和一个 TURN 地址 D，IPv6 则仍走运营商线路。这类结果容易被误读为“四项全泄漏”。实际上，它们可能只是各自的路径不同。关键不是有几个 IP，而是这些路径是否与你的预期一致。

在这个示意中，若只希望网页 HTTP 流量走代理，出口 A 可能符合配置；DNS 是否直连需要另行确认。如果网页可读取的 WebRTC 候选里出现原网络公网 C，就已经说明该页面在这次测试中能获知 C，并不需要等到媒体连接实际使用它才算暴露。是否属于不符合需求的泄漏，取决于你是否要求对该页面隐藏这个地址。

mDNS 候选尤其需要分清。浏览器常用随机生成的 .local 名称代表本地网络接口，避免直接暴露真实局域网信息。在 WebRTC 检测页里看到类似“2f8c…local”的条目，应理解为本地候选的隐私处理，而不是你的公网 IP 或主机名。将它当作泄漏证据，是常见误判。若同时存在原网络公网地址，且该应用本应被隧道保护，才属于值得重点核实的暴露信号。

IPv6 也要单独记录。IPv4 出口走代理 A，但 IPv6 仍走运营商直达链路时，支持双栈的目标站可能同时或优先通过 IPv6 观察到你的运营商地址。这不一定由代理配置错误导致，很多采用 CIDR 分流或仅代理 IPv4 的客户端，默认不会接管 IPv6 路由。此时不要急着下“IPv6 泄漏”结论，而是先确认 VPN 或代理是否声称覆盖 IPv6，再检查本地是否有 IPv6 默认路由指向隧道。

DNS 递归服务器的差异可以借助 ASN 与 RDAP 信息辅助判断。B 的地址若属于你主动指定的公共解析服务，即便与 HTTP 出口不同，也是正常现象；若属于原网络运营商且你原本想让解析流量进入隧道，才是需要排查的异常。Anycast 部署的解析服务可能在不同地区显示不同节点，不能只凭地理位置变化断定 DNS 走了直连。应关注运营方名称、ASN 归属，以及测试域名是否在权威侧观察到不符合预期的查询来源。

遇到这种多出口并存，第一件事不是关功能，而是把“预期”写下来。哪些应用应走代理，哪些应直连；DNS 应由谁处理；IPv6 应被隧道覆盖还是允许直连；WebRTC 在 VPN 接入时是否允许收集本地候选。完成一次测量后，再对比基线。若发现某一项与预期不符，回到具体设置中逐项调整。一次只改一个变量，例如先改 DNS，再复测，才能确定是哪条规则导致的差异。

重复测量与断线恢复：让检测结果经得起再次验证

一次检测通过只说明当时的环境符合预期。VPN 重连、系统唤醒、浏览器权限变化，都可能让路径改变。建议在正常使用场景后重复测量：断开再连接 VPN、休眠唤醒、切换 Wi-Fi 与移动网络后，分别查看 HTTP 出口、DNS 来源、WebRTC 候选和 IPv6 状态。这四种结果的稳定性，比单次全绿更有参考价值。

每次测量只保留一个变量变化。例如今天只改 WebRTC 相关设置，就保持 DNS 与 VPN 设置不变；明天只改 IPv6，就复测所有四项。若同时调整浏览器“安全 DNS”、代理分流和系统 IPv6 开关，发生时好时坏的现象，很难回溯是哪一处导致变化。记录时间、配置状态与结果摘要，比一张红色警告截图更利于长期维护。

浏览器权限会直接影响 WebRTC 候选。若站点没有麦克风或摄像头权限，浏览器可能不收集本地接口候选；一旦授权音视频，候选收集范围可能扩大。因此，在权限前后分别测试 WebRTC，才能观察到候选列表的变化。不要因为权限未授予时页面无候选，就认为不存在 WebRTC 暴露途径，这是把“未测量”当成了“已保护”。同理，无痕窗口不改变网络路由，不能当作防泄漏措施。

IPv6 应按需求明确处理：需要完整双栈保护时，选择并配置支持 IPv6 的隧道，核对实际路由与防火墙；若产品仅支持 IPv4，则确认它对 IPv6 有什么阻止或旁路策略。仅添加一条默认路由不保证所有应用和断线状态都受保护。全局关闭 IPv6 也可能影响兼容性，应先理解客户端能力并保留可恢复的配置，再分别验证正常、重连和断线状态。

断线恢复验收应包含“kill switch”策略。若某个 VPN 声称断线后阻止所有外发流量，则测试网络中断时 DNS 查询是否也一并失败，而不是回退到原网络解析器。有些实现只切断 IPv4 TCP，却允许 IPv6 或 DNS 继续走原线路，这种“部分保护”会留下观察窗。可以通过分别触发断线事件，观察 HTTP、DNS 和 IPv6 请求的行为来确认。

检测结果中的“未命中”不等于“安全”。如果 IPv6 因为网络不支持而显示无法连接，只能标记为“未确认”，不能解读为“已确认无 IPv6 泄漏”。一条路径只有在测试发出且结果符合预期后，才能称为本次验证通过。每次测量都应注明测试条件，例如浏览器版本、代理模式、VPN 协议和网络环境，为后续复现提供依据。

在更复杂的环境里，诸如 CGNAT 可能改变公共出口与内部地址的对应关系，此时可参考 公共 IP 与 CGNAT 状态检查 了解 NAT 层级；而某些安全检测工具会把正常现象误报为 VPN 或代理特征，可参考 VPN 与代理检测的误报分析 进一步判断工具输出。结合这些资料，能减少由于地址类型或检测逻辑造成的误判。

最终，把排查结果整理成一套验收记录：预期路径是否清晰，每一类流量在正常、重连、断线三种状态下是否符合预期，异常项是否已定位到具体设置。这样得出的结论——“在当前条件和测试范围内，已观察到的网络路径符合预期”——比任何一次性绿色标记都更有价值。