Hysteria2 协议是什么:基于 QUIC 为什么快,Shadowrocket 里适合哪些网络

Hysteria2 与 QUIC、UDP 的关系

Shadowrocket（小火箭）中的 Hysteria2 是一种代理协议类型。客户端与服务端通过基于 UDP 的 QUIC 连接交换数据，再由服务端连接目标地址。这里的 UDP 描述的是客户端到服务端之间的外层传输，并不意味着浏览器访问的所有网站都改用了 UDP，也不意味着应用原本的 TCP 数据可以不经可靠传输就直接丢弃。

QUIC 将可靠传输、流管理与 TLS 握手结合起来。对于需要可靠交付的数据，丢失的数据仍需要恢复；UDP 本身不负责重传，相关机制由 QUIC 实现。Hysteria2 可以承载 TCP 连接与 UDP 数据，但承载方式不同，不能把“外层使用 UDP”解释成“所有业务数据都保证到达”。

QUIC 的多路复用能够避免一个流的数据丢失直接阻塞其他流的有序交付，但各流仍共享连接的拥塞与带宽条件。链路严重拥塞时，所有业务仍可能受到影响。QUIC 也不等同于 HTTP/3；HTTP/3 是建立在 QUIC 之上的应用协议，不能仅凭二者都使用 QUIC 就把它们当成同一种用途。

为什么可能更快：拥塞控制与带宽估计

长距离链路的往返时间较大，发送端需要保持足够多的在途数据，才能利用现有带宽。丢包会触发可靠传输的恢复流程；某些拥塞控制算法还会据此降低发送速率。若丢包主要来自无线干扰而非链路拥塞，过度退让可能导致吞吐下降。Hysteria2 的设计重点之一，就是在这些条件下调整发送行为。

Hysteria2 体系中的 Brutal 拥塞控制以带宽目标为重要输入，根据反馈调整发送，尝试补偿丢包带来的影响。实际使用哪种控制方式，还与双方实现、协商结果及带宽配置有关。不能仅看到 Type 为 Hysteria2，就推断某种控制方式必然启用，更不能把 QUIC 本身当作固定速度提升的保证。

• 目标带宽偏低：即使链路仍有余量，发送速率也可能受配置约束，持续下载表现为较早到达平台。
• 目标带宽偏高：发送量超过真实承载能力时，可能形成排队、增加延迟与丢包，反而使网页响应或实时业务变差。
• 上下行不对称：家庭网络的上传能力可能明显低于下载能力，不能把下载测速数值直接复制为上传目标。
• 单位不同：Mbps 表示兆比特每秒，MB/s 表示兆字节每秒；例如 80 Mbps 在不计开销时约为 10 MB/s，这只是单位换算，不是速度承诺。

这里的“快”需要拆开看：首次打开网页的等待时间、持续下载吞吐、实时业务的抖动并不是同一个指标。提升持续吞吐不一定缩短 DNS 查询，也不一定改善目标网站服务器的响应时间。跨地区路由绕行、服务端负载与目标站限速，同样可能成为瓶颈。

适合哪些网络：先确认 UDP，再比较业务表现

高延迟、存在随机丢包，同时又允许稳定 UDP 通信的链路，是值得测试 Hysteria2 的场景。蜂窝网络信号波动或繁忙 Wi-Fi 可能造成丢包，但“蜂窝网络”本身不是推荐某协议的充分依据：不同地点、时段及接入网络对 UDP 的处理可能不同，应在实际使用地点重复测试。

测试时可以为每轮设定相同的观察窗口，例如持续传输 60 秒并重复 3 次，同时记录网络类型和是否出现中断。这是测试方法建议，不是本文的实测结果。不要同时切换服务器、修改 DNS、改变规则再比较速度，否则无法判断变化究竟来自哪一项。

Shadowrocket 添加步骤与字段核对

以下操作以用户已经持有自己的服务商与订阅信息为前提。订阅导入可以减少手动填写错误，但仍需检查导入后的协议类型与字段是否完整。应用中的字段呈现可能随当前界面而不同，服务端提供的连接参数应逐项对应，不要用其他协议的配置内容替代。

1. 核对类型

   进入 Home → 右上角“+” → Type，手动配置时选择 Hysteria2。使用已有订阅时，Type 选择 Subscribe，填写自己的订阅地址并保存，再回到 Home 更新该订阅；随后打开导入的条目确认其类型。

2. 填写地址

   按已有信息填写 Address 与 Port。Address 是服务端主机名或 IP，不是订阅地址；Port 使用服务端实际监听的 UDP 端口。例如服务端使用 443，就填 443，不能因网页常用该端口而自行改成这个值。

3. 核对认证

   填写 Password，并核对大小写、前后空格及复制是否完整。Hysteria2 的认证信息应来自对应服务端，不能把订阅链接中的 token 当作连接密码，也不能沿用其他协议的认证字段。

4. 检查 TLS

   展开当前条目的 TLS 相关设置，按已有信息核对 SNI 与证书验证所用名称。若 Address 使用 IP，而证书签发给域名，更要检查名称配置；遇到验证错误应核对证书、名称与有效期。

5. 保存并测试

   保存条目，回到 Home 选择它，再检查 Global Routing 的当前姿态并连接。先打开一个明确的测试目标，观察是否能完成加载，再做持续传输测试；修改前记录原值，避免多个参数同时变化。

若服务端启用了 Salamander 等可选混淆，客户端对应配置必须与服务端一致；混淆密码与连接认证密码是不同用途的参数。服务端没有启用时，不应自行添加。混淆也不能使被完全阻断的 UDP 自动恢复可达。

• Address：决定先连接哪台服务器；若使用域名，还依赖本地能够完成该域名的解析。
• SNI：用于 TLS 握手中的服务器名称指示，应与已有服务配置相符；它不是替换服务器地址的通用办法。
• 证书验证：检查对端身份是否符合预期。名称不匹配时应修正参数或证书，而不是把跳过验证当作常规步骤。
• 可选设置：带宽、混淆和端口范围等内容只在已有服务明确提供、且当前界面支持时填写，不猜测默认值或批量尝试端口。

连接后如何区分协议问题与分流问题

条目保存成功不等于连接认证成功；连接成功也不等于某个网页已经使用该连接。Shadowrocket 的 Global Routing 决定流量如何选择路径。排查时先看当前是 Config、Proxy、Direct 还是 Scene，再确定测试请求实际命中了哪条规则或哪种场景设置。

使用 Scene 时，应查看当前生效场景的配置，不把场景名称当作固定的代理行为。使用 Config 时，规则从上往下匹配，具体条件放在前面，FINAL 放在规则段末尾。以下仅演示语法关系，不是需要直接覆盖的完整配置，也不表示这些目标在当前网络中的可达性。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

其中 DOMAIN-SUFFIX 按域名后缀匹配，IP-CIDR 按地址范围匹配，GEOIP 按 IP 地理数据库匹配。若目标域名在更靠前的规则中命中 DIRECT，切换 Hysteria2 条目不会改变该请求的直连路径。应先确认请求所用策略，再讨论协议速度。

按现象排查：超时、认证、停顿与更新后失效

延迟测试显示数值，只代表该测试动作在当时得到响应，不能替代完整业务验证。尤其是 TCP 端口探测，无法确认 Hysteria2 所需的 UDP 握手。遇到问题时按失败阶段检查，通常比反复修改带宽参数更有效。

1. 始终连接超时：先核对 Address 和 Port，再确认服务端 UDP 监听及防火墙规则。如果使用域名，检查服务器域名能否解析；随后在自己可用的另一种接入网络上做对照。
2. 出现 TLS 错误：核对设备时间、SNI、证书名称与有效期。Address 使用 IP 时，尤其注意证书是否覆盖验证所用的名称。
3. 出现认证失败：核对 Password 是否属于这一个 Hysteria2 条目，检查复制空格、凭据是否已变更，以及可选混淆配置是否与服务端一致。
4. 已连接但网页打不开：检查 Global Routing、规则命中和 DNS。若仅部分域名失败，优先定位解析或目标可达性，不先认定整个协议不可用。
5. 传输一段时间后停顿：检查 UDP 限速、无线信号、服务端负载与路径 MTU 等因素。若设置了带宽目标，先记录原值，再降低目标进行单变量测试。
6. 订阅更新后变化：重新核对导入条目的类型、端口、认证及 TLS 信息，注意手动编辑的值可能被更新内容替换。以当前已保存的条目为准，不只看条目名称。

On Demand 控制的是按条件建立连接的行为，不是 Hysteria2 的拥塞控制开关。排查自动连接时可进入 Settings → On Demand 核对相关条件；排查传输速度时，应先保持连接状态与接入网络稳定，避免把自动重连造成的等待误认为吞吐下降。

最终判断应落在实际业务上：UDP 可达、参数一致、规则命中正确之后，再比较重复测试结果。若当前网络持续阻断或严重限制 UDP，调整带宽数值无法解决根本问题；若连接稳定且业务体验符合需求，也无需仅为追求单次测速峰值不断修改配置。