2026-10-17 · 协议科普 · 约 10 分钟

Hysteria2 协议是什么：基于 QUIC 的传输为何快、哪些网络场景适合

科普 Hysteria2 基于 QUIC/UDP 的传输思路与拥塞控制特点，说明它在高丢包、高延迟链路上的表现，以及在 Shadowrocket 中填写节点时要注意的字段。

本文速览

本文适合已经拥有自己的服务商与订阅、准备在 Shadowrocket 中使用 Hysteria2 的用户。先说明 QUIC、UDP 与拥塞控制的关系，再核对地址、端口、认证、TLS 和带宽字段，最后按连接现象定位问题。判断是否适合自己的网络，要看 UDP 可达性、丢包性质与持续传输表现，而不是只看一次延迟读数。

Hysteria2、QUIC 与 UDP 的关系

Hysteria2 是基于 QUIC 的代理协议。Shadowrocket（小火箭）作为客户端连接用户自己的 Hysteria2 服务端，再由服务端转发目标流量。应用购买与连接服务是两件事：购买客户端不会自动获得服务端地址、认证信息或订阅。

UDP 是底层传输，QUIC 在其上实现加密、连接管理、可靠流与拥塞控制。不能把“基于 UDP”理解成“数据丢失也不处理”：承载 TCP 代理流量时，QUIC 的可靠流仍需要确认与重传；代理 UDP 流量时，则使用适合数据报语义的传递方式。

UDP
客户端到 Hysteria2 服务端的底层传输
TLS 1.3
QUIC 使用的加密握手基础
443/UDP
可采用的服务端监听示例，并非固定端口

这里的 443/UDP 只是端口示例。服务端也可以监听其他 UDP 端口，客户端必须填写实际值。某个网络允许 443/TCP，不代表同样允许 443/UDP；浏览器能打开普通网页，也不能证明 Hysteria2 的传输路径可用。

传输为何可能更快：多路复用与拥塞控制

QUIC 可以在同一连接中承载多条流。某一条流发生丢包时，不必像把多条业务流装进单一 TCP 字节流那样，等待同一个外层有序字节流补齐后才交付其他流的数据。不过，各流仍共享链路容量与拥塞控制，单条可靠流自身也仍有按序交付的约束。

Hysteria2 的另一个重点是带宽驱动的 Brutal 拥塞控制。它按设定的目标速率发送，并对丢包进行补偿；在存在随机丢包、但链路仍有可用容量时，这种方式可能比遇到丢包就明显收缩速率的策略更容易保持吞吐。具体使用 Brutal 还是 BBR 等路径，取决于带宽设置、协商结果以及客户端与服务端实现，不能仅凭协议名称判断。

机制可能改善的现象仍然存在的限制
QUIC 多路复用不同流之间因外层有序传输造成的等待所有流仍竞争同一条链路的容量
可靠流重传丢包后恢复 TCP 代理业务的数据完整性补发数据消耗时间与额外带宽
Brutal随机丢包下的持续传输速率下降目标带宽设置过大可能放大排队与丢包
BBR 路径根据链路估计调整发送行为效果受路径、实现及服务端限制影响

判断：先测可用容量，再填带宽

先记录同一路径的持续下载、上传与响应延迟，再按实际容量设置带宽；若提高数值后吞吐不变、网页响应却变慢，应降低设置并复测，而不是继续加大数值。

“快”不是协议的固定属性。高延迟会增加握手、请求往返与丢包恢复的等待，QUIC 不能消除物理距离；服务端出口、目标网站限速和本地无线干扰也不会因为切换协议自动消失。本文不以未经测试的百分比承诺速度提升。

哪些网络场景适合，哪些应先排除

适合优先验证的情形，是 UDP 可达、链路延迟较高、存在一定随机丢包，同时又有可用带宽的网络。若丢包来自队列持续塞满，继续增加发送速率可能适得其反。应把“随机丢包”和“拥塞丢包”分开观察，不能只根据一个丢包百分比作决定。

Shadowrocket 添加 Hysteria2：字段核对顺序

优先使用用户已有订阅中的完整配置，避免手动遗漏 TLS 或认证参数。Hysteria2 与 Hysteria 的旧协议不能仅靠修改名称互换；导入后应打开条目，确认 Type 对应 Hysteria2。不同界面语言和应用版本的字段排列可能不同，以下按字段含义核对，不凭相似名称猜值。

  1. 确认来源

    准备自己已有服务的地址、UDP 端口、认证、TLS 与可选混淆参数。订阅导入路径为 Home → 右上角“+”→ Type → Subscribe，再填入自己的订阅 URL 并保存。

  2. 选协议

    手动添加时进入 Home → 右上角“+”→ Type → Hysteria2。订阅导入则打开对应条目核对 Type，不要将其改成其他协议后继续沿用原参数。

  3. 填连接信息

    按服务端资料填写地址与端口，再填写认证信息。地址栏只放主机名或 IP，不把网页路径、协议前缀或端口一起拼入；端口另填，例如服务端明确给出 443 时填写 443。

  4. 核对加密项

    检查 TLS 的服务器名称 SNI 与证书要求；服务端启用了混淆时，再逐项匹配混淆类型与密码。认证密码与混淆密码用途不同，不能互相替代。

  5. 保存并验证

    保存后回到 Home，选择该条目并连接。记录当前 Global Routing 设置，使用已知可访问的目标验证；测试结束后恢复日常配置，不同时修改 DNS、规则和带宽。

字段含义填写依据常见错误
服务器地址服务端给出的主机名或 IP误填管理网页地址或订阅地址
Port实际监听的 UDP 端口把其他服务的 TCP 端口当作此端口
认证信息服务端指定的完整认证字符串截断内容，或混入首尾空格
SNITLS 证书对应的服务器名称连接 IP 时误以为无需核对证书名称
混淆参数服务端是否启用及对应参数仅在客户端开启，或密码不一致
上传与下载带宽客户端方向的链路能力及服务端约束上下行填反，或将 MB/s 当成 Mbps

带宽单位要特别留意：1 MB/s = 8 Mbps，实际有效载荷还受传输开销影响。下载方向通常指服务端到客户端，上传方向相反；填写前以当前字段说明为准。不要因为本地接入标称速率较高，就把同样的数字视为远端路径可持续达到的容量。

连接成功后：确认流量确实经过该条目

Home 中选中了 Hysteria2 条目，不等于每个请求都经过它。Global Routing 的 Direct 表示直接连接；Proxy 用于代理路由验证；Config 按当前配置文件中的规则处理；Scene 还需核对当前场景的具体设置。诊断时必须记录姿态，否则协议对照可能实际测到不同路径。

使用 Config 时，到 Config 确认当前生效的文件，再核对目标请求命中的规则。规则通常按顺序匹配，以下仅用于解释语法，不是一份可直接替换现有文件的完整配置；其中 PROXY 策略需要在实际配置中存在并指向预期路径。

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

如果测试期间连接状态自行恢复，检查 Settings → On Demand 的现有设置，确认是否由按需连接触发。On Demand 负责连接触发条件，不会修复错误的认证、端口或 TLS 参数。暂时调整前先记下原设置，完成排查后恢复。

Hysteria2 常见问题：按现象排查

为什么一直超时，普通网页却能打开？

先核对地址解析结果与实际 UDP 端口，再在允许使用的另一网络下对照连接同一条目。普通网页可能使用 TCP，不能证明 UDP 路径正常。如果只在一个网络失败，优先检查该网络的 UDP 策略；两个网络都失败，再核对服务端监听、防火墙与服务状态。

为什么提示认证或证书错误？

认证错误先比对完整字符串及首尾空格，不要用订阅 URL 代替密码。证书错误则核对设备时间、SNI 和服务端证书；使用 IP 连接时，仍可能需要填写证书对应的域名。混淆不匹配也可能表现为握手失败，应与服务端参数逐项核对。

带宽填得更大，为什么反而卡顿？

目标速率超过路径容量时，排队、重传与补偿流量可能增加。降低带宽目标，暂停其他大流量任务，比较连续传输期间的网页响应。若吞吐没有提高而响应延迟变大，应保留较低设置，并核对服务端是否限制了实际可用速率。

连接已建立，为什么部分网站打不开？

先在 Home 核对 Global Routing，排除 Direct 或规则指向其他路径；再检查 Config 中的匹配结果与 DNS 解析。若只有大响应或特定网络下中断，再检查路径 MTU、UDP 分片及中间网络限制。不要在尚未定位时同时更换 DNS、端口和混淆参数。

订阅更新后，手动修改怎么不见了？

订阅更新可能重新写入受订阅管理的条目。先记录修改项，再确认上游订阅是否已经提供正确参数；长期配置应以用户自己服务的有效资料为准。订阅更新、Config 更新与 App Store 中的应用更新是不同操作，不能相互替代。

最终保留配置时，至少记录网络类型、服务端条目、Global Routing 姿态、带宽设置以及出现问题的具体操作。比较同一任务的多次结果，比单次速度峰值更有参考价值。若问题只在特定服务端发生，应携带已脱敏的错误现象向自己的服务提供方核对，不要公开认证信息。

App Store 正版核验 →