VPN 是否安全，不能只看客户端有没有显示“已连接”。连接建立后，网页请求、DNS 解析、IPv6 查询、WebRTC 候选地址以及系统后台服务，可能分别采用不同的网络路径。即使出口地址已经改变，DNS 请求仍可能交给本地运营商；即使 DNS 没有泄漏，浏览器的 WebRTC 也可能暴露本地网络接口。安全检查的重点，是确认这些环节是否都符合你的预期。
本文将 DNS 泄漏、IPv6 泄漏和 WebRTC 暴露分开说明，并给出一套可以在 Windows、macOS、Android、iOS 和 Linux 上复现的检查流程。你不需要只依赖某个检测页面的绿色提示，而应在连接前、连接后、切换线路后分别观察结果，再根据客户端开关、系统 DNS、浏览器设置和 Kill Switch 的状态完成修复。
VPN安全吗？DNS泄漏检测与修复方法
DNS 泄漏到底是什么
DNS 的作用是把域名转换成 IP 地址。当你打开一个网站时，设备通常先向 DNS 服务器询问目标域名对应的地址，然后再建立实际连接。启用 VPN 后，理想状态是 DNS 查询也沿着受保护的隧道发送，并由 VPN 服务端指定的 DNS 处理。DNS 泄漏则表示设备虽然改变了部分网络出口，但域名查询仍然通过本地网络、运营商 DNS、路由器或其他未预期的解析通道完成。
DNS 泄漏不一定意味着网页内容已经明文暴露，也不一定会让每个网站都出现异常。它更主要影响访问记录的可见范围、地区解析结果和隐私边界。例如，系统可能把国内域名交给本地 DNS，把国外域名交给 VPN DNS；也可能因为分流规则，只让浏览器流量进入隧道，却让系统服务继续使用默认网络。这样的配置未必是错误，但必须是你主动选择的结果，而不是客户端连接后无意形成的状态。
4
重点检查环节
3
常见泄漏类型
6
建议复核场景
1
每次只改一项
常见的泄漏来源包括客户端没有接管 DNS、系统手动设置了固定 DNS、IPv6 仍然绕过隧道、代理模式只覆盖浏览器、网络切换后旧解析仍被缓存，以及第三方安全软件重新接管了 DNS。某些客户端还会提供“自动选择 DNS”“按规则分流”或“允许局域网访问”等选项，这些选项改变的不是同一件事，排查时需要逐项记录。
DNS、IPv6 与 WebRTC 的区别
DNS 泄漏关注的是“域名由谁解析”。IPv6 泄漏关注的是“IPv6 流量是否有一条未经过隧道的路径”。WebRTC 暴露关注的是浏览器在建立实时通信连接时，是否把本地地址、局域网接口或其他候选地址提供给网页脚本。三者可能同时出现，也可能只有其中一种出现，因此检测页面显示的字段要看清楚。
| 检查对象 | 主要看什么 | 常见原因 | 修复方向 |
|---|---|---|---|
| DNS 泄漏 | 检测结果中的 DNS 服务商和地区 | 客户端未接管 DNS、系统固定 DNS、分流设置 | 开启 VPN DNS 或受保护 DNS，清理旧配置 |
| IPv6 泄漏 | 是否出现未预期的 IPv6 地址 | 服务或客户端没有覆盖 IPv6 | 启用 IPv6 隧道，或在明确了解影响后暂时关闭 IPv6 |
| WebRTC 暴露 | 浏览器页面能否读取本地或公网候选地址 | 浏览器实时通信接口直接访问网络 | 调整浏览器 WebRTC 策略或使用合适的隐私扩展 |
| 代理范围 | 浏览器、终端和应用是否走同一线路 | 仅设置了浏览器代理，系统流量未覆盖 | 核对 VPN 模式、应用代理和规则分流 |
需要特别注意的是，检测页面显示的 DNS 服务商不一定必须与 VPN 品牌名称完全一致。部分服务会使用上游解析服务、区域 DNS 或自建解析集群，页面可能显示实际处理查询的基础设施名称。判断是否异常时，应结合客户端说明、连接地区和断开 VPN 后的基线结果。如果连接后仍稳定显示你本地宽带运营商的 DNS，而客户端没有说明这是预期行为，就值得继续排查。
不要只问“有没有泄漏”，还要问“当前出现的 DNS、IPv6 和 WebRTC 地址是否都在我的配置预期内”。
检测前先建立基线
直接连接 VPN 后测试，往往很难判断哪些结果是变化，哪些结果本来就存在。更稳妥的做法是先断开 VPN，关闭其他代理工具，并在当前网络下记录一次基线。记录内容包括出口 IP、检测页面列出的 DNS 服务商、是否出现 IPv6 地址，以及浏览器 WebRTC 检测到的地址类型。记录不需要公开，也不要把完整地址和账户信息发布到公共平台。
建立基线时，尽量保持浏览器、网络连接和检测页面不变。先使用一个常规 DNS 泄漏检测页面观察结果，再使用 IPv6 检测和 WebRTC 检测分别复核。不要在同一轮测试里同时更改浏览器扩展、系统 DNS 和客户端模式，否则即使结果发生变化，也无法确定是哪一项设置起了作用。
- ✅ 先断开 VPN，记录本地网络的 DNS 和出口地址
- ✅ 关闭其他代理客户端，避免多个虚拟网卡同时工作
- ✅ 在同一浏览器中分别测试 DNS、IPv6 和 WebRTC
- ✅ 连接后等待网络状态稳定，再进行第二次测试
- ❌ 不把订阅链接、账户信息或完整检测截图公开
- ❌ 不用一次检测结果代表所有网络和所有应用
检测工具本身也可能使用缓存、脚本权限或浏览器扩展，因此页面没有显示结果时，不要马上认为系统没有 DNS。可以先刷新页面、允许必要的脚本执行，并换一个可信的检测页面进行交叉验证。检测期间还应避免浏览器开启严格的脚本拦截模式，否则 WebRTC 项目可能只是被阻止读取，而不是已经完成网络层面的修复。
动手检测与结果记录
下面是一套适合桌面端和移动端的操作顺序。不同客户端的按钮名称可能不同，但判断逻辑基本一致。每次只改变一项设置，测试结束后写下结果，能够显著减少反复试错。
- 断开 VPN，关闭系统代理和其他代理客户端，记录出口 IP、DNS 结果、IPv6 状态与 WebRTC 地址。
- 打开 VPN 客户端，选择一个稳定线路，确认系统出现 VPN 连接提示，再等待网络恢复。
- 重新打开 DNS 检测页面，观察 DNS 服务商、地区和地址数量是否发生符合预期的变化。
- 单独打开 IPv6 检测页面，确认是否出现未被客户端说明覆盖的 IPv6 地址。
- 在浏览器 WebRTC 检测页面中查看本地地址、私有地址和公网候选地址，不要只看最终的“安全”或“存在风险”结论。
- 断开后重新连接另一条线路，再测试一次，排除单个节点配置异常。
如果 DNS 检测显示多个地区或多个服务商，不必立即认定所有结果都是泄漏。有些客户端会同时配置多个解析服务器，也可能因 IPv4 和 IPv6 使用不同 DNS 而出现多组结果。真正值得警惕的是：断开 VPN 和连接 VPN 后，DNS 结果几乎完全相同；或者检测明确显示本地运营商，而客户端声称已经启用隧道 DNS。
如果只有 IPv6 地址暴露，说明问题可能集中在 IPv6 路由，而不是所有流量都绕过了 VPN。可以先查看客户端是否提供“阻止 IPv6”“IPv6 防泄漏”或“通过隧道处理 IPv6”的选项。若没有相关选项，临时关闭系统 IPv6 可以作为排错手段，但这可能影响依赖 IPv6 的网络、局域网设备和部分应用，不建议在不了解影响的情况下长期修改。
从 VPN 客户端开始修复
客户端是最优先检查的位置，因为它通常同时管理虚拟网卡、路由、DNS 和断线保护。进入设置后，寻找 DNS 防泄漏、使用 VPN DNS、阻止 IPv6、全局模式、系统代理和 Kill Switch 等选项。不要只凭选项名称判断含义，部分客户端的“增强隐私”可能会改变局域网访问或分流行为，启用后要重新测试本地打印机、文件共享和办公系统是否仍能使用。
如果使用服务商官方客户端，优先采用客户端提供的自动 DNS 和防泄漏设置，避免在系统中手动填写一组固定地址后与客户端规则冲突。如果使用 Clash Verge、sing-box、Shadowrocket 等兼容客户端，则要确认订阅配置中的 DNS 模式、Fake-IP 或 Redir-Host 行为、IPv6 开关和路由规则彼此匹配。不同内核对 DNS 劫持、分流和系统代理的实现不同，不能把一个客户端的配置习惯原样复制到另一个客户端。
Kill Switch 的作用是：VPN 隧道意外断开时，阻止指定范围的流量继续通过普通网络发送。它不是 DNS 防泄漏的替代品，也不等于浏览器隐私设置。开启后，应测试主动断开、切换线路和网络从 Wi-Fi 切换到移动数据等场景，确认应用是暂时无网络，还是悄悄回落到本地连接。若你依赖局域网设备，注意选择“仅保护外网”或类似的适合当前环境的模式。
系统 DNS 与浏览器设置
客户端设置正确但检测仍异常时，再检查操作系统。Windows 可能保留网络适配器中的手动 DNS、虚拟网卡优先级或旧的代理设置；macOS 可能在 Wi-Fi 服务中保存自定义 DNS；Linux 则可能由 NetworkManager、systemd-resolved、桌面环境或本地代理共同管理解析。移动设备上，私人 DNS、始终开启的加密 DNS、工作配置文件和其他安全应用也可能接管查询。
排查时建议先恢复网络服务的自动 DNS，再重新连接 VPN。修改后需要清理 DNS 缓存或重启相关网络服务，随后关闭并重开浏览器。不同系统的缓存层不完全相同，浏览器内部还可能保留自己的连接池，因此仅仅刷新一个页面不一定能立刻反映新设置。若你所在的办公或校园网络要求指定 DNS，不要直接删除配置，应先确认 VPN 是否支持在隧道内继续使用该解析服务。
浏览器方面，WebRTC 是单独的检查项。某些浏览器会允许网页通过实时通信接口发现网络候选地址，即使普通页面流量经过代理，也可能看到本地接口信息。可以在浏览器隐私设置中限制 WebRTC 暴露，或使用可信的隐私扩展；但扩展本身也会影响视频会议、语音通话和浏览器内实时功能。修改后要用同一检测页面复测，并确认常用会议服务仍能正常建立连接。
| 现象 | 优先检查 | 不要先做什么 |
|---|---|---|
| DNS 仍显示本地运营商 | 客户端 DNS 开关、系统手动 DNS、分流规则 | 不要立刻更换大量线路 |
| 只有 IPv6 地址异常 | 客户端 IPv6 防护与系统 IPv6 路由 | 不要把所有 DNS 设置反复重置 |
| WebRTC 显示本地地址 | 浏览器 WebRTC 策略和扩展权限 | 不要仅凭网页出口 IP 下结论 |
| 断线后网页仍能访问 | Kill Switch 范围、系统代理回落和应用分流 | 不要把客户端状态图标当作保护证明 |
修复后如何确认真的生效
修复不是看到一次结果变化就结束。首先重新连接当前线路，检查 DNS、IPv6 和 WebRTC；然后主动断开 VPN，观察 Kill Switch 是否按预期阻止受保护流量；接着切换 Wi-Fi、移动热点或其他网络，再重复检测。最后重启设备或客户端，确认设置不会因为启动顺序、网络变化或系统休眠而失效。
同时要验证应用范围。浏览器通过代理访问正常，不代表命令行、邮件客户端、游戏启动器或后台同步服务也使用相同路径。桌面端应分别测试浏览器与终端；移动端应检查目标应用是否被加入分流、排除列表或省电限制。对于需要长期保持连接的应用，Kill Switch 和后台运行权限尤其重要，否则系统暂停客户端后，网络可能回落到普通连接。
建议保存一份简短的个人检查记录：使用的客户端、连接模式、DNS 模式、IPv6 状态、WebRTC 结果，以及在不同网络下是否一致。不要保存订阅凭据，只记录设置名称和现象。以后升级客户端、导入新订阅或更换浏览器后，按这份记录重新复核，就能更快发现默认设置是否发生变化。
连接后 DNS 与 IPv6 没有出现未预期的本地路径，WebRTC 暴露符合浏览器设置，VPN 断开时受保护流量不会悄悄回落，并且常用应用的网络范围与自己的分流计划一致。
常见问题
检测到本地 IP 就一定是泄漏吗？
不一定。WebRTC 页面可能显示局域网私有地址，这与公网出口地址不是同一个概念；某些浏览器也会为了建立实时通信而展示接口候选。需要结合检测页面的字段、浏览器设置和你的隐私目标判断。若出现未预期的公网地址，或断开 VPN 与连接 VPN 后结果没有任何变化，就应进一步检查。
DNS 检测显示多个服务商正常吗？
可能正常，也可能需要排查。多组结果可能来自多个上游解析器、IPv4 与 IPv6 分开解析，或客户端的备用 DNS。重点是这些服务商是否属于你的预期路径，以及连接 VPN 后是否仍固定显示本地运营商。若无法确认，可以暂时关闭自定义 DNS、IPv6 和复杂分流，只保留客户端默认保护，再做一次基线对比。
只修改浏览器设置就够了吗？
只够解决浏览器层面的 WebRTC 暴露，不能自动修复系统 DNS、IPv6 路由或其他应用的网络路径。浏览器设置应与 VPN 客户端和操作系统配置一起验证。尤其是终端、后台同步和移动应用，它们可能完全不使用浏览器代理。
Kill Switch 开启后无法上网，是不是设置失败？
不一定。Kill Switch 的设计就是在隧道不可用时阻止受保护流量，避免流量回落到普通网络。先确认 VPN 是否已成功连接、客户端是否被系统省电策略暂停，以及 Kill Switch 是否设置为保护全部应用。如果本地网络和外网都被阻断，再根据客户端说明调整为适合当前场景的模式，并重新测试断线行为。
DNS 泄漏检测的价值，不在于追求某个页面上的单一“通过”标记，而在于建立可重复的验证流程：先做基线，再连接测试；分别检查 DNS、IPv6 和 WebRTC；每次只改一项设置；最后通过断线、换网和重启验证保护是否持续。这样即使更换客户端、线路或浏览器，也能快速判断问题出在解析、路由、浏览器接口还是应用分流。