Hysteria2 是 Shadowrocket（小火箭）支持的一种代理协议。它可能改善有随机丢包、时延波动的链路，但前提是网络允许 UDP，服务器参数也必须匹配。本文面向已经持有自己服务商配置或订阅的用户，按传输原理、参数核对、导入步骤和故障现象说明如何判断是否适用；本站不提供、不销售、不推荐节点或订阅。
Hysteria2 与 QUIC、UDP 分别负责什么
结论：Hysteria2 使用 QUIC 建立客户端到服务器的传输通道，而 QUIC 的数据包通过 UDP 发送。UDP 是底层承载，不意味着所有应用数据都变成了不可靠传输。QUIC 可以在 UDP 之上提供加密、确认、丢包恢复和可靠的流传输。
应用访问网站时，原始连接与代理传输通道是两个层次。例如，网站请求本身可以使用 TCP，而 Shadowrocket 到 Hysteria2 服务器的外层连接仍使用 QUIC。排查防火墙或服务器端口时，应检查外层使用的 UDP，而不是只确认相同数字的 TCP 端口是否开放。
QUIC 的多个流可以独立推进：一个流丢失的数据包通常不必阻塞其他流已经收到的数据。这减少了跨流的队头阻塞，但同一可靠流中的缺失数据仍然需要恢复；多个流也仍会竞争同一条网络链路。不能据此推断视频、网页和文件传输可以完全互不影响。
配置若写明使用 443/UDP，只验证 443/TCP 连通并不足以证明 Hysteria2 可用。应同时核对服务器监听、服务器侧防火墙以及当前接入网络是否允许对应的 UDP 流量。
为什么可能更快：关键在拥塞控制，而不只是 UDP
结论：Hysteria2 在部分高丢包链路上的优势，与其拥塞控制和发送策略有关，不是“UDP 天生比 TCP 快”。链路中的丢包可能来自拥塞，也可能来自无线干扰或其他随机损失。如果把所有损失都当作拥塞并大幅降低发送量，可用带宽就可能没有被充分利用。
Hysteria2 的 Brutal 拥塞控制思路，是依据配置的带宽目标并结合损失情况调整发送行为。它可能以更多实际发送流量换取有效吞吐。在支持带宽协商的配置中，客户端声明的接收能力、服务器限制与实际路径容量都会影响结果。协议也有使用 BBR 等拥塞控制的情形，不能仅凭名称认定当前连接一定使用某一种模式。
- 随机丢包明显、容量仍充足：补偿损失的发送策略可能更容易保持吞吐，但必须通过同一任务的重复测试确认。
- 真正的出口拥塞：继续提高发送量可能加重排队，表现为文件传输时网页响应更慢。
- 低丢包且时延稳定：协议差异未必是主要瓶颈，服务器负载、可用带宽与目标网站仍可能决定速度。
- UDP 被阻断或严格限速：传输可能无法建立，或只能维持很低吞吐；修改带宽数字不能解除网络限制。
带宽字段还涉及单位。Mbps 表示每秒兆比特，MB/s 表示每秒兆字节；按十进制单位计算，80 Mbps 的理论上限约为 10 MB/s，实际应用数据速率还会扣除协议开销与重传。填写参数时应以应用字段标注为准，不要把文件传输工具显示的数字直接原样照填。
结论：带宽目标先按可持续能力设置
若配置暴露带宽选项，先使用已有服务商提供的值；需要调整时，以当前网络可持续的上下行能力为依据。不要为了追求更大的数字，把短时峰值或套餐标称速度当作长期发送目标。
Shadowrocket 中需要核对哪些 Hysteria2 参数
结论：先把服务器提供的信息完整对应到应用，再调整性能选项。Hysteria2 与旧的 Hysteria 协议并不能仅通过改写名称互换；导入后应确认 Type 确实对应 Hysteria2。下面列出的是参数含义，不是可直接粘贴到 Config 的配置语法。
| 参数 | 核对内容 | 常见错误与表现 |
|---|---|---|
| 服务器地址 | 使用服务商给出的域名或 IP；hy2.example.com 仅为说明用域名。 | 地址拼错或解析异常，连接无法到达正确服务器。 |
| Port | 逐字核对实际端口；例如服务商指定 443 时，外层检查对象是 443/UDP。 | 把常见端口当作默认值，导致发送到错误监听位置。 |
| 认证信息 | 按服务商提供的完整认证字符串填写，保留大小写与符号。 | 遗漏字符、复制了空格，或沿用了另一条配置的凭据。 |
| TLS / SNI | 按要求填写服务器名称，并保持证书校验；连接地址与证书名称不一定相同。 | 把 IP 直接当作证书名称，或填写了证书并未覆盖的域名。 |
| Obfuscation | 只有服务器启用时才按要求配置；例如双方使用相同的 Salamander 设置和密码。 | 一端启用而另一端未启用，或密码不一致，可能表现为握手超时。 |
| 带宽选项 | 若当前编辑页提供相关字段，核对上下行方向、单位及服务商要求。 | 上下行填反、单位误读或目标过高，造成不稳定与额外排队。 |
连接地址负责把数据送到服务器，SNI 用于 TLS 握手中的服务器名称信息，并参与常见的证书名称核对流程。两者可以不同，但必须来自可信的配置说明。出现证书错误时，应检查名称、设备时间和服务器证书状态，而不是先关闭校验。
- 字段名称、可见选项及高级设置以应用内实际显示为准；订阅没有提供某个可选参数，不代表应该自行补一个值。
- 已有订阅应优先通过订阅更新获取修正参数。手动修改前先记录原值，避免下一次更新后混淆两套配置。
- 分享排错信息时，保留错误类型和参数名称即可；认证字符串、订阅地址中的令牌及相关密码应遮盖。
导入与首次验证：先确认连接，再检查规则
结论：先在 Home 完成导入和选择，再用单一测试请求验证连接。Home 管理服务器与连接状态，Config 管理规则配置，Settings 管理应用设置；将传输失败与规则选择错误分开处理，才能缩小排查范围。
-
准备参数
从自己已有服务商处核对服务器地址、端口、认证信息和 TLS 要求。若使用订阅，确认订阅中确实包含 Hysteria2 条目，不要只凭备注名称判断协议。
-
导入订阅
在 Home 右上角选择“+”，进入 Type → Subscribe，填写自己的订阅地址并保存，再在 Home 更新对应订阅。地址中若带有认证令牌，应按密码处理。
-
核对类型
打开导入条目的编辑页，核对 Type 为 Hysteria2，并按上表检查参数。手动添加时从 Home → “+” → Type → Hysteria2 开始，按现有配置逐项填写。
-
验证连接
回到 Home 选择该条目，开启连接，并按系统提示允许添加 VPN 配置。记录开始连接后的具体结果：持续等待、明确报错，还是能打开指定测试页面。
-
检查分流
在 Home → Global Routing 核对当前模式；如需短时隔离规则影响，可用 Proxy 测试同一个请求，再恢复日常使用的 Config，并核对目标域名实际命中的策略。
首次测试期间还应查看 Settings → On Demand。若已启用按需连接，应记录其状态；进行断开或切换网络测试时，可暂时关闭并在测试后恢复，以免自动连接行为干扰观察。On Demand 管理连接触发条件，并不负责修复 Hysteria2 的认证、TLS 或 UDP 连通性。
订阅更新可能改变服务器参数或条目列表。更新完成后，确认当前选中的仍是预期条目，再测试同一目标。不要同时更新订阅、改带宽、改规则和切换网络，否则无法判断哪个变化产生了效果。
用 Global Routing 区分协议问题与规则问题
结论：同一 Hysteria2 条目在 Proxy 下能访问、在 Config 下不能访问时，优先检查规则命中与所选策略，而不是立即更换传输参数。以下比较只针对 Global Routing 中用于本次验证的三种模式；Direct 只能作为目标本来就可直连时的基线。
Config
推荐按照当前启用的 Config 规则选择处理策略。目标可能命中 DIRECT、REJECT 或某个代理策略，因此必须确认请求是否实际使用了待测 Hysteria2 条目。
适合：日常按规则使用，以及连接验证完成后的分流检查。
Proxy
将由应用处理的连接交给当前代理策略，可用于短时减少 Config 规则对测试的干扰。它不能保证系统中所有流量都被接管，也不能绕过服务器认证或网络限制。
适合：同一请求在 Config 下异常时，隔离规则选择这一变量。
Direct
让由应用处理的连接直接访问目标，不使用待测 Hysteria2 通道。直连成功只能说明这条直连路径可用，不能据此认定代理服务器运行正常。
适合：对本来可直连的目标建立本地网络基线。
检查规则时，注意 DOMAIN-SUFFIX 按域名后缀匹配，IP-CIDR 按地址网段匹配，GEOIP 按 IP 地理数据库判断，FINAL 负责前面规则未命中时的最终策略。规则按顺序处理；前面的 DIRECT 或 REJECT 命中后，后面的代理策略就不能改变这次匹配结果。DNS 解析结果也可能影响基于 IP 的判断。
结论：先证明请求经过待测通道
只有确认目标请求实际使用了选中的 Hysteria2 条目，网页加载时间与传输速率才适合用来评价该连接。若命中 DIRECT，应先修正规则测试条件，不要把直连结果记成协议表现。
连接不上、测速低与断流应怎样分层排查
结论：按“是否到达服务器 → 是否完成握手与认证 → 是否正确分流 → 是否存在吞吐瓶颈”的顺序检查。一个延迟数字只能描述某一种探测的结果，不能同时证明 UDP 可达、认证有效和持续传输稳定；探测超时也需要结合实际连接结果判断。
| 观察现象 | 优先核对 | 下一步动作 |
|---|---|---|
| Wi-Fi 超时，蜂窝网络可连接 | 两种接入网络的 UDP 策略、路由及地址解析差异。 | 保持条目不变，仅切换接入网络重复测试，再核对 Wi-Fi 网络限制。 |
| 出现 TLS 或证书错误 | SNI、证书覆盖名称、设备时间与证书有效性。 | 按现有服务商信息纠正参数，保持证书校验，不用吞吐设置处理握手错误。 |
| 连接后提示认证失败 | 认证字符串是否完整，以及服务器端是否已更新凭据。 | 更新自己的订阅或核对原始参数；不要把重试次数当作解决办法。 |
| 网页可开，大文件慢 | 服务器出口、目标站限制、本地带宽、带宽选项与持续丢包。 | 固定网络与条目，比较小请求和持续传输，并记录任务开始后的变化。 |
| Proxy 正常，Config 异常 | 规则顺序、目标命中策略和 DNS 结果。 | 检查 Config 中相关规则，不同时修改协议参数。 |
| 空闲后首次请求失败 | 网络切换、UDP 映射超时、连接重建及 On Demand 状态。 | 记录空闲时长与恢复过程，重新连接后复测，再区分接入网与服务器问题。 |
以上是故障识别条件，不是本站实测结果。做自己的对照记录时，可在同一网络下对同一文件连续测试三次，每次观察 30 秒，分别记下是否成功、稳定阶段速率及同时打开网页的响应情况。固定测试时间与目标，可以减少缓存、目标站限速和瞬时网络波动带来的误判。
- 每轮只改变一个变量：例如第一轮只切换 Wi-Fi 与蜂窝网络，第二轮才核对带宽参数。
- 同时看延迟与吞吐：速率提高但交互明显变慢，可能意味着排队加重，不一定是更好的设置。
- 注意流量消耗：持续传输与丢包补偿都可能消耗额外流量，测试前确认自己的网络计费条件。
- 保留可复核记录：记录接入网络、所选条目、Global Routing 模式、测试目标和错误文字；不要公开认证信息。
适用结论与使用前提
Hysteria2 值得在 UDP 可用、存在随机丢包或时延波动的网络中，用已有配置进行对照验证。若 UDP 被限制、服务器出口已饱和或目标本身限速，协议名称无法替代对瓶颈的处理。长期使用时应以成功率、持续吞吐、交互响应和流量消耗共同判断，而不是只挑延迟最低的一次结果。
- 参数完整但握手失败：先核对 UDP、TLS 与认证，不先追求带宽数字。
- 握手成功但目标访问异常：先核对 Global Routing 和 Config 规则。
- 可用但速度不稳定：固定任务与网络做重复测试，再判断拥塞控制和链路条件是否匹配。
Shadowrocket 是闭源商业应用，以 iPhone / iPad 使用为主，也可在 App Store 产品页核对 Mac、Apple TV 和 Apple Vision 的兼容性。系统要求、兼容性与是否通用购买以 App Store 页面标注为准。唯一获取入口为 App Store，开发者为 Shadow Launch Technology Limited，应用 ID 为 932747118；应用采用一次性买断，价格以商店展示为准。
购买 Shadowrocket 获得的是客户端，不等于取得服务器、带宽或订阅。本文所有导入、参数与连接测试，都以用户已经拥有自己的服务商配置为前提。