VPN安⁠全吗？DNS泄漏与加密自查防护指⁠南

使用 VPN 并不代表所有隐私风险都会自动消失。客户端显示“已连接”，通常只能说明某个加密会话已经建立，不能直接证明 DNS 请求、浏览器 WebRTC、系统更新、应用分流和账号登录都按照预期工作。真正可靠的自查，应把无日志政策、传输协议、DNS 路径、出口地址和本地权限分开确认。

本文重点讨论 DNS 泄漏与加密配置。你将看到 DNS 泄漏为什么会发生、Shadowsocks、VMess、Trojan、Hysteria2 与 WireGuard 在这里分别扮演什么角色，以及如何在 Windows、macOS、Android、iOS 和 Linux 上按顺序检查。检测时不要只打开一个网页看结果；更稳妥的方法是连接前后各记录一次，并在切换线路、切换网络和修改协议后重复验证。

VPN 连接到底保护了什么

VPN 客户端通常会在设备上建立虚拟网络接口，再按照全局、规则或直连模式转发流量。全局模式会让更多请求经过代理通道；规则模式依据域名、地址、应用或规则集决定路径；直连模式则保留本地网络访问。三种模式都可能是合理选择，但它们的隐私边界不同。比如，浏览器页面经过代理，并不代表系统中的邮件客户端、游戏或后台同步也一定经过代理。

传输协议负责建立连接、协商加密并承载数据，但协议名称本身不是安全结论。Shadowsocks 是代理协议，常见配置依赖加密方法和密码；VMess 与 Trojan 通常由客户端结合传输层、TLS 或其他参数使用；Hysteria2 以 QUIC 为基础，适合在部分网络环境中处理传输；WireGuard 则是现代 VPN 协议，使用密钥建立隧道。实际保护程度还取决于客户端实现、密钥管理、证书校验、路由规则以及服务端配置。

例如，某个客户端支持 WireGuard，不代表所有导入的配置都自动启用了完整隧道路由；某个订阅包含 Trojan，也不代表浏览器的 DNS、WebRTC 或其他应用请求一定不会走本地网络。导入订阅后，应同时检查协议、模式、DNS 设置和系统代理状态，而不是只看线路名称。

这里的五个检查层面是出口地址、DNS 解析器、WebRTC 候选地址、应用分流和账号安全。它们相互关联，却不能互相替代。出口地址正常，不代表 DNS 没有泄漏；DNS 正常，也不代表浏览器 WebRTC 没有暴露本地地址。

DNS 泄漏为什么会发生

DNS 的作用是把域名转换为 IP 地址。用户在浏览器中输入域名后，设备需要先向某个 DNS 解析器发起查询，然后才能连接目标地址。当 VPN 只接管了网页流量，却没有接管 DNS 请求时，域名查询可能继续发送给本地宽带运营商、移动网络或公共 Wi-Fi 提供的解析器。这就是常说的 DNS 泄漏。

常见原因有四类。第一，客户端采用规则模式，却把 DNS 设置为本地直连；第二，系统中存在多个网络接口，例如 Wi-Fi、网线、虚拟机和容器同时工作，优先级发生变化；第三，IPv6 通道没有被同样处理，IPv4 看似正常，IPv6 查询却绕过隧道；第四，浏览器启用了自己的安全 DNS 或 DoH，导致浏览器查询路径与系统代理路径不同。

DNS 泄漏不等于网页内容一定被完整读取，但它可能暴露访问过的域名、查询时间和网络环境信息。在公共 Wi-Fi、办公网络或共享网络中，这类元数据也值得重视。另一方面，启用加密 DNS 也不是万能方案。如果 DoH 直接连接了某个解析服务，却没有遵循代理规则，查询本身虽然加密，路径仍可能不符合你的预期。

无日志政策与加密配置如何看

“无日志”不是一个只看宣传语的标签。阅读服务条款或隐私政策时，应区分连接日志、流量内容、DNS 查询、账号信息、支付记录、故障诊断数据和法律合规记录。服务方可能不保存浏览内容，但仍会保留账号创建时间、订阅状态或客服沟通记录。这样的信息不一定代表服务不安全，却说明“无日志”的范围需要看完整定义。

还要注意订阅链接本身。订阅链接通常包含与账号对应的线路或配置入口，虽然它不等同于网页登录密码，但泄露后可能让他人读取配置并在支持的客户端中使用。不要把链接放入公开代码、论坛、截图或共享文档。若怀疑泄露，应在服务面板重置或更换链接，并在所有 Windows、macOS、Android、iOS 和 Linux 客户端中重新导入。

加密配置也应从几个角度判断。首先，客户端是否校验证书或密钥，是否允许明显不安全的跳过验证选项；其次，协议参数是否来自可信订阅，而不是随意复制的未知配置；再次，客户端是否及时更新，能否正确处理 TLS、QUIC 或 WireGuard 密钥；最后，是否同时运行了两个代理客户端。两个客户端可能争抢系统代理、虚拟网卡和 DNS 设置，造成看似随机的泄漏。

• ✅ 阅读隐私政策中关于连接日志、DNS 和诊断数据的具体说明。
• ✅ 使用官方客户端或兼容的 Clash Verge、sing-box、Shadowrocket 等客户端导入订阅。
• ✅ 检查证书校验、密钥、TLS 和 WireGuard 配置是否由可信来源提供。
• ✅ 怀疑订阅链接泄露时，立即更换链接并更新所有设备。
• ❌ 不要因为协议名称听起来先进，就跳过 DNS、分流和浏览器设置检查。
• ❌ 不要同时开启多个代理客户端或多个虚拟网卡接管网络。

如果你主要在公共 Wi-Fi 下使用，建议优先确认客户端的自动连接、断线阻断和 DNS 处理能力。所谓断线阻断，是指隧道断开时，客户端暂时阻止符合代理规则的流量继续从本地网络发送。它可能影响正常上网，但能减少连接中断瞬间的意外直连。不同客户端对此功能的名称和覆盖范围不同，应查看当前版本的说明。

动手检查 DNS、出口与 WebRTC

下面是一套不依赖特定检测网站的通用流程。你可以先使用本站的 IP 查询 页面记录当前出口地址，再结合浏览器的 DNS 和 WebRTC 检测工具进行对照。检测页面只能提供观察结果，不能替代对客户端配置的理解。

1. 断开 VPN，连接当前常用的 Wi-Fi 或移动网络，记录出口地址、系统 DNS 和浏览器 WebRTC 结果。
2. 关闭不需要的代理软件、虚拟机网络和浏览器扩展，避免其他组件改变结果。
3. 打开客户端，先确认订阅已更新，再选择一个线路，记录使用的协议和连接模式。
4. 连接成功后重新查询出口地址，确认它与断开前不同，并检查 DNS 解析器是否仍显示本地网络提供方。
5. 在浏览器中检查 WebRTC。若结果暴露本地地址或不应出现的公网地址，检查浏览器的 WebRTC 策略、扩展和客户端分流设置。
6. 依次切换规则模式与全局模式，分别重复检测。两种模式结果不同，通常说明规则或 DNS 路由需要进一步调整。
7. 断开客户端后清理 DNS 缓存，再换一个网络重新连接，确认结果不是旧缓存造成的假象。

Windows 可以在命令提示符中使用 ipconfig /all 查看网络接口和 DNS；macOS 可在“系统设置”的网络详情中查看 DNS 与代理；Linux 常见的 resolvectl status、NetworkManager 或桌面网络设置也能提供线索。Android 和 iOS 的系统界面因版本不同而变化，重点是检查 VPN 配置、私人 DNS、应用级 VPN 和浏览器自定义 DNS。

WebRTC 为什么要单独检查

WebRTC 用于浏览器中的实时音视频、点对点连接和网络探测。它可能通过 ICE 候选机制发现本地网络接口或可用地址，因此浏览器代理已经生效，并不必然代表 WebRTC 的所有候选地址都被隐藏。对于不使用实时音视频的浏览器环境，可以关闭不必要的 WebRTC 权限或采用浏览器提供的隐私设置；如果必须使用视频会议，则应确认修改不会破坏业务功能。

WebRTC 检测结果中出现内网地址，不一定等于公网身份泄漏，因为内网地址本身通常只描述本地网络结构。但如果出现与当前 VPN 出口不一致的公网地址，就应检查浏览器、客户端和 IPv6 配置。不要为了追求“结果全空”而盲目安装来历不明的扩展，扩展本身也可能读取网页内容和网络请求。

发现泄漏后如何修复

修复时应从最小改动开始。先确认客户端是否有“通过代理解析 DNS”“远程 DNS”“防止 DNS 泄漏”或类似选项，再查看规则模式下 DNS 请求是否被单独分流。不要一次修改多个系统项，否则出现问题时很难知道哪一步产生了影响。修改后完全退出客户端并重新打开，必要时重启设备，再重复检测。

如果问题只在浏览器出现，检查浏览器的安全 DNS、独立代理、扩展和 WebRTC 设置。如果问题只在 IPv6 出现，先确认当前客户端是否支持 IPv6 隧道与 DNS 处理；在无法确认的情况下，可以根据设备和网络环境暂时关闭 IPv6 进行对比，但要记住这会影响其他网络服务。若问题来自多个客户端冲突，应保留一个负责接管系统网络的客户端，其余客户端关闭系统代理或退出。

在 Clash Verge、sing-box 或 Shadowrocket 中，重点看 DNS 模式、Fake-IP 或 Redir-Host 方案、规则匹配和 TUN 接管范围；不同内核对这些功能的实现并不完全一致。不要机械照搬其他平台的配置。Windows、macOS、Android、iOS 和 Linux 的权限模型、系统代理接口和虚拟网卡能力不同，同一份配置在不同设备上可能产生不同结果。

公共 Wi-Fi、支付与账号登录的安全清单

公共 Wi-Fi 下，最大的风险不只来自 DNS。热点名称可能被仿冒，网络可能要求打开未知认证页面，也可能存在不必要的局域网发现服务。连接公共网络时，先确认网络名称和登录页面来源，关闭文件共享与自动发现，不要在弹出的陌生页面中输入支付密码、邮箱密码或订阅凭据。VPN 主要保护符合规则的传输路径，无法替你判断热点是否可信，也无法阻止恶意应用读取设备中的信息。

支付和账号登录时，应优先使用官方应用或手动输入确认过的域名，检查 HTTPS 证书警告，不要在浏览器出现证书错误时继续操作。VPN 能帮助降低本地网络直接观察传输内容的机会，但服务方、浏览器、操作系统和目标网站仍可能掌握各自需要的账号、设备或风控信息。不要把“已经连接 VPN”理解为匿名登录或可以忽略多因素认证。

登录 VPN 面板、导入订阅和使用第三方客户端时，建议把订阅链接视为敏感配置。不要把链接与账号密码放在同一个共享笔记中，也不要在截图中完整展示。使用支持订阅更新的客户端时，更新前确认链接地址，更新后检查线路来源。若设备丢失，应尽快修改面板密码并更换订阅链接，同时退出或删除旧设备上的配置。

• ✅ 公共 Wi-Fi 下关闭文件共享、局域网发现和不必要的自动连接。
• ✅ 支付与登录前确认域名、证书和应用来源。
• ✅ 为重要账号启用多因素认证，并使用不同密码。
• ✅ VPN 断开后重新确认 DNS 和出口，不把旧检测结果当作当前状态。
• ❌ 不要在陌生热点的强制认证页输入订阅密码或支付信息。
• ❌ 不要把 VPN 当作杀毒软件、密码管理器或账号安全的全部方案。

常见问题解答

检测到 DNS 泄漏，是不是 VPN 完全没有加密？

不一定。DNS 泄漏说明部分域名查询没有按照预期路径处理，并不能直接证明所有网页内容都没有经过加密通道。你需要分别检查客户端模式、DNS 设置、IPv6、浏览器 DoH 和 WebRTC。修复后还要在不同网络和线路下复测。

公共 Wi-Fi 下开了 VPN，就可以放心支付吗？

不能简单这样判断。VPN 可以降低本地网络直接观察部分传输内容的机会，但无法保证热点本身可信，也无法替代 HTTPS、官方应用、多因素认证和设备安全。支付前仍应确认域名、证书和应用来源，避免在陌生认证页面输入敏感信息。

Shadowsocks、Trojan、Hysteria2 和 WireGuard 哪个一定更安全？

没有脱离配置和使用环境的绝对答案。它们的设计和传输方式不同，实际表现取决于客户端实现、服务端参数、密钥或证书校验、路由规则和更新维护。选择时应优先使用可信配置，确认客户端版本和 DNS 处理方式，并通过实际检测验证结果。

多久检查一次 DNS 和 WebRTC？

不必机械按固定周期检查，但在更换客户端、导入新订阅、修改 DNS、切换浏览器、升级系统、换 Wi-Fi 或移动网络后，建议重新检查。若发现异常，先记录当前模式和网络，再逐项修改，避免多个变量同时变化。

最后可以把安全自查固定成一张清单：确认服务政策，确认订阅来源，确认协议和证书校验，确认客户端模式，确认 DNS 与 IPv6，确认 WebRTC 与浏览器设置，最后再进行支付或重要账号登录。需要安装或导入客户端时，可参考本站的使用教程；完成配置后，再通过出口地址、DNS 和应用分流三方面交叉验证。这样做虽然多一步，却比看到“已连接”后直接认为全部安全更可靠。