VPN安⁠全吗？DNS泄漏自查与隐⁠私防护方法

使用 VPN 后，浏览器可以正常打开网页，并不代表所有网络请求都已经按照预期经过加密隧道。DNS 请求、IPv6 连接、WebRTC 候选地址，以及客户端断线重连时短暂恢复的直连，都可能让本地网络或目标服务看到部分额外信息。这里所说的“泄漏”不是指 VPN 一定失效，而是指某类请求绕过了原本希望使用的连接路径。

判断 VPN 是否安全，不能只看客户端界面上的“已连接”。更可靠的做法是分别检查 DNS 解析服务器、出口地址、浏览器 WebRTC 行为、IPv6 状态和断线保护。检查时还要结合自己的使用场景：日常办公关注连接是否持续，支付场景关注登录环境是否稳定，公共 Wi-Fi 则更需要避免断线后自动恢复直连。

DNS 泄漏到底暴露了什么

DNS 的作用是把域名转换成 IP 地址。当你在浏览器中输入一个网址时，系统或浏览器通常要先查询对应的域名记录，才能建立后续连接。若 VPN 已经连接，但查询仍然交给本地宽带运营商、酒店网络或公共 Wi-Fi 提供的 DNS 服务器，那么这些网络可能看到你查询过哪些域名，即使网页正文随后通过 VPN 加密传输。

DNS 泄漏不一定会暴露完整的页面内容，也不一定会直接暴露账号密码，但域名列表本身可能反映访问目的。例如办公系统、云盘、邮件平台和支付服务的域名，都可能成为网络活动的侧面线索。对于需要减少本地网络观察范围的人来说，DNS 请求是否沿隧道发送，是连接检查中不可忽略的一环。

DNS 泄漏通常发生在几个位置。第一，客户端只设置了系统代理，却没有接管系统级 DNS，部分应用因此继续使用操作系统原来的解析路径。第二，客户端启用了分流规则，明确允许某些域名直连，相关 DNS 查询也可能按照直连策略处理。第三，系统同时启用了 IPv4 与 IPv6，而 VPN 只覆盖其中一套协议。第四，浏览器开启了自己的安全 DNS 功能，查询请求可能由浏览器单独发送，不再遵循客户端的默认处理。

这里需要注意，看到某个熟悉的公共 DNS 名称，并不能单独证明存在泄漏。部分客户端会把 DNS 请求转发到远端解析器，再通过 VPN 隧道传送；检测页面显示的可能是服务商或出口地区的解析服务器，而不是设备当前物理位置的运营商 DNS。判断重点应放在请求是否经过预期隧道、检测结果是否随 VPN 开关变化，以及多个测试条件下结果是否一致。

检测前先固定测试条件

很多 DNS 检测结果之所以难以解释，是因为测试过程中同时切换了浏览器、线路、网络和代理模式。一次只改变一个条件，才能知道结果来自哪里。建议先关闭不必要的浏览器标签页、云盘同步、系统更新和其他网络工具，再记录当前网络环境。

1. 连接一个平时会使用的网络，例如家庭网络、办公网络或公共 Wi-Fi，并先确认普通网页可以打开。
2. 退出其他 VPN、代理客户端、加速器和虚拟网卡工具，避免多个程序同时修改系统路由与 DNS。
3. 记录 VPN 未连接时的检测结果，包括出口地址、DNS 服务商和 IPv6 是否可用。
4. 只启动一个客户端，连接目标线路后等待状态稳定，再进行第二次检测。
5. 切换到另一条同地区或不同地区线路，观察检测结果是否随连接变化，而不是只看一次页面。
6. 断开 VPN 后重新连接，检查重连期间是否出现短暂的直连访问。

测试页面显示多个 DNS 服务器并不必然是问题。大型解析服务可能返回多个地址，家庭网络也可能通过转发器使用上游 DNS。更值得关注的是检测结果是否包含当前本地运营商、酒店网络或办公网络的解析信息。如果 VPN 连接后仍稳定出现这些服务器，而客户端又没有明确说明采用本地 DNS 分流，那么就应继续排查。

动手完成一次 DNS 与出口检查

下面是一套不依赖特定客户端名称的操作流程。Windows、macOS、Android、iOS 和 Linux 的菜单位置不同，但检查思路相同：先看未连接状态，再看连接状态，最后故意制造一次断线，验证客户端是否按照设定阻止直连。

检查系统与浏览器的 DNS

在 Windows 中，可以查看当前网络适配器的 DNS 配置，也可以使用命令行查询域名解析结果；macOS 和 Linux 则可从网络设置、系统解析服务或终端命令中确认当前解析器。Android 与 iOS 通常不会把完整 DNS 路径展示在同一页面，应该结合 VPN 配置状态、客户端日志和公开检测页面判断。

浏览器的“安全 DNS”“加密 DNS”或类似选项需要单独检查。它的目标是保护浏览器到 DNS 服务之间的查询，但如果客户端没有接管这类请求，浏览器可能直接通过本地网络访问指定的解析服务。此时它未必属于传统意义上的明文 DNS，但仍可能绕过 VPN 的统一策略。日常使用中，应选择一种清晰的方案：要么由 VPN 客户端统一处理 DNS，要么明确配置浏览器的安全 DNS 也经过隧道，不要让两套策略互相覆盖。

检查 IPv6 与 WebRTC

IPv6 是独立于 IPv4 的网络协议。部分 VPN 客户端可以同时处理两者，部分客户端则只接管 IPv4。若网站通过 IPv6 直接连接，本地网络分配的 IPv6 地址可能被目标服务看到。检测时应确认 IPv4 和 IPv6 的出口是否都符合预期；如果客户端没有 IPv6 支持，可以在系统或网络适配器中暂时关闭 IPv6，作为排查手段，而不是在不了解企业网络配置的情况下长期修改生产设备。

WebRTC 是浏览器用于实时音视频通信的一组技术。建立通话时，浏览器会收集候选网络地址，以便判断双方如何连接。现代浏览器通常会通过 mDNS 隐藏部分局域网地址，但具体行为仍受浏览器版本、权限、扩展和客户端模式影响。使用浏览器检测页面时，应查看它列出的候选地址是否包含不希望暴露的本地网段或真实公网出口。不要为了测试而向陌生页面授予摄像头、麦克风或屏幕共享权限。

如果主要需求是办公和支付，最稳妥的做法不是盲目安装多个隐私扩展，而是使用可信浏览器、限制 WebRTC 权限，并在客户端启用完整流量接管后复测。浏览器扩展可能改变代理规则，也可能与企业安全软件冲突；安装前应查看权限范围、更新来源和是否能够随时停用。

未连接：记录 DNS、IPv4、IPv6 与 WebRTC 结果
已连接：再次记录上述项目
换线路：确认出口与解析路径随线路改变
断线：确认访问是否被阻止，而不是悄悄恢复直连

常见 DNS 泄漏修复方法

修复前先保存当前设置，逐项修改并在每次修改后重新检测。不要同时更换 DNS、代理模式、协议和浏览器扩展，否则即使问题消失，也很难知道真正有效的是哪一项。

优先检查客户端的 DNS 选项

许多客户端会提供“远程 DNS”“DNS 通过代理”“Fake-IP”“增强模式”或类似选项。名称因核心和版本而不同，不能只按字面判断。需要查看客户端文档，确认 DNS 请求是否由客户端接收、是否通过隧道发送，以及分流规则是否允许本地解析。若使用 Clash Verge、sing-box 或 Shadowrocket 等兼容客户端，应特别注意配置文件中的 DNS、tun、route、fake-ip 与直连规则是否相互匹配。

启用 TUN 模式后，客户端通常可以接管更多系统流量，但这不代表所有应用都自动遵循同一套 DNS 规则。某些应用自带解析机制，某些浏览器会单独启用安全 DNS，企业软件也可能使用固定服务器。修复后，应分别测试浏览器、办公软件和需要登录的应用，不要只验证一个网页。

谨慎处理分流与本地 DNS

分流的优点是让本地服务、打印机、局域网设备或不需要代理的站点保持直连，减少不必要的绕行。但分流规则越复杂，越容易出现“网页走代理、DNS 走本地”或“域名判断依赖本地解析”的情况。可以先切换到规则较简单的模式完成测试，再逐步恢复自定义规则。

如果办公网络要求使用内部 DNS 访问企业域名，不应为了追求检测页面全部显示远端解析器而直接删除企业配置。更合理的方式是把企业内部域名保留在企业解析路径，将普通公共域名交给客户端的远程 DNS，并让企业管理员确认这种分流符合安全政策。支付和办公设备尤其不适合随意使用来源不明的 DNS 服务。

清理系统中的冲突配置

系统中残留的旧 VPN、虚拟网卡、代理脚本和安全软件，可能在客户端退出后仍修改 DNS 或路由。排查时可以暂时停用不必要的网络工具，重启网络适配器，再重新连接客户端。若问题只在睡眠唤醒、切换 Wi-Fi 或从有线网络改为移动热点后出现，应把重点放在网络切换后的 DNS 缓存、路由恢复和客户端重连逻辑。

DNS 缓存会让旧结果在一段时间内继续被使用，因此修改后立即刷新页面，不能完全说明新配置已经生效。可清理系统 DNS 缓存、重启浏览器，并等待客户端重新建立连接。清缓存不会修复路由问题，它只是帮助测试结果更快反映当前配置。

• ✅ 先确认只有一个客户端负责系统代理或 TUN 接管
• ✅ 修改 DNS 后，同时检查 IPv4 与 IPv6 的解析路径
• ✅ 浏览器启用安全 DNS 时，确认它不会绕过客户端策略
• ✅ 切换 Wi-Fi、移动热点或睡眠唤醒后重新检测
• ❌ 不要把陌生检测页面要求安装的证书或扩展当成修复方案
• ❌ 不要仅凭 DNS 服务商名称判断一定安全或一定泄漏

Kill Switch 与断线保护应该怎样配置

Kill Switch 通常译为网络锁或断线保护。它的目标是在 VPN 隧道中断、客户端核心退出或线路重连期间，阻止指定流量直接从普通网络发出。对于公共 Wi-Fi、远程办公和处理敏感账号的设备，这项功能比单纯显示“自动重连”更重要，因为自动重连可能存在短暂的无隧道窗口。

不同客户端的实现方式并不完全相同。有的只阻止代理流量，有的会修改系统防火墙规则，有的只在 TUN 模式下生效，还有的允许局域网流量继续通过。启用后应阅读说明，确认它保护的是全部网络、指定应用，还是只保护已经纳入代理规则的连接。如果允许局域网访问，打印机、路由器管理页和企业内网可能仍保持可用，但这也意味着保护范围不是完全封闭。

配置完成后可以按以下方式验证：先连接 VPN，打开一个普通网页；再在客户端中断开线路或暂时关闭核心；观察网页是否停止加载、DNS 查询是否停止，以及系统是否自动恢复普通网络；重新连接后，再确认访问恢复。不要在正在进行的支付、文件上传或视频会议中进行测试，应使用无关的网页和测试账号，避免造成业务中断。

如果 Kill Switch 触发后无法恢复网络，先重新打开客户端并确认核心进程、虚拟网卡和防火墙规则状态，再按照客户端提供的“关闭网络锁”“恢复默认网络设置”流程处理。强行删除系统网络适配器或防火墙规则，可能让后续连接更难排查。Linux 用户还应检查 NetworkManager、systemd-resolved、iptables 或 nftables 等组件是否与客户端的接管方式冲突。

日常办公、支付与公共 Wi-Fi 的使用建议

办公场景中，建议使用规则清楚的分流方式，并确认企业域名、内部 DNS、远程桌面和文件同步软件的访问要求。不要把全部流量强制送入一条未经验证的线路，也不要在企业设备上随意安装第三方浏览器扩展。VPN 只负责其中一段传输保护，企业账号仍应使用多因素认证、最小权限和设备加密。

支付场景更重视环境连续性。频繁切换国家或地区出口，可能触发银行、支付平台或电商账户的风险控制。连接前确认客户端状态稳定，支付过程中不要主动切换线路；遇到验证码、证书警告或登录地区异常时，应停止操作并通过官方渠道核实。DNS 检测通过，也不代表支付平台一定接受当前出口。

公共 Wi-Fi 场景中，应先完成网络门户认证，再启动 VPN 和 Kill Switch。连接到新的热点后重新检查客户端状态，不要仅因为任务栏图标仍然存在，就认定隧道没有中断。关闭文件共享、远程管理和不需要的局域网发现功能，避免把网络隐私问题扩大为设备暴露问题。

另外，订阅链接和配置文件应像账号凭据一样保管。导入 Clash Verge、sing-box、Shadowrocket 或官方客户端时，只从可信入口复制完整链接；提交故障截图时遮挡链接、二维码、服务器地址中的认证信息和本地日志中的令牌。若怀疑订阅泄露，应尽快在服务面板中更新或重置，而不是继续公开使用旧链接。

常见问题

客户端显示已连接，为什么检测仍显示本地 DNS？

可能是客户端只接管了浏览器代理，没有接管系统 DNS，也可能是浏览器安全 DNS、IPv6 或分流规则绕过了隧道。先关闭其他网络工具，再分别检查客户端 DNS 设置、浏览器设置和 IPv6 状态。若办公网络有内部 DNS，还要确认哪些域名必须保留本地解析。

使用公共 DNS 就不会泄漏吗？

不会。公共 DNS 只是解析服务的提供者发生了变化，不能自动保证请求经过 VPN。即使 DNS 使用加密传输，如果请求直接从本地网络发出，仍然可能绕过 VPN 的统一路径。应结合检测结果和客户端日志判断传输路径。

WebRTC 暴露地址等于 VPN 失效吗？

不一定。WebRTC 展示的是浏览器收集到的候选地址，可能包括局域网地址、虚拟网卡地址或 VPN 出口地址。需要判断是否出现真实公网出口，以及这些地址是否属于当前网络。通过浏览器权限、WebRTC 策略和客户端完整接管来减少不必要的暴露。

开启 Kill Switch 后无法上网，是不是客户端坏了？

不一定。网络锁的设计就是在隧道不可用时阻止流量，因此线路连接失败期间无法访问属于可能的正常表现。先确认客户端核心、虚拟网卡和防火墙状态，再按照客户端说明恢复网络。不要为了临时打开网页而长期关闭断线保护。

DNS 泄漏自查的核心不是追求某个检测页面显示固定结果，而是理解每类请求从设备到目标服务的路径。完成 DNS、IPv6、WebRTC 和断线保护检查后，再根据办公、支付或公共 Wi-Fi 的实际需求调整分流。只有设置能够解释、断线行为能够验证、订阅与客户端来源可信，VPN 才能成为日常网络防护中的一环，而不是一个只看连接图标的黑盒。