Hysteria 2（歇斯底里）狂暴提速：基于 QUIC/UDP 协议恶劣网络下的性能怪兽

一、TL;DR：先给结论，再讲道理

如果你的线路属于「跨境出口拥塞严重、晚高峰丢包 5%~20%、TCP 一丢包就断崖掉速」这一档，Hysteria 2 目前仍然是性价比最高的暴力解法。它靠在用户态实现的 QUIC 之上挂了一个近乎「不讲武德」的拥塞控制算法 Brutal：不管丢多少包，客户端都按你设定的目标带宽持续灌包，用重传硬扛，从而把 TCP 那种「丢一个包就砍一半窗口」的连锁反应彻底掐断。

但请记住三句话：

Hysteria 2 不是魔法，是带宽赌博。它把「公平退让」换成「持续抢占」，代价是你的实际可用带宽必须真的大于目标带宽，否则会雪崩式自伤，甚至被运营商 QoS 直接点名。
它对 UDP 通道质量高度敏感。运营商 QoS、NAT 会话老化、UDP 缓冲过小、MTU 分片，这四件事任意一件出问题，表现会比 TCP 还惨。
它是最优解，但不是唯一解。稳定干净的精品线路（IEPL/IPLC）上，VLESS + Vision + Reality 的体验往往更省电、更稳、更隐蔽；Hysteria 2 的价值在于「烂网救火」和「大带宽单线程下载」。

下面这份指南，会把物理层机理、10 项量化对照、分平台配置、抓包诊断命令、避坑矩阵和 FAQ 全部讲清，尽量少一点玄学，多一点可验证的数据。

二、底层机理：为什么 UDP 能在烂网里跑出 TCP 的三倍速度

要理解 Hysteria 2，必须先理解 TCP 的「道德约束」。

TCP 的核心假设是：丢包 ≈ 网络拥塞。于是 CUBIC、BBR 这些算法在检测到丢包时会主动降速，给其他流让路。这在公网是美德，在跨境链路上却是灾难——因为跨境丢包的主因往往不是拥塞，而是运营商骨干出口的队列丢弃、国际带宽争抢、以及跨海光缆的瞬时抖动。你让路了，别人没让，你就永久性地被压在低速档。

BBRv3 相比 CUBIC 已经进步巨大，它把丢包和带宽探测解耦，在 1%~2% 丢包环境下仍能跑到线速的 70%~90%。但一旦丢包率越过 5%，BBRv3 也会开始退让，因为它的模型里仍然存在「丢包意味着路径容量下降」的先验。

Hysteria 2 走的是另一条路：

传输层用 QUIC（RFC 9000），跑在 UDP 上。QUIC 自己实现了流控、重传、加密与多路复用，天然绕开内核 TCP 的拥塞状态机，避免了 HTTP/2 场景下的队头阻塞。
拥塞控制用 Brutal。它由 Hysteria 作者实现，本质是「固定速率发送 + 强制重传」：客户端按 up 配置的目标速率持续发包，服务端按 down 配置回包。丢包不触发降速，只触发重传。理论上只要物理链路能撑住，吞吐就贴着目标值走。
TLS 1.3 握手内嵌。Hysteria 2 的流量在特征上非常接近标准 HTTP/3，配合 Salamander 混淆和端口跳跃，被动 DPI 的识别成本明显高于裸 Trojan/TLS。
认证与多路复用更轻。用户密码认证走 HTTP 请求头或 URL 参数，服务端可以做到极低的状态开销。

代价同样明确：Brutal 是一种非友好型拥塞控制。它不会对同链路上的其他流量礼让，在共享出口（尤其是家宽上行、部分运营商国际出口）上跑高目标带宽，会引发队列膨胀、丢包率进一步上升，最终进入「你灌得越猛、丢得越多、重传越多」的正反馈。这也是为什么很多人在家宽上开满 1Gbps 目标带宽，实测反而只有 20Mbps 的原因。

至于「运营商 UDP QoS 限速」，本质是三类机制叠加：一是运营商的流量整形策略对 UDP 大流量做标记降级（DSCP 重写、令牌桶限速）；二是 UDP 会话在不活跃时被 NAT 表项回收，导致连接莫名其妙断掉；三是部分地区对高频 UDP 大包进行速率限制。Hysteria 2 ��对抗手段是端口跳跃（Port Hopping）——客户端在服务端配置的 UDP 端口区间内周期性换端口，让基于「五元组 + 端口」的限速策略难以持续命中同一个流。这不是破解，而是规避策略命中，能不能生效取决于运营商的策略粒度。

三、协议横评：10 项量化指标对照

以下矩阵基于 AirPick 实验室 2026 年 Q1 的对照测试环境（华东电信家宽 1000M/100M、日本 IEPL 中转、晚高峰 20:00–23:00），数据为区间值，不代表任何服务商的普适承诺，仅供协议选型参考。

评估维度	Hysteria 2	TUIC v5	VLESS+Vision+Reality	Trojan-Go	WireGuard
传输层	QUIC over UDP	QUIC over UDP	TCP（可套 XTLS）	TCP + TLS	UDP（内核态）
握手往返	1-RTT（支持会话恢复）	1-RTT	1-RTT	1-RTT	1-RTT
20% 丢包下吞吐保留率	65%–85%	55%–75%	5%–15%	5%–15%	40%–60%
单线程大带宽上限	可达链路 80%+	可达链路 70%+	受 BBR 退让影响，通常 30%–60%	同上	高（但受 UDP 限制）
弱网 RTT 抖动	中（重传导致毛刺）	中	低	低	低
抗 UDP QoS 能力	强（端口跳跃 + 混淆）	中（部分实现支持）	强（全 TCP，不触发 UDP 策略）	强	弱（裸 UDP 特征明显）
抗主动探测/DPI	中高	中	极高（无证书、真站点 SNI）	中高	低
服务端 CPU 占用	高（用户态 QUIC，单核易成瓶颈）	高	低	低	极低
移动端耗电/发热	偏高	偏高	低	低	中
部署与调参复杂度	中（带宽参数需调）	中	低	低	中

一句话读表：丢包越狠、带宽越大，Hysteria 2 相对 TCP 系协议的优势越明显；线路越干净、设备越省电优先，Reality 反而更舒服。

四、谁该用 Hysteria 2：细分场景选型手册

强烈推荐：

晚高峰丢包明显的家宽用户：典型症状是 mtr 到出口第 5~7 跳开始出现 10% 以上丢包，Ping 尖峰抖动剧烈。Hysteria 2 的目标带宽设为实测可用带宽的 70%~80%，通常能挽回 3~5 倍的实际吞吐。
需要跑单线程大带宽的场景：4K/8K 视频流、大文件直下、云盘同步、Docker 镜像拉取。多线程下载对协议不敏感，单线程才是照妖镜。
移动网络 / 4G 5G 热点用户：蜂窝网络切换、信号衰减造成的瞬时丢包对 TCP 极不友好，QUIC 的连接迁移特性（Connection Migration）在这种场景下体验提升直观。

谨慎使用：

上行只有 30M 的家宽：Brutal 的上传目标带宽一旦设超过实际上行，会把自己打成拥塞，务必设到上行实测值的 60% 以下。
软路由性能弱（如 N100 以下、ARM 单核）：用户态 QUIC 的每包开销远高于内核 TCP，千兆场景下 CPU 会是硬瓶颈，实测可能只有 200–400Mbps。
对耗电敏感的长时间移动办公：QUIC 高频收发会让手机基带和 CPU 持续忙碌，续航下降 15%~30% 是常态。

不推荐：

已有稳定 IEPL/IPLC 专线、线路本身零丢包：这时候 Hysteria 2 的蛮力毫无用武之地，反而多消耗 CPU。
对企业合规出口有强审计要求的场景：UDP 大流量在很多企业网关上是异常行为，容易被安全设备拦截并告警。

💡 ⭐ 2026 不限时按量首选 · 【星岛梦】读者专享特惠通道：
2020 年老牌稳定运营，提供丰富的不限时按量计费套餐，企业级专线保障，用多少扣多少，适合备用与长周期：

9折立减nmw888复制 📋

直达星岛梦官网 ↗

👉 查看【星岛梦】实验室 2026 最新测速报告与深度评测 →

需要强调的是，Hysteria 2 只是「客户端协议」，它跑得快不快，八成取决于服务端背后是 IEPL 专线还是超售的普通中转。协议永远救不了烂线路，这点在 /tech/ 的线路科普里讲过很多遍。

五、分平台实操配置与三个高频坑

服务端参数怎么定？ 这是最容易被忽略的一步。bandwidth.up / bandwidth.down 是服务端的上限护栏，不是目标值；客户端的 up / down 才是实际目标速率。经验公式：

客户端 down = 服务端到目标资源实测单线程峰值的 75%
客户端 up = 本地上行实测峰值的 50%~60%
服务端护栏 = 上述数值的 1.5~2 倍，防止恶意占满

yaml

# 客户端 sing-box 片段（Hysteria 2）
{
  "type": "hysteria2",
  "tag": "hy2",
  "server": "example.com",
  "server_ports": ["20000:40000"],
  "hop_interval": "30s",
  "password": "your-password",
  "up_mbps": 30,
  "down_mbps": 300,
  "tls": {
    "enabled": true,
    "server_name": "your.domain.com",
    "insecure": false,
    "alpn": ["h3"]
  }
}

端口跳跃（Port Hopping） 需要服务端用 nftables 或 iptables 把整个 UDP 端口段 DNAT 到主监听端口，否则客户端跳到未监听端口会直接超时。Linux 示例：

bash

nft add rule ip nat prerouting udp dport 20000-40000 dnat to :8443

分平台要点：

Windows：推荐 Clash Verge Rev / NekoBox / sing-box 官方内核。注意 Windows Defender 防火墙可能对 UDP 高频外发做限流，建议为代理内核进程添加放行规则。
macOS：Surge、Stash、Clash Verge Rev 均支持；Hysteria 2 在 Apple Silicon 上原生编译比 Rosetta 快 30% 以上。
iOS / Android：Shadowrocket、Stash、sing-box、NekoBox。移动端务必关闭「后台保活」类省电白名单外的限制，否则 QUIC 会话被系统挂起会表现为频繁断流。
OpenWrt / 软路由：mihomo 与 sing-box 都支持，但强烈建议先在 x86 上跑通再上 ARM。开启 GSO/GRO 与调大 socket 缓冲是提升上限的关键。

三个高频坑：

目标带宽设成「签约带宽」：1000M 家宽晚高峰实际可用可能只有 80Mbps，设定 1000 只会自伤。
insecure: true 长期开着：省了证书配置，但失去了唯一的身份校验，被中间人劫持的代价远大于便利。
混淆（Salamander）与 CDN 混用：混淆会改变载荷特征，套 CDN 时大概率直接失败，二选一。

六、抓包排障诊断手册：6 条命令 + 判定表

Step 1 · 判断丢包发生在哪一跳

bash

mtr -u -c 200 -P 443 --report-wide 目标IP     # Linux/macOS
# Windows 用 WinMTR，UDP 模式需第三方工具

关键看丢包从第几跳开始出现、是否持续到终点。中间跳短暂丢包是正常的（ICMP/UDP 限速），只要最后一跳干净就不算问题；最后一跳丢包 > 5%，说明你的出口或对端就是瓶颈。

Step 2 · 探测路径 MTU，排除分片

bash

ping -M do -s 1472 1.1.1.1          # Linux
ping -f -l 1472 1.1.1.1             # Windows

如果 1472 不通而 1400 通，说明路径 MTU 低于 1500。QUIC 默认按 1200 字节构造初始包，一般没问题，但如果服务端配置了超大 UDP 载荷，分片会导致大量丢包，需下调 MTU 或开启 DPLPMTUD。

Step 3 · 验证 UDP 端口是否被限速/封禁

bash

tcping -u -p 8443 你的服务端IP
nc -u -v 你的服务端IP 8443        # 简单连通性

时通时不通、或者白天通晚上不通，基本可以判定是对 UDP 的策略性拦截或 QoS。

Step 4 · 端到端测速，看是否被单核限制

bash

curl -x socks5h://127.0.0.1:7891 -o /dev/null -s \
  -w "code=%{http_code} connect=%{time_connect} ttfb=%{time_starttransfer} speed=%{speed_download}\n" \
  "https://speed.cloudflare.com/__down?bytes=104857600"

同时用 top -H 或 htop 观察代理进程线程占用。若某一线程跑满 100% 而带宽没上去，就是典型的 CPU 瓶颈，考虑多核分发或换内核。

Step 5 · 查 UDP 内核丢包统计

bash

netstat -su | grep -iE "buffer|error|dropped"
ss -u -a -n | grep 8443
sysctl -w net.core.rmem_max=16777216 net.core.wmem_max=16777216

receive buffer errors 持续增长 = 收包速度跟不上，加大缓冲通常立竿见影。

Step 6 · 抓包确认流量形态

bash

tcpdump -i eth0 -n udp port 8443 -c 200 -w hy2.pcap

用 Wireshark 打开，看是否存在大量重复序号的重传、是否有明显的分片（Fragment）包、握手是否完整。判定表：

现象	高概率原因	处置方向
测速高但网页首开慢	DNS 未走代理 / MTU 偏大	改用远端 DNS，下调 MTU 至 1400
白天正常晚高峰崩	出口超售或 UDP QoS	降目标带宽、启用端口跳跃、换线路
连接频繁重建	NAT 会话老化	缩短 hop_interval 或保持心跳
上传慢下载快	up_mbps 设置过高	降到上行实测的 50%
CPU 单核打满	用户态 QUIC 瓶颈	开 GSO/GRO、换多核、降带宽

七、行业避坑矩阵：识别虚假宣传、超售与伪解锁

宣传话术	常见真相	验证方法
「千兆狂飙，无限速」	你本地可能只有 100M 出口	先测本机裸连速度，再对比代理速度
「Hysteria2 独家，速度翻三倍」	线路仍是普通中转，晚高峰照崩	晚 21:00 独立测速，连续测 3 天
「不限流量」	达量限速至 5~20Mbps	查看 TOS 里的 Fair Use 条款
「原生 IP 全解锁」	仅解锁自制剧，第三方版权内容不可用	实测 Netflix 非自制、Disney+、HBO
「1 元 / 月不限量」	蜜罐、黑产流量池或钓鱼	拒绝任何来源不明的超低价节点
「专线 IEPL 直连」	实为普通公网中转	mtr 观察中间跳是否出现 59.43 骨干段

一个通用判据：任何声称速度超过你物理带宽上限的，都是假的。 代理商能改变的只有跨境段，改变不了你家门口的最后一公里。

八、FAQ：7 个真实高频痛点

Q1：Hysteria 2 一定比 VLESS+Reality 快吗？ 不一定。干净线路上 Reality 和 hy2 的差值通常在 10% 以内；只有在丢包 > 5% 时，hy2 才会拉开明显差距。别为了「看起来更快」牺牲隐蔽性和省电。

Q2：UDP 被运营商限速了怎么办？ 先确认是限速还是丢包（用第六节的 mtr 和 tcping）。确认是限速，优先启用端口跳跃 + Salamander 混淆；如果仍无效，说明策略粒度很粗，只能回退到 TCP 系协议。

Q3：为什么测速很快，看视频还是卡？ 测速多为多线程并发，而视频流是单线程长连接，对 RTT 抖动和重传延迟极为敏感。同时检查是否是 DNS 解析慢、是否命中了劣质 CDN 节点。

Q4：手机端特别烫、掉电快？ QUIC 的高频小包收发对移动 SoC 是重负载。缓解方式：降低目标带宽、改用 Reality、或在充电时使用。这是物理限制，没有软件解法。

Q5：端口跳跃会被识别吗？ 端口范围过大且频繁跳跃本身也是一种特征，建议区间控制在 1000~3000 个端口内，hop_interval 设 30~60 秒，避免过于激进。

Q6：服务端 CPU 被打满怎么办？ 开启 GSO/GRO、把 max_idle_timeout 调低释放僵尸会话，或者直接换更强的机器。Hysteria 2 对单核性能的敏感性远高于其他协议。

Q7：目标带宽到底设多少合适？ 不要拍脑袋。用裸连单线程下载测出真实峰值，再乘 0.75。宁可保守，也不要把 Brutal 变成自伤武器。

九、延伸阅读内链矩阵

协议横向对比总

Hysteria 2（歇斯底里）狂暴提速：基于 QUIC/UDP 协议恶劣网络下的性能怪兽 ​

一、TL;DR：先给结论，再讲道理 ​

二、底层机理：为什么 UDP 能在烂网里跑出 TCP 的三倍速度 ​

三、协议横评：10 项量化指标对照 ​

四、谁该用 Hysteria 2：细分场景选型手册 ​

五、分平台实操配置与三个高频坑 ​

六、抓包排障诊断手册：6 条命令 + 判定表 ​

七、行业避坑矩阵：识别虚假宣传、超售与伪解锁 ​

八、FAQ：7 个真实高频痛点 ​

九、延伸阅读内链矩阵 ​

Hysteria 2（歇斯底里）狂暴提速：基于 QUIC/UDP 协议恶劣网络下的性能怪兽

一、TL;DR：先给结论，再讲道理

二、底层机理：为什么 UDP 能在烂网里跑出 TCP 的三倍速度

三、协议横评：10 项量化指标对照

四、谁该用 Hysteria 2：细分场景选型手册

五、分平台实操配置与三个高频坑

六、抓包排障诊断手册：6 条命令 + 判定表

七、行业避坑矩阵：识别虚假宣传、超售与伪解锁

八、FAQ：7 个真实高频痛点

九、延伸阅读内链矩阵