VPN泄漏测试 在线检测WebRTC和DNS泄漏
在线 VPN 泄漏测试工具：检测 WebRTC 是否暴露你的真实 IP，对比公网 IP 与 VPN 出口地址，判断 VPN 是否真正隐藏了你的位置。
更新于 2026-08-16
相关工具
功能特性
- WebRTC 泄漏检测：通过视频通话同款的 ICE 候选收集机制，检查 VPN 开启时是否有私有地址（192.168.x.x、10.x.x.x）泄露出去
- STUN 公网 IP 检测：Google 和 Cloudflare 两台 STUN 服务器回报互联网看到的地址，方便与 VPN 出口服务器对比
- mDNS 保护状态：Chrome 和 Edge 会把真实内网 IP 隐藏成 .local 名称，工具明确告诉你浏览器是在保护你，还是像 Firefox 一样暴露原始地址
- 清晰的结果判定：泄漏/受保护/不明确/失败四种结论，每种都给出具体下一步，而不是一堆裸 IP
- 诚实的 DNS 范围：纯静态页面无法真正测 DNS 泄漏（需要服务器解析唯一域名），工具如实说明并给出命令行和在线服务替代方案
- VPN 优先流程：推荐先连 VPN 再测试，把公网 IP 与提供商显示的出口服务器对比
- 不收集任何个人数据：检测完全在浏览器本地完成，结果不出页面，隐私检测工具本身就该这样
- 桌面与移动端通用：Chrome、Edge、Firefox、Safari 均支持，浏览器差异会在结果中解释
使用方法
- 1先连接 VPN，再打开本页。没开 VPN 测试显示的是运营商 IP，这是正常现象，不算泄漏。
- 2点「开始泄漏检测」，保持页面在前台。测试会收集约 4 秒的 ICE 候选。
- 3看公网 IP 卡片：VPN 开启时，这个地址应与你 VPN 应用里显示的出口服务器一致。
- 4看局域网 IP 那一栏：出现 192.168.x.x 或 10.x.x.x 说明 WebRTC 暴露了真实网络地址；显示 *.local 说明浏览器隐藏了它。
- 5判定为泄漏时：在浏览器设置里禁用 WebRTC（Chrome 的隐私内容设置）或安装 WebRTC 拦截扩展，然后重测。
- 6用第二台设备对比：同一 VPN 下两台设备的公网 IP 应一致，都不应出现私有地址。
- 7换 VPN 服务器后重测：切换国家后公网 IP 应随之改变，且内网 IP 始终不暴露。
- 8DNS 部分按提示操作：真正测 DNS 泄漏用命令行 dig +short whoami.akamai.net（macOS/Linux）或 nslookup myip.opendns.com（Windows），本页无法自己解析域名。
- 9浏览器升级后重测：浏览器版本更迭会改变 WebRTC 行为，去年的干净结果值得重新确认。
常见问题
什么是 VPN 泄漏测试？
VPN 泄漏测试检查你的真实 IP 或 DNS 查询是否逃出 VPN 隧道。本工具测 WebRTC 部分：收集浏览器在视频通话时会发送的 ICE 候选，查找 VPN 开启时本应隐藏的私有地址（192.168.x.x、10.x.x.x）。结果干净意味着浏览器只暴露了 VPN 控制的地址。
为什么这个工具不能测 DNS 泄漏？
不能。真正的 DNS 泄漏测试需要服务器解析一个唯一域名并报告哪个 DNS 服务器应答了，纯静态浏览器页面没有服务器做这件事。本工具诚实地只测 WebRTC。测 DNS 泄漏请用有后端的服务（如 dnsleaktest.com、ipleak.net），或命令行：Unix 用 dig +short whoami.akamai.net，Windows 用 nslookup myip.opendns.com。
为什么测试时浏览器暴露了 192.168.x.x？
局域网一栏出现 192.168.x.x、10.x.x.x 或 172.16-31.x.x，说明 WebRTC 正在暴露你的真实内网地址。Firefox、旧版 Safari 以及关闭了 mDNS 的 Chromium 默认就会泄漏。按顺序修复：更新浏览器（Chrome 和 Edge 已默认隐藏）、在浏览器设置里禁用 WebRTC、或安装 WebRTC 拦截扩展，然后重测。
局域网一栏显示 *.local 是什么意思？
.local 地址是 Chrome 和 Edge 生成 mDNS 混淆名，代替你的真实内网 IP，例如 6f8c-4a2b-1c9e.local。只看到 .local 地址意味着浏览器在保护你免受 WebRTC 泄漏。Firefox 和 Safari 不做这种混淆，所以它们可能显示原始私有 IP。
VPN 能阻止 WebRTC 泄漏我的 IP 吗？
不能。WebRTC 可以绕过 VPN 隧道直接向系统要内网地址，这正是泄漏测试存在的原因。VPN 对普通 HTTP 流量隐藏 IP，但启用 WebRTC 的浏览器仍可能暴露私有地址甚至真实公网 IP。修复在浏览器侧：禁用 WebRTC 或使用拦截扩展，任何 VPN 设置都挡不住它。
为什么结果里出现两个不同的 IP 地址？
公网 IP 来自 STUN 服务器，是互联网看到的地址；内网一栏的私有地址来自 host 候选，是你真实的网络地址。两者同时出现说明 WebRTC 泄漏了私有地址。只看到公网 IP、内网一栏显示 *.local 或为空，说明泄漏已堵住。
看到 10.x.x.x 或 172.16.x.x 就是真实 IP 泄漏吗？
是。这些是 RFC 1918 私有网段，出现意味着网站可以通过 WebRTC 获知你的内网地址，即使 VPN 开着。泄漏范围限于局域网地址而非公网 IP，但仍会暴露设备所在网络，削弱 VPN 的隐私预期。禁用 WebRTC 或装拦截扩展后重测。
Windows 或 Mac 上怎么检查 DNS 泄漏？
Windows 打开命令提示符运行 nslookup myip.opendns.com，Server 行显示应答的 DNS 服务器；macOS 或 Linux 运行 dig +short whoami.akamai.net 并对比 VPN 的 DNS。如果应答服务器属于你的运营商而不是 VPN，就存在 DNS 泄漏，应开启 VPN 自带的 DNS 保护。
为什么 Safari 显示私有 IP 而 Chrome 显示 .local？
Safari 对 WebRTC host 候选的 mDNS 混淆与 Chrome、Edge 不同，可能暴露原始私有 IP。Safari 14.1 之后加入了一定保护，但各版本行为不一。跨浏览器一致的修复是禁用 WebRTC 或用扩展拦截。
我的 VPN 提供商说没有泄漏，还要测吗？
要。VPN 提供商保证的是自家隧道的防泄漏，但 WebRTC 泄漏发生在浏览器里，不在 VPN 的控制范围内。提供商技术上可以零泄漏，你的浏览器却照样暴露私有 IP。本工具的检测结果取决于浏览器而非 VPN，这就是同一 VPN 在 Chrome 里干净、在 Firefox 里泄漏的原因。
为什么每次测试结果不一样？
ICE 候选收集不是确定性的：浏览器在几秒内陆续收集候选，STUN 服务器响应速度不同，部分候选会在测试窗口关闭后才到达。如果判定在几次运行间反复，测三次并相信最差的一次，因为一次泄漏就足以构成问题。
禁用 WebRTC 会影响视频通话或其他网站吗？
会。完全禁用 WebRTC 会让浏览器里的视频通话、屏幕共享和部分聊天功能失效。这是有意的取舍：彻底防泄漏对完整功能。折中方案是带站点白名单的拦截扩展，视频通话网站仍可用 WebRTC，其余网站保持拦截。
浏览器扩展真的能阻止 WebRTC 泄漏吗？
能。WebRTC Leak Prevent 或 uBlock Origin 的高级模式会强制浏览器禁用非代理 WebRTC 或剥离私有候选，在浏览器层面堵住泄漏。安装后重跑本测试：内网一栏应显示 *.local 或为空，而不是私有 IP。
这个测试会收集或存储我的 IP 吗？
不会。检测完全在浏览器本地运行：STUN 交换发生在你的浏览器和 STUN 服务器之间，结果只在页面渲染，不会发送到任何地方。本站没有分析钩子也没有服务器日志，这正是隐私检测工具该有的样子。看到的 IP 只显示在你自己的页面上，关掉标签页就消失。
VPN 会泄漏个人隐私吗？
VPN 本身不会主动泄漏隐私，但泄漏可能来自三处：WebRTC 让网页绕过 VPN 直接读取你的内网 IP（本工具检测的正是这个）；DNS 请求走了运营商服务器（需要服务端检测）；以及 VPN 服务商自己的日志政策。连接 VPN 后运行本工具，公网 IP 应与 VPN 出口一致、内网 IP 不暴露，即通过 WebRTC 检测。
为什么公网 IP 显示 IPv6 地址？
因为代理可能只接管了部分协议族。STUN 服务器同时有 IPv4 和 IPv6 地址，浏览器优先使用可用的 IPv6 连接，于是 STUN 看到的源地址就是实际出口的 IPv6 地址。它可能是代理出口，也可能（代理未接管 IPv6 时）是你的真实地址。请与代理应用显示的出口 IP 对比：一致说明 IPv6 走代理；不一致说明该协议族直连，需要在代理中开启对应协议族支持后重测。
为什么网页查 IP 和这个工具的结果不一样？
因为两条路径不同：查 IP 的网页通过 TCP/HTTP 访问服务器，走的是浏览器代理设置；本工具通过 UDP 连接 STUN 服务器，走的是网络协议栈的 UDP 路径。如果网页显示代理出口 IP 而这里显示真实 IP，说明你的代理只接管了 TCP，UDP 流量直连，这是代理客户端 UDP 规则或节点协议不支持 UDP 的典型表现。修复：在代理客户端检查 UDP 规则（Clash 类客户端常见 DIRECT），或改用支持 UDP 的节点协议（WireGuard、Trojan、Hysteria2）。