Hysteria2 基于 QUIC 协议（UDP），理论上在高延迟、高丢包网络里比 TCP 类协议快得多。但很多人部署完发现速度一般，原因通常是带宽参数没配对或者拥塞控制算法没选对。
这篇文章专门讲调优。假设你已经跑通了基础部署（参考 Hysteria2 搭建教程），现在想把速度榨出来。
带宽参数：最影响速度的配置
Hysteria2 的带宽参数控制着它的发送速率，没配或配错是速度差的最常见原因。
服务端 bandwidth
/etc/hysteria/config.yaml：
bandwidth:
up: 1 gbps # 服务端上行（客户端下载方向）
down: 1 gbps # 服务端下行（客户端上传方向）
这里填的是服务端（VPS）的实际带宽上限，不是你家宽带的速度。
常见 VPS 带宽：
- DMIT HK/US Premium：1 Gbps 端口，但共享，实际峰值 200-500 Mbps
- AWS t3 类型：5-25 Gbps（burst）
- 低价 VPS：通常 100-500 Mbps
怎么测 VPS 实际带宽：
# 在 VPS 上安装 speedtest
curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh | bash
apt install speedtest-cli -y
speedtest
根据测速结果填带宽值。
客户端 bandwidth
mihomo 配置里：
proxies:
- name: "hy2-node"
type: hysteria2
server: 你的VPS_IP
port: 443
password: 你的密码
bandwidth:
up: "50 mbps" # 你家宽带上行
down: "200 mbps" # 你家宽带下行
这里填的是客户端（你本地）的宽带速度。
测你家宽带速度：speedtest.net 或运营商测速页面，取实测结果的 80% 填进去（留一点余量）。
带宽不匹配的后果
| 问题 | 原因 |
|---|---|
| 速度只有 10-20 Mbps | 客户端 bandwidth 没填，用了默认值（很小） |
| 速度忽快忽慢 | 客户端带宽填超了实际值，拥塞控制频繁触发 |
| 下载快、上传慢 | up/down 填反了 |
拥塞控制算法：BBR vs Brutal
Hysteria2 支持两种拥塞控制：
BBR（默认）：Google 开发的 TCP 拥塞控制算法，移植到 QUIC。会根据网络状态动态调整发送速率，保守但稳定。
Brutal：Hysteria2 自己开发的算法，忽略网络拥塞信号，按配置的目标带宽强行发送，类似"无脑狂推"。在丢包严重的网络里效果很好，但会占用更多带宽资源。
什么时候用 Brutal
- 网络丢包率高（超过 5%）
- 你的 VPS 线路走国际骨干网，延迟高
- 想要稳定在某个速度（比如稳定 50 Mbps），不在乎偶尔丢包
Brutal 配置
服务端 config.yaml：
quic:
initStreamReceiveWindow: 26843545
maxStreamReceiveWindow: 26843545
initConnReceiveWindow: 67108864
maxConnReceiveWindow: 67108864
maxIdleTimeout: 30s
keepAlivePeriod: 10s
disablePathMTUDiscovery: false
bandwidth:
up: 1 gbps
down: 1 gbps
客户端（mihomo）开启 Brutal 模式：
proxies:
- name: "hy2-brutal"
type: hysteria2
server: 你的VPS_IP
port: 443
password: 你的密码
brutal-opts:
enabled: true
up: 50 # Mbps，目标上行速度
down: 200 # Mbps，目标下行速度
开了 Brutal 后，客户端会强行以目标速度发送，无论网络质量如何。
实际对比
我在广州家宽测试，VPS 是 DMIT 香港（延迟约 25ms，轻微丢包）：
| 配置 | 下载速度 | 上传速度 | 稳定性 |
|---|---|---|---|
| BBR，无带宽配置 | ~15 Mbps | ~8 Mbps | 稳 |
| BBR，正确配置带宽 | ~80 Mbps | ~40 Mbps | 稳 |
| Brutal，目标 100M | ~95 Mbps | ~45 Mbps | 有抖动 |
结论：BBR + 正确的带宽配置，通常已经足够好。Brutal 适合特定场景（高丢包、想要稳定速度保障）。
QUIC 窗口大小调优
QUIC 的接收窗口大小影响最大并发吞吐，默认值在高带宽环境下可能是瓶颈。
推荐配置（高速环境，如 100 Mbps+）：
quic:
initStreamReceiveWindow: 26843545 # 25.6 MB
maxStreamReceiveWindow: 26843545
initConnReceiveWindow: 67108864 # 64 MB
maxConnReceiveWindow: 67108864
这些数字是经验值，适合 100-500 Mbps 的场景。如果你的带宽更高，可以继续调大（建议不超过总 RAM 的 10%）。
MTU 调优
UDP/QUIC 的包大小影响效率，默认 MTU 对 VPN 场景不一定最优。
查看当前网络接口的 MTU：
ip link show eth0
# MTU 通常是 1500
Hysteria2 的 QUIC 包在 MTU 1500 的网络里，实际有效载荷约 1200-1350 字节（扣除各层头部）。
对于大多数场景，不需要手动调 MTU。只有在某些企业网络或特殊 ISP 里，如果发现速度异常低且有大量分片，才需要尝试降低 MTU：
# 客户端 mihomo
proxies:
- name: "hy2-node"
type: hysteria2
# ... 其他配置 ...
# 部分客户端支持设置 mtu
mtu: 1200
端口选择
Hysteria2 走 UDP，端口选择影响被封概率：
| 端口类型 | 代表 | 被封风险 |
|---|---|---|
| 443 | HTTPS（伪装） | 低，但 UDP 443 不常见 |
| 80 | HTTP（伪装） | 中 |
| 随机高端口（如 44563） | 无伪装 | 高（容易被扫到） |
最佳实践：用 443 或 853（DNS over QUIC），伪装成正常协议。
# 服务端
listen: :443
# 伪装成 HTTPS
masquerade:
type: proxy
proxy:
url: https://www.bing.com
rewriteHost: true
masquerade 配置让普通 HTTPS 请求（非 Hysteria2 客户端）打到这个端口时，返回 bing.com 的正常内容。
多节点负载均衡
如果你有多台 VPS，可以配置 mihomo 的 load-balance 组同时使用多个 Hysteria2 节点：
proxy-groups:
- name: "HY2 Balance"
type: load-balance
strategy: round-robin # 轮询，平均分配流量
proxies:
- hy2-us
- hy2-hk
- hy2-jp
url: "http://www.gstatic.com/generate_204"
interval: 300
或者用 fallback 模式（主节点挂了才切）：
- name: "HY2 Fallback"
type: fallback
proxies:
- hy2-us # 主节点
- hy2-hk # 备用
url: "http://www.gstatic.com/generate_204"
interval: 120
与 REALITY 的对比
选 Hysteria2 还是 REALITY，取决于你的网络环境：
| 场景 | 推荐 |
|---|---|
| 延迟敏感（<30ms），稳定线路 | REALITY（低延迟，无额外开销） |
| 高丢包、不稳定线路 | Hysteria2（QUIC 重传效率高） |
| 移动网络（4G/5G） | Hysteria2（QUIC 对移动网络更友好） |
| 需要绕过 UDP 封锁的网络 | REALITY（纯 TCP） |
→ 查看 Hysteria2 搭建教程 → 查看 Xray REALITY 服务端配置 → 查看 VPS 选购指南
📷 封面图 · Flux Schnell AI 生成 · panshi.io 品牌风格