WebRTC 检测显示本地 IP 或真实公网 IP，算泄漏吗？
WebRTC 用 ICE 收集可通信候选地址，本地地址、mDNS 名称、映射地址和中继地址含义不同。只有请求绕过预期代理并暴露直连公网出口，才是问题。
先看重点先看地址类型：192.168/10/172.16 等私网地址或随机 .local 名称不等于公网出口泄漏；代理节点的公网地址也属预期。若 WebRTC 页面显示本地运营商公网 IP，而你要求浏览器所有流量经代理，且 Clash 日志没有对应连接，才有绕过信号。
WebRTC 为语音、视频和点对点通信寻找可用路径，会通过 ICE 收集候选地址。W3C 规范明确提醒，这些地址可能透露设备位置和本地网络拓扑；IETF 也专门定义了浏览器应如何平衡通信能力与 IP 隐私。
检测页把候选地址列出来，不代表每一项都是“真实 IP 泄漏”。要看地址类别、归属和你的代理目标。
先分清页面列出的地址
| 检测结果 | 通常表示什么 | 能否直接判定泄漏 |
|---|---|---|
192.168.x.x、10.x.x.x、172.16–31.x.x |
家庭或公司局域网地址 | 不能，它不是公网出口 |
随机名称加 .local |
浏览器用 mDNS 隐藏本地主机地址 | 不能，说明隐私处理正在生效 |
| 与代理节点一致的公网 IP | 候选连接从代理出口出去 | 通常符合预期 |
| 与关闭代理时相同的运营商公网 IP | 可能存在直连候选 | 需要结合日志和实际连接复核 |
| TURN/relay 地址 | WebRTC 中继服务器 | 不等于你的本地 IP |
ICE 会尝试 host、server-reflexive 和 relay 等候选路径。页面出现候选地址与最终媒体实际选中哪一对路径也不是同一件事。
做三组相同条件的对照
在同一浏览器、同一页面和同一网络下分别测试：客户端关闭、只开系统代理、只开 TUN。每次完全关闭旧标签页再打开，并同步查看 Clash 日志。
- 系统代理出现运营商 IP、TUN 后消失：WebRTC 的 UDP 路径可能没有使用 HTTP 系统代理；
- 两种代理模式都显示节点出口：代理接管符合预期；
- 页面显示运营商 IP，但日志也有对应请求：还要确认页面列的是候选还是实际选中路径；
- 地址仅是私网或
.local：不要为了“零结果”关闭整个浏览器通信能力。
为什么网页代理正常，WebRTC 仍可能不同
系统代理主要处理愿意使用 HTTP/SOCKS 入口的应用请求。WebRTC 的 ICE 可使用 UDP，并不保证遵循浏览器网页的 HTTP 代理路径。TUN 接管层更低，更有机会覆盖这类流量，但仍要确保 IPv4、IPv6、UDP 和默认路由都进入虚拟网卡。
这和 DNS 泄漏是两件事：DNS 关心域名查询由谁处理，WebRTC 关心实时通信候选地址与实际媒体路径。
怎样修复真正的直连候选
先关闭其他 VPN 和代理扩展，只保留一个客户端。若你需要 WebRTC，又要求它经过代理，优先测试客户端 TUN，并在日志中确认 UDP/候选服务器请求被接管。节点本身不支持 UDP 时，WebRTC 可能退回 TCP/中继或直接失败，不能靠浏览器设置凭空补足。
浏览器或受管设备可能提供限制 WebRTC IP 处理的策略；这类策略会降低点对点连接成功率。只有明确不需要 WebRTC 时，才考虑在浏览器层禁用相关能力。不要安装来历不明、要求读取全部网页数据的“防泄漏”扩展。
什么才算验收通过
不是检测页空白，而是：没有出现本地运营商公网出口；实际通话或测试连接仍能工作；Clash 日志能解释候选服务和媒体连接；切换 Wi‑Fi、睡眠唤醒后结果仍一致。只刷新一次得到绿色提示，证明力度不够。
若页面显示的是本地 IPv6 而非 WebRTC 候选类型，参阅IPv6 泄漏的判定方法。
资料来源
以下来源于 2026/8/8 复核。版本、支持平台和发布状态以后续官方页面为准。
持续更新
收到新教程，也欢迎纠错
想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。
读者互动
这篇内容对你有帮助吗？
最新评论
- 正在加载评论……