VPN 泄露详解：如何真正测试 DNS、WebRTC 和 IPv6 泄露
VPN 泄露详解：DNS、WebRTC 和 IPv6 泄露（以及如何真正测试它们）
你的 VPN 应用显示已连接。这个词看起来像是一种保证，但它仅仅意味着你的设备已经与 VPN 服务器建立了一条加密隧道。它丝毫没有说明每一份能暴露身份的流量是否真的在走这条隧道。三种常见的故障模式——DNS 泄露、WebRTC 泄露和 IPv6 泄露——任何一种都可能在应用安静地亮着那个令人安心的绿色对勾时，暴露你的真实 IP 地址或浏览行为。
本指南做了三件单点泄露、只为卖 VPN 的页面从不会做的事。第一，它解释每种泄露背后的真实机制，让你明白为什么一条已连接的 VPN 仍可能出卖你。第二，它带你用免费、独立、无需信任任何厂商的工具进行自测。第三，它给出针对每种操作系统、浏览器和路由器的精确修复方法——以及确认修复确实生效的复测纪律。没有品牌推销，没有联盟链接，只讲原理。
VPN 泄露究竟是什么
泄露指的是本应通过加密隧道传输、却走了你普通互联网连接的任何流量，从而暴露了 VPN 本应隐藏的信息。本指南涉及的三种泄露会暴露两类不同的东西。DNS 泄露会把你查询过的网站暴露给你的 ISP（或者你不小心使用的那个解析器的运营方）。WebRTC 泄露和 IPv6 泄露则可能直接向你访问的网站暴露你的真实 IP 地址——也就是你在网上真实的位置与身份。
首先要明白最重要的一点：这是三个各有成因、各有修复方法的独立问题。竞争对手对此避而不谈，因为它不利于一键搞定的销售叙事，但这恰恰是问题的核心。你可以堵住 DNS 泄露，却仍然通过 WebRTC 泄露你的 IP；你可以在浏览器里加固 WebRTC，却仍然通过 IPv6 泄露。堵住其中一个，对另外两个毫无意义。这正是为什么一次真正的泄露测试每次都要把三者全部检查一遍。
每种泄露如何发生（机制）
DNS 泄露：逃出隧道的查询
在你的设备加载 example.com 之前，它会请求一个 DNS 解析器把这个名字翻译成 IP 地址。当 VPN 配置正确时，这个 DNS 查询会沿着隧道发往 VPN 控制的解析器。而当查询改走开放连接、发往你 ISP 的解析器（或路由器推送的解析器）时，就发生了 DNS 泄露。即便页面内容仍然走隧道，查询本身也会把你访问的每一个域名暴露给第三方——并把它和你的真实 IP 关联起来。
常见的罪魁祸首是：操作系统无视 VPN 的 DNS 设置、某个绕过隧道的硬编码解析器（比如手动设置的 8.8.8.8 或 1.1.1.1），或者把 DNS 路由到 VPN 之外的分流规则。在 Windows 上尤其要注意一个叫智能多宿主名称解析（smart multi-homed name resolution）的功能，它会同时从每一个网络接口发出 DNS 查询，并采用最先返回的那个答案——而最先返回的往往是你 ISP 的解析器。
WebRTC 泄露：浏览器主动交出你的 IP
WebRTC（Web 实时通信）是浏览器内置的技术，支撑着网页内的视频通话、语音聊天和点对点文件传输。为了让两个对等端直接相连，WebRTC 需要发现设备自身的 IP 地址。它通过 STUN 服务器来做到这一点——STUN 服务器会把它看到的公网 IP 回复给浏览器，同时它还会枚举本地网络地址。网页可以通过一个 JavaScript API 读取这些 ICE candidates——无需任何授权提示，也无需你点击任何东西。
让 WebRTC 即便在 VPN 正常工作时也很危险的关键在于：这种地址发现可能发生在浏览器加载普通页面所走的代理路径之外。网页最终可能看到操作系统认为真实的那个公网 IP——而它很可能是你的真实地址，而不是 VPN 的地址。WebRTC 泄露是一个浏览器问题。它无法靠 VPN 的 DNS 设置或断网开关来解决，这恰恰是为什么那些刚修好 DNS 泄露的人，会震惊地发现自己的 IP 仍然暴露在外。
IPv6 泄露：流量驶上了隧道从未铺设的路
许多 VPN 隧道只承载 IPv4 流量。如果你的 ISP 和家庭网络同时提供 IPv6 连接——这越来越成为默认情况——那么任何发往支持 IPv6 的目标的请求，都可能走你原生的 IPv6 连接，完全绕开只走 IPv4 的隧道。网站看到的是你的真实 IPv6 地址。VPN 从未碰过这部分流量，往往甚至根本没察觉，因为它一直只盯着 IPv4 这一侧。
这正是 IPv6 泄露如此悄无声息地常见的原因：什么都没坏，什么看起来都正常，VPN 还报告说连接成功。修复办法要么是在设备或网络上禁用 IPv6，要么是使用一款会明确为 IPv6 建立隧道、或在连接期间屏蔽 IPv6 的 VPN。指望你的服务商默默把它处理好并不是一种策略——你要亲自测试。
开始测试：免费工具以及如何解读结果
请使用独立的第三方工具，而不是你 VPN 服务商给你看的那个“你的 IP 已隐藏”页面——厂商有一切动机去报告成功。每一项测试都要在 VPN 已连接的状态下进行，使用你实际在用的同一个浏览器、同一台设备。作为基准，最好先在 VPN 关闭的状态下各跑一遍，这样你就知道自己真实的 IP 和 ISP 长什么样；然后打开 VPN，确认这些数值消失。
第 1 步——DNS 泄露测试
打开 dnsleaktest.com 并运行 Extended test（扩展测试）。它会加载一系列唯一的主机名，并报告是哪些 DNS 服务器解析了它们。一个干净的结果会显示属于你 VPN 服务商的解析器（或 VPN 所用的隐私解析器），而且关键是不会列出你 ISP 的名字，也不会出现你的真实所在国（如果你连接的是别处的服务器）。一个正在泄露的结果会显示你 ISP 的解析器，或者出现在你真实位置、本不该出现的服务器。ipleak.net 会在显示你 IP 的同时一并显示相同的 DNS 信息，方便交叉核对。
第 2 步——WebRTC 泄露测试
打开 browserleaks.com/webrtc。查看它通过 WebRTC 发现的 Public IP Address（公网 IP 地址）。一个干净的结果要么不显示任何公网 IP，要么只显示 VPN 服务器的 IP。一个正在泄露的结果会在 WebRTC 部分显示你的真实公网 IP，尽管页面头部（它使用普通的 HTTP 请求）显示的是 VPN 的 IP——这种不一致正是经典的 WebRTC 泄露特征。处于 10.x、172.16–31.x、192.168.x 范围内的本地地址，或 .local 的 mDNS 地址，通常无害；真正的危险是你真实的公网 IP 出现。
第 3 步——IPv6 及总体 IP 测试
打开 ipleak.net。它会在同一个页面上显示你的 IPv4 地址、任何 IPv6 地址以及你的 DNS 服务器。一个干净的结果只显示 VPN 的 IP（与你选择的国家相符），并且要么没有 IPv6 地址，要么显示一个同样属于 VPN 的 IPv6。一个正在泄露的结果会显示来自你 ISP 的 IPv6 地址，或者一对指向两个不同位置的 IPv4/IPv6。如果你看到一个真实的 IPv6 与一个 VPN 的 IPv4 并存，那就是一个教科书级的 IPv6 泄露。
一款隐藏了你 IPv4、却暴露了你 IPv6 的 VPN，并不是给了你一半的保护——对任何识别 IPv6 的网站来说，你就等于压根没用 VPN。
精确修复方法：按操作系统、浏览器和路由器划分
修复 DNS 泄露
在 VPN 应用里：启用任何“仅使用 VPN DNS”“DNS 泄露保护”或“屏蔽非 VPN DNS”的选项。许多应用默认开启此项，但第三方的 OpenVPN/WireGuard 配置往往没有。
Windows：禁用智能多宿主名称解析，它会把 DNS 分散到各个接口。在 Windows 专业版上，你可以把组策略中的“关闭智能多宿主名称解析”（Turn off smart multi-homed name resolution）设为“已启用”；否则更应选用一款会设置 DNS 并屏蔽其他解析器的 VPN 客户端。测试时，请从你的网络适配器中移除任何手动配置的公共 DNS（8.8.8.8、1.1.1.1）。
macOS / Linux：确保网络设置或
/etc/resolv.conf中没有硬编码任何绕过隧道的解析器；让 VPN 客户端来管理 DNS。在使用 systemd-resolved 的 Linux 上，确认 VPN 设置了域名路由，以便查询走它的解析器。路由器：如果你在路由器上运行 VPN，请把路由器的 DNS 设为 VPN 的解析器，并禁用任何 ISP 分配的 DNS。同时禁用会拦截或重定向 DNS 的路由器功能（某些“家长控制”或“DNS 重绑定保护”设置）。
修复 WebRTC 泄露（仅限浏览器）
Firefox：在地址栏输入
about:config，接受警告，搜索media.peerconnection.enabled，并将其设为false。这会完全禁用 WebRTC。如果你需要 WebRTC 来通话，就保持开启，但依靠一款能掩盖所发现 IP 的 VPN/扩展，然后复测。Chrome / Edge：没有内置开关可以彻底禁用 WebRTC。请注意，uBlock Origin 那个旧的“阻止 WebRTC 泄露本地 IP 地址”选项早在 2021 年就已从桌面扩展中移除，而且即便它当年存在，也只掩盖本地/局域网地址——它从未阻止真正会暴露你的公网 IP 泄露，所以它从来就不是人们以为的那种解决方案。现代 Chromium 已经使用 mDNS 来混淆本地 IP（你可以在
chrome://flags确认“Anonymize local IPs exposed by WebRTC”这个标志）。要控制公网 IP 的暴露，请使用一款专门的 WebRTC 控制扩展，然后用泄露测试来验证，因为不同扩展屏蔽得是否彻底各不相同。Safari：默认情况下 WebRTC 的暴露更为有限，但仍要测试。如果你不需要它，可以通过“开发”（Develop）菜单中的实验性/WebRTC 功能将其禁用。
现实考量：禁用 WebRTC 可能会让 Google Meet、浏览器版 Discord、Jitsi 等工具无法使用。如果你需要这些工具，更务实的做法是使用一款只交出 VPN IP、而不是直接关掉 WebRTC 的浏览器/扩展——并通过复测来确认。
修复 IPv6 泄露
最佳选择：使用一款明确提供 IPv6 泄露保护的 VPN（它会在连接期间屏蔽或为 IPv6 建立隧道）。打开该设置并复测。
Windows：在活动适配器上禁用 IPv6（网络适配器属性，取消勾选 Internet 协议版本 6），或使用 VPN 的 IPv6 屏蔽功能。当你停止使用一款无法处理 IPv6 的 VPN 时，记得重新启用它。
macOS：如果你的 VPN 无法为 IPv6 建立隧道，请在“系统设置”中把该网络服务的 配置 IPv6 设为 仅本地链路（或通过命令行设为 关闭）。
Linux：如果隧道只走 IPv4，请通过
sysctl按接口或全系统禁用 IPv6（例如net.ipv6.conf.all.disable_ipv6=1）。路由器：如果你在路由器上运行 VPN，请禁用路由器的 IPv6/WAN IPv6，这样网络上就没有任何设备能通过它泄露。对于整个家庭来说，这是最干净利落的修复方法。
为什么“已连接”的 VPN 仍会泄露
即便你已经三项测试全部通过一次，这种保护也并非永久——它是一种可能悄然失效的状态。以下这些时刻，正是“已连接”的 VPN 会安静地开始泄露的关头：
网络切换：从 Wi-Fi 换到以太网、切换接入点，或手机在 Wi-Fi 与蜂窝网络之间切换，都可能在 VPN 重新建立规则之前，瞬间把流量路由到隧道之外。
休眠与唤醒：笔记本从休眠中唤醒时，网络往往在 VPN 重连之前就先恢复了。在那几秒里，流量走的是裸连接——足够让后台应用带着你的真实 IP 向外通信。
重连与掉线：每当隧道掉线并重新拨号，都会有一个窗口期，除非有断网开关拦截，否则流量可能逃逸。
强制门户：酒店、机场和咖啡馆的 Wi-Fi 要求你在联网之前先加载一个登录页面。该页面按设计就是在 VPN 之外加载的，而某些配置在之后会一直处于泄露状态，直到你手动重连。
分流隧道：如果你把某些应用——或 DNS——排除在 VPN 之外，那这些排除项就是配置层面的泄露。请再三确认 DNS 没有被悄悄列入“绕过”名单。
IPv6 卷土重来：一次操作系统更新或网络重置，可能悄无声息地重新启用你此前禁用的 IPv6，毫无预警地重新打开那条通路。
断网开关与泄露保护设置——以及它们如何悄然失效
断网开关（kill switch）是应对掉线重连问题的安全网：当隧道中断时，它会阻断所有互联网流量，直到 VPN 恢复，从而在这段空隙里不让任何东西逃逸。内置的泄露保护（DNS 泄露保护、IPv6 屏蔽、网络锁定等功能）则强制让 DNS 和 IPv6 永远只走隧道。把两者都打开——它们能处理那些你无法手动盯防的故障窗口。
但要理解它们悄然失效的模式。断网开关只在应用检测到隧道中断时才会动作；如果隧道在技术上是连通的、但 DNS 或 IPv6 正绕着它泄露，断网开关看不到任何问题，也就什么都不会做。应用级的断网开关只保护 VPN 应用自身的流量，而非整个系统。某些断网开关在休眠/唤醒窗口期、或开机登录之前并不会生效。还有一种“防火墙式”的断网开关，在 VPN 关闭时会完全阻断流量，结果可能被误认为是断网，诱使人们把它关掉。教训是：断网开关能降低风险，但不能取代测试。证明你的设置有效的唯一凭证，就是一次通过的测试。
无害结果 vs. 真正的隐私失守
泄露测试页面上每一条陌生的条目，并非都是灾难。分清差别，能让你既不至于捕风捉影，也不会忽视真正的暴露。
无害：WebRTC 只显示本地/私有地址（10.x、172.16–31.x、192.168.x）或一个 mDNS 的
.local主机名。这些不会向网站暴露你的身份。无害：属于你 VPN 服务商或它所用隐私解析器的 DNS 解析器，即便它们与你的 VPN 服务器位于不同城市——服务商运营着成片的解析器集群。
无害：在你禁用 IPv6 之后压根没有任何 IPv6 地址。这正是目标，而非失败。
真正失守：任何测试显示出你的真实公网 IP（IPv4 或 IPv6）、你真实的城市/ISP，或在你刻意连接别处时却显示你的真实所在国。
真正失守：DNS 结果点名了你实际的 ISP，或者 IPv4 与 IPv6 解析到两个不同的位置。
真正失守：页面头部显示 VPN 的 IP，而 WebRTC 部分显示的却是你真实的那个——这种不一致本身就是泄露。
经验法则：当一个公网 IP 或你 ISP 的名字出现在不该出现的地方，那就是真正的失守。私有/本地地址和服务商自有的解析器只是噪音。
复测纪律：真正保护你的习惯
一次泄露测试是一张快照，而不是一纸证书。由于这种保护状态会在网络切换、休眠、重连和强制门户时被打破，测试只对你测试时所处的条件有意义。养成这个习惯：
每做完一项修复就复测一次——改一个设置，确认那个具体的泄露已堵住，再继续下一步。三项一起改、只测一次，会让你看不出究竟是哪个改动起了作用。
每次网络切换后复测——新的 Wi-Fi、切到蜂窝网络、插上以太网，或在强制门户登录之后。
在从休眠唤醒之后、以及一次 VPN 重连之后复测，因为这些是风险最高的窗口。
在操作系统和应用更新之后复测，更新可能悄悄重新启用 IPv6 或重置 DNS 行为。
每次都把三项测试一起跑——DNS、WebRTC 和 IPv6 相互独立，其中一项干净，并不能说明另外两项的任何情况。
实用结论
“已连接”是一个起点，而不是隐私的证明。用独立工具测试全部三种泄露——DNS 用 dnsleaktest.com，WebRTC 用 browserleaks.com/webrtc，IPv6 和你的总体 IP 用 ipleak.net。把它们当作三个独立的问题来对待：在操作系统或路由器层面强制使用 VPN DNS，在浏览器里压制 WebRTC，屏蔽或为 IPv6 建立隧道。打开你的断网开关和内置泄露保护，去守住那些你无法盯防的空隙，但永远不要盲目信任它们。然后在每次修复后、每次网络切换后复测。十分钟的测试，比任何服务商的营销页面都更能告诉你真实的暴露状况。
常见问题
什么是 VPN 泄露测试，我该怎么做？
VPN 泄露测试用于检查在 VPN 已连接时，是否有任何流量正逃出你的加密隧道，从而暴露你的真实 IP 地址或 DNS 查询。做法是：先连上 VPN，然后访问 dnsleaktest.com、browserleaks.com/webrtc 和 ipleak.net 等独立工具。如果其中任何一个显示出你的真实公网 IP、你的 ISP 或你的真实所在地，那你就有泄露。
DNS 泄露测试如何工作，怎样算通过？
DNS 泄露测试会加载一系列唯一的主机名，并报告是哪些 DNS 服务器解析了它们。如果解析器属于你的 VPN 服务商、且没有列出你自己的 ISP，那就算通过。如果出现了你 ISP 的解析器，或在你连接别处时却显示位于你真实位置的服务器，那就是没通过。
我该如何修复 DNS 泄露？
首先在 VPN 应用里启用“DNS 泄露保护”或“仅使用 VPN DNS”。在 Windows 上，还要禁用智能多宿主名称解析，并从适配器中移除任何手动设置的公共 DNS（如 8.8.8.8）。如果在路由器上运行 VPN，则把路由器的 DNS 指向 VPN 解析器并禁用 ISP 分配的 DNS，然后复测。
什么是 WebRTC 泄露，我的 VPN 能阻止它吗？
WebRTC 泄露是指浏览器的实时通信功能发现并向网页暴露了你的真实 IP 地址，即便 VPN 已连接也是如此。大多数 VPN 无法阻止它，因为这是一种浏览器行为，而非网络行为。在 Firefox 中，可在 about:config 里把 media.peerconnection.enabled 设为 false 来修复。Chrome 和 Edge 没有内置开关可禁用 WebRTC，所以请使用专门的 WebRTC 控制扩展并复测——别依赖 uBlock Origin 那个旧的本地 IP 开关，它已从桌面扩展中移除，而且本来就从未阻止过公网 IP 的暴露。
什么是 IPv6 泄露，我该如何在 VPN 上预防它？
IPv6 泄露发生在你那只走 IPv4 的 VPN 隧道无视 IPv6 流量时，使其走你的 ISP 连接并暴露你的真实 IPv6 地址。预防办法是在 VPN 中启用 IPv6 泄露保护，或在你的设备或路由器上禁用 IPv6。更改设置后，在 ipleak.net 上确认没有出现任何 ISP 的 IPv6 地址。
断网开关能防止 DNS 和 WebRTC 泄露吗？
不可靠。断网开关只在检测到隧道已掉线时才阻断流量，所以对于隧道仍连通时发生的 DNS 或 WebRTC 泄露，它什么都做不了。你需要单独的 DNS 泄露保护和浏览器端的 WebRTC 加固，而把断网开关作为应对重连和掉线的后备。
我应该多久做一次 VPN 泄露测试？
每次更改配置后都要测试，并在每次网络切换、休眠/唤醒周期、VPN 重连、强制门户登录，以及重大操作系统或应用更新之后复测。这些时刻中的每一个都可能悄悄重新打开一个泄露。每次都要把三项测试一起跑，因为 DNS、WebRTC 和 IPv6 是相互独立的问题。
