在当今网络环境中，UDP（用户数据报协议）在代理中的应用引发了诸多关注。本文将详细阐述 UDP 在代理中的各种疑惑及解决方案。
一、WebRTC 及其泄露问题
WebRTC（Web Real-Time Communication）即网页实时通信，是一个支持网页浏览器进行实时语音对话或视频对话的技术。它在实现实时通信的同时，也可能会泄露用户的真实 IP 地址。原因在于其与 UDP 有关。在普通网页浏览中，会发起多个 HTTP 请求加载资源，但检测 WebRTC 泄漏的网页会发起一条 stun 请求以建立 WebRTC 连接，而 stun 协议一般使用 UDP 传输。由于系统代理一般是 HTTP 代理，不支持代理 UDP 数据，所以这条 UDP 请求走直连，导致 WebRTC 泄露真实 IP。即使使用支持代理 UDP 的 socks5 协议，主流浏览器也不支持将 UDP 流量交给 socks5 代理，依然存在泄露风险。解决方法是使用插件禁用浏览器的 WebRTC 功能，或者使用透明代理让 UDP 流量走代理。
二、UDP 代理的方式及应用场景
- 原生 UDP 和 UoT
- 目前代理 UDP 的方式主要分为两种：一种是 socks5 和 SS 的原生 UDP，clash 加密 UDP 数据后直接通过 UDP 将数据发送给节点服务器；另一种是 vmess、vless、trojan 等协议使用的 UDP over TCP（UoT），以 Vmess 为例，数据被封装在 TCP 中再发给节点服务器。
- 原生 UDP 不适合线路差的 VPS，因为 UDP 没有拥塞控制机制，易被运营商 QoS，且出于安全考虑，给 SS 节点加上了 UoT 功能。如果线路好，原生 UDP 和 UoT 差距不大；如果线路差，UoT 更合适，还能套 CDN；若线路很差又对 UDP 有要求，可使用有加速效果的协议，但易被运营商 QoS。
- 游戏应用
- 对于游戏党而言，可选择购买游戏加速器，若有自己搭建的需求，选择好的线路如 CN2 GIA 很关键。直接使用 socks5 代理打游戏不一定会被封，但要确保不访问黑名单网站。
三、P2P 联机与 UDP 穿透
- P2P 联机方式及 UDP 打洞
- 目前游戏的通讯种类主要分为中心服务器和 P2P 联机，P2P 连接是玩家之间直接相互传输数据，需要先知道对方的公网 IP，通过 stun 服务器进行 UDP 穿透（NAT 穿透）。
- 如果拨号获取到的是公网 IP，可以通过修改路由器 NAT 的映射行为和过滤行为实现 fullcone（全锥），对于 P2P 而言最容易实现 UDP 打洞。但由于 IPV4 地址枯竭，很多人获取的是内网 IP，运营商 NAT 行为一般是最严格的对称 NAT，很难打洞成功，可通过 UDP 中继解决。
- 实现 fullcone 的方法
- 通过客户端和服务端的配合实现 fullcone，目前 fullcone 支持最好的是 xray 内核，服务端可使用基于 xray 内核的 x-ui 搭建，VPS 需要开放 1024 – 65535 的 UDP 端口。客户端建议使用 xray，因为 vmess 和 vless 的 fullcone 在 xray 中是通过 XUDP 实现的。可以通过 NATtypetester 工具检测当前的 NAT 类型。
四、HTTP3 与 QUIC 协议的问题
目前主流浏览器都支持 HTTP3，基于 QUIC 协议，而 QUIC 是基于 UDP 的。浏览器配置系统代理时会关闭 QUIC 功能，使用基于 TCP 的 HTTP2 访问网站；开启透明代理后，访问 YouTube 会使用基于 UDP 的 QUIC 协议，但如果线路不好，会出现卡顿或性能影响。普遍做法是禁用浏览器的 QUIC 功能或屏蔽 443 端口的 UDP 数据，但屏蔽端口会先发起 DNS 请求导致泄露，所以建议直接禁用浏览器的 QUIC 功能，也可使用系统代理。
总之，UDP 在代理中的应用涉及多个方面，需要根据实际情况选择合适的代理方式和解决方案，以确保网络安全和良好的使用体验。
