为什么 Hysteria2 比 VLESS 快
2026-09-29 16:00:00
前置知识:NAT VPS 自建代理的原理。本文解释一个实测现象背后的原理:同一台机器、同一条线路,把入站从 VLESS+REALITY(TCP)换成 Hysteria2(QUIC/UDP),下载速度从 83KB/s 涨到 887KB/s——10 倍。
实测复盘
| VLESS+REALITY | Hysteria2 | |
|---|---|---|
| 传输层 | TCP | UDP(QUIC) |
| 简单请求延迟 | 6~10 秒(高峰瘫) | 0.9~2.1 秒 |
| 20MB 下载 | 83KB/s(经常中途断) | 887KB/s,完整跑完 |
| 机器/线路/加密强度 | 完全相同 | 完全相同 |
变量只有一个:传输方式。所以速度差异的根源不在加密、不在机器,而在下面要讲的拥塞控制。
TCP 阵营(VLESS/REALITY)的原罪:丢包 = 减速
TCP 的拥塞控制写死在操作系统内核里,设计假设是:丢包 ≈ 网络拥堵 → 该减速了。
这个假设在正常线路上成立,但你到日本的线路晚高峰丢包严重——丢包是"运营商限速/线路质量差",不是"你发太快了"。此时 TCP 的行为变成灾难:
- 每检测到丢包,就主动把发送窗口砍半(指数退避),速度断崖式下跌
- 丢的包要等重传回来,后面的数据全部排队(队头阻塞)
- 结果:发一点、停一下、再发一点,83KB/s 就是这么来的
前端类比:一个过于保守的请求重试策略——接口一返回超时就 retryDelay *= 2 指数退避,实际是后端抖了一下,你却把并发压到了 1。
QUIC/Hysteria2 的三个杀手锏
1. 传输层自己写,不受内核摆布
QUIC 跑在 UDP 上,重传、确认、流控全部在应用层实现。内核 TCP 那套保守策略直接被绕开——相当于把浏览器内置的网络栈换成自己写的调度器。
前端最熟悉的类比:HTTP/3 就是 QUIC。你浏览器访问支持 HTTP/3 的网站时早就在享受它了,Hysteria2 把同款技术用在了代理隧道上。
2. 拥塞控制换成"抗丢包"的
- Hysteria2 默认 BBR:不再把丢包当拥堵信号,而是主动测量带宽和往返延迟来定发送速率
- 还有个招牌的 Brutal 模式:你直接告诉它"这条线有 X Mbps",它就恒定速率猛发,丢包也不减速,用快速重传硬补——专门对抗"故意丢包限速"的线路(我部署时没填带宽,走的是 BBR,已经够赢)
3. 没有队头阻塞
QUIC 的多个数据流相互独立:A 流丢包只重传 A,B 流照跑。TCP 里一个包丢了,排在后面的所有数据都得等它。
代价与适用性(公平起见)
- UDP 会被运营商"看管":有些线路对 UDP 做 QoS 限速,所以 Hysteria2 时快时慢、因运营商而异;UDP 被完全封锁就只能退回 TCP。建议 TCP 节点保留做兜底(我的配置里就是这么做的)
- 伪装定位不同:REALITY 借真证书,是 TCP 阵营最强的抗探测方案;Hysteria2 的流量长得像 HTTP/3 视频/网页流量,抗丢包强但抗封锁定位不同。一句话:REALITY 求稳,Hy2 求快,双节点互补
- Brutal 模式在共享线路上是"作弊式抢带宽",公共道德上适度使用
一句话总结
速度瓶颈不在机器、不在加密,在拥塞控制策略:TCP 把丢包当"该减速了",Hysteria2/QUIC 把丢包当"该补发了"。在一条丢包率高的烂线路上,这个认知差就是 10 倍速度差。