TUIC 是一个基于 QUIC 协议的代理方案,和 Hysteria2 同属"QUIC 加速"阵营,但走了不同的技术路线。如果说 Hysteria2 是 QUIC 世界的"民间高手",那么 TUIC 更像是"标准学院派"——它严格遵循 QUIC 和 TLS 1.3 的标准规范,不引入自定义混淆层,用最干净的方式实现低延迟传输。
这篇文章的目标很明确:从一台 VPS 开始,到客户端跑通为止。同时帮你判断 TUIC 和 Hysteria2 到底该怎么选。
一、TUIC 是什么?
1.1 一句话定义
TUIC(Terrible Universal IP Connection)是一个基于 QUIC 的轻量级代理协议。它在 QUIC 连接之上叠加了一层标准 TLS 1.3 认证,支持同时转发 TCP 和 UDP 流量,并原生支持 0-RTT 快速连接。
1.2 TUIC v5 的核心特点
- 严格遵循 QUIC 标准:不引入私有拥塞控制算法,完全使用 QUIC 原生的拥塞控制(可选 BBR/Cubic)。
- 标准 TLS 1.3 认证:服务端需要一张合法的 TLS 证书(与 Hysteria2 的密码认证不同)。
- 0-RTT 连接恢复:客户端缓存 TLS session 后,重连时无需完整握手,延迟极低。
- 同时转发 TCP + UDP:单一端口即可同时处理两种传输协议的代理流量。
- Rust 实现:服务端用 Rust 编写,内存安全且性能优秀。
1.3 与 Hysteria2 的核心差异
一句话概括:TUIC 是"标准派",Hysteria2 是"性能派"。
| 维度 | TUIC v5 | Hysteria2 |
|---|---|---|
| 认证方式 | 标准 TLS 1.3 证书 | 共享密码 |
| 拥塞控制 | QUIC 原生(BBR/Cubic) | 自定义 FLOWSIC |
| FEC 前向纠错 | ❌ 不支持 | ✅ 支持 |
| 0-RTT | ✅ 原生支持 | ❌ 不支持 |
| 混淆层 | 无(纯标准 QUIC) | 可选 obfs |
| UDP 中继 | ✅ 原生支持 | ⚠️ 有限支持 |
| 服务端语言 | Rust | Go |
二、部署前准备
2.1 环境需求
- VPS:推荐 HK / SG / JP / US 机房,带宽 ≥ 100Mbps。
- 系统:Debian 11/12、Ubuntu 22.04/24.04。
- 域名 + 证书:TUIC 要求 TLS 证书,需要一个域名并申请 Let's Encrypt 证书。
- 端口:默认 UDP 443(也可自定义)。
2.2 域名与证书准备
如果你已有域名和证书,可跳过此步。否则用以下方式快速获取:
# 安装 certbot
apt update && apt install -y certbot
# 申请证书(standalone 模式,需临时占用 80 端口)
certbot certonly --standalone -d your-domain.com
# 证书路径
# /etc/letsencrypt/live/your-domain.com/fullchain.pem
# /etc/letsencrypt/live/your-domain.com/privkey.pem
三、服务端部署
3.1 安装 TUIC v5
TUIC 服务端从 GitHub Releases 下载预编译二进制:
# 下载最新版(以 v5 为例,替换为实际版本号)
wget https://github.com/EAimTY/tuic/releases/latest/download/tuic-server-linux-x86_64 -O /usr/local/bin/tuic-server
chmod +x /usr/local/bin/tuic-server
3.2 生成 UUID 和密码
# 生成 UUID
cat /proc/sys/kernel/random/uuid
# 输出示例:a1b2c3d4-e5f6-7890-abcd-ef1234567890
# 生成密码(用于 UDP 中继认证)
openssl rand -base64 32
3.3 服务端配置文件
创建 /etc/tuic/config.json:
{
"port": 443,
"udp_relay_mode": "native",
"cubic": {
"reordering": 32
},
"congestion_control": "bbr",
"alpn": ["h3"],
"auth": {
"mode": "password",
"password": "你的密码"
},
"cert": "/etc/letsencrypt/live/your-domain.com/fullchain.pem",
"key": "/etc/letsencrypt/live/your-domain.com/privkey.pem",
"log_level": "info"
}
native 使用 QUIC 原生 UDP 转发,quic 则将 UDP 封装在 QUIC 流中传输(更稳定但多一跳开销)。congestion_control:
bbr 适合高带宽链路,cubic 更保守稳定。alpn:设为
["h3"] 可以进一步伪装为 HTTP/3 流量。
3.4 创建 systemd 服务
cat > /etc/systemd/system/tuic.service << 'EOF'
[Unit]
Description=TUIC Server
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/tuic-server -c /etc/tuic/config.json
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable tuic
systemctl start tuic
systemctl status tuic
3.5 防火墙放行
# ufw
ufw allow 443/udp
# 或 iptables
iptables -I INPUT -p udp --dport 443 -j ACCEPT
四、客户端配置
4.1 通用参数
| 字段 | 值 | 说明 |
|---|---|---|
| 协议 | tuic | 客户端协议标识 |
| 地址 | 你的域名 | 需与证书域名匹配 |
| 端口 | 443 | 默认 UDP 443 |
| UUID | (留空或任意) | TUIC v5 不使用 UUID 认证 |
| 密码 | 服务端配置的密码 | 两端必须一致 |
| ALPN | h3 | 与服务端 alpn 一致 |
| 跳过证书校验 | 通常关闭 | 使用自有证书时建议开启校验 |
4.2 Clash Verge / Mihomo 配置
proxies:
- name: "tuic-v5-node"
type: tuic
server: your-domain.com
port: 443
uuid: "你的UUID" # TUIC v5 中该字段可留空或填任意值
password: 你的密码
alpn:
- h3
udp-relay-mode: native
congestion-controller: bbr
reduce-rtt: true # 启用 0-RTT
skip-cert-verify: false # 使用自有证书时设为 false
4.3 Sing-box 配置
Sing-box 使用 JSON 格式的出站配置:
{
"outbounds": [{
"type": "tuic",
"tag": "tuic-out",
"server": "your-domain.com",
"server_port": 443,
"uuid": "任意UUID",
"password": "你的密码",
"congestion_control": "bbr",
"udp_relay_mode": "native",
"zero_rtt_handshake": true,
"tls": {
"enabled": true,
"server_name": "your-domain.com",
"alpn": ["h3"],
"insecure": false
}
}]
}
4.4 NekoBox / NekoRay(Android / Windows)
NekoBox 原生支持 TUIC v5:
- 点击 + → 类型选择 TUIC
- 填写地址(你的域名)、端口 443、密码
- ALPN 填
h3 - 开启 0-RTT(Reduce RTT)
- 保存 → 连接 → 测试延迟
五、性能优化技巧
5.1 拥塞控制选择
TUIC 支持 QUIC 原生的两种拥塞控制算法:
- BBR(推荐):Google 开发,适合高带宽、有一定丢包的跨国链路。能更充分地利用带宽。
- Cubic:TCP 时代的经典算法,更保守但更稳定。适合对延迟波动敏感的场景。
在配置中通过 "congestion_control": "bbr" 切换。
5.2 0-RTT 调优
TUIC 的 0-RTT 需要客户端缓存 TLS session ticket。首次连接仍是完整握手,后续重连才能享受 0-RTT。对于频繁切换网络的移动设备,这一特性显著降低重连延迟。
reduce-rtt。5.3 服务端系统调优
# 增大 UDP 缓冲区
cat >> /etc/sysctl.conf << 'EOF'
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 5000
EOF
sysctl -p
5.4 证书自动续签
Let's Encrypt 证书 90 天过期,务必设置自动续签:
# 测试续签
certbot renew --dry-run
# 添加 cron 自动续签(每天凌晨 2 点检查)
echo "0 2 * * * certbot renew --quiet --post-hook 'systemctl restart tuic'" | crontab -
六、与 Hysteria2 对比选型
技术规格对比见第一章,这里聚焦一个实际问题:你的场景该选谁?
6.1 场景速查表
| 场景 | TUIC v5 | Hysteria2 |
|---|---|---|
| 高丢包链路(5%+) | 无 FEC,丢包恢复弱 | ✅ FEC + 自适应速率 |
| 频繁切换网络(移动端) | ✅ 0-RTT 快速重连 | 需完整握手,重连较慢 |
| 免证书零配置 | 必须持有 TLS 证书 | ✅ 密码认证即可 |
| 标准协议兼容性 | ✅ 纯 QUIC + TLS 1.3 | 私有拥塞控制,非标准 |
| UDP 中继(游戏/DNS) | ✅ 原生双协议支持 | ⚠️ 有限 |
| 抗主动探测 | 中等(QUIC 有特征) | 中等(QUIC 有特征) |
| 客户端生态 | Mihomo / Sing-box / NekoBox | 更广泛(含 Shadowrocket) |
| 部署难度 | 中(需管证书) | 低 |
6.2 快速决策流程
你的链路丢包率高吗?
丢包 5%+ → 选 Hysteria2(FEC 是它的杀手锏)。丢包低 → 两者都行,继续往下看。
你有域名和证书吗?
没有 → 选 Hysteria2(密码认证,零证书部署)。有 → 继续。
你频繁切换 Wi-Fi / 移动网络吗?
是 → 选 TUIC v5(0-RTT 重连几乎无感)。不频繁 → 继续。
你需要中继 UDP 流量(游戏、DNS)吗?
是 → 选 TUIC v5(原生 TCP + UDP 双协议)。不需要 → 两者都行。
还在纠结?
直接选 Hysteria2。客户端生态更广、部署更简单、不需要管证书。TUIC 的优势场景(0-RTT、UDP 中继)对大多数日常用户来说不是刚需。
6.3 可以同时部署吗?
可以。两者使用不同的端口或同一端口的不同协议栈,互不冲突。很多资深用户的实际方案是:
- VLESS-Reality 做主线路(抗封锁兜底)
- Hysteria2 做加速线路(高丢包链路提速)
- TUIC v5 做备选线路(移动端 0-RTT 或 UDP 中继需求)
客户端按场景手动切换或用规则自动分流即可。
七、常见问题排查
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 连接超时 | UDP 443 被阻 | ss -u -lpn | grep tuic,防火墙检查 |
| TLS 握手失败 | 证书过期 / 域名不匹配 | certbot certificates 检查有效期 |
| 认证失败 | 密码不一致 | 比对服务端 config.json 里的 password |
| 能连但速度慢 | 拥塞控制不合适 | 切换 BBR/Cubic,检查 VPS 带宽 |
| 0-RTT 不生效 | 首次连接 / session 过期 | 第二次连接才会生效,确认客户端开启 reduce-rtt |
| 连接经常断开 | NAT 超时 | 确认客户端 keepalive 设置 |
7.1 查看服务端日志
# 查看 TUIC 服务日志
journalctl -u tuic -f
# 关键日志
# tuic-server: connection from 1.2.3.4:54321
# tuic-server: client authenticated
八、安全与运维要点
- 密码管理:TUIC 的密码是唯一认证凭据。定期轮换(每 30-90 天),泄露即被滥用。
- 证书安全:私钥文件权限设为
600,仅 root 可读。 - 日志隐私:服务端日志包含连接元数据(IP、时间戳),生产环境建议调低日志级别。
- 多用户场景:TUIC v5 原生不支持多用户 UUID 隔离,多用户需多实例或配合面板使用。