Hysteria2 的收益取决于 UDP 可达性、丢包成因与带宽设置，不是更换协议就必然提速。本文面向已经持有自己的服务商配置或订阅的用户，依次解释 QUIC 传输、拥塞控制、参数核对与 Shadowrocket 分流测试，帮助区分协议限制、配置错误和网络瓶颈。
一、Hysteria2 与 QUIC、UDP 的关系
Hysteria2 是代理协议，QUIC 是其底层传输基础，UDP 是承载 QUIC 数据包的传输层协议。这三个名称描述不同层次，不能把 Hysteria2 简化成“把所有请求改为 UDP”。应用原本发出的 TCP 连接，可以通过 Hysteria2 的 QUIC stream 转发；应用的 UDP 流量则使用相应的数据报转发机制。
QUIC 基于 TLS 1.3 建立加密连接，提供独立的 stream。某个 stream 的数据丢失时，不需要像在单一 TCP 字节流上复用多个请求那样，让其他 stream 都等待同一个缺失字节。不过，同一 stream 内仍然需要按序交付；多个 stream 也共享路径容量与拥塞控制，不能据此推断丢包对其他请求完全没有影响。
Hysteria2 的外层连接依赖 UDP。网页使用 HTTPS，并不意味着网络一定允许这条代理连接通过。网络可能放行 TCP 443，却限制 UDP 443；即使使用相同的端口数字，两者的可达性也要分别验证。
二、拥塞控制如何影响高丢包链路
拥塞控制决定发送端在什么时机、以多大速率发送数据。传统丢包型算法常把丢包视作拥塞信号并降低发送速率；但无线干扰、链路抖动等因素也会造成丢包。如果丢包并不代表路径容量耗尽，过于保守的降速可能使剩余容量得不到利用。
Hysteria2 可使用 Brutal 拥塞控制，根据配置的带宽目标和观测到的丢包情况调整发送节奏。它并非忽略丢包，而是尝试补偿丢失的数据量，让有效吞吐接近目标。QUIC stream 的可靠性仍由确认和重传等机制提供，不能把“拥塞控制补偿”理解为丢失数据无需恢复。
- 随机丢包但仍有容量：带宽目标合理时，Brutal 可能比强烈依赖丢包降速的算法维持更高吞吐。
- 真实拥塞：如果瓶颈链路已满，继续提高目标速率可能增加排队、丢包与交互延迟。
- 动态容量：蜂窝网络的可用容量随信号和负载变化，固定目标可能在某个时段合理，在另一个时段过高。
- 算法协商：Hysteria2 也存在使用 BBR 的工作路径；具体使用方式受客户端实现、带宽设置与服务端协商影响，不能只凭协议名判断当前算法。
还要区分 Mbps 与 MB/s：前者通常表示每秒兆比特，后者表示每秒兆字节。按十进制单位换算，80 Mbps 约等于 10 MB/s，且尚未扣除协议开销。填写前先核对字段要求，不能把文件下载器显示的 MB/s 数字直接当成 Mbps。
三、在 Shadowrocket 中核对已有配置
Shadowrocket（小火箭）中的 Hysteria2 配置应来自用户已有的连接信息。先在 Home 打开相应条目的编辑页，核对协议类型与服务端参数；若条目由订阅生成，手动修改前先记录原值，因为后续更新可能覆盖本地修改。不同界面展示可能有所调整，以下英文名称用于识别参数含义，不表示每个版本都有完全相同的字段排布。
连接与认证
- Type
- 选择 Hysteria2，不能只修改条目名称。
- Server
- 填写已有配置中的主机名或 IP。
- Port
- 与服务端监听的 UDP 端口一致，例如 443。
- Password
- 与服务端认证信息一致，不自行补空格或换行。
端口示例不是可用连接资料，实际值以用户已有配置为准。
加密与传输
- SNI
- 应与证书验证所需的域名相符。
- Certificate
- 保持证书验证，先排查域名、有效期与设备时间。
- Obfuscation
- 如配置要求使用 Salamander，模式与密钥须两端一致。
- Bandwidth
- 核对上下行方向和单位，按实际容量设置。
不要用跳过证书验证来掩盖 SNI 或证书配置错误。
Server 与 SNI 可以承担不同职责：前者决定连接到哪里，后者参与 TLS 握手中的服务器名称指示，并通常与证书名称核对有关。使用 IP 作为连接地址时，仍可能需要配置证书对应的域名。遇到证书错误，应先检查设备时间和域名是否正确，而不是反复更换端口。
- 在 Home 确认当前选中的确实是待测 Hysteria2 条目，避免编辑了一个条目却连接另一个条目。
- 暂时在 Global Routing 选择 Proxy，以减少规则绕行对测试的干扰；记录原设置，完成测试后恢复。
- 建立连接并访问同一个测试目标，分别记录能否打开、首个响应时间及持续传输表现。
- 若有订阅更新，更新后再次核对类型、端口和带宽字段，确认测试使用的是预期配置。
四、先确认路由，再判断协议是否生效
条目支持 Hysteria2，不等于每个请求都经过它。Global Routing 中的 Direct 不会使用代理出站；Config 按当前配置的规则处理请求；Proxy 用于代理路由测试；Scene 则需要结合当前场景设置核对。排查时应先固定路由姿态，否则“更换协议后速度没有变化”可能只是请求仍然直连。
下面是说明匹配顺序的最小规则片段，不是完整连接配置。其中 PROXY 是策略目标，不是名为 Hysteria2 的规则关键字；它最终使用哪个出站，应结合当前选择与配置确认。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,PROXY匹配 example.com 及其子域名。这里使用保留示例域名，仅用于解释语法。IP-CIDR行让指定私有地址段直接连接；no-resolve避免为了这一行的匹配主动解析域名。GEOIP,CN,DIRECT根据 IP 地理数据库匹配，结果取决于目标地址及数据库内容，不等同于域名所属地。FINAL,PROXY是前面的规则均未命中时的兜底。规则自上而下匹配，更具体的例外应放在兜底之前。
Settings → On Demand 控制自动连接的触发条件，不负责为域名选择 Hysteria2，也不会修改上述规则的先后顺序。为了观察一次可重复的连接过程，可以先记录 On Demand 设置，再手动完成测试，避免网络切换触发的自动重连与参数问题混在一起。
五、哪些网络适合测试，哪些条件会限制收益
适合测试 Hysteria2 的前提是目标 UDP 端口可达，并且用户已有匹配的服务端配置。高时延、存在非拥塞性丢包但仍有剩余带宽的链路，是值得观察其吞吐表现的场景。若瓶颈在本地 Wi-Fi、服务端出口或目标网站限速，协议本身不能消除这些上限。
- 固定比较条件：使用同一设备、同一网络、同一目标文件，在接近的时间段测试；不要同时更新订阅或切换多项参数。
- 区分建立连接与持续传输：记录握手能否完成，再记录持续下载。连通性测试只说明某种探测成功，不能代替完整吞吐测量。
- 观察负载下延迟：下载时同步检查网页响应。如果吞吐略高却交互明显卡顿，应考虑目标带宽过高或队列拥塞。
- 更换接入网络复核：同一配置在 Wi-Fi 失败、蜂窝成功，提示差异可能位于接入网络的 UDP 策略、NAT 或路径质量，不足以证明配置一定正确。
- 每次只改一项：先处理可达性，再处理认证与证书，最后调整带宽。每次变更后恢复相同测试条件。
六、常见问题与对应检查顺序
为什么其他连接能用，Hysteria2 一直超时？
先在 Home 核对 Server 与 Port，再确认服务端对应 UDP 端口可达。仅有 TCP 连接成功不能证明 UDP 放行。保持配置不变，换一个接入网络复测；若表现随网络变化，优先检查网络策略，再查认证和服务端监听状态。
带宽填得越大是不是越快？
不是。先确认字段单位和上下行方向，以用户自己的稳定测量值为依据逐步调整。若提高目标后延迟显著增加、有效吞吐没有提高，应退回上一个设置，而不是继续增大数值。
已经连接，为什么访问结果仍像直连？
在 Home 核对选中条目，再检查 Global Routing。暂时用 Proxy 建立测试基线；如果切回 Config 后行为改变，就到 Config 检查目标是否先命中 DIRECT，以及 FINAL 是否落到预期策略。
网络切换后断开，要重新填写全部参数吗？
不需要先改参数。先确认新网络有可用连接，再重新建立隧道，并检查 Settings → On Demand 的触发条件。QUIC 具备连接迁移相关能力，但是否能连续保持还取决于实现、NAT 和路径策略，不能把协议能力当作切网不断开的保证。
结论是先验证 UDP 可达，再核对认证、证书与路由，最后才讨论拥塞控制和带宽目标。只有在相同测试条件下记录吞吐、延迟与失败现象，才能判断 Hysteria2 是否适合当前路径。Shadowrocket 是闭源商业应用，客户端买断 ≠ 线路套餐；本站不提供、不销售、不推荐节点或订阅。