一、为什么浏览器代理环境下无法使用 WebRTC UDP？

大多数人第一次遇到 WebRTC 在代理环境中无法使用时，通常会以为是 VPN 或浏览器的问题。但真实原因是：

浏览器在检测到系统代理（HTTP / HTTPS / SOCKS5）后，会主动禁用 QUIC 与 WebRTC 的 UDP 能力。

原因包括：

• HTTP/SOCKS 代理不一定支持 UDP
• WebRTC 的 UDP 可能绕过代理导致隐私泄露
• 浏览器策略层面为了安全会强制使用 TCP 替代

结果就是：STUN 无法工作、srflx candidate 获取失败、TURN 只能走 TCP、媒体流延迟巨大。

二、恢复 WebRTC UDP 的唯一正确方式：TUN 透明代理

浏览器只能在以下情况下继续正常使用 UDP：浏览器必须认为自己“直连网络”，即不经过代理。

解决方案：使用 sing-box 或 Clash Meta 在系统层开启 TUN，使所有 TCP/UDP 透明接管，让浏览器无感知。

三、使用 sing-box 启用 WebRTC UDP（推荐方式）

1. 启用 TUN 模式

sing-box 的 tun 入站可以彻底透明化所有网络流量，使浏览器无需设置任何代理即可被透明接管。

{
  "tun": {
    "enable": true,
    "stack": "system",
    "auto_route": true,
    "auto_route_ipv6": true
  }
}

2. 配置出站以支持完整 UDP 转发

{
  "outbounds": [
    {
      "type": "vmess",
      "server": "example.com",
      "port": 443,
      "uuid": "xxxx",
      "udp_fragment": true,
      "domain_strategy": "prefer_ipv4"
    }
  ]
}

关键字段 udp_fragment 可防止 WebRTC 较大的 DTLS/SRTP 包被分片丢弃。

3. 验证 WebRTC 是否恢复 UDP

访问测试页面：

https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

正确结果应包含：srflx (udp)、relay (udp)

四、使用 Clash Meta 支持 WebRTC UDP（次优但可行）

1. 启用 TUN

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true

2. 确保代理节点启用 UDP 支持

proxies:
  - name: proxy
    type: vmess
    server: example.com
    port: 443
    uuid: xxxx
    udp: true

注意：开源版 Clash 不支持 UDP，必须使用 Meta 内核。

五、WebRTC 在代理下的真实网络流向解析

浏览器 → UDP → 系统网络栈 → TUN → sing-box/clash → 代理节点 → 公网 → STUN/TURN 服务器

由于浏览器并不知道自己通过代理发送数据，因此不会禁用 WebRTC UDP。

六、常见问题与排查

1. 没有 srflx：说明 STUN 包没真正发出去 → 检查节点 UDP 支持
2. relay 只有 TCP：TURN UDP 被阻断 → 可能是运营商或代理实现不完整
3. WebRTC 延迟高：说明 WebRTC 回落到 TCP → 检查是否启用了 TUN
4. Clash 不生效：可能不是 Meta 内核

七、总结

要让浏览器在代理环境下保持 WebRTC UDP 能力，必须使用 TUN 透明代理，让浏览器“以为”自己直连网络。

sing-box 是当前最稳定、对 UDP 支持最强的方案；Clash Meta 也能满足大多数场景。