Hysteria2 使用基于 UDP 的 QUIC 传输，适合在 UDP 可用的前提下，对高延迟或存在随机丢包的线路进行对照测试。它不保证比其他协议更快，也不能绕过所有 UDP 限制。本文面向已经有服务商与订阅的 Shadowrocket 用户，说明传输原理、带宽设置、导入核对方法，以及如何区分规则问题、认证失败和网络限制。
Hysteria2、QUIC 与 UDP 的关系
Hysteria2 是代理协议，QUIC 是它使用的传输基础，UDP 则负责承载 QUIC 数据包。三者处在不同层次：应用请求经过代理封装，再通过 QUIC 连接发送到服务端。不能因为底层使用 UDP，就把 Hysteria2 理解成不处理丢包、只管发送的数据通道。
UDP 本身不保证到达顺序和可靠交付，QUIC 则在其上实现连接管理、可靠流、丢包恢复与拥塞控制。网页这类原本使用 TCP 的业务，也可以由代理转发到 QUIC stream 中；业务是否使用 UDP，与客户端到服务端这段连接是否使用 UDP，是两个不同问题。
QUIC 与 HTTP/3 关系密切，但不能把二者画等号。使用 QUIC 不代表所有代理流量都变成普通网页请求，也不代表网络管理设备一定放行。即使浏览器能通过 TCP 443 打开某个网站，也不能据此证明同一地址的 UDP 443 可以建立 Hysteria2 连接。
为什么可能更快：恢复机制与拥塞控制
所谓“快”，需要分成握手耗时、首个响应、持续吞吐量和交互稳定性。QUIC 集成安全握手，并支持多个独立的 stream。某个 stream 中等待丢失数据时，其他 stream 不必因同一个传输层有序字节流而全部等待；不过，各 stream 仍然共享连接的拥塞控制与实际链路容量，不能完全互不影响。
Hysteria2 的吞吐表现也与拥塞控制有关。其协议体系支持以带宽目标驱动的 Brutal 思路，并可使用 BBR 类拥塞控制；实际采用哪种行为，取决于客户端实现、带宽参数及服务端限制。不能只凭协议名称推断当前连接的算法，更不应把某个实现的可选参数直接当作 Shadowrocket 中必然存在的开关。
- 随机丢包：如果链路仍有可用容量，较积极的发送与恢复策略可能维持更高吞吐；这不等于数据无需重传。
- 真正拥塞：当瓶颈已被占满，继续增加发送可能造成排队、更多丢包和更高延迟，影响通话与网页交互。
- 高往返延迟：握手与丢包恢复等待更明显，协议机制可能改善体验，但无法消除物理距离和绕路造成的时延。
- 服务端限速：服务端的带宽、负载与出口限制仍是上限；提高客户端填写值不会增加服务端实际容量。
哪些场景值得测试，哪些场景先检查网络
高延迟、随机丢包、UDP 可达，是值得测试 Hysteria2 的条件，而不是速度保证。家庭宽带、公共 Wi-Fi 与蜂窝网络对 UDP 的处理可能不同；同一条服务端线路在不同接入网络下，也可能表现为稳定传输、只能短暂连接，或持续超时。
| 网络现象 | 优先判断 | 核对动作 |
|---|---|---|
| 高延迟且偶有丢包 | 可能适合对照测试，但需确认 UDP 可用 | 固定服务端和测试内容，分别记录首个响应、吞吐与中断次数 |
| 网页能直连，Hysteria2 一直超时 | TCP 可达不代表 UDP 可达 | 核对实际 UDP 端口，并切换 Wi-Fi 与蜂窝网络复测 |
| 下载开始很快，随后明显卡顿 | 可能存在队列积压、限速或服务端负载 | 停止其他下载，检查带宽填写值，再用同一文件重测 |
| 低延迟、低丢包且当前连接稳定 | 未必有更换协议的收益 | 优先比较稳定性，不只比较一次峰值速度 |
| 切换网络后连接中断 | 地址变化、NAT 状态或网络策略可能影响连接 | 重建连接并检查日志，不把 QUIC 的连接迁移能力当作无中断保证 |
结论：先确认 UDP 可达，再比较吞吐
同一配置在蜂窝网络可用、在当前 Wi-Fi 持续超时时，先记录网络差异并核对 UDP 放行情况；此时反复提高带宽值，不能解决连接建立失败。
在 Shadowrocket 中导入并核对 Hysteria2
订阅和连接参数应从你的服务商处获取。优先导入服务商提供的现有配置，减少手动转写错误。订阅更新只是重新获取配置，不等于服务端一定可达；更新后还应确认当前选中的条目、协议和认证信息没有变化。
-
导入订阅
在 Home 右上角选择“+”，进入 Add Server，将 Type 设为 Subscribe，填入自己的订阅地址并保存。回到 Home，对该订阅执行更新，再查看生成的条目。
-
核对协议
在 Home 打开目标条目的编辑页，确认 Type 对应 Hysteria2，并逐项核对服务端地址、端口与认证信息。不要把旧协议的密码或端口沿用到新条目。
-
核对安全项
按服务商提供的内容检查 TLS、SNI 和可选的混淆参数。连接地址与证书使用的域名可能不同，SNI 应与服务端要求一致；遇到证书错误时先核对域名、系统时间与证书链。
-
固定测试路径
在 Home → Global Routing 中临时选择 Proxy，并选定要测试的 Hysteria2 条目。这样可减少 Config 规则使测试请求走 DIRECT 的干扰；测试结束后恢复原先的使用姿态。
-
记录连接结果
打开连接后访问固定测试目标，分别记录能否建立连接、首个响应是否明显等待、传输是否中断。若连接会自动重建，同时检查 Settings → On Demand，避免把按需触发误判为手动操作失效。
端口必须与服务端配置一致。例如服务端明确使用 UDP 443，就核对条目中的端口为 443，同时确认服务端已允许该 UDP 端口。若提供了混淆密码，它与连接认证密码可能承担不同用途，不能任意互换。不要为排除故障而长期关闭证书校验；应先修正不匹配的参数。
区分 Global Routing 姿态与协议性能
协议决定客户端到服务端怎样传输，Global Routing 决定请求是否送往代理路径。Home → Global Routing 中的 Proxy、Direct、Config、Scene 不能理解成四种协议。Scene 的结果取决于已有场景配置；排查时先确认它实际采用的设置，避免测试过程中路径随条件变化。
Config
推荐按当前配置中的规则处理请求。目标命中 DIRECT 时，不会因为选中了 Hysteria2 条目就自动改走该连接；适合作为核对规则后的日常姿态。
适合：规则已核对、需要按目标分流的日常使用
Proxy
将请求交给当前代理路径，适合临时减少 Config 规则对测试的影响。仍需核对所选条目以及其他可能影响流量路径的设置。
适合：固定代理条目、检查协议连通性的短时测试
Direct
使用直连路径，不能据此测出 Hysteria2 服务端的吞吐表现。它可以帮助建立本地接入网络的对照，但目标本身的可达性也会影响结果。
适合：核对本地网络与直连目标是否正常
在 Config 中，DOMAIN-SUFFIX 按域名后缀匹配，IP-CIDR 按地址网段匹配，GEOIP 根据地址归属数据库匹配，FINAL 处理前面未命中的请求。规则顺序和对应策略共同决定路径。若测试目标命中 DIRECT，就应先修正规则判断，而不是把直连速度归因于 Hysteria2。
常见问题：超时、证书与带宽填写
同一个条目，为什么换个 Wi-Fi 就超时？
先保持条目参数不变，分别在 Wi-Fi 与蜂窝网络重建连接。若只有一个网络失败，记录发生时间、服务端端口和错误信息，再核对该网络是否限制 UDP。不要仅用网页能否打开作为 UDP 可达的证据。
提示证书错误，能直接忽略吗？
先检查设备时间，再比对服务商提供的 SNI 与证书域名；若连接地址为 IP，也不能假设证书就应匹配该 IP。仍不一致时向服务商确认配置，不以长期跳过验证代替修复。
带宽填得越大，下载就越快吗？
不是。先确认输入单位，以及上行、下行是否按客户端方向填写。使用服务商给定值或与实际链路相符的保守值进行测试，每次只调整一项，同时观察网页响应和持续下载，避免只看瞬间峰值。
延迟测试有数值，为什么网页仍打不开？
测试结果不一定覆盖目标网站的完整请求。回到 Home 确认所选条目，再核对 Global Routing；需要排除规则影响时临时使用 Proxy。随后区分 DNS 解析错误、TLS 错误与连接超时，按错误类别检查参数。
建立可重复的对照测试
协议比较应尽量只改变一个变量。不同服务端、不同出口或不同时间段得出的速度差异，不能直接归因于 QUIC。即使服务商提供多个协议入口，也应先确认它们是否使用相同线路与相同带宽限制。没有这些前提，测试只能说明两个连接的整体差异。
- 固定环境：使用同一设备、同一接入网络、同一测试目标，暂停后台更新和其他大流量任务。
- 重复采样：每组至少测试三次，记录日期时段、首个响应、持续速度与失败次数；这些是建议记录项，不是本文声称的实测结果。
- 观察负载延迟：持续下载时再打开普通网页；若吞吐提高但交互明显变慢，应检查带宽目标和链路排队。
- 保留错误类别：分别记录超时、认证失败、证书错误和传输中断，不把所有失败统一写成“速度慢”。
- 保护凭据：分享记录前删除订阅地址中的 token、认证密码和混淆密码，只保留排查所需的网络与错误信息。
最终选择以当前网络中可重复的结果为准：UDP 可达、参数正确、持续传输稳定，才有讨论吞吐优势的基础。Hysteria2 可以作为已有服务配置中的一种传输选择；高丢包或高延迟只是测试理由，不是必然更快的结论。