如果你问代理协议里谁最快,答案通常只有一个——Hysteria2。
它基于 QUIC 协议构建,用一套名为 Brutal 的自定义拥塞控制算法,在丢包率高达 10-20% 的恶劣网络环境下,仍然能维持接近带宽上限的传输速度。下载场景比 VLESS Reality 快 30-50%。
但快是有代价的。Hysteria2 的 UDP 流量在国内偶尔被 QoS 限速,伪装能力不如 Reality,配置不当还可能反向降速。本文从原理到部署,把 Hysteria2 彻底讲透。
一、QUIC 协议基础:为什么不用 TCP?
TCP 的致命缺陷
传统代理协议(VLESS、Trojan、Shadowsocks)都基于 TCP 传输。TCP 的可靠传输机制有一个核心行为:当网络出现丢包时,TCP 会主动降速。
这是 TCP 拥塞控制算法(CUBIC、BBR 等)的设计哲学——假设丢包意味着网络拥塞,通过降低发送速率来"让出"带宽。
在正常互联网环境下,这套机制工作得很好。但在跨境代理场景中,问题来了:
- 国际出口的丢包不一定是拥塞:跨境链路的丢包可能是 QoS 策略、线路质量波动、设备故障等原因,降速并不能改善
- GFW 的主动干扰:GFW 通过注入 RST 包或选择性丢包来干扰代理连接,TCP 会错误地认为是拥塞并降速
- 高峰期的带宽竞争:国际出口带宽紧张时,使用"温和"拥塞控制的 TCP 连接会被"激进"的连接挤压
QUIC 的关键特性
QUIC(Quick UDP Internet Connections)最初由 Google 开发,后成为 IETF 标准化 HTTP/3 的底层传输协议。相比 TCP:
| 特性 | TCP | QUIC |
|---|---|---|
| 传输层实现 | 内核空间 | 用户态 |
| 握手延迟 | TCP握手+TLS握手 (2-3 RTT) | 0-1 RTT |
| 队头阻塞 | 有(单连接内所有流互相阻塞) | 无(多流独立传输) |
| 连接迁移 | 不支持(IP变化需重连) | 支持(基于 Connection ID) |
| 加密 | 可选 | 强制 TLS 1.3 |
| NAT 穿透 | 困难 | 相对容易(UDP) |
QUIC 的这些特性使它在弱网环境(丢包、延迟抖动)下比 TCP 稳定得多。
Hysteria2 对 QUIC 的修改
Hysteria2 并不使用标准 QUIC。它保留了 QUIC 的加密和多路复用能力,但替换了拥塞控制算法——这是 Hysteria2 的核心创新。
标准 QUIC 实现(Google quiche、Cloudflare quiche)使用类似 TCP 的拥塞控制(Cubic、BBR),遇到丢包同样会降速。Hysteria2 将其替换为自定义的 Brutal 算法。
二、Brutal 拥塞控制:暴力美学
核心原理
Brutal 算法的设计哲学用一句话概括:你告诉我你有多少带宽,我就用多少带宽,不管丢包。
传统拥塞控制(如 BBR)通过不断试探动态调整发送速率:
BBR: 慢启动 → 探测带宽 → 如果丢包 → 降低发送速率 → 重新探测Brutal 的方式完全不同:
Brutal: 用户指定目标带宽 → 按目标带宽发送 → 如果丢包 → 增加发送速率(补偿丢包)当网络丢包时,Brutal 不是降速,而是加速。逻辑是:如果你的目标带宽是 100 Mbps,当前丢包率 10%,Brutal 会以约 111 Mbps 的速率发送,确保经过丢包后实际到达对端的有效数据量仍然是 100 Mbps。
| 拥塞控制 | 目标带宽 | 丢包率 | 实际发送速率 | 对端实际接收 |
|---|---|---|---|---|
| TCP/BBR | 100 Mbps | 10% | 降到 50-70 Mbps | 45-63 Mbps |
| Brutal | 100 Mbps | 10% | 加速到 ~111 Mbps | ~100 Mbps |
为什么有效
在跨境代理场景中,丢包的原因通常不是传统意义上的"网络拥塞":
- QoS 策略:运营商对特定类型流量限速
- 线路质量波动:海底光缆信号衰减、设备故障
- GFW 干扰:选择性丢包或注入干扰
在这些场景下,TCP 的"降速让步"策略完全是在浪费可用带宽。Brutal 的激进策略反而能充分利用剩余带宽。
设计争议
Brutal 算法的激进性质意味着它对网络不够"友好"——在带宽有限的共享网络中,Hysteria2 可能挤占其他用户的带宽:
- 对使用者:高丢包环境下速度更快
- 对网络:可能加剧拥塞(如果带宽确实不足)
- 对其他用户:共享带宽场景下可能"欺负"使用标准拥塞控制的连接
因此 Hysteria2 官方建议:将带宽设置为你的实际线路带宽,不要设得过高。设置过高会导致大量无效重传包,反而浪费带宽和增加延迟。
三、Hysteria2 vs Hysteria1:迁移须知
Hysteria 经历了从 1.x 到 2.x 的重大升级,两者不兼容:
| 特性 | Hysteria 1 | Hysteria 2 |
|---|---|---|
| 协议伪装 | 自定义 QUIC 头部 | 标准 HTTP/3 握手 |
| 认证方式 | 自定义 | 标准 HTTP/3 + 密码 |
| TLS 证书 | 自签名(常见) | 支持 ACME 自动获取 |
| 抗检测 | 中等(自定义头部可识别) | 较强(标准 HTTP/3 流量) |
| 性能 | 高 | 更高(优化协议开销) |
| 维护状态 | 已停止维护 | 活跃开发 |
Hysteria2 的最大改进是协议层面——握手过程与标准 HTTP/3 完全一致,从外部看就是一个普通的 HTTP/3 连接。这使得 GFW 很难通过协议特征识别 Hysteria2 流量。
⚠️ Hysteria1 和 Hysteria2 不能共存。如果你还在用 1.x,建议直接迁移到 2.x。
四、服务端部署完整流程
第一步:安装 Hysteria2
# apernet 官方一键脚本
bash <(curl -fsSL https://get.hy2.sh/)
# 或从 GitHub Releases 手动安装
wget https://github.com/apernet/hysteria/releases/latest/download/hysteria-linux-amd64
chmod +x hysteria-linux-amd64
mv hysteria-linux-amd64 /usr/local/bin/hysteria第二步:编写服务端配置
配置文件路径:/etc/hysteria/config.yaml
基础配置(使用 ACME 自动证书):
listen: :443
# TLS 证书:推荐 ACME 自动获取(需要域名指向服务器 IP)
acme:
domains:
- your-domain.com
email: your-email@example.com
# 认证
auth:
type: password
password: your-strong-password-here
# 伪装站点(非 Hysteria 客户端访问时显示的网站)
masquerade:
type: proxy
proxy:
url: https://www.bing.com
rewriteHost: true进阶配置(含 OBFS 混淆 + 端口跳跃 + ACL):
listen: :20000-30000 # 端口跳跃:监听 10000 个端口
# 手动指定证书(已有 Let's Encrypt 证书时)
tls:
cert: /etc/letsencrypt/live/your-domain.com/fullchain.pem
key: /etc/letsencrypt/live/your-domain.com/privkey.pem
auth:
type: password
password: your-strong-password-here
# OBFS 混淆(墙内强烈推荐)
obfs:
type: salamander
salamander:
password: another-strong-password
# 服务端带宽上限
bandwidth:
up: 1 gbps
down: 1 gbps
# ACL:屏蔽特定目的(如禁止 BT)
acl:
inline:
- reject(geoip:cn)
- reject(suffix:torrent.com)
# 伪装站点
masquerade:
type: proxy
proxy:
url: https://www.bing.com
rewriteHost: true第三步:启动服务
systemctl enable --now hysteria-server
systemctl status hysteria-server
# 查看日志
journalctl -u hysteria-server -f配置字段说明
| 字段 | 作用 | 必填 |
|---|---|---|
listen | 监听地址和端口,支持范围语法 :20000-30000 | ✅ |
acme | 自动从 Let’s Encrypt 获取证书 | 二选一 |
tls | 手动指定证书路径 | 二选一 |
auth | 认证配置,目前支持 password 类型 | ✅ |
obfs | 流量混淆,降低 DPI 识别率 | 推荐 |
bandwidth | 服务端带宽上限 | 可选 |
masquerade | 伪装站点配置 | 推荐 |
acl | 访问控制列表 | 可选 |
五、端口跳跃(Port Hopping)
为什么需要端口跳跃
GFW 可能对特定端口进行封锁。如果 Hysteria2 固定监听 443 端口,一旦被封就无法使用。端口跳跃让服务端同时监听一个端口范围,客户端每 30 秒随机切换端口,GFW 难以全部封锁。
服务端配置
listen: :20000-30000服务端会监听范围内的第一个端口,并自动通过 nftables/iptables 将其他端口的流量重定向到该端口。
⚠️ 端口跳跃需要服务端有 nftables 或 iptables 权限,且防火墙需放行整个 UDP 端口范围。
客户端配置
{
"type": "hysteria2",
"server": "your-domain.com",
"server_ports": "20000:30000",
"password": "your-strong-password",
"tls": {
"enabled": true,
"server_name": "your-domain.com"
}
}客户端会每 30 秒在端口范围内随机切换,保持连接不中断。
六、OBFS 混淆深入
不开 OBFS 时
- 抓包工具能看到清晰的 QUIC 握手 + DATAGRAM
- DPI 容易识别为 “Hysteria2 流量”
开 salamander OBFS 后
- 所有 UDP 包内容变成随机字节
- DPI 看到的是"未知 UDP 流量"
- 大幅降低识别率(约 50%)
代价
- 服务端 CPU 占用增加 20-30%
- 客户端有少量额外开销
配置方式
服务端和客户端必须配置相同的 OBFS 密码:
服务端:
obfs:
type: salamander
salamander:
password: your-obfs-password客户端(sing-box):
{
"obfs": {
"type": "salamander",
"password": "your-obfs-password"
}
}💡 墙内强烈建议开启 OBFS,墙外可关闭以提升性能。
七、四客户端集成配置
方案一:Clash Meta (mihomo)
proxies:
- name: "hysteria2-jp"
type: hysteria2
server: your-domain.com
port: 443
password: your-strong-password
up: "50 Mbps"
down: "100 Mbps"
# sni: your-domain.com # 通常自动推断
- name: "hysteria2-us-port hopping"
type: hysteria2
server: your-domain.com
port: "20000:30000" # 端口跳跃
password: your-strong-password
up: "50 Mbps"
down: "100 Mbps"
obfs: salamander
obfs-password: your-obfs-password方案二:sing-box
{
"outbounds": [
{
"type": "hysteria2",
"tag": "hy2-node",
"server": "your-domain.com",
"server_port": 443,
"password": "your-strong-password",
"obfs": {
"type": "salamander",
"password": "your-obfs-password"
},
"tls": {
"enabled": true,
"server_name": "your-domain.com"
},
"up_mbps": 50,
"down_mbps": 500
}
]
}方案三:Hysteria2 官方客户端
server: your-domain.com:443
auth: your-strong-password
bandwidth:
up: 50 mbps
down: 100 mbps
socks5:
listen: 127.0.0.1:1080
http:
listen: 127.0.0.1:8080方案四:Shadowrocket (iOS) / v2rayN (Windows)
GUI 客户端配置步骤:
- 点击「+」新建节点
- 协议选择 Hysteria2
- 填写字段:
- Server / Port:服务器地址和端口
- Password:认证密码
- OBFS Password:如果服务端开启了 OBFS
- TLS SNI:服务端证书对应的域名
- Up / Down 速率:与实际线路带宽匹配
- 保存并测试连接
客户端支持矩阵
| 客户端 | 平台 | Hysteria2 支持 |
|---|---|---|
| Hysteria2 官方客户端 | 全平台 | ✅ 完整 |
| Clash Meta (mihomo) | 全平台 | ✅ 完整 |
| sing-box | 全平台 | ✅ 完整 |
| Shadowrocket | iOS | ✅ 完整 |
| NekoBox | Android | ✅ 完整 |
| v2rayN 7.x | Windows | ✅ 通过 sing-box 核心 |
| Surge | iOS/macOS | ❌ 不支持 |
八、性能调优实战
带宽参数:最关键的一步
Brutal 算法的效果完全取决于带宽参数的准确性:
| 设置 | 结果 |
|---|---|
| 设置过高 | 发送大量超出实际带宽的数据包,绝大部分被丢弃,反而导致速度下降和流量浪费 |
| 设置过低 | 无法充分利用可用带宽 |
| 建议 | 设置为实际带宽的 80-90%。例如 100M 宽带设置 80-90 Mbps |
💡 测速方法:先用 Speedtest 测出你的实际国际出口带宽,然后按 80-90% 设置。不要用国内测速结果。
服务端硬件要求
QUIC 加密计算量大,Hysteria2 服务端比 VLESS 略高:
| 用户规模 | 推荐 VPS 配置 |
|---|---|
| 单用户 | 1 vCPU + 1GB RAM |
| 10 并发用户 | 2 vCPU + 2GB RAM |
| 50 并发用户 | 4 vCPU + 4GB RAM |
| 开启 OBFS | 以上配置再增加 20-30% CPU |
⚠️ 不要运行在树莓派或极便宜的 VPS 上——QUIC 在用户态执行,需要较强的 CPU。
UDP 转发的天然优势
Hysteria2 基于 UDP 构建,对 UDP 流量有天然传输优势。传统 TCP 代理处理 UDP 流量(游戏、语音通话、视频会议)时,需要将 UDP 封装在 TCP 隧道中——这引入了 TCP 的队头阻塞问题和额外延迟。
Hysteria2 直接在 QUIC(UDP)层面传输 UDP 数据包,避免了这些问题,特别适合:
- 在线游戏(低延迟 UDP 通信)
- VoIP 语音通话
- 视频会议
- 实时直播推流
九、与其他协议对比
| 维度 | Hysteria2 | VLESS+Reality | Trojan | TUIC |
|---|---|---|---|---|
| 底层协议 | UDP (QUIC) | TCP | TCP | UDP (QUIC) |
| 拥塞控制 | Brutal | 系统默认 | 系统默认 | 标准 QUIC |
| 下载速度 | ★★★★★ | ★★★☆ | ★★★☆ | ★★★★ |
| 响应延迟 | ★★★★ | ★★★★★ | ★★★★★ | ★★★★ |
| 抗 GFW 检测 | ★★★☆ | ★★★★★ | ★★★★ | ★★★☆ |
| 高丢包环境 | 极好 | 较差 | 较差 | 好 |
| 流量伪装 | HTTP/3 | HTTPS | HTTPS | QUIC |
| 需要域名 | 推荐 | 不需要 | 需要 | 推荐 |
| UDP 转发 | 原生 | TCP隧道 | TCP隧道 | 原生 |
| 适合场景 | 速度优先 | 抗检测优先 | 兼容性 | 平衡 |
Hysteria2 vs VLESS+Reality
这两个协议设计目标不同:
- VLESS+Reality 核心目标是不被发现(极致流量伪装)
- Hysteria2 核心目标是传输更快(极致速度)
如果你的 VPS 线路质量好、丢包率低,VLESS+Reality 速度与 Hysteria2 差距不大,但抗检测能力更强。如果线路丢包率高(5% 以上),Hysteria2 速度优势非常明显。
最佳实践:双协议组合
同时部署 Hysteria2 和 VLESS+Reality,各司其职:
- 日常浏览 → VLESS+Reality(抗检测强,响应快)
- 4K 视频 / 大文件下载 → Hysteria2(速度碾压)
- 游戏 / 视频会议 → Hysteria2(UDP 原生,低延迟)
两者使用不同端口即可共存。
十、从 Hysteria1 迁移
迁移步骤
- 备份旧配置:
cp /etc/hysteria/config.yaml /etc/hysteria/config-v1-backup.yaml- 升级二进制:
bash <(curl -fsSL https://get.hy2.sh/)- 重写配置文件(v2 格式不兼容 v1):
# v2 格式
listen: :443
acme:
domains:
- your-domain.com
email: your-email@example.com
auth:
type: password
password: your-strong-password
masquerade:
type: proxy
proxy:
url: https://www.bing.com
rewriteHost: true- 重启服务:
systemctl restart hysteria-server- 更新所有客户端配置(v2 链接格式与 v1 不同)
v1 vs v2 链接格式
# v1 链接格式
hysteria://server:port/?protocol=quic&auth=password&peer=domain& insecure=1
# v2 链接格式
hysteria2://server:port/?auth=password&obfs=salamander&obfs-password=xxx&sni=domain十一、常见错误诊断
错误一:handshake failed: invalid certificate
| 原因 | 解决方案 |
|---|---|
| 服务端 TLS 证书过期 | 重新获取证书,检查 acme 配置 |
| 客户端 server_name 与证书不匹配 | 确认 SNI 填写的是证书对应域名 |
| 客户端时间不准 | 同步系统时间:ntpdate pool.ntp.org |
错误二:udp socket bound but no traffic
| 原因 | 解决方案 |
|---|---|
| VPS 防火墙未开 UDP 端口 | ufw allow 443/udp 或在安全组放行 |
| VPS 提供商阻止 UDP | 联系提供商或在控制台开启 UDP |
| ISP 拦截 UDP 流量 | 切换到 TCP 方案(VLESS+Reality) |
错误三:connection lost frequently
| 原因 | 解决方案 |
|---|---|
| 网络丢包严重 | 确认带宽设置是否匹配实际线路 |
| UDP 被 ISP QoS | 尝试端口跳跃或更换端口 |
| OBFS 密码不匹配 | 核对服务端和客户端 OBFS 密码 |
错误四:速度反而不如 VLESS
| 原因 | 解决方案 |
|---|---|
| 带宽参数设置不合理 | 按实际带宽的 80-90% 设置 |
| 运营商限制 UDP | 改用 VLESS+Reality |
| VPS CPU 不足 | 升级 VPS 或关闭 OBFS |
错误五:端口跳跃不生效
| 原因 | 解决方案 |
|---|---|
| nftables/iptables 未安装 | apt install nftables |
| 防火墙未放行端口范围 | 放行 20000-30000/udp |
| 客户端配置格式错误 | 用 server_ports: "20000:30000" 而非 port |
十二、何时选择 Hysteria2
推荐场景
| 场景 | 推荐协议 | 原因 |
|---|---|---|
| 4K / 8K 视频流 | Hysteria2 | 大带宽需求,Brutal 算法优势明显 |
| 大文件下载 | Hysteria2 | 下载场景比 VLESS 快 30-50% |
| 在线游戏 | Hysteria2 | UDP 原生转发,延迟低 |
| 视频会议 | Hysteria2 | UDP 原生,无队头阻塞 |
| 普通网页浏览 | VLESS+Reality | TCP 更稳定,响应延迟低 |
| 长会话(编程/SSH) | VLESS+Reality | TCP 连接稳定性更好 |
| 高度审查环境 | VLESS+Reality | Reality 伪装最强 |
| 服务端在国内 | VLESS+Reality | UDP 在国内易被限速 |
不推荐场景
- 运营商严格限制 UDP:某些运营商对 UDP 流量 QoS 到 1-2 Mbps,Hysteria2 无法发挥优势
- VPS 性能极弱:QUIC 用户态实现需要较强 CPU
- 追求极致隐蔽:UDP 大流量本身是特征,不如 Reality 隐蔽
总结
Hysteria2 代表了代理协议设计中"速度优先"的极端思路。它不追求最完美的伪装,而是用暴力的带宽利用率换取恶劣网络环境下的最佳速度体验。
核心要点回顾:
- Brutal 算法是灵魂——丢包时加速而非降速,在高丢包跨境链路中碾压 TCP 协议
- 带宽设置是关键——设成实际带宽的 80-90%,过高浪费流量,过低浪费速度
- OBFS 混淆是保险——墙内必开,降低 DPI 识别率约 50%
- 端口跳跃是防线——防端口级封锁,GFW 难以全封
- 双协议组合是王道——VLESS+Reality 做日常,Hysteria2 做速度,各取所长
如果你还在用 Hysteria1,现在就迁移到 2.x——1.x 已停止维护,2.x 的 HTTP/3 伪装和协议优化是质变。
