WebRTC指纹防泄漏：mDNS 只遮住本地 IP，真正要核对的是 STUN 有没有走代理

一个常见场景：检测页 WebRTC 显示 .local，出口 IP 却对不上

运营人员打开环境检测页，看到 WebRTC 一栏显示 xxx.local 或「未泄漏」，心里却还是不踏实：真实出口 IP 到底会不会被读到？如果 WebRTC 真的安全，为什么有些环境里，检测页显示的地址和 HTTP 请求的出口 IP 对不上？

这个疑问背后，其实是 W3C 在 2026 年 7 月更新的 WebRTC 规范草案带来的认知变化——它强调了对 ICE 候选地址的隐私保护，但 mDNS（.local）掩码只解决了第一层问题，真正决定公网出口 IP 是否暴露的，是 STUN 请求有没有随浏览器一起走代理。

先看公开事实：W3C 2026 年 7 月 WebRTC 规范草案更新说了什么

W3C 于 2026 年 7 月更新了 WebRTC 规范草案，重点强调针对 NAT 穿透与 ICE 候选的地址隐私保护。但需要留意的是，在非权限申请场景下，mDNS（.local）掩码仅作用于本地 host 候选层面，也就是把内网 IP 替换成 .local 主机名。它并不会阻断 STUN 跨代理的 UDP 请求直连公网——也就是说，srflx 候选（服务器反射地址）可能暴露真实公网出口 IP。

简单说，这次草案更新关注的是「ICE 候选地址的隐私」，但 mDNS 不是万能的。它管得住内网 IP，管不住 STUN 探测得到的公网地址。上述内容源自 W3C《WebRTC: Real-Time Communication in Browsers》规范文档（2026 年 7 月版本）。

第一层：本地地址——mDNS 把内网 IP 换成 .local，解决的到底是什么

要理解 mDNS 的作用边界，先要明白 host 候选是什么。WebRTC 在建立连接前会收集本机所有可用的网络地址，其中直接绑定在网卡上的 IP 就是 host 候选，包括局域网内的私有地址，比如 192.168.1.5。

在早期 WebRTC 实现里，这些内网 IP 可能被网页读取，造成局域网信息泄露。mDNS 掩码的作用，就是把这些 host 候选中的内网 IP 替换成类似 random-id.local 的主机名，让网页无法直接拿到你家的路由器内部地址。

但请注意：这一层被处理好，只代表局域网地址不再直接外泄，与公网出口 IP 是否暴露是两回事。mDNS 只影响 host 候选，而 srflx 候选是 STUN 服务器返回的公网地址，并不在 .local 掩码的覆盖范围内。

第二层：ICE 候选与 STUN 路由——srflx 的公网地址从哪来，为什么可能绕过代理

ICE 候选通常有三类：host、srflx、relay。

• host 候选：本机网卡的 IP（内网或公网直连地址）。
• srflx 候选：通过 STUN 服务器反射得到的公网地址，代表浏览器看到的「出口 IP」。
• relay 候选：通过 TURN 服务器中转的地址，通常用于 NAT 穿透失败时。

srflx 候选是 WebRTC 用来与对端建立 UDP 通道的关键。浏览器会向 STUN 服务器发送一个绑定请求，STUN 服务器在回包中携带「从公网看到的源地址」，这就是 srflx。整个过程走的是 UDP。

问题来了：如果你在代理客户端（如 SOCKS5/HTTP 代理）中只配置了 TCP 转发，或者浏览器扩展只接管 HTTP 流量，UDP 流量不会被代理接管。这种情况下，STUN 请求就会绕过 SOCKS5/HTTP 代理，直接通过本机网络发送到 STUN 服务器，服务器返回的公网地址就是你本地宽带或移动网络的真实出口 IP。

所以，mDNS 做得好，不等于 STUN 不走代理。STUN 的 UDP 请求是否随代理路由，才是决定 srflx 是否暴露真实 IP 的关键。这一机制层描述参考自一份 2026 年 1 月公开发布的 WebRTC 泄漏防护研究资料（见文末资料边界）。

配了 SOCKS5 代理，WebRTC 还会泄漏吗？ 会。只要该 SOCKS5 链路未承载 UDP（或客户端未开启 UDP 转发/强制路由），STUN 的 UDP 请求就会绕过代理直连，srflx 读到的仍是本机真实公网 IP。

第三层：出口一致性——WebRTC 读到的地址与 HTTP 出口是不是同一个

既然 srflx 代表 WebRTC 看到的公网地址，HTTP 请求又是另一个出口（经过代理的 IP），那么判断 WebRTC 是否真正防泄漏，最可靠的判据不是检测页上写「未泄漏」，而是对比两个值：

1. 当前网页通过 WebRTC 获取的 srflx 公网 IP。
2. 当前网页通过 HTTP 请求显示的公网出口 IP（比如访问一个 what-is-my-ip 服务）。

要知道 WebRTC 是否真的泄漏了真实 IP，靠的就是这一步并排比对，而不是检测页上的那句结论。如果两个 IP 完全一致，说明 UDP 流量和 TCP 流量走了同一条链路，这一层过关；如果不一致，说明 STUN 请求绕过了代理，真实 IP 已暴露。

这就是 WebRTC 泄漏真实 IP 怎么检测的实际操作。不要只看 .local 或「未泄漏」，那是第一层的结果；要主动去核对第三层的出口一致性。

关闭 WebRTC 是不是更安全：能力边界与副作用

不少运营人员选择直接关闭 WebRTC，认为这样能杜绝所有可能的泄漏。从减少 API 暴露面的角度，关闭确实有用——网页拿不到任何 WebRTC 相关的地址信息，自然也就没有 srflx 泄漏的问题。

但关闭 WebRTC 属于「不提供数据」，而不是「提供一致数据」。关闭后 WebRTC 相关接口不再返回数据，这一状态本身也是一种可被读取的特征，与「提供一致数据」是两种不同的处理思路。同时，关闭 WebRTC 可能带来副作用：

• 依赖音视频通话的站内功能（如客服、直播互动）无法使用。
• 部分页面可能检测到 WebRTC 不可用，从而影响功能可用性。

因此，关闭 WebRTC 是否划算，要看你的业务是否需要音视频能力。如果你只做常规的图文运营，关闭或许是一种选择；但如果你需要直播或语音沟通，就得权衡功能损失与安全收益。至于指纹浏览器里的 WebRTC 该怎么设置，与其纠结开关本身，不如先确认 STUN 的 UDP 流量是否随代理走。

按层定位的自检顺序：先判断问题出在掩码、STUN 路由还是出口一致性

如果你发现 WebRTC 读数与 HTTP 出口不一致，可以按三层顺序排查：

1. 第一层：检查是否还能读到内网段地址。如果能读到 192.168.x.x 之类的 IP，说明 mDNS 掩码没生效；如果显示 .local，说明 host 候选已被掩码。
2. 第二层：观察 srflx 候选是否出现，以及它的地址来源。如果 srflx 显示的是本地宽带 IP，而代理出口是另一个 IP，说明 STUN 请求绕过了代理。
3. 第三层：比对 srflx 出口与 HTTP 出口，如果不一致，问题出在 UDP 路由。

针对第二层的问题，STUN 请求不走代理时可以做什么？先检查代理客户端是否开启 UDP 转发或强制路由，如果当前代理类型不支持 UDP，可考虑更换为支持 UDP 转发的代理类型。部分代理客户端提供 UDP 转发或强制路由选项，但是否默认开启、以何种方式实现，各服务商差异较大，需以自身链路实测为准。另外，多数情况下，浏览器扩展通常只代理 HTTP，不处理 UDP，所以扩展代理模式下更容易出问题。

第三层是否一致，是最终的判断标准。如果 srflx 出口与 HTTP 出口一致，即使检测页显示 .local，也可以认为这一环境在 WebRTC 层面没有直接暴露真实 IP。

团队多环境的典型问题：系统级 VPN 叠加、扩展式代理、多环境共用同一出口

在团队运营中，问题往往更复杂。常见的错配有三种：

• 系统级 VPN 叠加浏览器代理：VPN 接管整个系统网络，但浏览器代理又指定了另一个出口，导致 TCP 和 UDP 可能走不同的链路。比如 VPN 的出口是 A IP，而 HTTP 代理是 B IP，WebRTC 的 STUN 会走系统 VPN 的 UDP，结果 srflx 显示 A IP，与 HTTP 出口 B IP 不一致。
• 浏览器扩展式代理：这类扩展一般只接管 HTTP/HTTPS 流量，对 UDP 无能为力，所以 STUN 请求会直连本地网络，暴露宽带 IP。
• 多环境共用同一出口：如果一个代理 IP 被多个环境使用，这些环境的 WebRTC 读数会趋同——所有环境的 srflx 都是同一个 IP，这反而可能成为环境关联的信号。

这些情况不一定是 WebRTC 本身的问题，而是网络链路配置导致的。排查时不妨带上 UDP 的因素，而不是只检查 HTTP。

在 NexBrowser 环境里做代理绑定与出口地址交叉核对

NexBrowser 支持按环境独立绑定 HTTP/HTTPS/SOCKS5 代理，使「这个环境的 HTTP 出口」与「这个环境的 WebRTC srflx 读数」成为可交叉核对的一组数据。单环境核对动作分两步：

1. 进入环境，打开检测页，记录 WebRTC srflx 的公网 IP。
2. 记录同一环境的 HTTP 请求出口 IP，比对两者是否完全一致。

如果环境数量多，逐个打开检测页既费时又容易漏。NexBrowser 提供 Local API，可用于程序化调起并管理环境，把逐个点开检测页的人工动作改为可重复的例行抽检；具体比对仍需由你自己的脚本读取 WebRTC 与 HTTP 出口结果完成。NexBrowser 不提供泄漏判定或风控结论，是否泄漏仍需以实测比对结果为准。

常见说法对照、一页可抄的核对清单与资料边界

最后，用一张表纠正两个流行误解，并给出可直接使用的核对清单。

三层核对清单：

1. 第一层（host）：检测页 WebRTC 是否显示 .local？如果有内网 IP，说明 mDNS 未生效。
2. 第二层（srflx）：srflx 候选的来源 IP 是否与代理出口一致？如果不一致，检查 UDP 转发或强制路由设置。
3. 第三层（出口一致性）：WebRTC srflx 公网 IP 与 HTTP 请求出口 IP 是否完全相同？一致才算这一层过关。

资料边界： 本文技术结论仅基于以下两类公开资料，不涉及任何平台内部检测规则：

• W3C《WebRTC: Real-Time Communication in Browsers》规范文档（2026-07-30）
• 公开的 WebRTC 泄漏防护研究资料（2026-01-15）

各代理服务商对 UDP 的支持方式存在差异，请以自身链路实测为准。本文未覆盖具体平台检测细节、封号案例或风控阈值，关闭 WebRTC、mDNS 等做法的适用场景与副作用需结合自身业务判断。