一提代理,多数人的第一反应是”帮网页请求换个出口”,也就是转发 TCP 流量。可语音通话、视频会议、部分实时联机场景用的是另一种协议——UDP,它没有”连接”的概念,转发起来完全是另一套逻辑。如果代理方案不支持 UDP,这些应用要么直接报错,要么悄悄退回备用路径,表现就是”网页能用,语音不通”。
UDP 走代理,和 TCP 不是一回事
TCP 的套路:先握手,再传数据
TCP 是面向连接的协议,客户端与目标之间要先完成三次握手建立一条明确的会话,之后数据按顺序可靠到达。代理转发 TCP 时,只需把这条会话”原样接住”再送往目标,谁先谁后、丢没丢包都清清楚楚。
UDP 的麻烦:没有”连接”可言
UDP 是尽力而为的报文协议,每个数据报都是独立的,自带目标地址和端口,发出去就不管了,不保证顺序、不保证到达。代理想转发它,必须先解决一个基本问题:它该把这份数据报往哪里送?TCP 靠会话就能确定目标,UDP 则需要在转发路径上额外记录”这个客户端想要的目的地”。
| 对比项 | TCP 走代理 | UDP 走代理 |
|---|---|---|
| 有无连接 | 先建会话再传数据 | 无连接,报文独立 |
| 目标怎么确定 | 会话建立时已明确 | 需代理额外记录映射 |
| 丢包处理 | 自动重传保证到达 | 不重传,丢了就丢了 |
| 典型应用 | 网页、文件传输、登录 | 语音、实时通信、部分联机 |
SOCKS5 的解法:UDP ASSOCIATE
SOCKS5 协议专门为 UDP 设计了一个机制,叫 UDP ASSOCIATE。流程大致是:客户端先通过一条 TCP 控制连接向代理发出 UDP ASSOCIATE 请求,代理收到后分配一个 UDP 端口并告知客户端;之后客户端把要发送的数据报发给这个端口,并在报文头部附上真实的目标地址,由代理转发出去;返回的应答也由代理送回给客户端。控制连接保持存活,映射就不失效。
- 端口与地址必须一致:代理分配的 UDP 端口只认”绑定它的那台客户端”,换地址或换端口会被丢弃
- 会话会超时:控制连接或映射长期无流量,代理可能回收端口,需要重新协商
- 防火墙别漏放:不少网络环境只放行常用端口,UDP 高位端口不通,表现就是”通道建立了却收不到数据”
- 做好丢包预期:UDP 本身不保证可靠,链路拥挤时语音断续、画面卡顿属正常现象,先查线路再看配置
UDP 能走代理,但它从来不是”免费赠送”的——要么协议支持,要么应用自己封装,总得有人负责把它接住。
与 IP 代理的关系:是否支持 UDP,是评估代理方案时要问清的关键参数。网页浏览类业务只走 TCP,普通代理足够;而语音、实时通信这类应用依赖 UDP,就必须确认代理对 UDP 的转发能力,否则出口换了、功能却缺一块。选型时把”业务跑什么协议”和”代理支持什么协议”对齐,比单纯比较出口数量更有意义。所有安排都应服务于正常的业务运营,不用于违反目标平台规则的目的。