WebRTC连接包含两条完全不同的路径：信令常通过HTTPS、WebSocket或SSE交换Offer、Answer和ICE Candidate；音视频媒体则通过ICE选择UDP、TCP或TURN中继路径。网页登录、房间加入和信令都正常，不代表媒体网络可达。
WebRTC主要组件
| 组件 | 作用 | 代理边界 |
|---|---|---|
| 信令服务 | 交换SDP与ICE Candidate | 可经过HTTP代理或反向代理 |
| STUN | 发现公网映射地址 | 通常使用UDP，也可有不同传输 |
| TURN | 在直连失败时中继媒体 | 支持UDP、TCP或TLS取决于服务 |
| ICE | 收集、检查并选择候选对 | 决定最终媒体路径 |
普通HTTP代理为什么只解决一部分
浏览器访问信令API和WebSocket可以通过企业HTTP代理，但WebRTC媒体通常优先UDP。HTTP CONNECT不等于通用UDP隧道。因此企业网络里常见“页面能打开、通话一直连接中”。
STUN能做什么，不能做什么
STUN帮助客户端了解NAT映射并生成服务器反射候选，但不转发媒体。某些NAT和防火墙无法利用STUN建立对等路径，尤其是地址和端口映射严格变化的环境。此时需要TURN。
对称NAT为何更难直连
对称NAT可能针对不同目的地分配不同公网端口，STUN得到的映射不能直接用于另一个Peer。再加上入站过滤，Candidate检查会失败。不要通过修改浏览器IP或伪造Candidate解决，应提供可靠TURN中继。
TURN需要开放哪些传输
理想情况下支持UDP中继；严格企业网络可能只允许TCP或TLS到批准端口。TURN over TLS可更容易通过部分出口，但媒体在TCP上会受到队头阻塞，丢包时延迟可能上升。应同时测试UDP、TCP和TLS候选。
TURN凭据怎样保护
公开固定用户名和密码会被滥用中继带宽。应使用短期凭据、签名机制或受控Token服务，限制有效期与配额。日志只记录匿名会话、区域、传输和错误，不保存完整凭据和媒体内容。
ICE Candidate应该看哪些类型
Host、Server Reflexive、Peer Reflexive和Relay Candidate分别代表本地、STUN映射、检查中发现和TURN中继。排查时观察候选收集是否完整、哪类候选对成功，以及最终协议和区域，不应公开用户完整内网地址。
为什么TURN连上但音视频仍卡
中继可达只解决连接。还需检查往返延迟、抖动、丢包、可用带宽、编码码率和CPU。TURN区域离用户太远、出口拥塞或TCP回退都会影响质量。应使用WebRTC统计中的RTT、Packets Lost、Jitter和码率。
WebSocket断线会影响媒体吗
已建立媒体可能暂时继续，但重新协商、成员变化和ICE Restart依赖信令。信令代理的空闲超时和心跳仍需正确配置。WebSocket排查可参考代理下WebSocket握手、心跳与重连。
IPv6会提高直连率吗
端到端IPv6可能减少NAT障碍，但企业防火墙、浏览器和TURN仍需支持。双栈网络会并行产生多类候选，不应通过永久关闭IPv6隐藏错误。记录最终候选协议和地址族即可。
测试矩阵
- 同一局域网测试Host Candidate；
- 不同家庭网络测试STUN直连；
- 严格NAT环境验证TURN UDP；
- 阻断UDP后验证TURN TCP/TLS；
- 测试信令断线与ICE Restart；
- 测量不同TURN区域的RTT与丢包；
- 验证短期凭据过期和带宽限制。
结论
WebRTC代理故障必须把信令与媒体分开。HTTP代理能让页面和信令联网，却无法自动承载UDP媒体；完整方案依赖STUN发现、TURN中继、短期凭据和多传输质量测试。
