---
title: Hysteria2 与 TUIC：基于 QUIC 的协议
date: 2026-05-10
categories:
  - 协议与原理
tags:
  - Hysteria2
  - TUIC
  - QUIC
  - UDP
  - 协议
excerpt: Hysteria2 和 TUIC 利用 QUIC/UDP 实现高带宽低延迟。解析技术原理和适用场景。
index_img: /images/posts/quic-protocols.png
---

> **摘要**: Hysteria2 和 TUIC 是基于 QUIC（HTTP/3 底层协议）构建的代理协议。它们利用 UDP 传输实现高带宽和低延迟，特别适合流媒体和大文件下载场景。本文解析两者的技术原理、各自特点和适用场景。

## 为什么用 QUIC

在讨论 [Hysteria2](https://hysteria.network/) 和 TUIC 之前，首先需要理解它们为什么选择了 [QUIC](https://datatracker.ietf.org/doc/html/rfc9000) 而不是沿用传统的 TCP。这个选择不是赶时髦，而是为了解决 TCP 在代理场景中的根本性缺陷。

### TCP 的局限

几乎所有主流代理协议——Shadowsocks、VMess、VLESS、Trojan——都建立在 TCP 之上。TCP 在现代高延迟、有丢包的跨境链路上存在几个固有问题。

**队头阻塞（Head-of-Line Blocking）**是最核心的问题。TCP 保证数据有序到达，一个数据包的丢失会阻塞同一 TCP 连接上的所有后续数据。

**拥塞控制过于保守**也是长期存在的问题。TCP 的拥塞控制算法在检测到丢包后会大幅降低发送速率，在跨境代理的高延迟链路上，实际吞吐量远低于链路的理论带宽。

**握手开销**同样值得关注。TCP 建立连接需要三次握手加上 TLS 握手，在跨太平洋链路上意味着数百毫秒的固定延迟开销。

### QUIC 的优势

QUIC 基于 UDP 构建，支持多路复用的独立流消除队头阻塞；0-RTT 或 1-RTT 连接建立大幅降低延迟；内置 TLS 1.3 加密；拥塞控制在用户空间实现，可以自由定制。

QUIC 已经是 HTTP/3 的基础，截至 2026 年，全球超过 30% 的 Web 流量通过 QUIC 传输。基于 QUIC 的代理流量在网络中并不异常。

![QUIC 与 TCP 对比](/images/inline/quic-vs-tcp.png)
*图片来源：[Catchpoint](https://www.catchpoint.com/)*


## Hysteria2

### 设计理念

Hysteria2 的设计目标非常明确：**在恶劣的网络条件下最大化传输吞吐量**。它把"快"放在了首位。

### Brutal 拥塞控制

Brutal 是 Hysteria2 最具特色也最具争议的设计。标准拥塞控制在检测到丢包后降低发送速率，但在跨境代理场景中，丢包往往不是真正的网络拥塞，而是链路本身的质量问题。

Brutal 的做法：**用户直接指定目标带宽**，Brutal 会尝试维持这个发送速率，无论网络是否出现丢包信号。在丢包率 5%-10% 的跨境链路上，Brutal 的实际吞吐量可以达到传统 TCP 的 3-5 倍。

但 Brutal 对同网络其他用户"不友好"、流量特征异常、带宽估算需要准确。Hysteria2 也支持 BBR 拥塞控制作为替代选项。

### 协议特点

- **HTTP/3 伪装**：流量在网络层面看起来像标准的 HTTP/3 连接
- **简化的认证机制**：使用简单的密码认证
- **内置 ACME 支持**：可自动申请和续期 TLS 证书
- **端口跳跃（Port Hopping）**：在多个 UDP 端口之间轮换连接，增加抗封锁韧性
- **同时支持代理和 VPN 模式**

### 部署示例

```yaml
listen: :443

tls:
  cert: /path/to/cert.pem
  key: /path/to/key.pem

auth:
  type: password
  password: your-password

masquerade:
  type: proxy
  proxy:
    url: https://example.com
    rewriteHost: true
```

## TUIC

### 设计理念

TUIC 的关键词是"规范的 QUIC 代理"。它不使用激进的拥塞控制，而是利用 QUIC 本身的多路复用、低延迟握手等特性来提升代理性能。

### 协议特点

- **多路复用 QUIC Stream**：每个代理请求使用独立的 QUIC Stream，真正实现无队头阻塞
- **UUID 认证**：与 VLESS/VMess 生态保持一致
- **0-RTT 支持**
- **标准拥塞控制**：使用 BBR 或 Cubic，流量行为模式更接近正常网络流量

### 与 Hysteria2 的区别


| 维度 | Hysteria2 | TUIC |
|------|-----------|------|
| 拥塞控制 | Brutal（激进）/ BBR | BBR / Cubic（标准） |
| 认证方式 | 密码 | UUID + Password |
| 端口跳跃 | 支持 | 不支持 |
| 客户端支持 | 广泛 | [sing-box](https://github.com/SagerNet/sing-box) 为主 |
| 开发活跃度 | 活跃 | 较低 |
| 适用场景 | 高带宽需求 | 通用代理 |

### TUIC 的现状

截至 2026 年中，TUIC 的项目维护状态不太理想。如果你是新用户在 QUIC 方案中做选择，推荐直接选 Hysteria2。

## QUIC 协议在中国的现状

### UDP 封锁与 QoS 问题

中国各大运营商对 UDP 流量的态度存在明显差异。中国移动对 UDP 的限制最为严格，中国电信和中国联通相对好一些。移动网络（4G/5G）通常比宽带更严格地限制 UDP。

### 检测风险

GFW 对 QUIC 流量的分析能力正在持续增强。Brutal 模式的流量特征、单一 IP 的 QUIC 连接集中度、连接时长和流量模式都是潜在的检测信号。检测风险评估：中等，且呈上升趋势。

## 该不该用 QUIC 协议

### 适合使用的场景

- ISP 对 UDP 限制不严
- 需要高带宽传输（4K/8K 流媒体、大文件下载）
- TCP 节点高峰拥堵
- 作为备用协议

### 不适合的场景

- ISP 封锁或严格限速 UDP
- 主要使用移动网络
- 隐蔽性是首要需求
- 游戏加速（延迟波动敏感）

### 推荐策略

对于大多数用户，最务实的做法是**多协议组合**：

- **主力协议**：VLESS + Reality（TCP，最可靠，抗检测能力最强）
- **备用协议**：Hysteria2（UDP 友好环境下的高带宽选项）
- **客户端配置**：利用 sing-box 或 mihomo 的自动切换功能

不要把所有节点都放在同一种协议上。TCP 和 UDP 属于不同的传输层，运营商的封锁策略通常也是分开的。保持协议多样性是最基本的风险分散策略。

## 常见问题

### Q: Hysteria2 和 VLESS+Reality 只能选一个吗？

不用。两种协议完全可以同时部署在同一台服务器上——VLESS+Reality 监听 TCP 443，Hysteria2 监听 UDP 443，互不干扰。

### Q: 怎么测试我的网络支不支持 UDP/QUIC？

最直接的方法：连接一个 Hysteria2 节点，尝试正常使用。也可以检查 YouTube 是否通过 h3 协议加载。

### Q: TUIC 还值得用吗？

如果你是新用户，推荐直接选 Hysteria2。如果你已经在使用 TUIC 且运行稳定，没必要急着迁移。

### Q: 端口跳跃是什么意思？

端口跳跃允许 Hysteria2 客户端在一个预设的端口范围内轮换连接端口，大幅增加了封锁方的成本。TUIC 不支持端口跳跃。

### Q: Brutal 模式的带宽应该设多少？

应该设为你的实际链路带宽的 80%-90%，而不是一个脱离实际的高值。如果不确定，建议先用 BBR 模式测试基准带宽。