很多人把 VPN 连接成功等同于“所有网络信息都已经隐藏”，但这两件事并不完全相同。VPN 通常会改变部分流量的出口，并在设备与 VPN 服务器之间建立加密通道；DNS 查询、浏览器的 WebRTC 请求、IPv6 流量以及未纳入代理规则的应用，仍可能按照另一条路径访问网络。因此，判断 VPN 是否安全，不能只看客户端是否显示“已连接”，还要确认域名解析和浏览器通信是否与预期路径一致。
DNS 泄漏与 WebRTC 泄漏也不是同一种问题。DNS 泄漏主要关注“域名由谁解析、解析请求从哪里发出”；WebRTC 泄漏则关注浏览器为了建立实时通信而收集和交换哪些网络候选地址。二者都可能暴露本地网络或实际地区线索，但检测方式、修复位置和对正常功能的影响不同。本文将按照“理解成因—实际检测—逐项修复—复测验证”的顺序，整理一套适合 Windows、macOS、Android、iOS 和常见浏览器的自查方法。
DNS 与 WebRTC 泄漏分别是什么
DNS 是把域名转换为 IP 地址的系统。用户访问网站时，浏览器通常先发起 DNS 查询，再连接返回的服务器地址。如果设备连接 VPN 后，DNS 查询仍然交给本地宽带运营商、公共 Wi-Fi 路由器或系统中预先配置的解析服务器处理，就可能出现 DNS 泄漏。网站内容本身也许已经通过 VPN 访问，但解析记录仍然暴露给原来的网络提供方。
DNS 泄漏常见于几种配置组合。第一种是 VPN 客户端只接管了浏览器或部分应用的代理，而没有接管系统 DNS；第二种是分流规则允许 DNS 走直连，却没有向用户清楚说明；第三种是 IPv6 处于开启状态，但 VPN 隧道只处理 IPv4，系统于是通过本地 IPv6 网络发出请求。还有一种情况是浏览器启用了 DoH，也就是基于 HTTPS 的 DNS 查询。DoH 可以提高传输隐私，但如果它连接的是浏览器预设的解析服务，并且没有纳入 VPN 的统一策略，仍可能造成解析路径与其他流量不一致。
WebRTC 是浏览器支持实时音视频通信的一套技术，常用于语音、视频会议、屏幕共享和点对点连接。为了判断设备是否能够建立连接，浏览器可能通过 STUN 等机制收集网络候选地址。现代浏览器通常会使用 mDNS 等机制减少本地地址直接暴露的机会，但实际结果仍会受到浏览器版本、权限、扩展、操作系统和 VPN 类型影响。某些检测页面显示出额外的公网候选地址时，说明浏览器的 WebRTC 路径可能没有完全遵循代理或隧道规则。
还要注意“浏览器代理”和“系统级 VPN”并不等价。浏览器扩展通常只影响浏览器产生的部分请求，其他应用、DNS 或 WebRTC 的底层连接未必会同步改变。系统级 VPN 一般能够覆盖更多流量，但如果客户端采用规则分流、允许局域网访问，或者没有处理 IPv6，也不能直接推断所有请求都被统一接管。
- ✅ DNS 泄漏重点检查解析服务器、解析地区与查询路径。
- ✅ WebRTC 泄漏重点检查浏览器候选地址是否出现额外公网出口。
- ✅ 检测时应使用同一设备、同一浏览器和同一 VPN 配置前后对比。
- ❌ 不要只根据 VPN 客户端上的“已连接”图标判断隐私状态。
- ❌ 不要把更换 DNS 服务器误认为已经修复了 VPN 隧道问题。
动手检测：先建立基线，再逐项复测
检测前建议先关闭其他代理客户端、浏览器代理扩展和网络加速工具，避免多个程序同时修改路由。确认 VPN 客户端使用的是你日常需要的模式，例如全局、规则分流或应用分流，并记录当前是否允许局域网访问、是否启用 IPv6 以及是否启用 Kill Switch。检测的目的不是寻找一个“看起来最干净”的页面，而是确认所有重要请求是否符合自己的网络策略。
DNS 泄漏检测步骤
第一步，在未连接 VPN 时打开 DNS 检测工具，记录检测页面列出的解析服务器所属网络或地区。第二步，连接 VPN 后关闭并重新打开检测页面，执行完整检测，而不是只做快速查询。第三步，比较连接前后的解析服务器。如果 VPN 连接后仍反复出现本地运营商、家庭宽带或当前公共网络提供的 DNS，通常说明系统 DNS 没有被隧道接管，或者当前分流模式允许 DNS 直连。
检测时不要只看服务器名称。部分解析服务使用统一品牌名称，页面显示的地理位置也可能来自数据库推断，因此应同时查看组织名称、IP 地址和检测时间。一次检测结果也不能证明长期状态，因为切换网络、切换节点、恢复睡眠、更新订阅或重新连接后，系统路由可能发生变化。Windows 可以检查系统网络适配器和 DNS 配置，macOS 可以查看当前网络服务的 DNS 设置；Android 与 iOS 则应优先查看 VPN 客户端是否提供 DNS 防泄漏或全隧道选项。
WebRTC 泄漏检测步骤
在同一个浏览器中，先记录未连接 VPN 时检测页面显示的候选地址，再连接 VPN 后重新加载页面。需要区分本地地址、VPN 出口地址和其他公网地址。出现局域网地址不一定等于严重泄漏，许多浏览器会展示经过 mDNS 处理的本地主机名或不可直接路由的地址；真正需要重点关注的是，VPN 连接后是否仍出现与实际网络相关的公网出口，或者是否出现与预期地区明显不同的可识别地址。
如果你使用的是浏览器代理扩展，WebRTC 的连接可能仍由浏览器底层网络组件处理，扩展并不能保证所有实时通信都通过代理。可以暂时停用扩展，改用系统级 VPN 再测试，以便判断问题来自代理范围还是 VPN 本身。检测页面还可能请求摄像头或麦克风权限，除非确有需要，否则不要授予来源不明的网站这些权限。完成测试后，应在浏览器设置中撤销不必要的站点权限。
| 检测现象 | 可能原因 | 优先检查位置 |
|---|---|---|
| 连接 VPN 后仍显示本地 DNS | 系统 DNS 未被接管、分流规则允许直连或 IPv6 绕过隧道 | VPN 的 DNS 选项、分流模式、系统网络适配器 |
| 浏览器出现额外公网候选地址 | WebRTC 未遵循浏览器代理，或浏览器与 VPN 的处理方式不一致 | 浏览器 WebRTC 设置、扩展权限、VPN 类型 |
| 只有某个浏览器检测异常 | 该浏览器启用了独立 DoH、代理扩展或特殊隐私策略 | 浏览器网络、DNS、扩展和站点权限 |
| 断网重连后结果发生变化 | 路由、DNS 或 Kill Switch 在重连期间短暂未生效 | 客户端启动项、自动连接、断线保护和系统防火墙 |
DNS 泄漏的修复顺序与注意事项
修复 DNS 泄漏时，第一步是确认 VPN 客户端是否支持“使用 VPN DNS”“防止 DNS 泄漏”或类似选项。不同客户端的名称可能不同，但核心目标是让 DNS 查询与需要保护的流量使用一致的隧道策略。启用后重新连接 VPN，再进行完整检测。不要只在系统里手动填写一个公共 DNS，因为这可能改变解析服务，却不能保证查询一定经过 VPN。
第二步是检查分流规则。规则模式下，系统可能将本地服务、局域网地址和部分域名设置为直连，这在访问打印机、企业内网或本地设备时有用，但也可能让某些 DNS 请求绕开隧道。对于需要隐私保护的浏览器流量，应确认 DNS 规则没有被单独设为直连。使用 Clash Verge、sing-box 或其他兼容客户端时，还要留意 DNS 模式、Fake-IP、TUN 模式与规则集之间的关系，不能只看订阅是否成功导入。
第三步是处理 IPv6。若服务端或客户端没有完整支持 IPv6，系统却继续通过本地 IPv6 网络访问互联网，就可能形成旁路。可以先在 VPN 文档中确认 IPv6 支持情况，再决定是让 IPv6 一并进入隧道，还是在受控环境中暂时关闭设备的 IPv6。关闭 IPv6 可能影响部分网络和本地服务，因此应记录原设置，修改后观察常用网站、应用和局域网功能是否正常。
第四步是检查浏览器的安全 DNS。Chrome、Edge、Firefox、Safari 及移动端浏览器对 DoH 或安全 DNS 的实现并不完全相同。如果浏览器强制使用独立解析服务，VPN 的 DNS 策略可能无法统一管理。你可以先暂时关闭浏览器独立 DNS 进行对比；如果关闭后恢复正常，再根据 VPN 的兼容说明决定是否启用。安全 DNS 并非一定不安全，关键是解析请求是否符合你的威胁模型和网络策略。
WebRTC 防护：不要盲目关闭浏览器功能
WebRTC 的处理应根据使用场景决定。完全关闭 WebRTC 可以减少部分实时通信路径，但也可能导致视频会议、网页语音、屏幕共享和在线客服功能异常。对于经常使用这些功能的人，更合理的做法是先更新浏览器和 VPN 客户端，确认浏览器是否已经采用 mDNS 隐藏本地地址，再通过浏览器的隐私设置限制 WebRTC 暴露可识别公网地址的行为。
浏览器扩展可以提供额外的 WebRTC 防护选项，但扩展本身也需要被信任。安装前应查看权限范围、开发者信息和更新记录，避免使用要求读取所有网页内容、修改全部网络请求却没有清晰说明的扩展。移动端浏览器尤其不能简单套用桌面端教程：iOS 和 Android 的浏览器通常受到系统网络接口限制，某个桌面扩展的设置并不代表移动端也存在同样的开关。
如果检测结果只显示本地私有地址，且没有显示真实公网出口，通常不必为了追求“页面完全没有任何候选地址”而破坏 WebRTC。若检测仍出现不希望暴露的公网地址，可以尝试以下顺序：先关闭浏览器代理扩展并使用系统级 VPN；再检查 VPN 是否启用了全隧道或 TUN 模式；最后才考虑浏览器隐私策略或可信扩展。修改后应实际测试视频通话和麦克风权限，确认防护没有造成新的使用问题。
- ✅ 优先使用更新后的浏览器与系统级 VPN 进行复测。
- ✅ 对需要视频会议的设备，先验证功能再决定是否限制 WebRTC。
- ✅ 只安装权限透明、来源可靠并且能够说明工作方式的扩展。
- ❌ 不要把浏览器代理扩展当成覆盖整个设备的 VPN。
- ❌ 不要为了隐藏普通局域网地址而关闭所有摄像头、麦克风或实时通信能力。
Kill Switch 与公共网络中的完整防护
Kill Switch 通常被翻译为网络锁或断线保护。当 VPN 隧道意外断开时，它通过系统防火墙、路由规则或客户端策略阻止部分流量继续直连，从而减少短暂暴露。但 Kill Switch 的实现方式各不相同，有的只在客户端运行后生效，有的能够覆盖系统启动阶段；有的只拦截 IPv4，有的还需要额外开启 IPv6 防护。启用后不能仅凭开关状态判断有效，应该主动断开 VPN，观察浏览器和其他应用是否确实无法建立不受控的网络连接。
需要特别检查 DNS 是否包含在断线保护范围内。有些客户端会阻止网页流量，却允许系统继续向原 DNS 服务器查询；也有客户端在重连时短暂恢复默认网络。Windows 和 macOS 用户可以通过断开 VPN、关闭自动重连并观察 DNS 检测结果进行验证。Android 和 iOS 用户应查看客户端说明，确认系统 VPN 配置是否支持“始终开启”或“无 VPN 时阻止连接”等功能，并注意这些选项可能影响本地网络、推送通知和应用联网。
公共 Wi-Fi 环境中的风险不只来自地址泄漏，还包括假冒热点、恶意门户、局域网扫描和自动连接。连接咖啡店、机场或酒店网络时，应关闭设备的自动加入未知网络功能，尽量使用 HTTPS 访问网站，不在未确认网络名称和登录页面真实性前输入敏感信息。VPN 可以保护设备到 VPN 服务器之间的传输，但不能替你判断当前热点是否可信，也不能消除钓鱼页面、恶意文件和账户密码重复使用带来的风险。
在公共网络中，建议先连接 Wi-Fi，再启动 VPN，确认隧道建立后才处理重要账户；如果 VPN 未连接或 Kill Switch 未生效，则避免进行支付、管理后台登录和上传敏感文件。使用结束后删除不再需要的 Wi-Fi 配置，并检查设备是否仍保持自动连接。对于企业设备或家庭共享设备，还应区分个人 VPN、公司安全接入和普通代理的边界，避免把不同用途的配置混在一起。
常见问题 FAQ
DNS 泄漏是不是代表 VPN 完全没有加密？
不一定。DNS 泄漏说明域名解析请求可能没有按照预期通过 VPN，但其他网页数据仍可能经过加密隧道。它依然值得修复，因为解析记录能够暴露访问过的域名、网络提供方或大致网络环境。应将 DNS 路径和网页内容路径分开判断，不要用其中一项推断全部状态。
只在一个浏览器发现 WebRTC 地址，需要处理吗？
需要先确认该地址是什么类型，以及是否真的属于不希望暴露的公网出口。如果只有一个浏览器出现，常见原因是它启用了独立代理、DoH、扩展或不同的 WebRTC 策略。可以用同一 VPN 在另一个浏览器复测，再逐项关闭扩展和独立网络设置，避免直接修改系统所有网络配置。
开启 Kill Switch 后是不是就不需要检查 DNS？
不是。Kill Switch 主要负责断线时阻止流量外泄，DNS 是否被纳入保护取决于具体客户端和系统防火墙实现。某些配置可能阻止网页连接，却没有阻止 DNS 查询。因此，Kill Switch 应与 DNS 检测、IPv6 检查和断线复测结合使用。
公共 Wi-Fi 下只要连接 VPN 就绝对安全吗？
VPN 能减少设备到 VPN 服务器之间被本地网络直接读取的风险，但不能保证热点本身可信，也不能防止钓鱼网站、恶意下载、弱密码和错误的文件共享设置。公共网络使用时仍应关闭自动连接、检查网站地址、启用账户多重验证，并在 VPN 未建立或断线保护未确认时避免处理重要信息。
最后，可以把自查流程固定为一套习惯：连接前记录 DNS 与 WebRTC 基线，连接后分别检测；修复 DNS、IPv6、分流或浏览器设置后重新建立隧道；再主动测试 Kill Switch，并在公共网络中检查自动连接和权限。这样做比单纯更换节点或反复刷新检测页面更容易定位问题，也能避免把 DNS 泄漏、WebRTC 候选地址和普通网页访问故障混为一谈。