Clash 中的 TCP 与 UDP：协议差异、代理模式与性能调优

📡 TCP 与 UDP 协议基础

TCP（传输控制协议）和 UDP（用户数据报协议）是互联网传输层的两个核心协议。TCP 提供面向连接、可靠、按序到达的字节流服务，而 UDP 提供无连接、不可靠但低开销的数据报服务。简单来说：TCP 像打电话，需要建立连接、确认信息；UDP 像发信件，直接发送，不管对方是否收到。

特性	TCP	UDP
连接方式	面向连接（三次握手）	无连接
可靠性	确认重传、流量控制	不保证送达
顺序保证	有序传输	可能乱序
头部开销	20 字节	8 字节
典型应用	HTTP/HTTPS、FTP、SSH	DNS、视频通话、在线游戏

在代理环境中，这两个协议的处理方式差异巨大，直接影响性能和应用兼容性。

⚙️ Clash 如何对待 TCP 和 UDP？

Clash 核心本身支持对 TCP 和 UDP 流量的分别控制。在配置文件中，你可以通过 port（HTTP/HTTPS 代理）和 socks-port（SOCKS5 代理）来监听 TCP 连接，而 UDP 支持则依赖于 SOCKS5 或透明代理模式。默认情况下，系统代理模式仅代理 TCP 流量（浏览器 HTTP 请求等），UDP 流量不会自动被代理，除非启用 TUN 或 TPROXY 等模式。

💡 关键点： 如果你只是设置了系统代理（如 Windows 的“代理”设置），那么只有支持代理协议的 TCP 应用会走 Clash，UDP 流量（如游戏、DNS 查询）依然直连本地网络。

在规则层面，你可以为 TCP 和 UDP 使用不同的策略组。例如，让 DNS（通常走 UDP 53 端口）使用可靠的节点，而普通浏览使用延迟更低的节点。

🌐 透明代理模式：REDIRECT、TPROXY、TUN

要想代理 UDP 流量，必须让 Clash 在网络层“接管”所有数据包。这需要用到透明代理技术，常见的有三种：

REDIRECT（仅 TCP）

REDIRECT 是 Linux 上最简单的透明代理方式，通过 iptables 将 TCP 连接重定向到 Clash 的端口。但它无法处理 UDP，因为 Linux 内核的 REDIRECT 模块不支持 UDP。

TPROXY（支持 TCP + UDP）

TPROXY 是更强大的透明代理技术，可以在不修改原始目标地址的情况下同时代理 TCP 和 UDP。它在 Linux 上需要内核支持，并且需要通过路由策略或 iptables 的 TPROXY 目标实现。Clash 配合 TPROXY 可以完美代理游戏、DNS 等 UDP 应用。

# 示例：使用 iptables 和 TPROXY 转发 UDP 流量给 Clash
iptables -t mangle -A PREROUTING -p udp --dport 53 -j TPROXY --on-port 7892 --tproxy-mark 0x1/0x1

TUN 模式（跨平台，完整接管）

TUN 模式创建虚拟网卡，将三层 IP 包完整交给 Clash 处理，自然支持 TCP 和 UDP。在 Clash Verge Rev 等客户端中，开启 TUN 模式即可一键代理所有流量，包括 UDP。这是目前最通用、最省心的方案，但需要处理虚拟网卡的路由配置。

详细 TUN 设置与优化请参阅《TUN 模式原理与优化指南》。

🎮 游戏场景：UDP 是关键

大多数网络游戏使用 UDP 协议来传输实时位置、射击判定等数据，因为低延迟比绝对可靠更重要。如果只代理了 TCP，游戏的 UDP 数据包将绕过代理，导致 高延迟、丢包，甚至无法连接服务器。

解决方案：

启用 TUN 模式（推荐），让所有流量包括 UDP 都经过 Clash。
在规则中为游戏服务器域名或 IP 段指定专门的 url-test 策略组，自动选择低延迟节点。
如果游戏使用特定端口，也可使用 DST-PORT 规则精确分流 UDP 流量。

rules:
  - DOMAIN-SUFFIX,game.example.com,🎮游戏节点
  - DST-PORT,27015-27030,🎮游戏节点  # Steam 游戏常用端口
  - MATCH,PROXY

相关策略组配置可参考《Clash 策略组完全解析》。

🔍 DNS 优化：TCP 还是 UDP？

传统 DNS 查询使用 UDP 53 端口，但在代理环境下容易发生 DNS 泄漏 或污染。Clash 提供多种 DNS 工作模式：

UDP 53 劫持： 在 TUN/TPROXY 模式下，将所有发往 53 端口的 UDP 包重定向到 Clash 内置 DNS 模块，确保使用加密上游（如 DOH/DOT）。
Fake-IP： 返回一个虚拟 IP，后续连接由 Clash 根据域名规则处理，彻底杜绝 DNS 泄漏。但会消耗内存存储映射表。
DNS-over-HTTPS (DOH) / DNS-over-TLS (DOT)： 使用 TCP 443 端口加密传输 DNS 查询，隐私性更好，但延迟略高。

建议在 TUN 模式下开启 fake-ip，既避免 UDP DNS 泄漏，又能让规则基于域名高效匹配。具体配置可查阅 TUN 模式文章中的 DNS 泄漏章节。

🛠️ 实战配置与性能调优

1. 分离 TCP 与 UDP 策略组

有时我们希望 TCP 流量走低延迟节点，UDP 流量（如 DNS）走高可用节点，可以这样设置：

proxy-groups:
  - name: TCP默认
    type: url-test
    proxies: [节点A, 节点B, 节点C]
    url: 'http://www.gstatic.com/generate_204'
    interval: 300
  - name: UDP默认
    type: fallback
    proxies: [节点A, 节点B, 节点C]
    url: 'http://www.gstatic.com/generate_204'
    interval: 300

rules:
  - AND,((PROTOCOL,UDP),(NOT,((DST-PORT,53)))),UDP默认
  - MATCH,TCP默认

上述规则借助 Clash Meta 的 AND 逻辑，将除 DNS 外的 UDP 流量单独分流。

2. 调整 TUN 协议栈

在 Linux 上，TUN 可以配置为 system 或 gvisor。system 模式性能更好，但对 UDP 的兼容性依赖内核版本。如果 UDP 丢包严重，可尝试切换为 gvisor 以获得更一致的网络栈行为。

3. 开启 UDP 超时清理

长时间运行的 UDP 连接（如游戏）可能积累大量会话，占用内存。在客户端中调整 UDP 空闲超时，及时释放无效连接。

🔧 常见问题与排障

🛑 UDP 流量完全没有走代理？ 检查是否启用了 TUN 或 TPROXY 模式。系统代理仅代理 TCP。

🛑 游戏延迟很高但测速正常？ 可能游戏使用的是 UDP，而你的策略组对 UDP 使用了高延迟节点。确认规则中 UDP 流量匹配到了正确的策略组。

🛑 DNS 解析慢或失败？ 可能是 UDP 53 劫持未生效，DNS 请求直连了本地 ISP。请检查 TUN 配置中的 dns-hijack 参数，或改用 fake-ip 模式。

更多网络层面的问题排查，请参考《订阅排障手册》和常见问题页面。

📌 总结与最佳实践

TCP 和 UDP 需要不同的代理处理方式，开启 TUN 模式是代理 UDP 的最简单方案。
游戏、VoIP、流媒体等实时应用强烈依赖 UDP，务必确保其被代理并选择低延迟节点。
利用 Clash Meta 的 PROTOCOL 匹配器，可以为 TCP 和 UDP 指定不同策略。
DNS 使用 DOH/DOT（基于 TCP）或 Fake-IP 模式可以兼顾安全与性能。
定期检查客户端日志中关于 UDP 超时或错误的信息，优化缓存与超时设置。

深入理解 TCP/UDP 在代理中的行为后，配合精细的规则编写和智能策略组，你可以打造一套完美适配游戏、影音与日常浏览的代理体系。