很多用户在使用 快连 时会发现一个现象：网页浏览、视频播放一切正常，但一旦打开游戏、语音通话或视频会议，就会出现延迟飙升、声音断续、画面卡住甚至直接连不上。换了好几个节点也没用，重装客户端也无效。问题往往不在节点质量，而在于传输层协议——具体来说，是 TCP 和 UDP 在代理链路中的处理方式不同。
快连作为网络代理工具，需要在本地接收应用发出的流量，再通过加密隧道转发到远端节点，最后由节点代发到目标服务器。这个过程中，TCP 流量和 UDP 流量的代理路径并不相同。TCP 有连接状态、有重传机制，代理实现相对成熟；UDP 是无连接协议，代理时需要对每个数据包单独封装和转发，实现复杂度和兼容性要求都更高。如果分流规则没有正确区分两者，就很容易出现"网页能开、游戏不能玩"的情况。
本文将从 TCP 与 UDP 的基本差异讲起，分析哪些应用依赖 UDP、哪些必须走 TCP，再给出快连中 UDP 分流的配置思路和 UDP over TCP 的取舍建议。无论你是游戏玩家、远程办公用户，还是只想让视频通话更稳定，都能从中找到对应的调整方向。
一、TCP 与 UDP 在代理中的核心差异
TCP 和 UDP 是互联网传输层的两大协议，它们的设计目标完全不同。
TCP：可靠但开销大
TCP 面向连接，提供顺序保证、重传机制和拥塞控制。代理 TCP 流量时，本地客户端可以与代理端口建立稳定的连接，代理端再与远端节点建立另一条连接，两边各自维护状态。这种"连接对连接"的模型实现成熟，兼容性好，几乎所有代理协议都优先支持 TCP。
UDP：轻量但无状态
UDP 无连接，不保证送达、不保证顺序，适合对实时性要求高、能容忍少量丢包的场景。代理 UDP 时，代理端需要为每个 UDP 会话维护映射关系，把本地发出的数据包封装后转发，再把返回的数据包解封装送回本地。这个过程对代理实现的性能、NAT 穿透能力、节点支持度都有较高要求。
代理链路上的表现差异
| 维度 | TCP 代理 | UDP 代理 |
|---|---|---|
| 连接模型 | 面向连接，状态清晰 | 无连接，需会话映射 |
| 兼容性 | 几乎所有节点支持 | 取决于节点和协议是否开启 UDP 转发 |
| 延迟特性 | 握手和重传带来额外延迟 | 无握手，延迟更低，但丢包不重传 |
| 典型问题 | 队头阻塞、重传放大延迟 | 节点不支持时直接失败，或表现为超时 |
理解了这些差异，就能明白为什么有些应用走快连正常、有些异常。不是快连"偏心"，而是应用本身依赖的协议决定了它对代理链路的要求不同。
二、哪些应用强烈依赖 UDP
以下类型的应用如果 UDP 转发不通，通常会出现明显异常，甚至完全无法使用。
1. 在线游戏
绝大多数多人在线游戏使用 UDP 传输实时位置、动作和状态。UDP 的低延迟特性适合高频小包传输，TCP 的重传和队头阻塞会导致操作延迟、人物瞬移。如果快连没有正确转发 UDP，游戏可能卡在登录界面、匹配失败，或者进入后延迟极高。
2. 语音与视频通话
微信语音、Discord、Teams、Zoom、腾讯会议等实时通信工具，媒体流普遍优先使用 UDP。UDP 不通时，部分应用会自动回退到 TCP，但音质和延迟会明显变差；另一些应用则直接提示"网络连接失败"。
3. 游戏主机与串流
PS Remote Play、Steam Link、Moonlight 等串流工具对 UDP 依赖很强。UDP 不通时，画面卡顿、花屏、手柄输入延迟会非常明显。
4. QUIC 与 HTTP/3
现代浏览器和部分应用使用 QUIC（基于 UDP 的 HTTP/3）。如果 UDP 被阻断，浏览器会自动回退到 TCP 的 HTTP/2，通常不影响访问，但会损失 QUIC 带来的连接建立速度和弱网优势。部分应用如果强制使用 QUIC 且没有回退逻辑，就可能直接失败。
5. DNS over UDP
传统 DNS 查询使用 UDP 53 端口。如果 UDP 转发异常，域名解析会变慢或失败，表现为"网页打不开但 ping IP 正常"。
三、哪些应用必须走 TCP
与 UDP 相反，以下场景对可靠性要求高，必须使用 TCP。
- 网页浏览（HTTP/HTTPS）：虽然 HTTP/3 使用 UDP，但大多数网站仍以 TCP 为主，且浏览器会自动回退。
- 文件传输：FTP、SFTP、SMB、WebDAV 等依赖 TCP 的顺序和重传保证。
- 邮件收发：SMTP、IMAP、POP3 均基于 TCP。
- 远程登录：SSH、RDP、VNC 需要稳定连接，TCP 是默认选择。
- 包管理器与代码仓库：git、npm、pip、apt 等大多走 TCP，部分支持 HTTP/3 但非必需。
这些应用如果被错误地强制走 UDP 或 UDP over TCP 转换，反而可能引入额外开销和不稳定。所以分流策略的核心不是"全部走 UDP"或"全部走 TCP"，而是"按应用类型分别处理"。
四、快连中的 UDP 分流配置思路
快连客户端通常提供"UDP 转发"或"UDP 支持"相关开关，部分版本还支持按应用或按规则分流。配置时建议遵循以下思路。
步骤一：确认节点是否支持 UDP
并非所有节点都开启 UDP 转发。如果节点不支持，即使本地开启了 UDP 转发，流量也会失败或回退。可以在快连节点列表中查看节点说明，或先用一个已知支持 UDP 的节点测试。
步骤二：开启 UDP 转发总开关
在快连设置中找到"UDP 转发""UDP 支持"或类似选项并开启。这是让游戏、语音等应用能够走代理的前提。
步骤三：按应用或按规则分流
如果快连支持分应用代理或自定义规则，可以把游戏、语音应用单独指向支持 UDP 的节点，把浏览器、下载工具指向普通节点。这样既能保证实时应用的低延迟，又不会让所有流量都承担 UDP 转发的开销。
步骤四：处理 UDP over TCP 回退
部分代理协议在 UDP 不通时会尝试把 UDP 流量封装进 TCP 传输（UDP over TCP）。这种方式能提高兼容性，但会引入额外延迟和队头阻塞，不适合对实时性要求高的游戏。如果发现游戏延迟异常但能连上，可以检查是否启用了 UDP over TCP，必要时关闭。
步骤五：验证分流是否生效
可以用游戏内的延迟显示、语音通话的质量、或网络诊断工具观察 UDP 流量是否正常。如果某个应用仍然异常，再单独检查该应用的规则和节点支持情况。
五、UDP over TCP 的取舍
UDP over TCP 是一种折中方案：把 UDP 数据包封装在 TCP 连接中传输，从而绕过对 UDP 转发的依赖。它的优点是兼容性好，几乎所有节点都支持；缺点是引入了 TCP 的重传和队头阻塞，延迟和抖动会明显增加。
适用场景：
- 节点不支持 UDP，但应用必须使用 UDP 才能工作。
- 网络环境对 UDP 有限制，TCP 更容易穿透。
- 对延迟不敏感、但对连通性要求高的场景。
不适用场景：
- 竞技类游戏、实时语音、视频会议等对延迟敏感的应用。
- 已经确认节点支持原生 UDP 转发的情况。
六、常见问题解答
Q1：为什么网页能打开，但游戏一直连接失败？
网页主要走 TCP，游戏主要走 UDP。如果快连的 UDP 转发未开启，或当前节点不支持 UDP，游戏就会连接失败。建议开启 UDP 转发并更换支持 UDP 的节点。
Q2：开启 UDP 转发后，网速会变慢吗？
UDP 转发本身不会显著降低带宽，但会增加代理端的处理开销。如果节点性能不足，可能出现 UDP 流量不稳定。可以根据实际体验选择是否对非实时应用也开启 UDP。
Q3：DNS 查询走 UDP 还是 TCP？
传统 DNS 默认走 UDP 53 端口，大响应或区域传送时回退到 TCP。如果发现域名解析异常，可以检查 UDP 转发是否正常，或在快连中启用加密 DNS（DoH/DoT），后者通常走 TCP 443 或 853。
Q4：视频会议用 UDP 还是 TCP？
大多数视频会议工具优先使用 UDP 传输媒体流，UDP 不通时回退 TCP。UDP 模式下延迟更低、抗丢包更好；TCP 模式下可能出现画面卡顿和声音延迟。建议为视频会议应用开启 UDP 转发。
Q5：如何知道某个应用走的是 TCP 还是 UDP？
可以在系统资源监视器、防火墙日志或抓包工具中查看连接协议。Windows 资源监视器的"网络"选项卡会列出每个进程的 TCP/UDP 连接；macOS 可用 nettop 或 Wireshark 观察。了解应用的协议类型，有助于判断分流规则是否配置正确。
七、总结
快连的 TCP/UDP 分流不是"越复杂越好"，而是"按需分配"。网页、文件传输、远程登录等可靠性优先的场景走 TCP；游戏、语音、视频通话、QUIC 等实时性优先的场景走 UDP。配置时先确认节点支持 UDP，再开启 UDP 转发，必要时按应用分流，最后根据实际体验决定是否启用 UDP over TCP 作为兜底。
理解协议差异后，很多"节点不行""快连不稳定"的困惑都会迎刃而解。如果你在配置过程中遇到问题，可以查阅 快连官网常见问题 页面，或参考 快连技术博客 中的协议相关文章。保持客户端为最新版本也很重要，新版通常会改进 UDP 转发的兼容性和性能，可通过 快连下载 页面获取全平台安装包。