VPN 安全吗，不能只看客户端是否显示“已连接”。VPN 通常会改变部分网络流量的传输路径，但 DNS 查询、浏览器的 WebRTC 请求、系统代理例外规则，以及应用自身的网络实现，都可能让请求绕过预期的加密隧道。也就是说，连接成功不等于所有域名查询、所有应用流量和所有本地网络请求都已经受到同样保护。

DNS 泄漏的典型表现是：网页访问看起来正常，出口 IP 也已经改变，但 DNS 检测页面仍显示本地运营商或原网络环境的解析服务器。WebRTC 泄漏则可能在浏览器建立实时通信时暴露本地地址、局域网地址或其他候选连接信息。两类问题的成因不同，修复方法也不能简单归结为“换一条线路”。下面从原理、检测、修复到公共 Wi-Fi 自查，整理一套适用于 Windows、macOS、Android、iOS 和 Linux 的排查流程。

DNS 泄漏到底是什么

访问网站时，设备通常先把域名解析成 IP 地址，再向目标服务器发起连接。DNS 查询本身可能不包含网页正文，却会暴露“设备正在查询哪些域名”这一层信息。如果 VPN 只接管了网页连接，却没有接管系统的 DNS 请求，查询就可能继续发送到本地路由器、运营商 DNS 或公共网络自动分配的解析服务器。

常见原因包括客户端没有启用 DNS 接管、系统优先使用了物理网卡的 DNS、虚拟网卡路由优先级不正确，以及分流模式故意让 DNS 走本地网络。某些浏览器还支持自己的安全 DNS 或加密 DNS，它可能绕过系统设置，直接连接浏览器指定的解析服务。移动设备则可能受到私人 DNS、配置描述文件、网络切换和省电策略影响。

DNS 泄漏不一定意味着网页内容已经被读取，也不代表 VPN 加密完全失效，但它会让域名访问记录与本地网络产生关联。在公共 Wi-Fi、校园网、酒店网络等环境中，错误的 DNS 还可能导致域名被篡改、解析失败或跳转到不预期的页面。因此，DNS 是网络隐私检查中不可省略的一环。

4

重点检查层

5

支持平台

90+

国家覆盖

200+

线路数

上面的“重点检查层”指出口 IP、DNS、WebRTC 和应用实际流量；它们分别回答不同问题。出口 IP 检查的是对外地址，DNS 检查的是域名如何解析，WebRTC 检查的是浏览器实时通信候选地址，应用检查则确认某个程序是否真正使用了代理或虚拟网卡。

修复前先做一次完整检测

检测时不要只打开一个页面看结果。先断开 VPN，记录当前网络的出口 IP、DNS 服务商和浏览器 WebRTC 信息；再连接 VPN，等待状态稳定后重新检测。两次结果的差异比单次截图更有参考价值。检测期间尽量关闭其他代理客户端，避免 Clash Verge、sing-box、Shadowrocket、系统代理和浏览器扩展同时接管流量，造成结果互相干扰。

检查出口 IP 与 DNS

出口 IP 检查用于确认网页连接是否从预期线路出去。DNS 检查则要观察解析服务器所属地区、运营商或组织，而不只是看网页是否能打开。如果连接后出口 IP 已改变，但 DNS 服务器仍明显属于本地宽带或当前 Wi-Fi 网络，就应继续检查 DNS 接管状态。

在 Windows 可以使用命令行查看当前解析器：

ipconfig /all
nslookup example.com

macOS 和 Linux 可以从系统网络设置、NetworkManager 或终端工具查看当前 DNS。不同系统的显示方式并不完全一致，因此不要仅凭某一行地址判断泄漏。重点是比较 VPN 连接前后的解析服务器、默认路由和实际查询结果。若客户端使用本地 DNS 转发器，系统中看到的可能是 127.0.0.1 或局域网地址，此时还需要回到客户端确认它把查询转发到哪里。

检查浏览器 WebRTC

WebRTC 用于视频会议、语音通话和点对点连接。浏览器可能通过 ICE 机制收集多个候选地址，其中包括本地网卡地址、局域网地址和经代理或 VPN 暴露的地址。即使网页普通请求已经经过 VPN，WebRTC 仍可能采用另一套连接逻辑。

检查时应使用可信的 WebRTC 检测页面，并分别记录连接前后的候选地址。看到内网地址不一定就是严重问题，因为 192.168.x.x、10.x.x.x 等地址通常只在本地网络中使用；但如果检测结果出现与当前 VPN 出口不一致的公网地址，或者浏览器在断开和连接状态下暴露相同的真实公网地址，就需要处理浏览器权限、扩展和 WebRTC 策略。

检查项目 正常时应关注什么 异常信号 下一步
出口 IP 与所选线路和预期地区一致 仍显示原网络公网地址 检查接管模式与路由
DNS 由客户端或预期解析服务处理 显示本地运营商或 Wi-Fi DNS 启用 DNS 接管并刷新缓存
WebRTC 没有暴露不应出现的公网候选地址 连接状态变化后仍暴露真实地址 调整浏览器 WebRTC 设置
应用流量 实际应用遵循代理或虚拟网卡规则 浏览器正常，其他程序仍直连 检查分流规则和应用代理设置

电脑端 DNS 泄漏修复清单

Windows、macOS 和 Linux 的修复思路相同：让 VPN 客户端明确接管 DNS，确认 DNS 请求走隧道，再处理系统缓存和浏览器独立设置。若客户端提供“防 DNS 泄漏”“远程 DNS”“严格路由”“阻止隧道外 DNS”等选项，应先理解其作用再启用。严格模式通常会阻止无法通过隧道发送的查询，但也可能让某些局域网域名无法解析。

  • ✅ 在客户端中启用 DNS 接管或远程 DNS，避免只开启普通系统代理。
  • ✅ 使用虚拟网卡或全局接管模式测试一次，区分分流规则与隧道本身的问题。
  • ✅ 检查物理网卡和虚拟网卡的 DNS 优先级，避免断开 VPN 后的 DNS 继续抢先响应。
  • ✅ 修改设置后清理 DNS 缓存，再关闭并重新打开浏览器。
  • ❌ 不要把多个 VPN 客户端的 DNS 转发器同时启动。
  • ❌ 不要只把系统 DNS 手工改成某个公共 DNS，就认为已经完成加密保护。

Windows 用户可以先执行 ipconfig /flushdns 清理缓存；macOS 与 Linux 的缓存刷新方式会随系统版本和解析服务不同而变化，应优先使用系统网络服务或发行版文档提供的命令。清缓存的作用是让后续查询重新发起，它不能修复错误的路由，也不能替代客户端的 DNS 接管。

如果使用 Clash Verge 或 sing-box，应检查 DNS 模式、监听地址、Fake-IP 或 Redir-Host 相关设置，以及规则是否把 DNS 请求送到代理端。不同配置的行为差异很大：Fake-IP 可能改变应用看到的解析结果，直连 DNS 可能是分流设计的一部分。排查时建议先使用一份结构简单的配置，确认基础隧道正常，再逐步恢复复杂规则。

电脑端结论： 优先验证“DNS 查询是否随隧道走”，再讨论使用哪家解析服务。更换 DNS 地址本身，并不能保证 DNS 请求没有绕过 VPN。

手机端与浏览器的处理方法

Android 设备需要同时留意 VPN 应用权限、私人 DNS、始终开启 VPN 和阻止无 VPN 连接等系统选项。私人 DNS 可能使用系统指定的 TLS 解析服务，也可能与 VPN 客户端的 DNS 方案冲突。若开启了“始终开启 VPN”或类似阻止无 VPN 连接的功能，断线时部分应用可能完全无法联网，这是保护策略生效，不应误判为 DNS 故障。

iOS 会通过系统 VPN 配置和网络扩展管理连接。连接后若网页正常但某些应用仍显示原地区，可能是应用使用了独立的网络路径、缓存了旧结果，或者客户端采用的是按应用分流。iOS 的系统权限、配置描述文件和蜂窝网络切换也值得检查。遇到 Wi-Fi 与蜂窝网络切换后状态异常，可以先断开 VPN，确认当前网络可用，再重新连接并重复检测。

浏览器层面要检查安全 DNS、代理扩展和 WebRTC 权限。安全 DNS 不一定是坏事，但如果它绕过了 VPN 客户端的统一策略，就会出现“网页走隧道、解析走浏览器”的分离情况。代理扩展也可能只作用于当前浏览器，不能代表其他应用受到保护。对于视频会议、在线课堂等 WebRTC 使用频繁的场景，应在实际浏览器和实际网络环境中验证，而不是只依赖客户端的连接提示。

公共 Wi-Fi 下的风险与自查顺序

公共 Wi-Fi 的风险不只来自 DNS 泄漏。热点可能要求网页认证、限制 UDP、拦截特定端口，或者在连接初期使用强制门户跳转。VPN 建立前，设备通常需要先完成热点认证；如果一连接 Wi-Fi 就立刻启用严格阻止模式，可能无法打开登录页面。更稳妥的做法是确认热点来源，完成必要的网络认证，然后再启动 VPN，并检查客户端是否显示完整握手。

在咖啡店、机场、酒店或会议场所，不要因为名称相似就直接连接开放热点。关闭文件共享、局域网发现和不必要的投屏功能，避免在同一局域网中暴露服务。VPN 可以减少部分传输被旁路观察的风险，但不能阻止钓鱼页面、恶意下载、账号盗用或设备本身感染恶意软件。

  1. 确认 Wi-Fi 名称和认证页面来自场所的正式渠道。
  2. 连接后先观察是否需要网页登录，不要在未知页面输入重要账号。
  3. 完成认证后启动 VPN，等待客户端显示连接稳定。
  4. 检查出口 IP、DNS 和 WebRTC，不要只查看系统状态栏。
  5. 使用网银或重要账号前，确认出口地区没有频繁变化。
  6. 离开热点后关闭自动加入，必要时忘记该网络。

如果公共网络只允许 TCP，而客户端当前线路依赖 UDP 或 QUIC，连接可能反复失败。这时可以在兼容的客户端中切换传输方式或协议，例如在支持的配置中尝试 Shadowsocks、VMess、Trojan、Hysteria2 或 WireGuard 的其他线路，但不要随意修改服务端未提供的参数。协议名称不是安全保证，关键仍是客户端是否正确验证服务端、流量是否按预期接管，以及 DNS 是否随隧道处理。

发现泄漏后怎样定位问题

排查应采用一次只改一项的方式。先关闭浏览器扩展和其他代理工具，保留一个客户端；再切换到全局接管或虚拟网卡模式测试。如果全局模式正常而规则模式异常，问题多半在分流规则、域名匹配或 DNS 规则。若全局模式仍然异常，则继续检查客户端权限、系统路由、虚拟网卡和网络扩展。

  • ✅ 先确认客户端版本、订阅状态和权限没有异常。
  • ✅ 断开后清理缓存，再连接并重新检测，避免使用旧查询结果。
  • ✅ 分别测试浏览器、终端和一个常用应用，确认是否只有单个程序绕过代理。
  • ✅ 更换网络环境后重复测试，区分本地 Wi-Fi 限制与客户端配置问题。
  • ❌ 不要看到一个异常地址就立即认定所有流量都已泄漏。
  • ❌ 不要同时改协议、DNS、分流和浏览器设置，否则很难知道哪一步产生了变化。

若只有浏览器出现 WebRTC 公网地址，应从浏览器权限和 WebRTC 策略入手；若所有设备都显示本地 DNS，则要检查客户端或订阅配置；若只有某个应用不受保护，则查看该应用是否使用 QUIC、独立代理、系统代理例外或自己的 DNS。Linux 上还要留意终端环境变量与桌面代理是否一致，Android 和 iOS 上则要留意应用级分流与系统网络切换。

DNS 泄漏自查常见问题

出口 IP 变了，为什么还要查 DNS？

出口 IP 和 DNS 是两条不同的观察线索。前者表示某些连接对外呈现的地址，后者表示域名查询由谁处理。VPN 可能成功接管网页连接，却遗漏系统、浏览器或某个应用发出的 DNS 请求，所以两者必须分别确认。

把 DNS 改成公共 DNS 就安全吗？

不一定。公共 DNS 可能改善解析可用性，但如果查询仍通过本地网络发送，网络路径和暴露范围并没有自动改变。应先确认客户端是否接管 DNS、查询是否经由隧道，再考虑解析服务的可靠性、隐私政策和分流需求。

WebRTC 检测显示内网地址，需要修复吗？

内网地址通常只在局域网中使用，单独出现不等于真实公网地址泄漏。真正需要关注的是是否出现与 VPN 出口不一致的公网候选地址，以及浏览器是否在断开 VPN 后仍保留可被外部识别的连接信息。根据使用场景调整 WebRTC 权限，并重新进行连接前后的对照测试。

修复后多久应该再次检查？

每次修改客户端、浏览器、系统网络设置、订阅配置或更换网络环境后，都应重新检查。特别是从家庭宽带切换到公共 Wi-Fi、从 Wi-Fi 切换到蜂窝网络，或系统更新网络扩展后，原先的结果不能直接当作当前状态。保持单一客户端、记录改动并重复验证，通常比频繁更换线路更容易找到问题。

最终结论： VPN 安全性不能由“已连接”三个字单独证明。完成出口 IP、DNS、WebRTC 和实际应用流量四项检查，再结合公共 Wi-Fi 的设备与账号防护，才能更准确地判断当前连接是否符合自己的隐私需求。