Hysteria2 与 TUIC 协议：高丢包网络下的速度救星

如果你用过 Shadowsocks 或 VMess 协议，大概率经历过这样的场景：节点显示延迟只有 80ms，但实际下载速度只有 2MB/s，看视频频繁缓冲。问题往往不在节点本身，而在传输协议。传统代理协议基于 TCP，在高丢包、高延迟的网络环境下性能急剧下降。Hysteria2 和 TUIC 作为基于 QUIC 的新一代协议，正是为解决这一痛点而生。

为什么 TCP 代理在高丢包网络下很慢

TCP 是可靠传输协议，每个数据包都需要确认（ACK）。当网络丢包率上升时，TCP 的拥塞控制算法会降低发送速率，触发重传，形成恶性循环。更糟糕的是，TCP 的「队头阻塞」问题：一个包丢了，后面所有包都要等待重传完成才能被处理。

对于代理场景，TCP 的劣势更加明显：

• 代理流量经过额外封装，每个 TCP 连接都是「TCP over TCP」，双重拥塞控制互相干扰
• 国际线路丢包率常在 5%–15%，TCP 在此环境下吞吐量可能不到带宽的 30%
• 高延迟放大了丢包的影响——每个重传都要等待一个 RTT

这就是为什么同样的节点，用 SS 协议可能只有 5MB/s，换成 Hysteria2 却能跑到 50MB/s 以上的原因。

QUIC：现代传输协议的基石

QUIC（Quick UDP Internet Connections）是 Google 提出的基于 UDP 的传输协议，现已成为 HTTP/3 的标准传输层。相比 TCP，QUIC 的核心优势：

• 0-RTT 连接建立 — 复用之前的连接参数，二次连接无需握手
• 无队头阻塞 — 每个数据流独立传输，一个流丢包不影响其他流
• 用户态拥塞控制 — 不受操作系统 TCP 栈限制，可以更激进地利用带宽
• 连接迁移 — 网络切换（如 Wi-Fi 切 4G）时连接不中断

Hysteria2 和 TUIC 都构建在 QUIC 之上，但设计理念和优化方向不同。

Hysteria2：暴力美学

Hysteria2 的核心思路是尽可能占满可用带宽。它使用 Brutal 拥塞控制算法——不依赖丢包信号来调节速率，而是根据客户端与服务器协商的带宽上限直接发送。这在高丢包、高延迟线路上效果极为显著。

Hysteria2 的主要特点：

• 基于 QUIC，内置 TLS 1.3 加密和混淆
• Brutal 拥塞控制，在高丢包环境下仍能保持高吞吐
• 支持端口跳跃（Port Hopping），对抗 UDP 限速和封锁
• 配置简单，服务端和客户端都易于部署
• 对服务器带宽要求较高——它会真的试图用满你设定的带宽上限

Clash 中 Hysteria2 节点配置示例：

- name: "HY2-Node"
  type: hysteria2
  server: example.com
  port: 443
  password: your-password
  sni: example.com
  skip-cert-verify: false
  up: 50        # 上行带宽 Mbps
  down: 200     # 下行带宽 Mbps

up 和 down 是 Hysteria2 的关键参数，告诉 Brutal 算法你的带宽上限。设太低浪费性能，设太高可能导致丢包加剧。建议从实际带宽的 70%–80% 开始测试调整。

TUIC：均衡之选

TUIC（The Universal Implicit Congestion Control）同样基于 QUIC，但走了一条不同的路。它由 sing-box 项目作者开发，设计目标是在低延迟和稳定性之间取得平衡，而非一味追求极限速度。

TUIC 的主要特点：

• 基于 QUIC，原生 TLS 1.3 加密
• 使用标准 QUIC 拥塞控制（BBR/Cubic），行为更「温和」
• 支持 UDP over Stream 模式，兼容性和稳定性更好
• 支持 0-RTT 握手，连接建立极快
• 对服务器资源占用相对较低

Clash 中 TUIC 节点配置示例：

- name: "TUIC-Node"
  type: tuic
  server: example.com
  port: 443
  uuid: your-uuid-here
  password: your-password
  sni: example.com
  alpn: [h3]
  skip-cert-verify: false
  congestion-controller: bbr
  udp-relay-mode: native

congestion-controller 可选 bbr 或 cubic。BBR 在高延迟线路上表现更好，Cubic 则更保守稳定。一般建议先用 BBR，如果出现不稳定再切换到 Cubic。

Hysteria2 vs TUIC：怎么选

两款协议没有绝对的优劣，关键看你的网络环境和使用场景：

• 高丢包、高延迟国际线路 → Hysteria2。Brutal 算法能强制利用带宽，速度提升最明显
• 网络质量中等、追求稳定 → TUIC。标准拥塞控制更可预测，长时间使用不易出现异常
• 看流媒体、下载大文件 → Hysteria2。极限吞吐量更高
• 日常浏览、社交、办公 → TUIC。低延迟连接建立，体验更流畅
• 服务器带宽有限 → TUIC。不会像 Hysteria2 那样试图占满带宽
• 服务器带宽充足 → Hysteria2。能把大带宽优势转化为实际速度

实际使用中，很多用户会在订阅中同时保留两种协议的节点，根据当前网络状况灵活切换。Clash 的 url-test 代理组可以自动选择延迟最低的节点，但无法自动判断哪种协议在当前网络下速度更快——这需要你手动测试几次来建立经验。

在 Clash 中优化 QUIC 协议体验

确保内核版本足够新

Hysteria2 和 TUIC 都需要 Mihomo 内核支持。在客户端设置中检查内核版本，建议使用 v1.18 以上版本，以获得最佳兼容性和性能。

UDP 连通性

QUIC 基于 UDP，如果网络环境封锁或限速 UDP 流量，两种协议都会失效。Hysteria2 的端口跳跃功能可以一定程度缓解封锁——通过在多个端口间轮换，降低单端口被封锁的概率：

- name: "HY2-Hopping"
  type: hysteria2
  server: example.com
  port: 443
  ports: 443,8443,2053,2083,2087,2096
  password: your-password

与 TUN 模式配合

QUIC 协议在 TUN 模式下工作良好，但需确保 DNS 配置正确。建议使用 fake-ip 模式并开启 udp 支持，否则部分 QUIC 连接可能因 DNS 解析问题而失败。

不要过度叠加混淆

QUIC 本身已有 TLS 加密，无需再套一层 obfs 混淆。额外的封装层只会增加开销、降低性能。如果担心流量特征，Hysteria2 的 Salamander 混淆已经足够。

常见问题排查

节点显示超时或无法连接

首先确认 UDP 是否通畅——在命令行运行 nc -u example.com 443 测试 UDP 连通性。如果 UDP 被封锁，需要联系服务提供商确认是否支持 TCP 回退，或换用 TCP 系协议节点。

Hysteria2 速度达不到预期

检查 up/down 参数是否设得太低。另外，Brutal 算法在丢包率超过 20% 时也会显著降速——这不是协议的问题，而是物理线路的极限。尝试切换不同线路的节点对比。

TUIC 频繁断连

尝试将 congestion-controller 从 BBR 改为 Cubic。如果使用了 udp-relay-mode: native，改为 quic 也可能改善稳定性。检查服务端是否限制了单 IP 连接数。

两种协议都比 SS/VMess 慢

这说明你的网络环境对 UDP 不友好，或者节点服务器距离太远。QUIC 的优势在中高丢包线路上才能体现——如果丢包率低于 1%、延迟低于 50ms，传统 TCP 协议可能反而更稳定。用测速工具对比同一节点的不同协议，选择实际最快的那个。

总结

Hysteria2 和 TUIC 代表了代理协议从 TCP 向 QUIC 演进的方向。Hysteria2 用 Brutal 拥塞控制追求极限速度，适合高丢包、大带宽场景；TUIC 用标准 QUIC 拥塞控制追求均衡稳定，适合日常使用。两者都需要 Mihomo 内核支持，在 Clash 中配置简单，只需在订阅或配置文件中添加对应节点即可。

建议你在订阅中保留多种协议的节点，在实际网络环境中测试对比，找到最适合自己的协议组合。别忘了从本站下载最新版 Clash 客户端，确保内核版本支持这些新协议。