Hysteria2 值得在 UDP 可达、往返延迟较高或存在随机丢包的网络中验证，但不能仅凭协议名称判断速度。本文面向已经持有自己的服务商配置与订阅的用户，先解释 QUIC 的传输机制，再给出 Shadowrocket 中的导入、分流核对与复测步骤，帮助区分参数错误、UDP 受限和规则未命中三类问题。
一、Hysteria2 与 QUIC：优势来自哪里
Shadowrocket（小火箭）中的 Hysteria2 是一种代理协议选择。它以 QUIC 为传输基础，而 QUIC 使用 UDP 承载数据，并结合 TLS 1.3 完成安全连接。这里需要区分两件事：底层使用 UDP，不等于应用数据全部采用不可靠传输；QUIC 可以在 UDP 之上为流提供有序交付、丢失恢复与流量控制。
传统 TCP 连接中的多个应用请求若共享同一条有序字节流，一处丢包可能阻塞后续数据交付。QUIC 将不同流的交付分开管理，某个流等待缺失数据时，其他流不必仅因这一缺口而一起等待。不过，各流仍可能共享拥塞控制与链路容量，因此“流之间减少交付阻塞”不能理解为“丢包完全没有影响”。
- UDP：提供数据报承载，不自行保证可靠交付，也不会自动绕过网络限速。
- QUIC：在传输层实现连接管理、安全握手与多流机制；同一个流内仍需要保持有序交付。
- Hysteria2：在 QUIC 之上组织代理通信，并具有面向吞吐的拥塞控制与带宽配置机制。
- 实际体验：还受无线信号、链路拥塞、服务器负载、目标站点及配置参数共同影响。
Hysteria2 在部分随机丢包链路上的吞吐优势，也与其带宽驱动的拥塞控制方式有关，并非所有基于 QUIC 的连接都会得到相同结果。客户端带宽声明、服务器限制和协商结果都会影响行为；不能把“使用 QUIC”直接换算成一个固定的提速百分比。
二、高延迟与高丢包：先分清瓶颈
高延迟意味着发送请求到收到响应需要更长时间。Hysteria2 无法消除物理距离造成的往返时间，但可能在适合的链路上维持更高吞吐。高丢包则要进一步区分：无线干扰造成的随机丢失，与队列持续拥塞导致的丢失，不适合用完全相同的办法处理。网络已经拥塞时，单纯加大发送量可能使通话、网页和其他设备的连接一起变差。
| 网络现象 | 如何理解 | 验证动作 |
|---|---|---|
| 小网页正常，大文件吞吐低 | 可能涉及丢包、拥塞或远端带宽，不能只看延迟。 | 固定同一文件、同一服务器与同一网络，重复传输并记录用时。 |
| 空闲时正常，下载时延迟大幅增加 | 可能是链路队列积压，较激进的发送设置会加重现象。 | 暂停其他大流量任务，降低带宽声明后再次比较。 |
| Wi-Fi 无法连接，蜂窝网络正常 | 当前 Wi-Fi 可能限制 UDP，也可能存在不同的 DNS 或出口策略。 | 保持配置不变，仅切换网络，分别核对解析与握手结果。 |
| 首次请求慢，持续传输正常 | 应分别检查 DNS、连接建立与目标站点响应。 | 分开记录首次打开时间与后续传输表现。 |
结论：先做单变量复测
只有在服务器、目标资源和分流路径固定后，切换网络或调整一个参数得到的差异才有判断价值；不要同时更换订阅、DNS 与 Global Routing 后把改善归因于 Hysteria2。
可以采用一个明确的记录方案：每个网络完成 3 次相同资源的传输，每次持续约 60 秒，记录完成字节数、用时、是否中断及测试时间段。此处是复测方法，不是产品性能数据。单次峰值和一个延迟读数，都不足以证明协议更适合当前网络。
三、在 Shadowrocket 导入并核对 Hysteria2
以用户已有的订阅或完整配置为起点。Hysteria2 需要服务端支持，不能只把已有服务器的 Type 改成 Hysteria2。导入后仍应核对 Address、Port、认证信息与 TLS 参数；订阅内容完整时，保留原始字段通常比凭经验补填更可靠。
-
导入已有订阅
打开 Home → 右上角“+”→ Type → Subscribe，粘贴自己已有的订阅链接并保存。订阅地址含访问凭据，不应公开粘贴到截图或排查记录中。
-
核对协议类型
回到 Home，进入导入的服务器编辑页，核对 Type 是否为 Hysteria2；如果订阅里没有该类型，向原配置提供方确认，而不是自行更改类型。
-
检查连接字段
逐项检查 Address、Port、认证信息及 SNI。Port 必须与远端监听端口一致；例如远端明确指定 443，才填写 443，不能把它当作统一默认值。
-
固定测试路径
在 Home 选中待测服务器，打开 Global Routing → Proxy，建立连接后测试同一个目标资源。若使用策略组，应同时确认实际选中的成员，避免测到其他服务器。
-
恢复日常配置
验证完成后，把 Global Routing 恢复为原先使用的 Config，并重新访问目标资源。若 Proxy 正常而 Config 异常，继续检查规则和策略组，不要先修改传输参数。
SNI 用于 TLS 握手中的服务器名称指示，应按原配置填写；连接地址是 IP 时，证书对应的域名仍可能需要单独指定。遇到证书错误，应检查服务器名称、证书有效性与设备时间，而不是通过放宽证书校验掩盖问题。配置包含混淆参数时，客户端与服务端也必须一致，单方面启用不会修复 UDP 不通。
四、Global Routing：区分传输问题与分流问题
Global Routing 决定请求如何选择出站路径，并不会把某个协议变得更快。排查时最常见的误判，是已经选中 Hysteria2 服务器，却没有确认目标请求实际使用它。以下只比较 Shadowrocket 自身的路由姿态，推荐项针对日常使用，不代表故障排查时也只能使用该项。
Config：按配置分流
推荐依据当前启用配置中的规则处理请求。目标可能进入 DIRECT，也可能进入代理或策略组；选中服务器不等于每个请求都会使用它。
适合：规则已经核对完成的日常连接。
Proxy：验证代理路径
将受该姿态控制的请求导向代理路径，便于暂时减少规则匹配带来的变量。仍要核对当前服务器或策略组的实际选择。
适合：判断服务器能否连接，以及排除规则误匹配。
Direct：建立直连基线
使用直连路径，不经过所选代理服务器。它可以用于观察本地网络本身是否异常，但直连结果不能证明 Hysteria2 的 UDP 握手正常。
适合：比较本地网络与代理路径的差异。
在 Config 中排查时，先确认启用的是哪份配置，再查看规则顺序。DOMAIN-SUFFIX 根据域名后缀匹配，IP-CIDR 根据 IP 网段匹配，GEOIP 依赖 IP 地理归属数据，FINAL 处理此前未命中的请求。不要只看到末尾的代理策略，就忽略前面已经命中的 DIRECT 规则。
- Proxy 正常、Config 异常：优先核对命中规则、策略名称及策略组成员。
- 两种姿态均无法建立连接：优先核对地址解析、UDP 可达性、认证与 TLS 参数。
- 连接经常自动重新建立：检查 Settings → On Demand 中已配置的按需连接条件，区分连接管理行为与传输故障。
五、UDP 受限时：端口、握手与 MTU 的边界
Hysteria2 的外层传输依赖 UDP。某个网络允许访问 TCP 443，不代表同样允许 UDP 443；网页能打开，也不能证明 QUIC 可用。端口号相同只说明数字相同，传输协议不同仍会受到不同的防火墙与流量策略处理。
出现连接超时时，先确认远端 UDP 监听与网络放行情况。把 Port 改成 443 只有在服务端确实监听 UDP 443 时才有意义；任意改端口通常只会增加一个配置错误。端口跳跃也需要服务端范围与客户端配置配合，不能用它解决所有 UDP 被整体阻断的环境。
- 立即返回认证错误：先核对认证字符串、订阅是否已更新，以及是否选中了正确条目。
- 明确返回证书错误：先检查 SNI、证书名称与设备时间，不把它归类为带宽不足。
- 持续等待后超时：核对 Address、Port、DNS 结果及 UDP 路径；超时本身不能证明是哪一处丢包。
- 握手成功但传输停顿：再考虑链路拥塞、路径 MTU、远端负载与目标站点响应。
QUIC 的初始数据报涉及至少 1200 字节的 UDP 载荷要求，路径若无法正确承载相关报文，握手或后续传输可能异常。但看到卡顿就修改 MTU 并不是通用解法：路径 MTU、隧道开销与界面中可调整的参数并不等价，也不要把 WireGuard 配置里的 MTU 数值直接套到 Hysteria2。先保留默认值与原配置，仅在有明确诊断依据时调整。
六、常见问题与最终选择
延迟数字更低，就一定更快吗？
不一定。先固定 Home 中的服务器与 Global Routing 姿态，再分别测网页首次响应和持续传输。延迟反映的只是某一种探测结果，不能代替吞吐、稳定性及实际业务表现。
为什么换到蜂窝网络就能用了？
保留相同服务器、端口和认证信息，对比 Wi-Fi 与蜂窝网络。若仅 Wi-Fi 失败，先检查该网络的 UDP 策略、DNS 与出口条件；不要为了适应单个网络反复改动正确的认证信息。
订阅能更新，为什么服务器仍连不上？
订阅获取与 Hysteria2 传输是两条不同的验证路径。更新成功只说明取到了配置。回到 Home 检查导入条目的 Type、Address 和 Port，再以 Global Routing → Proxy 单独验证连接。
所有网络都该改用 Hysteria2 吗？
不需要。在 UDP 受限或当前连接已经稳定的网络，保留可用配置更合理。若已有配置包含其他传输方式，可以在相同目标与时段下比较；不要仅因协议名称更新就替换已验证的路径。
最终选择以可重复的连接结果为依据：UDP 可达、参数正确且持续传输稳定，才适合把 Hysteria2 纳入日常配置。高延迟与随机丢包提供了验证它的理由，但不是性能保证；需要的结论是“当前网络是否更稳定、目标任务是否更顺畅”，而不是一个脱离测试条件的速度排名。