TL;DR：Hysteria2 丢包排查先降 MTU，再限速率。QUIC 跑在 UDP 上，路径里任何一段不喜欢大包，都会变成卡顿、重传或起播慢。不要一上来把带宽参数填满。
Hysteria2 的速度来自 QUIC 与 Brutal 拥塞控制，但它也更依赖链路质量。很多问题不是「协议坏了」，而是 MTU、速率和路径丢包没有调到同一档。
典型症状
| 现象 | 可能原因 |
|---|---|
| speedtest 很高，网页首开慢 | 小包重传、DNS 路径异常 |
| 视频起播慢，播放后正常 | 首段请求丢包或握手重试 |
| 手机热点可用，家宽卡 | 家宽路径 MTU 或 UDP 策略不同 |
| 晚高峰明显变差 | 真实可用带宽低于配置速率 |
先把现象写下来，别同时改 MTU、端口、obfs、速率。一次改太多，最后不知道是哪项生效。
MTU 为什么会影响 Hy2
MTU 是单个包能承载的最大尺寸。路径 MTU 低时，大 UDP 包可能被分片或丢弃。TCP 有更成熟的发现与回退机制，UDP 场景下就更依赖应用和系统处理。
实操建议：
- 客户端 MTU 先设 1200。
- 观察 5 分钟网页、视频、下载三类场景。
- 如果正常，再试 1250、1300。
- 一旦卡顿复现，退回上一个值。
速率参数别填满
Brutal 需要你告诉它大概带宽。填太高，它会持续施压，丢包链路会更糟。更稳妥的写法是：把上下行都写成真实可用带宽的 70%-80%。比如晚高峰实测上行 30 Mbps，就不要写 100 Mbps。
如果你只是想确认订阅侧是否支持 Hy2，可用兼容 Clash / Singbox / V2Ray 的订阅做交叉测试，但 MTU 与速率仍要按本机网络调。
服务端检查表
服务端先看基础资源，再看协议参数。若同一台机器上还有下载、转码或其它高吞吐任务，Hy2 的抖动会被放大；排障时最好留出空闲窗口，避免把机器负载误认为链路问题。
- CPU 没有被加密计算打满。
- UDP receive/send buffer 足够。
- 防火墙没有对目标端口做限速。
- 云厂商安全组允许 UDP 入站。
- Hy2 服务端版本与客户端内核不要相差太久。
客户端检查表
- MTU 从 1200-1250 开始。
- 速率填真实可用值，不填标称套餐值。
- sing-box 与 Mihomo 参数按各自文档写。
- 排障期间关闭其它占用 UDP 的应用。
- 每次只改一个参数并记录结果。
调 Hy2 不追求一个万能配置。能在你的网络、你的设备、你的时间段里持续顺滑，才算调完。
排查时的优先级
遇到 Hysteria2 MTU 丢包 相关问题时，先固定一个可复现样本，再改配置。不要凭感觉同时换设备、地区、账号和客户端。对“部署 Hysteria2 服务端、使用 sing-box 或 Mihomo Hy2 出站的用户”来说，最省时间的方法是按“现象、范围、最近变更、可回滚动作”四步记录。
| 步骤 | 要确认什么 |
|---|---|
| 现象 | 是报错、限速、空白页、扣费异常，还是权限不足 |
| 范围 | 只影响一个账号/设备，还是同一批任务都失败 |
| 变更 | 最近是否改过版本、地区、套餐、密钥或规则 |
| 回滚 | 能否回到上一个正常状态并复测 |
什么时候停止继续试错
如果同一问题连续试了三种方案仍无改善，先停下来整理证据。把错误截图、时间、账号地区、请求 id、订单号或配置片段放在一起，再决定是联系官方支持、换备用路径，还是回退到旧方案。客户端、协议、规则和网络工具配置 里的很多问题不是单点开关能解决，复盘记录比继续乱改更重要。