打开 WebRTC 泄露检测页，原本应该显示 192.168.x.x 或 10.x.x.x 的位置，现在却变成一串类似 8f2c1a9e-7d3b-4f5a-9e1c-...local 的随机主机名。很多运营人员的第一反应是：检测页坏了，或者 WebRTC 被关了。其实都不是。

这串 .local 名称，是浏览器按 IETF 的 mDNS ICE 候选规范（draft-ietf-rtcweb-mdns-ice-candidates）对“host 候选”中的内网地址做的随机化替换。也就是说，WebRTC 本地 IP 并没有消失，只是网页脚本可读的内容从“数字地址”变成了“随机名称”。真正要回答的问题是：这个机制替换了什么、没替换什么，以及你还得单独核对哪些东西。

检测页里那串 .local 到底是什么

把 mDNS 候选放在 WebRTC 协商的背景里看，事情会更清楚。WebRTC 建立连接前，会收集一组“ICE 候选”，每一个候选代表一种可能的网络路径。mDNS 只对其中一类候选生效，而检测页把多类候选混在一起展示，才造成了误读。

三类 ICE 候选：host、srflx、relay 各自暴露的是哪个地址

按 MDN 对 RTCIceCandidate.type 和 address 属性的定义，WebRTC 的候选地址分三种：

• host（主机候选）：设备本机物理或虚拟网卡上的地址，通常是 192.168.x.x、10.x.x.x 这类私有 IP。
• srflx（服务器反射候选）：由 STUN 服务器观测到的 NAT 公网出口地址和端口，也就是数据从你的网络出去后，在公网一侧看到的地址。
• relay（中继候选）：由 TURN 服务器分配的中继转发地址，数据经 TURN 服务器中转后使用这个地址。

三种候选来源不同，暴露的对象也不同。检测页一般会按类型排列，但如果只看“有没有内网 IP”来判断是否泄露，就会漏掉后两种候选携带的信息。

mDNS 主机候选做了什么

根据 mDNS ICE 候选规范，浏览器会动态生成一个 UUID.local 主机名，替换 host 候选里的私有 IP。目的很明确：防止网页脚本通过读取局域网 IP，把同一台设备在不同站点、不同账号之间关联起来，形成跨会话指纹。

关键在于：候选仍然存在，连接协商也照常进行，只是网页侧拿到的是一串名称，而不是直接可读的地址。mDNS 是一种“混淆”而不是“删除”，通信能力没有被移除。所以看到 .local 时，应该理解为“host 候选已被保护”，而不是“WebRTC 已关闭”。

RFC 8828 怎么看 WebRTC 的地址暴露

RFC 8828 是 WebRTC IP 地址处理需求的规范。它提到，如果缺乏限制，WebRTC 在建立 P2P 连接时，可能向网页应用暴露两类常规 HTTP 请求拿不到的信息：一是多网卡公网 IP 和局域网私有地址，二是绕过 HTTP 代理的 UDP/STUN 直连通道。

也就是说，规范讨论的范围比“内网 IP 是否可见”要宽。mDNS 方案对应的是“私有地址”这一类；而 UDP 直连通道和公网出口地址，属于另一类需要单独处理的问题。把两者混为一谈，是许多配置误判的起点。

mDNS 没有解决的问题：公网出口地址仍由 STUN/TURN 与代理链路决定

这是核心。WebRTC 本地 IP 被 mDNS 替换后，srflx 候选仍可能暴露公网出口地址。mDNS 混淆只作用于 host 候选的内网 IP，无法掩码或替换 STUN/TURN 探测生成的 srflx 与 relay 地址。如果浏览器发出的 UDP/STUN 请求没有进入你配置的代理隧道，而是直连网络，那么 STUN 服务器看到的公网出口 IP 就会原样出现在 srflx 候选里。此时检测页即使不显示内网 IP，srflx 一栏也会写出真实的出口地址。

所以，“检测页没有内网 IP”只能说明 host 候选已被 mDNS 保护，不能推出“代理配置正确”。代理是否生效，要看 srflx 或 relay 的读数是否与你预期的出口一致。

三个不同层面：本地 IP 掩码、代理出口一致性、平台风控判定

把常被混为一谈的三件事分开：

第一层：浏览器是否按规范对 host 候选做了 mDNS 替换。这是浏览器行为，与你的代理配置无关。只要看到 .local，就说明这一层是正常的。

第二层：srflx/relay 读数是否与你配置的代理出口一致。这是链路配置问题。如果 srflx 显示的地址与代理出口不符，说明有流量绕过了代理，需要回查代理类型、UDP 转发设置和系统路由。

第三层：平台如何判定账号。这是平台侧的综合模型，由设备、网络、行为、支付等多维度信号共同决定。我们没有依据断言任何主流平台把 WebRTC 内网 IP 单独作为关联判定依据，也不应把 WebRTC 泄露描述成封号的直接原因。单一网络参数不能决定风控结果。

在 NexBrowser 环境里的两项独立核对项

在 NexBrowser 的独立浏览器环境中，你可以把下面两项作为开号前自检的检查项，分开记录：

一是该环境配置的 HTTP/HTTPS/SOCKS5 代理是否与预期出口一致。这个可以通过代理出口检测工具单独验证，不依赖 WebRTC 检测页。

二是浏览器侧 WebRTC 候选读数本身：host 候选是否显示为 .local 名称，srflx 候选显示的地址是什么。把它作为环境记录的一部分，与代理出口读数并列，而不是用一张检测页截图代替全部结论。

NexBrowser 提供独立的浏览器环境与代理配置管理，支持按环境分别设置代理；以上两项核对在环境内可以独立完成，互不替代。需要说明的是，这里不涉及任何 WebRTC 屏蔽或候选伪造能力，我们不建议把“隐藏 WebRTC”当作降低风控风险的手段。

常见误读清单

最后用一个清单收束：

• 看到 .local 是正常掩码结果，不是检测页失效，也不是 WebRTC 被关闭。
• srflx 显示的地址与预期代理出口不一致，才是需要回查代理与 UDP 链路的信号。
• 不同第三方检测页对候选字段的展示方式和评分口径并未由公开标准统一规定。同样的网络环境，A 站显示“有风险”、B 站显示“正常”，不一定代表配置出了问题，更可能是字段口径和评分算法不同。

下次开号前自检，建议把 WebRTC 候选读数与代理出口读数分成两栏分别记录。看到 srflx 地址与预期出口不符时，先回查代理类型、UDP 转发和系统路由，再决定是否调整环境，而不是仅凭一张检测页截图下结论。