WebRTC 泄漏检测：你的 VPN 是否泄露了真实 IP？
本 WebRTC 泄漏检测工具采用与商业追踪脚本完全相同的对等连接机制，实时验证浏览器所暴露的地址中，是否存在本应由 VPN 严格隐藏的真实网络信息。该工具通过建立包含空白数据通道的 RTCPeerConnection（全程无需调用摄像头、麦克风，亦无授权弹窗），向两个公共 STUN 服务器发起探测以获取外网连接视角，并将其与接收你常规 HTTPS 请求的 IP 地址进行严格比对。
如何看懂检测展示的 ICE 候选地址
WebRTC 协议为了寻找两端设备能够建立直连的所有网络通路，会自动收集并生成一份 ICE 候选地址（ICE candidates）列表。本页面将展示完整的原始列表，标明每项的候选类型与传输协议，并在 5 秒探测窗口结束后自动停止监听。
表格上方清晰列出了通过 HTTP 协议获取的标准 IPv4 与 IPv6 地址 — 其数值与我的 IP 地址是什么页面的结果完全一致。这构成了对比基准，最终结论正是源于两者的异同。
host、srflx 与 relay — 标签代表什么含义
- 本地（host） — 本机网卡自身拥有的地址：通常为局域网 IP（如
192.168.1.14）或随机混淆的.local域名。 - 公网（通过 STUN） —
srflx（Server Reflexive）候选，即 STUN 服务器观测到数据包抵达的公网入口。这是使用 VPN 时最关键的判定点。 - 中继（TURN） — 经由第三方中继服务器转发的通信；因本页面仅配置 STUN 服务器，正常情况下极少出现此类候选。
各项检测结论的具体解读
- 检测到泄漏 — STUN 捕获的公网候选地址与你的 HTTP IP 不一致；在开启 VPN 时，这意味着 WebRTC 数据包绕过了加密隧道。
- 无泄漏 — 两侧测得的公网 IP 完全一致，隐匿隧道运作正常。
- 本地 IP 暴露 — 列表中直接显露了明文局域网私网 IP，未启用 mDNS 混淆。
- 受保护 — 本地内网地址已被随机生成的
.local域名完全匿名化。 - 无公网 IP / WebRTC 已阻断 — STUN 服务器不可达，或浏览器已彻底禁用 WebRTC 协议。
为什么 WebRTC 会泄露本已被 VPN 隐藏的 IP
WebRTC 标准制定的初衷是为了实现浏览器与浏览器之间低延迟的音视频通话及文件 P2P 直传。在跨越不同路由器 NAT 设备时，它必须获悉连接从外部视角来看来自哪个具体公网地址。STUN 服务器专职解答这一疑问，且任何网页均可通过 JavaScript 在后台无感发起此类探测。
当你希望隐匿真实网络身份时，这便构成了致命盲区。全系统 VPN 会将主流 HTTP 流量导入虚拟网卡隧道，然而 WebRTC 会向 STUN 独立发射专属 UDP 数据报文；一旦遭遇分流或分流机制不健全，UDP 往往直接直连默认网关。浏览器插件类 VPN 是最为典型的重灾区：它们通常仅充当网页代理，根本无法接管操作系统底层的 UDP 协议栈 — 这正是检测结果可能与纯 HTTP 方式的 VPN 检测结论相互矛盾的根本原因。
随机的 .local 主机名并非泄漏
若 host 候选列中显示类似 7b3f9c21-4d0a-48e7.local 的字符串而非明文 192.168.1.14，这完全属于正常且安全的现象。这是主流浏览器推行的 mDNS 混淆机制：浏览器为本地网卡生成临时单次多播 DNS 域名予以替代。Chrome、Edge、Brave、Firefox 与 Safari 均已默认集成此防护 — uBlock Origin 亦因此在 v1.38 版本中移除了自建 WebRTC 选项。需要明确的是：mDNS 仅能保护局域网私网地址，无法阻止公网 VPN 泄漏；且一旦用户授予了摄像头或麦克风权限，网页依然可依法读取真实的局域网私有 IP。
如何在 Chrome 与 Edge 中修复 WebRTC 泄漏
这两款 Chromium 浏览器均未在常规图形界面中提供一键关闭开关，且 chrome://flags 与 edge://flags 也已删除了相关实验性禁用选项。目前行业推荐以下三种行之有效的应对方案：
- 使用系统级全量隧道（Full-Tunnel）VPN 客户端，摒弃单薄的浏览器代理插件。只要确保操作系统全部 UDP 流量强制入轨，STUN 无论如何只能观测到虚拟节点的 IP。
- 安装拓展强制锁定 IP 路由策略。例如 WebRTC Leak Prevent 等扩展并不直接拦截协议，而是将底层
chrome.privacy.network.webRTCIPHandlingPolicy参数锁定为default_public_interface_only或disable_non_proxied_udp，彻底杜绝内网旁路。 - 通过注册表或策略组部署系统策略。Chrome 可配置
WebRtcIPHandling；Edge 则可在注册表SOFTWARE\Policies\Microsoft\Edge下指定WebRtcLocalhostIpHandling为AllowPublicInterfaceOnly或DisableNonProxiedUdp。修改需重启浏览器，可在edge://policy验证。
如何在 Firefox 中彻底禁用 WebRTC
Firefox 是主流桌面浏览器中唯一保留底层原生硬开关的软件。在地址栏输入 about:config 并确认风险提示，搜索配置项 media.peerconnection.enabled 并双击将其修改为 false。修改立即全局生效无需重启，此时所有网站的 WebRTC 通信将全面阻断，本页面将提示连接被阻止。
注意该操作属于全局一刀切方案：网页版腾讯会议、Google Meet、Teams、Discord 与 Zoom 直连将无法工作。若需在保留实时音视频通话的同时保障安全，建议将上述项保持为 true，转而将 media.peerconnection.ice.default_address_only 设为 true — 这将限制 Firefox 仅汇报默认路由出口（即 VPN 隧道出口）。
如何在 Brave 中防范 WebRTC 泄漏
Brave 浏览器在用户界面中直接还原了被 Chrome 隐藏的控制权。打开 brave://settings/privacy，滚动找到 WebRTC IP handling policy（WebRTC IP 处理策略）。在开启 VPN 或代理时，关键配置项如下：
- Default（默认） — 枚举所有网卡，可能暴露出真实的内网私有地址。
- Default Public and Private Interfaces（默认公网与私网） — 虽仅用默认路由，但仍会呈现对应的内网私有 IP。
- Default Public Interface Only（仅默认公网接口） — 仅采用默认出口网卡，隐藏内网地址，音视频正常工作。适合作为日常首选推荐。
- Disable Non-Proxied UDP（禁用非代理 UDP） — 强制要求走 TCP 代理；若代理不支持 UDP 则直接阻断。这是最严苛的防护级（Brave Tor 窗口的默认行为），但可能影响 P2P 连通率。
Safari、iPhone 与 Android 设备的特殊考量
在移动端和苹果 WebKit 生态中，常规的 PC 端方案往往不再适用。
macOS 上的 Safari
现代 Safari 已取消了持久的全局禁用开关。开发菜单中的 WebRTC 相关选项仅在当前运行会话内临时有效。Safari 默认对内网私有地址施加 mDNS 混淆，直到被赋予相机或麦克风权限。因此最有效的手段是在 Safari > 设置 > 网站 中收紧权限，并搭配全局系统级 VPN。
iPhone 与 iPad (iOS/iPadOS)
iOS 平台上的所有第三方浏览器（无论是 Chrome 还是 Firefox）底层均被强制使用苹果 WebKit 内核，无法开启 about:config，亦无扩展机制；内容拦截器（Content Blockers）亦无法过滤 WebRTC。唯一的防护方案是在 设置 > VPN 中使用支持全量 UDP 代理的系统级 VPN 协议，并在 Safari 中重新测试。
Android 安卓系统
Android 版本的 Chrome 既无扩展也无 WebRTC 标志位；而 Android 版 Brave 则完整保留了前述的 IP 处理策略设置。Firefox 手机版仅在 Nightly 与 Beta 分支开放 about:config。系统层级方案是在安卓系统设置中打开 始终开启的 VPN 并勾选 阻止未使用 VPN 的连接。
本检测工具无法探测的盲区与边界
本页面仅能如实反映浏览器内部 JavaScript 执行环境所能探知的信息。它无法察觉操作系统底层引发的非浏览器流量外泄（如未被代理劫持的后台系统服务、或者 VPN 忽略的 IPv6 泄漏通路），亦不涵盖 DNS 泄漏探测。若本地防火墙拦截了 STUN 报文，界面会提示「无公网 IP」，这并不代表绝对安全，仅表明探针未获回执。此外，IP 地址仅是数字身份的一环：通过 我的浏览器是什么 所揭示的屏幕参数、字体列表与系统特征，即便处于洁净的 VPN 环境下同样能被高级指纹追踪算法识别锁定。
常见问题解答
连上了 VPN 之后，WebRTC 还会泄露真实 IP 吗？
完全有可能。WebRTC 会向 STUN 服务器自主发送专属的 UDP 数据报文。在使用分流规则缺陷的客户端或普通的浏览器插件代理时，这些 UDP 流量会绕过代理直接走本地真实运营商网关。STUN 服务器便会记录并回传真实 IP，网页只需一段普通 JS 代码即可无感读取。系统级全局 VPN 客户端能彻底解决此漏洞。
有没有办法在 Edge 浏览器中彻底关闭 WebRTC？
通过普通设置界面无法关闭：Edge 未设置总开关，早期的 about:flags 隐藏配置项也已被官方移除。在 Windows 环境下，可在注册表 SOFTWARE\Policies\Microsoft\Edge 中部署组策略 WebRtcLocalhostIpHandling 并设为 AllowPublicInterfaceOnly 或 DisableNonProxiedUdp。保存后重启浏览器生效，可在 edge://policy 查看状态。
在 Firefox 中应该去哪里禁用 WebRTC 和 PeerConnection？
在地址栏输入 about:config：检索配置项 media.peerconnection.enabled 并双击切换为 false。无需重启浏览器即刻全局禁用 WebRTC，但在线音视频会议将无法连接。若希望兼顾通话功能，建议保持开启，并将 media.peerconnection.ice.default_address_only 改为 true 即可。
如何能够在 Safari 中永久关闭 WebRTC？
当前主流版本的 Safari 无法持久性完全关闭该功能。早年开发者菜单下的实验性开关已被移除，现有的选项在每次浏览器重启后均会重置。鉴于 Safari 已原生对局域网私有地址执行 mDNS 混淆，最实用的对策是在“Safari > 设置 > 网站”中封锁权限，并搭配系统级全局 VPN 掩盖公网痕迹。
在 Brave 浏览器中防止 WebRTC 泄漏的最佳设置是什么？
进入 brave://settings/privacy，将 WebRTC IP handling policy 调整为“Disable Non-Proxied UDP”。此时 WebRTC 将通过代理走 TCP 通信，STUN 服务器绝无可能探知你的真实地址。若担心 P2P 会话无法建立，“Default Public Interface Only”则是保障通话且隐藏内网的实用折中之选。
我究竟应该选择哪种 WebRTC IP 处理策略？
绝大多数用户推荐选择“Default Public Interface Only”：它完美封堵了内网私网地址，保留了 UDP 协议栈，音视频呼叫不受任何影响。仅当身处不可靠网络、对匿名性有严苛需求且使用代理时，才建议选择“Disable Non-Proxied UDP”。默认的两项策略均存在泄露风险，不建议维持默认。
为什么我的私有局域网 IP 地址会被 WebRTC 暴露在公网上？
在最新的主流浏览器中，明文暴露已成为历史。Chrome、Edge、Brave、Firefox 与 Safari 均已将内网 IP 替换为以 .local 结尾的单次随机 mDNS 主机名，网页仅能读取到混淆后的代码。若本检测工具直接抓取到了明文的 192.168.x.x，说明浏览器的安全机制异常或处于失防状态。