Hysteria2 是什么：QUIC 协议为什么在丢包网络里更快，以及它的限制

Hysteria2 是什么

Hysteria2 是一个基于 QUIC 的代理协议，是 Hysteria 项目在 2023 年发布的第二代版本。它和 Shadowsocks、Trojan 最大的不同在于传输层：后两者跑在 TCP 上，Hysteria2 跑在 UDP 之上的 QUIC 协议上，并且用一套自定义的拥塞控制算法代替了 TCP 的标准行为。

它受关注的原因很直接：在丢包严重的跨境线路上，比如晚高峰的直连或普通中转，Hysteria2 节点的下载速度经常是同机房 TCP 协议节点的数倍。要理解这一点，需要先理解 TCP 为什么怕丢包。

TCP 为什么怕丢包

TCP 的拥塞控制有一个核心假设：丢包意味着网络拥塞。主流算法（如 Linux 默认的 Cubic）一旦检测到丢包，就会大幅缩减拥塞窗口（也就是发送速率），然后缓慢爬升，直到下一次丢包再缩减。在设计这套机制的年代，这个假设基本成立：有线网络很少随机丢包，丢包几乎都是路由器队列溢出导致的。

但跨境线路并不符合这个假设。国际出口在晚高峰的丢包，一部分是真实拥塞，一部分是随机的；长距离、多跳的路径上，即便带宽充足也可能有 1%–3% 的背景丢包。TCP 无法区分这两种情况，一律降速。结果就是 Mathis 公式所描述的：单条 TCP 连接的吞吐量大致与 1/(RTT × √丢包率) 成正比。RTT 200ms、丢包 5% 的线路上，单条连接的吞吐量会被压到几 Mbps，哪怕物理带宽有几百 Mbps。

这就是晚高峰“带宽明明够、速度就是上不去”的技术原因。换节点、换另一种 TCP 协议都解决不了，因为瓶颈在拥塞控制的逻辑里。

QUIC 改变了什么

QUIC 最初由 Google 设计，2021 年成为 IETF 标准（RFC 9000），是 HTTP/3 的传输层。它跑在 UDP 上，在用户态实现了可靠传输、加密与多路复用。对代理协议来说，QUIC 带来四点有意义的变化。

• TLS 1.3 内建：握手与加密是协议的一部分，通常 1-RTT 完成，支持 0-RTT 恢复，比“TCP 三次握手 + TLS 握手”少一个来回。
• 流级别的多路复用：一个 QUIC 连接内可以有多条独立的流，某条流丢包只阻塞它自己，不会像 TCP 那样让整个连接等待重传（队头阻塞）。浏览网页时几十个请求同时跑，这个差别很明显。
• 更精确的丢包恢复：QUIC 的每个包有唯一递增的编号，重传包使用新编号，没有 TCP 的重传歧义问题，RTT 估计与丢包检测更准确，恢复更快。
• 连接迁移：连接由连接 ID 而不是 IP 与端口四元组标识，手机从 Wi-Fi 切到蜂窝网络时连接不断。

但要说清楚：标准 QUIC 默认仍然使用 Cubic 或 BBR 这类拥塞控制，遇到丢包同样会降速。QUIC 本身只是“恢复得更聪明一点”，并不能让吞吐量在 5% 丢包下翻倍。真正让 Hysteria2 快的，是下面这一步。

Hysteria2 的关键：Brutal 拥塞控制

因为 QUIC 在用户态实现，协议作者可以自由替换拥塞控制算法。Hysteria2 的默认算法叫 Brutal，逻辑简单到近乎粗暴：用户告诉它链路带宽是多少，它就按这个速率发送，丢包了就重传，但不降速。

它不再把丢包当作拥塞信号，而是把带宽当作已知条件。在丢包 10% 的线路上，Brutal 会按配置速率的大约 110% 发送，用冗余发送覆盖丢包，最终交付速率仍然接近配置值。这正是“丢包网络里更快”的来源：不是传输效率更高，而是不再因为丢包而自我限速。

Brutal 需要用户提供上传与下载带宽两个参数（客户端配置里的 up 与 down）。如果留空，Hysteria2 会退回到 BBR 算法，表现接近普通 QUIC，仍然比 Cubic 稍好，但没有 Brutal 那种对丢包的免疫。

其他设计：混淆、端口跳跃与伪装

Hysteria2 还有几项与可用性直接相关的设计。

这些特性是否可用取决于机场的服务端配置，订阅链接里会带上对应参数，用户一般不需要手动设置。

它的限制

Hysteria2 不是万能的，在四类情况下它可能比 TCP 协议更差。

UDP 限速与丢弃：这是最常见的问题。部分运营商对长时间、大流量的 UDP 连接做 QoS 限速，表现为 Hysteria2 节点开始几分钟非常快，之后速度急剧下降甚至断流。这不是机场故障，而是网络策略，切换到同地区的 Trojan 或 Shadowsocks 节点即可恢复。

UDP 被完全封锁：一些校园网、企业网、公共 Wi-Fi 只放行 TCP 的 80 与 443 端口，Hysteria2 在这些网络下根本连不上。

公平性：Brutal 不会在拥塞时让步，它会挤占同一链路上其他 TCP 流的带宽。对用户来说，这意味着开着 Hysteria2 下载时，同一网络下其他人的视频可能会卡；对机场来说，意味着一个 Brutal 用户可能影响同节点上的其他用户，所以不少机场只在部分节点提供 Hysteria2，或限制其带宽参数。

资源开销：用户态 QUIC 的 CPU 占用高于内核 TCP，手机上持续高速传输时发热与耗电更明显；路由器等低性能设备上的吞吐量可能受 CPU 限制。

另外，Hysteria2 的抗识别能力属于中等。标准 QUIC 流量很常见（Chrome 访问 Google 服务就是 QUIC），但长时间高速率的 QUIC 流本身就是一种特征，Salamander 混淆能缓解但不能根除。需要强抗干扰的场景，VLESS + REALITY 或 Trojan 更合适，各协议的横向对比见网络协议。

怎么用：客户端支持与配置要点

主流客户端对 Hysteria2 的支持已经很完整。Mihomo（Clash Meta）内核的 Clash Verge 与 Clash Meta for Android、sing-box 内核的 sing-box 官方客户端与 Hiddify、iOS 上的 Shadowrocket 与 Stash、Windows 上的 v2rayN、Android 上的 v2rayNG 都支持。旧版 Clash 内核（非 Meta）不支持，导入后会看不到 Hysteria2 节点，升级客户端即可。

机场订阅中的 Hysteria2 节点在 Mihomo 配置里大致是这样：

proxies:
  - name: "HK-Hysteria2"
    type: hysteria2
    server: hk.example.com
    port: 443
    password: your-password
    up: "50 Mbps"
    down: "200 Mbps"
    sni: hk.example.com
    skip-cert-verify: false
    obfs: salamander
    obfs-password: your-obfs-password

使用时注意三点。

1. up / down 按自己的宽带填：订阅里机场给的是通用值，自己的宽带比它小就改小；留空则退回 BBR。
2. 不要开启 skip-cert-verify：除非机场明确说明使用自签证书。跳过证书校验会让连接失去身份验证。
3. 保留 TCP 备用节点：在自动选择分组里同时放入同地区的 Trojan 或 Shadowsocks 节点，UDP 被限速时客户端会自动切换。

需要说明的是，本站当前收录的 22 家品牌在公开资料中都没有列出 Hysteria2：协议集中在 Shadowsocks、VMess、VLESS 与 Trojan，例如光速云、大佬云全线 VLESS，一翻云是 Shadowsocks + Trojan，暮光网络与微风网络未公开协议。如果你确实需要 Hysteria2，购买前要向品牌单独确认，以实际订阅中的节点为准；收录品牌的专线节点本身丢包较低，多数情况下用 TCP 协议已经足够。

总结

Hysteria2 快在两个层面：QUIC 提供了更精确的丢包恢复、无队头阻塞的多路复用与连接迁移；Brutal 拥塞控制则干脆不把丢包当作降速信号，按用户配置的带宽持续发送。在晚高峰丢包 5%–20% 的跨境线路上，这让它的实际速度远高于会反复降速的 TCP 协议。

代价是对网络环境的依赖：UDP 可能被限速或封锁，Brutal 对其他流量不公平，带宽参数填错会适得其反。合理的用法是把 Hysteria2 当作丢包严重时的加速选项，而不是唯一协议：按实际宽带填好 up 与 down，保留 TCP 节点作为备用，遇到几分钟后掉速就切换。想了解其他协议的定位与客户端支持情况，见网络协议专题。