媒体通道防穿透

WebRTC 候选地址检查

WebRTC 协议通过 STUN/TURN 服务器建立点对点通信，可能绕过常规应用层代理直接探测底层网卡公网地址。通过分析收集到的 ICE candidate 类型，排查真实 IP 穿透隐患。

诊断目标：WebRTC ICE 候选与真实公网暴露排查● 未开始

工具回答的问题：浏览器在音视频通信时，是否会因 WebRTC STUN 流程绕过代理、暴露真实家庭宽带 IP？

测试前说明与 STUN 端点：本测试仅在您主动启动后，通过公开受控的 STUN 服务器 (stun:stun.l.google.com:19302) 生成候选。测试完毕后立即关闭并销毁 RTCPeerConnection 对象，不保留连接。

候选类型说明：host (本机局域网/mDNS) | srflx (STUN反射公网地址) | relay (中继)

如何理解 WebRTC 检测结果？

1. srflx 候选地址：这是 STUN 服务器观察到的你的对外公网 IP。如果你开了全局代理，但这里的 srflx 地址却显示为你本地宽带运营商 IP，说明你的 UDP 流量绕过了代理直接穿透直连（即 WebRTC 泄露）。

2. 防范方法：在 Chrome/Firefox 中可安装 WebRTC Control 插件禁用非代理 UDP，或者在 Clash Verge 等客户端开启 TUN 模式并接管全局 UDP 流量。

WebRTC 穿透原理与 ICE 候选类型深度解析

理解 host、srflx 与 relay 三种候选机制，彻底封堵跨国会议或游戏中的真实 IP 泄露。

1. 什么是 ICE 候选？为什么代理常常“防不住”WebRTC？

常规浏览器代理（如 SwitchyOmega 或系统代理设置）只接管 HTTP/HTTPS 协议流量；而现代网页中的音视频通话（如 Google Meet、Discord、Zoom 网页版）采用 WebRTC 架构，使用底层的 UDP 协议向 Google 或公共 STUN 服务器发起 NAT 打洞探测请求。若代理软件不支持 UDP 转发，操作系统会直接走本地物理网卡把真实公网 IP 透露给 STUN 服务器，并在 SDP 握手报文中返回给目标网站。

2. 三步根治 WebRTC 真实 IP 泄露

① 开启客户端 TUN 虚拟网卡模式：在 Clash Verge Rev 或 sing-box 中启用 TUN 模式，确保所有 UDP 报文被虚拟网卡接管加密送往节点；
② 检查节点是否支持 UDP 转发：若节点不支持 UDP（例如廉价中转屏蔽了 UDP 53/3478），WebRTC 依然可能降级直连；
③ 浏览器策略加固：在 Chrome 扩展商店安装「WebRTC Control」或在 Firefox 的 about:config 中将 media.peerconnection.enabled 设为 false。