本文面向已经持有自己的服务商配置或订阅、需要在 Shadowrocket 中核对 Hysteria2 参数的用户。先区分 QUIC 与 UDP 的职责，再逐项检查服务器、端口、认证、TLS 与 SNI，最后用固定网络和同一请求判断故障发生在传输、认证还是分流环节。本文不提供、不销售、不推荐节点或订阅。
Hysteria2、QUIC 与 UDP 的关系
Shadowrocket（小火箭）中的 Hysteria2 是代理协议类型，不是 Global Routing 的一种姿态，也不是启用后就会作用于全部连接的加速开关。只有实际选中了相应条目，并且请求被路由到该条目或包含它的策略时，请求才会通过这一连接发送。
Hysteria2 以 QUIC 为传输基础，而 QUIC 的底层承载是 UDP。UDP 本身不负责重传和按序交付；QUIC 在其上提供加密、流管理及可靠传输等机制。因此，“基于 UDP”不等于网页数据可以随意丢失，也不表示应用原来的 TCP 请求会失去可靠性。
这里需要区分内层与外层：应用访问网页时可能使用 TCP，Shadowrocket 将这类请求交给 Hysteria2 后，设备到代理服务器之间使用的是基于 UDP 的 QUIC 连接。目标网站不必支持 QUIC；代理服务器如何连接目标，与设备到代理服务器的外层传输是两个环节。
- UDP：提供数据报承载。当前网络必须允许设备与服务器对应 UDP 端口通信。
- QUIC：负责连接、加密及流传输。不同流之间可减少传统单条 TCP 连接丢包造成的跨流阻塞，但同一可靠流仍受丢包恢复影响。
- Hysteria2：在上述传输基础上定义认证、代理请求及数据转发方式，需要客户端与服务器参数相互匹配。
高丢包网络下的表现与适用边界
Hysteria2 的设计包含面向高时延、有损链路的拥塞控制思路；其中 Brutal 机制与配置的带宽值有关。能否得到较稳定的吞吐量，仍取决于链路容量、丢包原因、服务器负载以及实际采用的拥塞控制模式。不能仅凭协议名称推导出固定速度，也不能认为丢包越多收益越大。
尤其要区分随机丢包与拥塞丢包。如果无线信号波动导致少量随机丢包，适当的传输机制可能改善利用率；如果出口已经拥塞，继续提高发送量可能增加排队、延迟与丢包。把带宽参数写成远大于可用上行的数值，不会创造额外容量。
判断：先核对 UDP 可达性，再调整带宽
若同一配置在蜂窝网络可用、在某个 Wi-Fi 下持续握手超时，先核查该 Wi-Fi 到服务器 UDP 端口的路径；不要通过提高带宽或关闭证书验证来处理传输不通。
- 可以评估的场景：UDP 可达、服务器参数明确，且现有链路存在较高时延或随机丢包。
- 需要谨慎的场景：网络对 UDP 有严格限制、出口长期满载，或者套餐流量与设备耗电需要控制。
- 不能直接解决的环节：错误的认证信息、过期证书、错误规则和目标网站自身故障。
在 Shadowrocket 中核对 Hysteria2 字段
已有订阅通常已经包含服务器参数，优先检查导入结果，不要把不同条目的字段拼接使用。手动添加时，从 Home 点击添加按钮，在 Type 中选择 Hysteria2，再按持有的配置填写。具体字段的排列与可见选项可能随应用界面调整，未显示的高级参数不要用其他选项代替。
| 字段或参数 | 填写依据 | 常见误差 |
|---|---|---|
| Type | 选择 Hysteria2，与服务器协议一致。 | 把 Hysteria 与 Hysteria2 当作可互换类型。 |
| 服务器地址 | 填写已有配置的主机名或 IP 地址。 | 把完整订阅 URL 填进地址栏，包含路径或查询参数。 |
| 端口 | 填写服务器实际监听的 UDP 端口，例如配置明确给出的 443。 | 认为所有服务器都使用 443，或只确认 TCP 443 可达。 |
| 认证信息 | 逐字保留已有配置提供的认证值。 | 复制时多带空格，或把订阅 token 当作连接密码。 |
| TLS / SNI | 保持证书验证；SNI 使用配置要求的服务器名称。 | 连接地址为 IP 时，误把该 IP 直接作为证书名称。 |
| obfs | 仅在服务器启用并给出对应参数时配置。 | 将混淆密码与认证信息混用，或仅在客户端启用。 |
| 带宽参数 | 若界面提供，按实际上下行能力和原配置填写，并确认单位。 | 混淆 Mbps 与 MB/s，或用理论峰值代替可持续容量。 |
SNI 用于 TLS 握手中的服务器名称指示；证书验证还需要检查服务器身份是否与预期名称匹配。服务器地址决定连接发往哪里，SNI 与证书名称决定验证谁，两者可以不同，但必须有明确的配置依据。遇到证书错误时应核对名称、设备时间与服务器证书，而不是把跳过验证作为常规配置。
Hysteria2 与早期 Hysteria 的协议和参数并非直接兼容。订阅更新后若类型识别异常，应检查原始条目是否明确声明 Hysteria2，以及应用是否能够识别该订阅格式；仅修改条目名称不会改变实际协议。
已有订阅导入、更新与首次验证步骤
订阅 URL 是获取配置的入口，不是代理服务器地址。它可能包含可用于读取配置的凭据，应按敏感信息处理。下面的地址仅用于辨认结构，不能用于实际连接：https://example.com/sub?token=xxxx。不要将真实订阅链接放入公开截图或排查记录。
- 导入已有订阅：在 Home 点击添加按钮，通过 Type 选择 Subscribe，将自己的订阅 URL 填入 URL 并保存。返回 Home 后确认对应分组已出现，且有可识别的 Hysteria2 条目。
- 核对更新结果：需要刷新时，对该订阅执行 Update，等待完成后检查条目类型、服务器和端口。若出现获取失败，先区分订阅地址不可达与代理服务器不可达，不要把两类错误混在一起。
- 选择测试条目：在 Home 选择需要验证的 Hysteria2 条目，记录其名称与端口。若由策略组选择出口，还要确认策略组实际选中了该条目。
- 控制路由变量：在 Global Routing 中临时使用 Proxy 验证所选出口；测试后恢复原来的路由姿态。Direct 不会验证代理链路，Config 则需要结合当前配置的规则判断。
- 建立连接并发起请求：打开连接开关；首次使用时按系统提示授权 VPN 配置。随后访问一个已知可正常访问的页面，观察是否出现握手、认证、证书或解析方面的错误。
- 恢复日常配置：回到 Global Routing → Config 后，检查同一请求命中的规则与策略，确认不是在 Proxy 下可用、恢复规则后却被分流到其他出口。
握手超时、证书错误与分流问题怎么区分
排查时按连接阶段分组，比反复改动全部字段更容易定位。先记录当前网络、选中条目、Global Routing 姿态与错误文本，再一次只修改一项。某次延迟测试有结果，只说明该测试覆盖的环节返回了响应，不能替代真实网页请求，也不能证明所有 UDP 转发场景正常。
同一条目在 Wi-Fi 超时，换蜂窝网络就能用？
保持服务器、端口与认证值不变，只切换网络复测。若差异稳定出现，优先核查 Wi-Fi 的 UDP 出口限制、路由与防火墙。TCP 443 能访问并不能证明 UDP 443 可用；Hysteria2 也不会因为 UDP 被阻断就自动变成 TCP 连接。
提示证书名称不匹配，应该改哪里？
回到 Home 编辑该条目，对照已有配置检查服务器地址与 SNI，并确认设备日期、时间正确。若地址是 IP、证书签发给域名，应使用配置指定的名称进行验证；仍报错时，需要服务器端核查证书，而不是关闭验证。
Proxy 下可以打开，Config 下却不行？
到 Config 确认当前使用的配置，再检查规则顺序与目标策略。规则通常自上而下匹配；DOMAIN-SUFFIX、IP-CIDR、GEOIP 与 FINAL 可能让同一请求走向不同策略。先看实际匹配结果，不要据此认定 Hysteria2 握手失败。
连接刚开始正常，持续传输后延迟明显升高？
先停止其他占用上行的任务，检查已有配置中的带宽参数与单位，再用相同请求复测。如果界面提供可调参数，逐步降低后观察排队延迟；不要同时改端口、SNI 和认证值，否则无法判断是哪一项产生影响。
如果只有个别网站失败，应进一步区分 DNS 解析、规则命中与目标服务限制。连接开关处于开启状态，只能说明系统 VPN 处于相应状态，不代表每个域名都经由同一个出口。需要自动连接时，Settings → On Demand 属于触发连接的设置，不会修复错误的 Hysteria2 认证或端口。
用固定条件评估是否适合当前网络
评估应围绕自己的日常网络，而不是以一次最高速度作为结论。保持设备、服务器、目标资源及 Global Routing 姿态一致，在相近时段重复测试，并把 Wi-Fi 与蜂窝网络分开记录。没有同条件数据时，不应给出“提高多少百分比”的判断。
- 记录连接成功率：例如连续尝试 5 次，每次断开后重新连接，记录成功次数与失败阶段；这是测试方法，不是协议表现数据。
- 记录交互延迟：观察页面首次响应及持续传输时的交互情况。平均吞吐量高，不代表网页首次打开一定更快。
- 记录网络切换影响：从 Wi-Fi 切至蜂窝网络后重新发起请求。实际会话能否延续受网络和实现影响，不应仅凭 QUIC 名称作保证。
- 记录资源成本：留意流量消耗与设备耗电。重传及额外流量可能使统计值高于应用内容大小，应结合实际使用判断。
保留能稳定复现的配置，再恢复日常 Config 分流；遇到只在某一网络失败的情况，应优先调查该路径。Hysteria2 的选择依据是 UDP 可达性、参数正确性与重复测试结果，而不是把协议类型当作所有连接问题的统一解决办法。