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

先理解 IP、DNS 与 WebRTC 泄漏分别是什么

所谓“泄漏”，并不一定意味着账号密码已经被盗，更常见的含义是：本来希望通过 VPN 线路发出的网络信息，仍有一部分从本地网络、浏览器或其他连接接口直接暴露出去。不同类型的泄漏暴露内容不同，修复方法也不一样，因此不能看到测试页面显示异常就直接更换节点。

出口 IP 暴露

出口 IP 是外部网站看到的访问来源地址。连接 VPN 后，通常希望网站看到的是远端线路的出口，而不是当前宽带、校园网、公司网络或移动网络的公网地址。如果检测页面仍显示本地网络的地址，可能是客户端没有真正接管流量，也可能是某个浏览器标签页、独立应用或旧连接没有经过当前隧道。

需要注意的是，网站看到的地址不等于可以直接定位到个人住址。IP 信息通常只能作为网络出口、运营商或大致区域的线索，但它仍然可能用于关联访问行为。因此，检查出口 IP 是基础步骤，却不能代替 DNS 和 WebRTC 检查。

DNS 泄漏

DNS 负责把域名转换成 IP 地址。当浏览器访问某个网站时，先要询问 DNS 服务器。若 VPN 只接管了网页连接，却让 DNS 查询继续发送到本地宽带运营商、路由器或公共网络提供的解析服务，外部观察者可能从 DNS 请求中推断访问过哪些域名。网页内容本身即使通过远端线路传输，解析路径也可能暴露本地网络特征。

DNS 泄漏不一定表现为“所有 DNS 都来自本地”。有些测试会同时显示多个解析服务，原因可能是系统缓存、浏览器的安全 DNS、操作系统的备用 DNS，或者客户端规则没有覆盖 UDP、TCP 与加密 DNS 请求。判断时应结合客户端日志和浏览器设置，而不是只看测试页面上的一个名称。

WebRTC 泄漏

WebRTC 是浏览器支持实时音视频、语音通话和点对点连接的一组技术。为了建立连接，浏览器可能收集网络接口、候选地址和连接路径信息。在某些浏览器配置下，WebRTC 测试页面可能显示本地网络地址，或者显示与普通网页出口不同的地址。

WebRTC 地址显示异常，不代表所有网页请求都已经绕过 VPN。它说明浏览器的实时通信接口拥有独立的地址发现行为，需要单独处理。完全关闭 WebRTC 可能影响在线会议、浏览器语音和实时协作，因此更合理的做法是根据实际需求调整浏览器权限与 WebRTC 策略。

检测前先固定环境，避免结果被误导

泄漏测试最容易出现的问题，是用户同时切换客户端、线路、浏览器和网络，最后得到一个无法解释的结果。开始前应先记录当前网络环境、使用的客户端、接管模式和浏览器。测试过程中尽量只改变一个设置，这样才能知道是哪项调整产生了影响。

确认客户端确实处于工作状态

首先查看客户端是否显示连接成功，并确认系统代理、TUN 模式或系统 VPN 配置处于预期状态。系统代理主要影响能够读取操作系统代理设置的浏览器和应用；TUN 模式通常通过虚拟网络适配器接管更多 IP 流量，但可能受到防火墙、虚拟机、企业安全软件或其他 VPN 的影响。客户端中的“全局”往往是规则模式，不等于已经接管所有程序。

不要同时运行两个会修改系统代理、默认路由或虚拟网卡的工具。它们可能互相覆盖 DNS、路由和代理设置，导致测试结果在刷新页面后变化。若设备上安装过其他 VPN 或代理客户端，建议先完全退出不使用的程序，再重新连接当前客户端。

清理缓存，但不要把缓存当成泄漏

系统和浏览器会缓存 DNS 解析结果。刚切换线路后，测试页面可能仍然显示旧信息，或者部分域名暂时沿用先前的解析结果。可以关闭测试页面后重新打开，必要时重启浏览器或客户端，再进行对比。清理缓存不能修复真正的 DNS 路径问题，但能减少旧结果对判断的干扰。

如何检查出口 IP 与 DNS 解析路径

IP 和 DNS 应当连续检查，但结论需要分开记录。出口 IP 检查关注外部网站看到的访问来源，DNS 检查关注域名由谁解析、请求从哪里发出。两者都正常时，只能说明这两条路径符合当前测试结果，仍然需要进一步查看 WebRTC。

第一步：检查出口 IP

1. 在未连接客户端时打开 IP 检测页面，记录页面显示的地址、网络归属和大致区域。
2. 连接客户端后关闭原页面，再重新打开同一类型的检测页面。
3. 比较连接前后的结果，确认页面是否显示远端线路的出口信息。
4. 使用第二个独立检测页面复核，避免单个页面缓存或识别方式造成误判。

如果连接前后显示完全相同，先检查客户端是否真的建立连接，系统代理是否被浏览器使用，以及浏览器是否启用了不受客户端控制的网络功能。如果只有某个应用显示本地地址，则问题可能只存在于该应用，而不是整台设备。对于命令行、游戏、更新器等程序，还要确认它们是否支持系统代理，必要时检查 TUN 模式和路由状态。

第二步：检查 DNS

DNS 检测页面一般会列出多个解析服务器或网络归属。不要只根据服务器所在国家或城市判断安全性，因为解析服务的位置不一定等于 VPN 出口位置。更重要的是确认解析请求是否来自预期的网络路径，以及本地运营商、家庭路由器或公司网络是否仍出现在结果中。

若 DNS 结果异常，可以依次检查客户端的 DNS 选项、操作系统网络适配器、浏览器的安全 DNS，以及路由器是否强制接管 DNS。浏览器可能使用 DoH，也就是通过 HTTPS 发送加密 DNS 请求；这种请求可能绕过客户端原本设置的 DNS。关闭或调整安全 DNS 前，应先了解所在网络和组织的要求，尤其是企业设备不要随意改动受管配置。

WebRTC 泄漏的检测与浏览器处理方法

WebRTC 检测需要在浏览器中完成。连接客户端后，打开可信的 WebRTC 检测页面，观察页面列出的候选地址类型。测试页面可能显示本地局域网地址、VPN 出口地址、网络接口地址或经过中继的地址。不同浏览器版本、系统权限和 WebRTC 实现方式会影响显示结果，因此不应只凭一个字段就断定所有流量都发生了泄漏。

先区分本地地址与真实公网出口

局域网地址常见于家庭路由器、办公室网络或移动热点内部，通常属于私有地址范围。它可能揭示设备正在使用某种本地网络，但不等于直接暴露公网出口。真正需要重点关注的是：WebRTC 是否显示连接 VPN 前的公网地址，或者显示与当前客户端出口不一致、且可以关联本地网络的地址。

如果 WebRTC 页面显示的只是本地接口信息，而 IP 和 DNS 检查均符合预期，可以根据隐私要求决定是否进一步限制。若显示了连接前的公网地址，应优先处理浏览器的 WebRTC 行为，并重新测试实时会议、语音通话和视频协作功能，避免为了隐藏地址而影响工作所需的浏览器能力。

按浏览器需求调整

浏览器隐私设置、扩展和企业策略都可能影响 WebRTC。部分浏览器允许限制 WebRTC 暴露本地地址，部分浏览器则需要通过隐私设置或受信任的扩展进行控制。扩展本身也会读取网页访问权限，因此不要安装来源不明、权限过大的插件。调整后应完全关闭旧标签页，重新打开检测页面，并用一次实际的视频或语音场景确认功能是否仍可用。

如果设备由学校或公司统一管理，浏览器设置可能被策略锁定。此时不要强行覆盖策略，应向管理员确认允许的连接方式。iOS 和 Android 上的浏览器又受到系统网络扩展和应用沙盒限制，桌面端的某些 WebRTC 设置不能直接照搬到移动端。

• ✅ 连接客户端后重新打开 WebRTC 检测页面，不使用旧标签页的缓存结果
• ✅ 区分局域网地址、VPN 出口地址与连接前公网地址
• ✅ 修改浏览器策略后测试视频会议、语音和实时协作功能
• ❌ 不要把某个检测页面显示的全部地址都简单判定为公网泄漏
• ❌ 不要同时安装多个功能重复且权限不明的浏览器扩展

Windows、macOS、手机与 Linux 的防护重点

不同平台的网络接管机制不同，防护重点也不能完全照搬。桌面系统更容易遇到系统代理、TUN、虚拟网卡和后台程序之间的冲突；移动系统通常依靠系统 VPN 接口，但省电策略、应用分流和网络切换会影响持续连接。

Windows 与 macOS

Windows 上应检查系统代理开关、虚拟网络适配器、DNS 设置和防火墙提示。使用 Clash Verge、sing-box 或其他兼容客户端时，要确认订阅中的协议与客户端内核均受支持，并区分系统代理、规则模式和 TUN 模式。若使用 TUN，出现本地软件无法联网时，应检查虚拟适配器和其他安全软件，而不是立即判定线路失效。

macOS 常见问题包括网络扩展授权、睡眠唤醒后代理残留，以及系统代理开关与客户端状态不一致。重启客户端后，应重新确认网络扩展是否启用、DNS 是否恢复到预期状态。某些命令行工具还会读取自身配置或环境变量，浏览器正常不能证明终端请求也采用同一路径。

iOS 与 Android

iOS 通常通过系统 VPN 配置建立连接。首次添加配置时要确认系统授权，切换 WiFi 与移动数据后重新查看 VPN 状态。若客户端支持分应用或按需连接，应确认当前浏览器是否被纳入范围。Android 的本地 VPN 接口同样可能受到省电限制、后台冻结和分应用规则影响，连接成功后应在不同网络环境下重复检查。

手机上的浏览器 WebRTC 行为还可能受系统版本和浏览器内核影响。不要因为桌面浏览器的设置有效，就假设移动端也会自动采用相同规则。重要场景下，应分别在 WiFi 和移动数据环境中检查 IP、DNS 与 WebRTC，并观察从后台恢复后是否仍保持正确状态。

Linux 与命令行环境

Linux 上需要同时关注 NetworkManager、systemd-resolved、路由表、TUN 设备和应用自身的代理变量。图形客户端能够连接，不代表终端工具、容器或虚拟机一定使用同一条路径。命令行程序可能读取 HTTP_PROXY、HTTPS_PROXY 等环境变量，也可能完全忽略它们。排查时应查看程序文档和当前路由，而不是只在浏览器中做测试。

公共 WiFi 场景下如何降低风险

机场、酒店、咖啡店和会议场所的公共 WiFi 可能要求网页认证，也可能存在错误 DNS、强制跳转或不稳定的网络设备。连接 VPN 前，通常需要先完成网络本身的登录认证，否则客户端可能因为无法访问认证页面而显示连接失败。完成认证后再启动客户端，并重新检查 IP、DNS 与 WebRTC。

公共网络中不要只依赖 VPN 解决所有问题。应关闭文件共享、打印机发现和不必要的局域网访问，避免自动连接名称相似的热点。访问网站时仍要注意 HTTPS、账号多因素认证和系统更新。VPN 可以减少部分网络路径暴露，但不能阻止钓鱼页面、恶意软件、弱密码或浏览器扩展主动读取数据。

如果公共 WiFi 频繁断线，客户端可能反复重连并出现短暂的直连窗口。可以开启客户端提供的断网保护、阻止无 VPN 连接或类似功能，但启用后要确认它不会阻断网络认证页面。移动设备还应检查 VPN 断开后系统是否自动恢复到普通网络，以及后台切换网络时是否重新建立连接。

• ✅ 先完成公共 WiFi 的网页认证，再启动客户端并重新检查
• ✅ 关闭不需要的局域网共享和自动连接陌生热点
• ✅ 网络切换后重新确认 VPN 状态、DNS 路径和出口 IP
• ✅ 对重要账号启用多因素认证，避免把 VPN 当成账号安全的替代品
• ❌ 不要在公共电脑上保存订阅链接、密码或客户端登录信息

发现泄漏后按顺序排查，不要盲目换线路

如果 IP、DNS 或 WebRTC 检测出现异常，可以按照“确认连接状态—检查接管范围—检查浏览器—排除本地冲突—复测”的顺序处理。每完成一个步骤就重新测试，并记录结果。这样可以判断问题究竟来自线路、客户端、浏览器还是操作系统。

1. 确认当前只运行一个主要的 VPN 或代理客户端，并查看连接状态。
2. 确认浏览器是否使用系统代理，应用是否被规则分流到直连。
3. 检查客户端 DNS 设置、系统 DNS、浏览器安全 DNS 和路由器配置。
4. 检查 WebRTC 浏览器策略与扩展，必要时先在无扩展窗口中复测。
5. 切换网络后重新检查，区分家庭网络、公共 WiFi 和移动数据造成的差异。
6. 完成调整后测试网页、命令行、视频会议等实际使用场景。

如果只有某个网站或应用报告异常，先确认它使用的检测方法和缓存状态。部分网站会把本地局域网地址、浏览器语言、时区或其他信息统称为“隐私风险”，这不一定等同于 DNS 泄漏。若多个独立检测页面都显示本地公网出口，或者 DNS 结果持续出现本地网络服务商，则应优先检查客户端接管与系统配置。

常见问题

VPN 显示已连接，为什么 DNS 仍然可能泄漏？

“已连接”通常只代表客户端建立了连接，不代表浏览器、系统服务和所有应用都使用同一个 DNS。浏览器安全 DNS、系统备用解析、路由器强制 DNS 或规则分流都可能让解析请求走另一条路径。应检查客户端 DNS 设置与浏览器安全 DNS，并在调整后重新测试。

WebRTC 显示本地地址就一定不安全吗？

不一定。需要先判断显示的是局域网私有地址，还是连接 VPN 前的公网出口地址。局域网地址可能只是浏览器列出了本地网络接口；真正需要重点关注的是是否暴露了不应公开的公网地址。处理后还要验证视频会议和语音功能是否正常。

更换节点能解决所有泄漏吗？

不能。节点主要影响远端连接与出口，无法自动修复浏览器 WebRTC 策略、系统代理冲突或本地 DNS 配置。如果问题在设备或浏览器层面，更换线路通常不会改变结果。应先定位泄漏类型，再修改对应设置。

怎样确认修复确实生效？

不要只刷新一次页面。完成调整后关闭旧标签页，重新连接客户端，分别检查出口 IP、DNS 和 WebRTC，再在实际应用中测试。随后切换一次网络或重启客户端，确认设置不会在网络变化、系统睡眠或应用重启后失效。