VPN安⁠全吗？DNS与WebRTC泄漏自查修复指⁠南

先分清三类泄漏分别暴露什么

DNS 是把域名转换为 IP 地址的解析系统。当浏览器访问一个网站时，设备通常要先查询对应域名。如果 VPN 已经改变了网络出口，但 DNS 查询仍交给本地宽带运营方、公共 Wi-Fi 路由器或系统默认 DNS，就可能暴露正在解析的域名。DNS 泄漏不一定会直接显示你的完整浏览记录，但会让第三方看到部分访问目标，并可能导致解析结果与 VPN 出口地区不一致。

WebRTC 是浏览器支持实时音视频通信的一组技术。为了让浏览器建立点对点连接，它可能收集网络接口地址、局域网地址或通过特定候选信息推断公网出口。是否暴露、暴露哪些地址，取决于浏览器版本、操作系统、权限、网站脚本和客户端的代理接管方式。仅开启浏览器 HTTP 代理时，WebRTC 的处理方式尤其值得检查。

IPv6 泄漏发生在客户端只接管 IPv4，而设备或网络仍通过 IPv6 访问目标时。此时网页可能同时看到 VPN 的 IPv4 出口和本地网络的 IPv6 地址。关闭 IPv6 并不是所有设备上的最佳方案；更重要的是确认客户端是否支持并正确接管 IPv6，以及断线时是否有规则阻止流量绕过隧道。

检测前先建立可比较的基线

检测时最容易出现的错误，是只连接 VPN 后测试一次，却没有记录未连接时的结果。建议先关闭客户端，使用同一台设备、同一个网络和同一个浏览器，记录普通连接下显示的公网 IPv4、IPv6 状态、DNS 服务商以及浏览器是否能发现局域网地址。随后关闭网页标签，连接 VPN，再用相同条件重新测试。这样才能区分“网络本来就有的信息”和“连接后仍然暴露的信息”。

测试过程中不要同时开启两个 VPN 或代理客户端，也不要在不同网络之间来回切换。Windows、macOS、Android、iOS 和 Linux 的系统网络栈不同，浏览器扩展代理、系统代理、虚拟网卡模式和规则分流也会产生不同结果。若使用 Clash Verge、sing-box 或 Shadowrocket 等兼容客户端，应确认订阅导入后实际启用的是哪种运行模式，而不是只看配置文件已经成功加载。

如何判断 DNS 是否泄漏

连接 VPN 后打开可信的 DNS 检测页面，执行标准或扩展检测，观察返回的 DNS 服务器所属网络、国家或地区。若结果中仍大量出现本地网络运营方的 DNS，或者 DNS 所在地区与当前 VPN 出口明显不符，就需要进一步检查。少数检测站会显示缓存结果、浏览器预取结果或网络中的公共 DNS，这些信息不能脱离测试环境单独下结论。

为了确认结果，先刷新 DNS 缓存，再完全退出浏览器并重新打开。Windows 可以在命令提示符中执行 ipconfig /flushdns；macOS、Linux 和移动设备应优先使用系统提供的网络重连、飞行模式切换或重启方式，不要随意执行来源不明的命令。若重连后结果仍稳定显示本地 DNS，检查客户端是否启用了“使用 VPN DNS”“防止 DNS 泄漏”或类似选项。

如何判断 WebRTC 是否暴露地址

使用支持 WebRTC 检测的页面时，分别记录普通连接和 VPN 连接下显示的地址类型。需要区分公网出口地址、局域网地址和候选地址：显示 VPN 节点的公网地址通常是预期结果；显示本地路由器分配的私有地址，说明浏览器仍能识别本地接口，但不必然等于公网身份暴露；显示未启用 VPN 时的公网地址，则需要重点处理。

WebRTC 检测也可能受到浏览器权限、网站脚本、mDNS 保护机制和代理类型影响。一个页面没有发现地址，不代表所有网站都无法获取信息。更稳妥的做法是更新浏览器，检查摄像头和麦克风权限，关闭不需要的实时通信权限，并在不同浏览器中复查。不要为了“检测通过”而安装来历不明的扩展，因为扩展本身可能读取浏览数据。

先从 VPN 客户端和协议模式修复

修复 DNS 泄漏时，第一步不是手动把 DNS 改成某个公共地址，而是确认客户端是否能让 DNS 请求跟随隧道发送。官方客户端通常会提供防 DNS 泄漏、私有 DNS、始终使用 VPN DNS 或类似选项。打开后重新连接，并检查系统网络详情中是否仍使用本地路由器提供的解析地址。

如果使用第三方客户端，必须理解“系统代理”和“虚拟网卡”不是一回事。Clash Verge 的系统代理主要影响遵循系统代理设置的应用；浏览器和部分桌面应用可能会遵循，但某些独立程序、DNS 服务和系统组件未必如此。sing-box 的 TUN 模式更接近系统级流量接管，但仍需要正确配置 DNS 路由、FakeIP 或真实 IP 模式，以及局域网和本地服务的例外规则。Shadowrocket 在 iOS 上也需要检查全局、配置规则和 DNS 设置是否互相匹配。

协议本身也会影响接管范围。WireGuard 通常以系统 VPN 接口承载流量；Shadowsocks、VMess、Trojan 和 Hysteria2 更多属于代理生态中的协议或传输方案，能否覆盖全部应用，取决于客户端是否提供 TUN、虚拟网卡或系统 VPN 能力。只在浏览器中填写代理地址，不能自动保护其他应用，也不能保证 WebRTC 和系统 DNS 都沿用同一条路径。

Kill Switch 的作用是在隧道中断、节点切换或客户端退出时阻止流量回到普通网络。它并不是“连接后自动隐身”，而是断线保护机制。启用后应实际测试：连接 VPN，打开一个网页或持续网络任务，然后主动断开客户端，观察网络是否停止；重新连接后再确认访问是否恢复。测试完成后，也要确认局域网打印机、公司内网或本地开发服务是否需要加入允许列表。

• ✅ 优先使用客户端内置的防 DNS 泄漏与 Kill Switch 选项。
• ✅ 使用第三方客户端时确认是系统代理还是 TUN、虚拟网卡模式。
• ✅ 检查 DNS 路由是否与代理出站路径一致，避免 DNS 单独直连。
• ✅ 节点切换后重新检查 IPv4、IPv6、DNS 和 WebRTC。
• ❌ 不要把浏览器代理设置当成整台设备的完整保护。
• ❌ 不要同时启动多个网络接管工具，避免路由和 DNS 互相覆盖。

按设备完成实际修复

Windows

Windows 上先确认客户端以系统 VPN 或虚拟网卡方式运行，再检查网络适配器的 IPv4 和 IPv6 状态。若客户端明确支持 IPv6，应优先开启并测试；若不支持，可以在当前网络适配器中临时关闭 IPv6，重连后重新检查。关闭 IPv6 会影响部分本地网络和应用，不建议在不了解网络需求时永久修改。

浏览器方面，更新 Chrome、Edge 或 Firefox，检查 WebRTC 相关权限和扩展。不要仅依赖代理扩展，因为扩展通常只处理浏览器请求，不能替代系统 VPN。完成设置后执行 DNS 缓存刷新，重启浏览器，再做一次完整检测。

macOS

macOS 用户应查看当前网络服务、VPN 配置和 DNS 服务器列表。若使用官方客户端，检查是否启用连接后自动使用 VPN DNS、断线阻止网络或类似保护。若使用兼容客户端，确认系统代理开关与客户端模式一致，并留意浏览器、终端和其他应用是否采用不同的网络路径。

macOS 的隐私权限也会影响 WebRTC。浏览器不需要使用摄像头和麦克风时，可以在系统隐私设置中收回权限。修改网络设置后，建议断开 Wi-Fi 或有线网络再重新连接，避免旧 DNS 缓存和旧路由继续影响结果。

Android 与 iOS

Android 上要区分系统“私人 DNS”和 VPN 客户端的 DNS 处理。两者同时配置时，实际请求可能由系统策略、客户端 VPN 接口或应用自身决定。连接后检查 VPN 图标、始终开启 VPN 和阻止未使用 VPN 的连接等选项，并观察电池优化是否让客户端在后台被暂停。若应用支持分应用 VPN，确认浏览器确实包含在 VPN 应用范围内。

iOS 上，官方 VPN 配置、Shadowrocket 等客户端和浏览器的 WebRTC 行为都受系统权限与配置规则影响。确认客户端已获得添加 VPN 配置的授权，检查全局或规则模式是否把目标浏览器纳入范围，并关闭不需要的网站摄像头、麦克风权限。iOS 对底层接口的可见性有限，检测结果应结合客户端连接状态、DNS 设置和断线测试综合判断。

Linux

Linux 上常见的 DNS 管理组件包括 NetworkManager、systemd-resolved 和发行版自己的网络服务。使用 WireGuard、OpenVPN 或代理客户端时，要确认解析请求是否进入 VPN 接口，而不是仍由物理网卡上的默认解析器处理。若使用 sing-box 等工具的 TUN 模式，应检查路由表、DNS 规则和 IPv6 路由，避免只接管 TCP 而遗漏 UDP 或其他协议。

命令行工具可以帮助定位问题，但命令输出必须结合当前网络结构理解。查看路由、解析器和接口状态时，重点比较连接前后默认路由、DNS 服务器以及 IPv6 路由是否改变。不要因为某个测试命令没有返回结果，就直接认定不存在泄漏；有些网络会屏蔽探测包，但网页访问仍然正常。

用断线与切换测试验证修复是否有效

修复完成后不要只刷新一次检测页面。第一轮测试可以在 VPN 已连接时查看 DNS、IPv4、IPv6 和 WebRTC；第二轮测试切换到另一个节点，确认 DNS 解析和公网出口会随之变化，且没有重新出现本地运营商的 DNS。第三轮测试主动断开 VPN，检查 Kill Switch 是否阻止浏览器继续访问。最后重新连接，确认网络恢复且客户端没有因为后台限制而失效。

如果只有某个网站提示地址异常，不要立刻归因于 VPN 泄漏。网站可能使用 Cookie、账号登录、浏览器指纹或此前缓存的信息识别用户。可以使用无痕窗口清理缓存后复查，但无痕模式也不是匿名工具，它只是减少本地会话保存。真正有价值的是在多个检测页面、多个浏览器和不同网络条件下观察是否出现稳定、可重复的本地地址或 DNS。

还要检查应用级分流。规则模式下，浏览器可能通过 VPN，而邮件、游戏启动器或其他应用继续直连；也可能只有部分域名进入隧道。对于需要完整接管的场景，使用系统 VPN 或 TUN 模式通常更容易验证。对于需要本地服务正常运行的场景，则应明确哪些网段和域名允许直连，并在每次修改规则后重新测试。

常见问题

DNS 检测显示多个服务器，是不是一定泄漏？

不一定。多个服务器可能来自同一 VPN 服务商的不同解析入口，也可能是 IPv4 和 IPv6 同时启用造成的结果。需要查看这些服务器所属网络和地区，判断是否混入了本地运营商或当前物理网络的 DNS。若来源无法解释，关闭浏览器预取、刷新缓存并重新连接后再测。

WebRTC 显示局域网地址，是否代表公网真实地址已经暴露？

局域网私有地址与公网出口地址不是同一类信息。局域网地址通常只能说明浏览器识别到了设备接口，公网地址则更直接关联到网络出口。仍建议限制不必要的摄像头和麦克风权限、更新浏览器，并确认检测页面没有同时显示未连接 VPN 时的公网地址。

关闭 IPv6 就一定能解决 IPv6 泄漏吗？

关闭 IPv6 可以减少客户端不支持 IPv6 时的绕行机会，但它不是唯一方案，也可能影响本地网络和应用。更理想的做法是使用能够正确处理 IPv6 的客户端和模式。无论选择开启还是关闭，都要在修改后重新连接并检查 IPv6 是否仍能访问。

Kill Switch 开启后为什么本地网络仍然可用？

不同客户端对 Kill Switch 的定义不同。有些只阻止互联网流量绕过隧道，有些会允许局域网访问，有些则提供严格模式。应查看客户端说明和允许列表，分别测试公网网站、局域网设备以及 DNS 请求。若希望断线时完全停止外网访问，需要选择严格的断线保护模式。