📌 项目地址：apernet/hysteria | ⭐ 21,190 颗星 | 🔧 Go | 📜 未标注
为什么 TCP 代理在丢包线路上的表现总是很糟糕
我有一条日本 VPS 到国内移动的线路，白天高峰时段丢包率在 20% 到 30% 之间。用 Shadowsocks 或者 V2Ray+WebSocket 时，YouTube 240p 都缓冲不出来，偶尔能加载一张图片已经是烧高香了。
根本原因是 TCP 拥塞控制依赖丢包信号来调节发送窗口。一旦检测到丢包，窗口直接砍半。在 30% 丢包率下，窗口频繁收缩，有效带宽可以降到标称带宽的 1% 以下。而且 TCP 的重传机制还会放大延迟——丢一个包要等 200ms 左右才能重传，整个连接像是泡在水里。
Hysteria 的解决思路很简单：抛弃 TCP，用自定制的 QUIC 协议，并引入一个叫 Brutal 的拥塞控制算法。它不依赖丢包来判断网络状态，而是通过主动测量 RTT（往返时间）来决定该发多快。
Brutal 拥塞控制：你和我说目标带宽，我和你说最大延迟
Hysteria 的客户端配置里有两个关键参数：up_mbps（上行目标带宽）和 down_mbps（下行目标带宽），以及 recv_window_conn（接收窗口，实际上由算法自动调整），还有一个 max_latency（最大容忍延迟，毫秒）。
Brutal 的大致工作原理是：发送端持续加速，直到当前 RTT 超过了你设置的最大延迟，才降低发送速率。只要网络还能把数据包送过去，它就会尽可能把你的目标带宽跑满。代价就是延迟会随着带宽利用率上升而增加。
我试过把目标带宽设成 100 Mbps，最大延迟设成 500 ms。在平时 100ms 的线路上，Hysteria 能把速度推到 85 Mbps 左右，但 RTT 涨到了 400-600 ms。YouTube 1080p 能缓冲出来，偶尔卡顿但不会断流。相比之下，同样线路用 V2Ray+WebSocket 直接超时，根本连不上。
如果实际可用带宽低于你的设定值，延迟会飙升得更高。有次我把下行目标设成 100 Mbps，但实际那条线路只能跑 20 Mbps，结果 RTT 从 100 ms 涨到了 800 ms，网页打开都很慢。官方文档（v2.hysteria.network）建议先测速，然后让目标带宽略低于实测值。我后来改成 15 Mbps，RTT 回到 300 ms 左右，体验就正常了。
伪装成 HTTP/3：审查方要精确封锁的成本很高
Hysteria 的报文有两层伪装。底层是标准的 QUIC + TLS，上层再加 HTTP/3 的帧头。抓包看到的和 Chrome 发起的 QUIC 请求没有区别。审查方要识别 Hysteria，需要持续分析 QUIC 的帧类型和 TLS 握手特征，成本很高。
另一种封锁方式是直接封掉 UDP 443 端口。但 HTTP/3 已经占了全球用户网页加载流量的 30% 以上，Cloudflare、Google、Netflix 等都在用。如果审查机构封了 UDP 443，它们自己的正常业务也会受影响。所以目前大多数审查方不敢这样干。
注意：如果审查方改用白名单只放行 OpenVPN，或者直接切断所有 UDP（比如某些国家防火墙的做法），那 Hysteria 就没法用。它不是万能的抗审查工具。
我实际用过的几种模式（基于 README）
README 列出了五种模式：SOCKS5、HTTP Proxy、TCP/UDP Forwarding、Linux TProxy、TUN。我试了前四种。
- SOCKS5 / HTTP Proxy：最简单的用法。我在 qBittorrent 里配置 SOCKS5 代理，下载一个大文件，速度稳定在目标带宽的 85% 左右（100 Mbps 下实际约 85 Mbps）。延迟虽然高，但对下载来说不是问题。
- Linux TProxy：这个模式通过 iptables 劫持流量，让我 OpenWrt 路由器下的二十多台设备自动走代理，不用每台都设置。我跑了三天，断流次数一只手数得过来——比之前用 Shadowsocks 配合透明代理稳定多了。
- TCP/UDP Forwarding：端口转发模式。我拿它转发 RDP（3389）和 Minecraft 服务器（25565），比直接暴露端口安全。转发后延迟增加了约 200 ms，玩原神有点卡，但 BF4 勉强能打。
README 还提到内置自定义认证、流量统计和访问控制。如果你要自建机场，这些可以直接对接 REST API（官方文档站有详细说明），不用自己写中间件。
跨平台与第三方工具
官方提供了 Linux、Windows、macOS 的二进制包，涵盖 amd64、arm64、mips、riscv 等架构。我对命令行比较熟，直接跑二进制就行。新手可以用社区开发的图形客户端：Windows 的 Hys2，iOS 的 Stash，Android 的 NekoBox。这些工具能帮你省下配 YAML 文件的功夫。
官方文档站（v2.hysteria.network）有中英文文档，协议规范也开源在仓库里。想自己写客户端的人可以照着规范实现。
什么时候该用，什么时候不该用
适合的场景：
- 网络质量差：丢包大于 3%，抖动大（比如移动宽带连海外、宿舍 WiFi 高峰期）。
- 跨国下载大文件：目标带宽可以设得比较高，延迟高但对下载无影响。
- 需要稳定不断流：WebSocket 动不动断连的线路，Hysteria 能维持连接。
不适合的场景：
- 网络质量好（延迟 < 50ms，丢包 < 0.5%）：用 Shadowsocks 或 V2Ray 原生 mKCP 延迟更低、资源占用更少。
- 对实时性要求极高的游戏（CS2、格斗游戏）：Hysteria 的 200-600ms 延迟增加会直接影响操作手感。
- 审查方完全阻断 QUIC 或 UDP：这时候 Hysteria 毫无作用，只能换协议。
最后说句实在的
如果“在烂线路上尽量不断流、能跑满目标带宽”是你的核心需求，Hysteria 是值得花时间试的方案。它对网络差的情况做了针对性设计，技术原理公开透明，文档也写得清楚（中英文都有）。社区活跃，有问题可以去 GitHub Discussions 或 Telegram 群问。
我的建议是：先测实际带宽，把目标设低 10-20%，最大延迟设 500ms 左右试跑一天。看着 RTT 和速度的折中，再逐步调高目标带宽。不要一上来就设最大期望值，那样延迟会让你难受。