tech/network · 集群 A · 网络基础原理 · 4/6

TCP 与 UDP 在代理场景中的差异：握手、重传与 UDP 转发支持

TCP 和 UDP 的本质区别

TCP 和 UDP 是传输层最常用的两种协议，最核心的区别是：TCP 先建立连接、保证数据按顺序完整送达；UDP 不建立连接、发出去就不管了。这个差异决定了它们适合完全不同的应用。

可以把 TCP 想象成挂号信——每封都要签收，丢了重寄；UDP 像广播——说出去就算，没听到也不会重播。对实时通话来说，晚到的数据比丢掉的数据更没用，所以 UDP 更合适。

TCP 握手与重传对体验的影响

TCP 在发送数据前要先完成三次握手，这意味着每建立一个新连接至少要多花一个往返时间。在跨境场景下，单次往返本身就比较长，握手开销会被放大。

客户端                         服务器
  │ ── SYN ──────────────────▶ │
  │ ◀──────────────── SYN+ACK ─│   一个往返时间
  │ ── ACK ──────────────────▶ │
  │ ── 数据 ─────────────────▶ │

如果叠加 TLS 加密握手，还要再增加往返。这就是为什么跨境访问“第一次打开慢、之后快”——连接复用后省去了握手。

TCP 的重传和拥塞控制在丢包时会主动降低发送速率。当链路丢包率较高时，TCP 的吞吐量会明显下降，这也是晚高峰“能连上但很慢”的一个原因。丢包的来源与观察方法见 路由与丢包。

代理场景中 UDP 为什么更容易出问题

UDP 在代理场景中出问题的概率明显高于 TCP，原因来自三个层面：接管层、转发层和网络层。

接管层：常见的系统代理设置主要服务于 HTTP 和 SOCKS 类请求，许多应用的 UDP 流量根本不会经过系统代理，而是直接从物理网卡发出。只有 TUN 这类在网络层接管的方式，才能统一捕获 UDP，原理见 TUN 虚拟网卡原理。

转发层：即使 UDP 进入了代理内核，还要满足两个条件才能被转发——客户端配置中启用了 UDP 转发，且所用的代理协议和节点支持 UDP。如果任一环节不支持，UDP 会被丢弃或按规则直连。不同协议对 UDP 的支持方式不同，可参考 代理协议 专题。

网络层：UDP 没有拥塞控制，在一些网络中会被更严格地限速或在拥塞时优先丢弃。QoS 的原理见 QoS 队列与限速机制。

UDP 流量能否被代理的判断链：
[应用发出 UDP]
    │
    ├─ 被系统代理接管？ 通常否 → 需要 TUN
    │
    ├─ 内核 UDP 转发开启？ 否 → 丢弃或直连
    │
    ├─ 协议/节点支持 UDP？ 否 → 失败
    │
    └─ 网络对 UDP 限速？ 是 → 能通但质量差

哪些应用依赖 UDP

了解哪些应用依赖 UDP，可以帮你在排障时更快锁定方向。

• 语音与视频通话：多数实时通话软件优先使用 UDP 传输音视频流。
• 在线游戏：大部分实时对战类游戏用 UDP 同步状态，部分登录与商城仍用 TCP。
• DNS 查询：传统 DNS 使用 UDP 端口 53，DNS 处理方式见 DNS 污染是什么。
• QUIC / HTTP/3：许多主流网站已支持基于 UDP 的 QUIC，浏览器会优先尝试。
• 部分下载与同步工具：一些点对点类工具使用 UDP。

QUIC 值得单独说明。当 UDP 被丢弃时，浏览器通常会在超时后回退到 TCP，用户感受到的是“能用，但首次打开偏慢”；如果 UDP 路径不稳定，QUIC 连接反而可能比 TCP 更容易断。部分用户会在客户端规则中对 QUIC 做特殊处理，这属于个人取舍，建议在理解原理后自行决定。

如何判断 UDP 是否被正确转发

判断 UDP 是否被正确转发，核心是看客户端日志或连接面板。具体可以这样做：

1. 确认接管方式：当前是系统代理还是 TUN 模式？如果是系统代理，大部分 UDP 不会出现在客户端里。
2. 查看连接列表：在客户端连接面板中筛选 UDP 连接，看目标应用的流量是否出现。
3. 查看命中策略：UDP 连接命中了哪条规则、走了哪个策略组，是代理还是直连。
4. 检查配置开关：确认客户端或配置中 UDP 相关选项已开启，不同客户端的菜单名称可能不同且可能随版本变化。
5. 对比节点：同一配置下换几个节点测试，判断是否为特定节点不支持。

如果日志里压根看不到该应用的连接，问题在接管层；如果看到了但走了直连，问题在规则；如果走了代理但失败，问题在协议或节点支持。这种分层思路在 分层排障法 中有完整展开。

常见误区澄清

围绕 TCP 与 UDP，用户中流传着一些似是而非的说法，这里逐一澄清：

• “UDP 一定比 TCP 快”：UDP 省去了握手和重传，延迟下限更低，但在丢包较多的链路上，应用层仍要自己处理丢失的数据，实际体验不一定更好。
• “开了 UDP 转发就万事大吉”：开关只解决转发层，接管层和网络层仍可能出问题，三层要分别确认。
• “客户端延迟测试正常，UDP 就没问题”：多数延迟测试走的是 TCP 握手或 HTTP 请求，并不能反映 UDP 路径质量。
• “UDP 不通就是节点不支持”：节点支持只是条件之一，系统代理模式下 UDP 根本没进入内核的情况更常见。

这些误区的共同点，是把多层问题简化成单一原因。保持“逐层确认”的习惯，比记住任何一条结论都更有用。

小结

TCP 与 UDP 的差异不只是课本知识，它直接决定了“为什么网页能用而语音不行”这类常见问题的答案。记住三个检查点——接管层是否捕获、转发层是否支持、网络层是否限速——基本就能覆盖大多数 UDP 故障。

如果你在选择服务时关心 UDP 与协议支持，可以在 机场品牌库 中查看各品牌的协议资料，或用 对比工具 并排查看。资料中的协议若标注为待核实，请以服务商最新说明为准；所有数据本站未实测。