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

Hysteria2 协议科普:基于 QUIC 为什么快,适合哪些网络场景

从 QUIC 传输和拥塞控制讲起,解释 Hysteria2 在高丢包、高延迟链路下的表现,以及在 Shadowrocket 中添加该类节点时要填的字段。

本文速览

本文适合已经持有自己的服务商与订阅、准备使用 Hysteria2 的用户。先区分 QUIC 的传输能力与拥塞控制的作用，再核对 Shadowrocket 中的连接参数，最后用固定测试条件判断网络是否适合。读完可以知道哪些字段必须一致，以及连接超时、证书错误和吞吐不稳定分别应从哪一层检查。

先确认客户端、协议与线路的边界

Shadowrocket（小火箭）是 Apple 平台的付费客户端，主要用于 iPhone 与 iPad，唯一获取入口是 App Store。商店页可核对开发者 Shadow Launch Technology Limited 和应用 ID 932747118。应用一次性买断；系统要求、兼容设备和通用购买以 App Store 页面标注为准。

客户端买断 ≠ 线路套餐。本文所有操作均以用户已有自己的服务商与订阅为前提。Hysteria2 是连接协议，不是订阅本身；同一份订阅可能包含不同协议的记录，订阅能够更新，也不等于其中每条记录都能在当前网络连通。Shadowrocket 是闭源商业应用，应用安装、订阅更新与服务端维护是三个不同环节。

QUIC 为什么可能更快：连接复用与丢包恢复

Hysteria2 基于 QUIC，QUIC 的底层传输使用 UDP，并集成 TLS 1.3 的安全握手。这里的 UDP 不代表把网页数据随意发出后就不管了：QUIC 可以在其流上实现可靠、有序交付，包括确认、重传与流量控制。应用侧的 TCP 请求与 UDP 请求，可以通过 Hysteria2 分别承载。

理解 QUIC 的一个关键是流之间的隔离。传统 TCP 连接中的某段数据丢失时，后续字节需要等待补齐；多个请求若共用这条字节流，就可能一起等待。QUIC 的不同流可以独立交付，一条流缺失数据，不必让另一条已收齐数据的流也等待同一缺口。但同一条流内部仍需按序交付，而且不同流仍共享链路容量和拥塞状态。

UDP
QUIC 的底层传输，需要链路允许相应 UDP 端口
TLS 1.3
QUIC 集成的安全握手机制
443/UDP
可采用的服务端监听示例，并非协议固定端口

连接复用能减少重复建立连接的开销，但不应把它理解成“任何时候都能零等待”。首次访问、证书验证、域名解析和目标站点响应仍会耗时。是否复用已有连接，也取决于连接状态与实现行为。网页加载慢不一定等于传输协议慢。

判断：先确认 UDP 可达，再讨论吞吐

如果当前网络无法到达服务端的 UDP 监听端口，调整带宽参数没有意义。先对照服务端实际端口完成连接验证，再观察持续传输是否改善。

拥塞控制能解决什么，不能解决什么

高延迟意味着一次反馈需要更久；丢包则可能来自无线干扰、拥塞、设备队列溢出等不同原因。许多传统拥塞控制策略会把丢包视为降低发送速率的信号。在随机丢包明显但仍有可用带宽的路径上，发送窗口持续收缩，可能使带宽利用率偏低。

Hysteria2 的性能特点不只来自 QUIC，还与拥塞控制策略有关。其中 Brutal 采用带宽目标与丢包补偿思路，尝试维持目标吞吐。它不是凭空增加线路容量：目标设置过高可能增加排队、丢包与额外流量，影响同网络中的其他业务。实际使用哪种策略以及是否采用带宽协商，取决于客户端能力与服务端配置，不能只凭节点名称判断。

网络现象可能的作用仍需核查
高延迟、存在随机丢包合适的拥塞控制可能提高持续吞吐丢包是否由拥塞造成、可用带宽是否稳定
低延迟、低丢包可能正常工作，但未必出现明显优势服务端负载、目标站点限速
UDP 被限制可能超时或频繁断开接入网络策略与服务端防火墙
上传长期占满下载与交互仍可能因排队而变慢上行占用、设备队列与带宽目标

若界面提供上传、下载带宽参数，应按字段标注的单位填写，不要将 Mbps 与 MB/s 混用：理论上 80 Mbps 等于 10 MB/s，实际应用吞吐还需扣除协议开销。这是单位换算，不是速度承诺。参数应参考当前线路的稳定可用值，而非宽带套餐标称峰值。

在 Shadowrocket 中添加 Hysteria2：先核对字段

优先使用用户已有订阅中的完整记录，避免手工抄写遗漏。若需要手动添加，应先从已有服务信息中核对协议类型、服务器地址、端口、认证密码与 TLS 参数。Hysteria 与 Hysteria2 不能仅凭名称相似就互换，其他协议的密码和端口也不能直接套用。

  1. 导入记录

    进入 Home → 右上角「+」→ Type → Subscribe，填写自己的订阅地址并保存，完成更新后检查记录是否出现。若手动添加，则在 Home →「+」→ Type 中选择 Hysteria2。

  2. 核对地址

    核对服务器地址与 Port。地址字段只填服务端提供的主机名或 IP，不要自行加网页路径。比如服务端明确监听 443/UDP，Port 才填写 443；端口不能仅凭常见值猜测。

  3. 核对认证

    将服务端给出的认证信息填入 Password。订阅访问凭据与节点认证密码用途不同，不要互相替换；复制时注意末尾空格、大小写以及特殊字符。

  4. 核对 TLS

    按服务端要求填写 SNI，并保持证书校验。连接地址是 IP 时，SNI 仍可能需要填写证书对应的域名。不要通过启用 Allow Insecure 掩盖域名不匹配或证书失效。

  5. 检查可选项

    若服务端启用了混淆，需使用相同类型及混淆密码；没有启用时不要自行补填。上传、下载带宽及其他扩展字段以实际界面与服务端说明为准，导入后也应检查是否完整保留。

  6. 连接验证

    保存后返回 Home，选择该记录，再检查 Global Routing。测试时明确目标请求应走哪种路径，开启连接并访问固定目标；不要把列表中的延迟结果当成完整下载速度。

验证路由：区分协议问题与规则问题

记录已选中，不等于所有请求都会经过它。Home → Global Routing 中的 Proxy、Direct、Config、Scene 用于选择不同的处理姿态。排查时应记录原选项，只短暂改变一项，测试结束后恢复；不要同时更换协议、规则与 DNS，否则无法定位改善来自哪里。

Config

推荐

按当前启用配置的规则处理请求。需要确认目标实际命中的规则和策略，才能判断是否使用了 Hysteria2；Config 本身不保证某个域名一定走代理。

适合：日常按既有规则使用，并核对具体请求的去向。

Proxy

将代理路径作为排查基准，减少普通分流规则对测试结论的干扰。应同时确认当前选中的记录，系统层面的排除流量仍需另行考虑。

适合：短时验证连接本身，判断异常是否与分流规则有关。

Direct

采用直接连接路径，不用于验证 Hysteria2 的代理吞吐。可以用它观察本地网络与目标的直连表现，但这不是同一服务端路径的性能对照。

适合：确认基础网络是否可用，或排查直连访问异常。

Scene 按已配置的场景条件组织路由选择，不能把它当成固定等同于 Proxy 的开关。若启用了 Settings → On Demand，也应记录其当前状态，避免按条件触发的连接行为影响测试判断。On Demand 控制连接触发，不会直接提高 Hysteria2 的吞吐。

超时、低速与断流：按现象逐项排查

测试应固定设备、目标资源与时间段，每次只改变一个条件。建议分别在 Wi-Fi 和蜂窝网络各做三次相同资源的传输，记录连接是否成功、持续吞吐范围、是否断流以及当时的路由姿态。这是测试流程，不是预设的性能结论；不要用一次峰值代表全天表现。

观察到的现象优先检查下一步操作
一直连接超时地址、UDP 端口、服务端监听与网络限制保持记录不变切换接入网络，比较能否完成连接
提示认证失败Password 与服务端认证要求核对原始信息，更新已有订阅后再次检查记录
提示证书错误SNI、设备时间、证书域名与有效性纠正对应字段或由服务端维护者修复证书
小流量正常，大传输停顿丢包、路径 MTU、带宽目标与拥塞先降低不合理的带宽目标，记录现象再进一步检查路径
连接正常但某个网站很慢规则命中、DNS、目标站点及服务端出口换一个固定目标复测，区分单站问题与整条连接问题
Wi-Fi 失败，蜂窝正常本地路由器、接入网络的 UDP 策略检查网络策略，不要立即重填全部认证参数

路径 MTU 问题只能作为排查线索，不能仅凭“大文件慢”就下结论。若低负载时连通、持续传输后延迟明显升高，还应检查上行是否被占满，以及是否存在过高的带宽目标。调整时保留原值，一次只改一个参数，并用同一资源复测。

结论：按稳定性选择，而不是按协议名称选择

在 UDP 可达、参数正确的前提下，若多次测试都表现为持续吞吐更稳定且断流更少，可以继续使用已有的 Hysteria2 记录；若当前接入网络持续限制 UDP，应先处理网络条件，或使用自己已有的其他可用连接记录。

保留排查记录时，只记录错误类型、测试条件和脱敏后的字段说明。订阅地址、Password 及混淆密码属于连接凭据，不应放入公开截图或日志。需要重新核对基础设置时，可先阅读站内入门指南，再回到 Home 检查记录与 Global Routing。

下载 Shadowrocket