使用 VPN 后，很多人会先查看出口 IP 是否发生变化，却忽略了 DNS 查询、WebRTC 通信和断线时的流量处理。表面上网页已经显示为新的网络出口，实际请求仍可能通过本地网络服务商的 DNS 服务器完成解析，浏览器也可能借助 WebRTC 暴露本地或公网地址。这样的情况不一定意味着 VPN 加密本身失效，但说明设备上的所有网络请求并没有按照预期路径处理。
DNS 泄漏检测与修复并不是只点击一次检测网站那么简单。检测结果会受到浏览器、操作系统、代理模式、IPv6、分流规则和网络切换的共同影响。本文从工作原理开始，说明如何区分 DNS 泄漏、WebRTC 泄漏与普通出口变化，再给出 Windows、macOS、Android、iOS 和 Linux 上通用的排查思路。最后还会介绍 Kill Switch、隐私政策和订阅客户端选择时应该关注的细节。
DNS 泄漏到底是什么
当你在浏览器中输入一个域名时，设备需要先把域名转换成 IP 地址，这个过程就是 DNS 解析。没有额外配置时，系统通常会使用当前 Wi-Fi 路由器、宽带运营商或移动网络提供的 DNS 服务。VPN 建立连接后，理想状态是 DNS 请求也通过加密隧道发送，由 VPN 连接对应的 DNS 服务器完成解析。如果网页流量走了 VPN，但 DNS 查询仍直接发往本地网络，就形成了 DNS 泄漏。
DNS 泄漏暴露的通常不是完整网页内容，而是设备请求过哪些域名。对于隐私保护而言，访问过的域名本身也可能构成重要信息。例如，账号登录、网银支付、医疗咨询或工作平台的域名，都可能反映用户正在使用的服务。公共 Wi-Fi 环境中的网络管理员也可能通过 DNS 请求观察连接目标，甚至对解析结果进行修改。
需要注意的是，使用第三方 DNS 地址并不自动等于安全。把 DNS 从运营商更换为公共 DNS，只能改变解析服务提供方，不能保证请求已经进入 VPN 隧道。真正需要确认的是：VPN 客户端是否接管了 DNS、系统是否还保留旧的解析路径、IPv6 是否绕过了隧道，以及分流规则是否把部分域名发送到直连网络。
90+
可选国家
200+
可选线路
14 天
退款承诺
不限
同时在线设备
DNS 泄漏、WebRTC 泄漏与普通 IP 显示有什么区别
DNS 泄漏检查的是域名解析请求由谁处理。检测页面通常会列出多个 DNS 服务器及其所属网络。如果 VPN 已连接，但结果仍显示本地宽带运营商或当前 Wi-Fi 网络的 DNS，就需要进一步检查客户端的 DNS 接管设置。检测结果中出现多个服务器并不必然是泄漏，关键在于这些服务器是否属于预期的 VPN 或安全 DNS 路径，以及它们是否与当前真实网络环境相符。
WebRTC 是浏览器用于实时音视频、屏幕共享和点对点连接的一组技术。某些浏览器或网页可能通过 WebRTC 发现设备的本地地址、网络接口信息，甚至在特定环境下发现公网地址。它与 DNS 泄漏不是同一个问题：前者涉及浏览器接口暴露地址，后者涉及域名解析路径。关闭浏览器代理、启用隐私扩展或使用不兼容的浏览器设置，都可能让 WebRTC 检查结果与普通网页出口显示不同。
普通 IP 检测只观察网页服务器看到的连接出口。如果检测页面显示的是远端线路地址，说明该页面的 HTTP 或 HTTPS 请求已经经过某种代理或 VPN 路径。但这不能代表后台应用、UDP 流量、系统更新、命令行程序和其他浏览器标签页全部采用同一路径。尤其是系统代理模式，往往只影响遵循系统代理设置的应用；TUN 或虚拟网卡模式通常能够接管更多 IP 流量，但也需要处理路由冲突和系统权限。
| 检查项目 | 主要观察内容 | 可能暴露的信息 | 优先修复方向 |
|---|---|---|---|
| 出口 IP | 网页服务器看到的公网地址 | 当前连接出口与大致地区 | 确认客户端已连接并选择正确线路 |
| DNS 请求 | 解析请求使用的服务器归属 | 访问过的域名类别 | 启用 VPN DNS、检查分流与 IPv6 |
| WebRTC | 浏览器能够发现的网络接口地址 | 本地地址或潜在公网地址 | 调整浏览器 WebRTC 权限与代理设置 |
| 断线流量 | VPN 中断后应用是否仍能联网 | 断线期间的真实连接路径 | 配置 Kill Switch 或阻断规则 |
如何进行一次可靠的在线检测
在线检测前，先关闭其他 VPN、代理软件、浏览器隐私代理和网络加速工具，避免多个程序同时修改路由或 DNS。连接目标客户端后，等待状态稳定，再分别打开出口 IP 检查、DNS 泄漏检查和 WebRTC 检查页面。检测过程中不要频繁切换线路，否则旧连接、浏览器缓存和新的解析请求可能混在一起，导致结果难以判断。
- 记录未连接 VPN 时的出口 IP、DNS 服务器归属和 WebRTC 显示内容。
- 连接 VPN 后重新加载检测页面，确认出口 IP 是否发生预期变化。
- 查看 DNS 服务器列表，重点判断是否仍出现本地运营商、家庭路由器或公共 Wi-Fi 的 DNS。
- 在浏览器隐私设置中检查 WebRTC 相关选项，再用同一页面重新测试。
- 切换一次 Wi-Fi、移动热点或有线网络，重新连接客户端后再次检查。
- 退出 VPN 或临时模拟断线，观察 Kill Switch 是否阻止了外部网络访问。
检测时最好使用浏览器的无痕窗口，或者至少清理页面后重新加载。这样做不是为了让检测结果“更好看”，而是减少缓存、扩展和旧连接对判断的干扰。若多个检测网站给出的 DNS 结果不完全相同，也不要立即认定其中一个必然错误。不同页面可能使用不同的检测请求和解析域名，应结合客户端日志、系统 DNS 设置和网络切换结果综合判断。
如果连接 VPN 后 DNS 服务器仍显示本地网络，但客户端明确支持 DNS 防泄漏功能，可以先重启客户端，再检查系统网络适配器中的 DNS 配置。Windows 可能存在物理网卡和虚拟网卡同时工作，macOS 可能保留旧的网络服务顺序，Linux 则可能由 NetworkManager、systemd-resolved 或桌面环境分别管理解析。移动设备还要留意系统的私有 DNS、分应用 VPN 和省电限制。
DNS 泄漏的实际修复步骤
修复时应按照“客户端、系统、浏览器、网络环境”的顺序逐层确认。最优先检查 VPN 客户端是否提供“防止 DNS 泄漏”“使用 VPN DNS”“远程 DNS”或类似选项。启用后重新连接，不要只保存设置而不重建连接。部分客户端只有在 TUN 模式或特定核心下才能完整接管 DNS，系统代理模式可能仍无法覆盖所有应用。
Windows 与 macOS
Windows 用户可以查看当前活动网络适配器、虚拟网卡和 DNS 服务器，确认 VPN 连接建立后默认路由与 DNS 是否发生相应变化。若物理网卡仍保留优先级更高的 DNS，或者浏览器启用了独立的安全 DNS，系统设置与浏览器设置可能出现分离。修改后应断开并重新连接，再清理 DNS 缓存进行验证。
macOS 用户应检查“网络”中的服务顺序、VPN 配置和 DNS 服务器列表。某些网络扩展需要系统授权，授权未完成时客户端界面可能显示已启动，但流量接管并不完整。睡眠唤醒、从有线切换到 Wi-Fi、从 Wi-Fi 切换到手机热点后，建议重新连接并再次检查，因为系统可能重新选择物理网络的解析路径。
Android、iOS 与 Linux
Android 上要同时关注 VPN 配置、始终开启 VPN、阻止未使用 VPN 的连接，以及系统“私有 DNS”设置。不同客户端对这些功能的处理方式不同，不能只依据一个开关名称判断是否已经生效。iOS 通常通过系统 VPN 配置接管连接，用户应检查 VPN 状态、按需连接设置和网络切换后的恢复情况。若使用分应用规则，要确认浏览器和需要保护的应用没有被排除。
Linux 环境更容易出现多个网络服务共同管理 DNS 的情况。NetworkManager、systemd-resolved、桌面网络设置和代理核心可能分别写入不同配置。排查时应先确认当前 DNS 管理者，再检查默认路由、虚拟接口和代理进程状态。使用 sing-box、Clash Verge 等兼容客户端时，还要确认导入的订阅格式与核心版本匹配；客户端能显示配置，不代表 TUN、DNS 劫持或规则路由已经成功启动。
| 平台 | 优先检查位置 | 常见原因 | 复测方式 |
|---|---|---|---|
| Windows | 网络适配器、虚拟网卡、浏览器安全 DNS | 旧 DNS 优先级更高或网卡冲突 | 重连、清理缓存并重新检测 |
| macOS | 网络服务顺序、网络扩展与 VPN 配置 | 授权未完成或睡眠后路径未恢复 | 切换网络后重新连接测试 |
| Android | 始终开启 VPN、私有 DNS、分应用设置 | 应用被排除或系统省电限制 | 检查状态栏并分别测试应用 |
| iOS | 系统 VPN 配置与按需连接 | 网络切换后配置未重新加载 | 关闭再开启 VPN 后检测 |
| Linux | 解析服务、默认路由、TUN 与核心日志 | 多个网络服务同时写入配置 | 检查路由和 DNS 管理进程 |
WebRTC 与 Kill Switch 应该怎样配置
WebRTC 泄漏主要发生在浏览器层面。用户可以在浏览器隐私设置中限制 WebRTC 暴露本地地址，或者使用可信的隐私扩展管理相关权限。配置完成后，需要完全关闭并重新打开浏览器，再进行 WebRTC 检测。不要只依赖浏览器扩展的图标状态，因为某些扩展只影响特定版本或特定请求类型。
如果你经常使用视频会议、语音聊天或网页实时通信，不建议为了隐藏地址而盲目关闭所有 WebRTC 功能。更合理的做法是限制不必要的本地地址暴露，同时确认需要使用摄像头、麦克风和屏幕共享的网站仍能正常工作。隐私设置可能影响点对点连接、设备发现和媒体传输，修改后应按真实使用场景测试。
Kill Switch 的作用是在 VPN 连接中断、客户端退出或隧道暂时失效时，阻止指定流量直接回到普通网络。它尤其适合公共 Wi-Fi、网银支付、账号登录和需要保持固定出口的工作场景。不同客户端的实现方式可能是系统防火墙规则、虚拟网卡阻断、应用级网络锁或“始终开启 VPN”。配置时要确认它保护的是全部流量，还是仅保护已被代理接管的应用。
- ✅ 在客户端中启用 DNS 防泄漏或远程 DNS，并在重连后复测
- ✅ 需要覆盖更多应用时，确认 TUN 或系统 VPN 模式已经获得权限
- ✅ 为浏览器限制不必要的 WebRTC 地址暴露，并测试会议功能
- ✅ 在公共 Wi-Fi 和账号登录场景中启用 Kill Switch
- ❌ 不要同时运行两个会修改默认路由的 VPN 或代理客户端
- ❌ 不要把“全局模式”理解为已经自动阻断所有断线流量
服务商隐私政策和客户端安全怎么看
技术设置只能减少本地网络侧的暴露，不能替代对服务商的信任判断。选择 VPN 服务时，应阅读隐私政策中关于连接日志、DNS 请求、账户信息、支付记录、故障日志和第三方处理商的说明。重点不是寻找“绝对匿名”这样的宣传语，而是确认哪些数据会被收集、保存多久、在什么情况下披露，以及用户是否能够删除或管理相关信息。
客户端来源同样重要。Windows、macOS、iOS、Android 和 Linux 用户应优先使用服务商提供的官方客户端或可信兼容客户端。Clash Verge、sing-box、Shadowrocket 等工具可以通过订阅链接导入配置，但它们负责的是本地连接管理，并不会替服务商证明日志政策。导入前要确认协议兼容性、DNS 模式、TUN 权限和规则来源；使用第三方转换服务处理订阅时，则需要承担订阅泄露的额外风险。
隐私政策还应与实际功能相互印证。例如，客户端声称支持 DNS 防泄漏，却没有相关开关、日志说明或可验证的行为，用户就应保持谨慎。服务商提供的节点数量、覆盖国家和协议类型属于连接能力信息，不等于每条线路都具备相同的隐私特性。无论使用 Shadowsocks、VMess、Trojan、Hysteria2 还是 WireGuard，都需要结合客户端实现、DNS 路由和断线保护一起判断。
如果你希望先了解客户端导入和网络设置，可以查看站内的使用教程，再根据当前设备逐项完成测试。测试记录不必包含订阅链接、账户密码或完整 IP；截图前应遮挡敏感字段，只保留能够说明问题的设置和检测结果。
DNS 泄漏常见问题
检测到本地 DNS，就一定说明 VPN 完全失效吗？
不一定。它通常说明 DNS 请求没有按照预期经过 VPN，但网页流量可能仍然使用远端出口。应分别检查出口 IP、DNS、IPv6 和应用流量，不要因为某一项异常就推断全部连接都已失效。
把 DNS 改成公共 DNS，能彻底解决泄漏吗？
不能保证。更换 DNS 只是改变解析服务，关键仍是 DNS 请求是否被 VPN 或系统 VPN 正确接管。还要考虑浏览器独立 DNS、IPv6、分流规则和网络切换后的配置恢复。
开启 Kill Switch 后为什么有些应用无法联网？
Kill Switch 可能会阻止所有未经过 VPN 的连接，包括本地网络、局域网设备或没有被客户端正确接管的应用。应先确认客户端权限、TUN 或系统 VPN 状态，再根据需要调整局域网访问和分应用规则。
更换线路后还需要重新检测吗？
建议重新检测。不同线路、协议和客户端核心可能使用不同的 DNS 策略或传输方式，切换线路后旧连接也可能暂时保留。重新连接并刷新检测页面，才能确认当前线路的实际状态。
建立一套可重复的安全检查习惯
VPN 安全不是连接按钮变成绿色就结束，而是要确认流量路径、解析路径、浏览器接口和断线行为都符合预期。首次配置时，可以先在普通网络下记录基线，再连接 VPN 检查出口 IP 和 DNS，随后验证 WebRTC，最后临时测试 Kill Switch。完成后在 Wi-Fi、移动热点和设备休眠恢复等不同状态下重复检查，才能发现只在特定网络环境中出现的问题。
日常使用中，不要频繁叠加多个代理工具，也不要为了追求更多线路而忽略客户端更新、订阅来源和隐私政策。遇到检测异常时，按照“暂停其他网络工具—确认客户端模式—检查 DNS—检查浏览器—检查 IPv6—测试断线保护”的顺序排查，通常比盲目更换节点更容易定位原因。