Hysteria2 的潜在优势来自 QUIC 的传输机制与带宽相关的拥塞控制，不是 UDP 自带速度保证。本文面向已经拥有服务参数或订阅的用户，依次说明链路条件、认证与 TLS 参数、Shadowrocket 中的配置步骤，以及如何区分 UDP 不通、证书错误和规则分流问题。先确认能建立连接，再讨论吞吐量。
Hysteria2、QUIC 与 UDP 分别负责什么
Shadowrocket（小火箭）中的 Hysteria2 是一种代理协议选项。它以 QUIC 为基础，而 QUIC 的数据包由 UDP 承载。这三个名称不是同义词：UDP 提供数据报传输，QUIC 在其上实现加密、连接管理及可靠流，Hysteria2 再定义代理认证、请求转发和相关传输行为。服务端必须支持对应协议，不能只把现有记录的 Type 改成 Hysteria2 就完成转换。
UDP 本身不保证送达，也不保证顺序，但这不等于经 Hysteria2 访问网页时会丢失页面内容。对于需要可靠传输的数据，QUIC 的流机制负责确认和重传；对于代理的 UDP 流量，协议可通过数据报机制承载，语义与可靠字节流不同。判断协议性能时，应区分外层传输与内部应用实际使用的连接。
端口必须以用户已有服务参数为准。同一个数字的 TCP 端口和 UDP 端口属于不同传输协议：服务器的 TCP 443 可访问，不能证明 UDP 443 可用。普通网页能打开，也只能证明当前网页使用的路径可用，不能代替 Hysteria2 的握手检查。
为什么高延迟、丢包链路可能受益
网络吞吐量不仅取决于标称带宽，还受往返时延、丢包、发送窗口与拥塞控制影响。传统基于丢包反馈的控制方式，可能把无线干扰造成的随机丢包也视为拥塞，继而降低发送速率。Hysteria2 的自有拥塞控制机制，试图在这类条件下更积极地利用链路容量；是否采用该机制以及实际效果，还取决于客户端、服务端与带宽协商配置。
QUIC 的多流机制减少了不同流之间的传输层队头阻塞：一个流等待丢失数据重传时，不必因为同一条有序字节流的缺口而直接阻塞所有其他流。但丢包并未消失，同一个可靠流仍要等缺失数据补齐，多个流也仍然共享链路容量和拥塞状态。因此，“使用 QUIC”不能推导出“任何网络都更快”。
- 高延迟、存在随机丢包：在 UDP 可达、服务端资源充足的前提下，较积极的发送策略可能改善持续传输的吞吐量。
- 低延迟、低丢包：瓶颈可能已经是接入带宽、服务端出口或目标站点，换协议未必带来可感知差异。
- 真实链路拥塞：继续提高发送量可能增加排队、抖动和丢包，不能把丢包全部归因于无线干扰。
- UDP 被阻断或限速：可能表现为握手超时，或建立连接后持续传输受限，协议机制无法消除路径限制。
结论：先确认 UDP 可达，再调整带宽
如果连接始终停在握手阶段，先核对服务器地址、UDP 端口和所在网络；不要用提高带宽数值处理可达性问题。只有连接稳定建立后，才有条件比较吞吐量与延迟。
填写参数前，先区分地址、认证与 TLS
Hysteria2 记录至少需要正确的服务器地址、端口和认证信息。TLS 身份核验、混淆及带宽选项则要与已有服务配置一致。订阅里携带的参数应作为核对起点，而不是凭经验全部覆盖。尤其不要把服务器连接地址、证书名称和认证密码当成可以互换的字段。
| 参数 | 填写与核对方式 | 常见误判 |
|---|---|---|
| 服务器地址与 Port | 照已有参数填写域名或 IP，以及对应 UDP 端口；端口数值范围为 1–65535。 | 认为所有服务都使用 443，或把 TCP 可达当作 UDP 可达。 |
| 认证信息 | 保留大小写及完整字符。若服务要求组合格式，按其原始格式填写。 | 只填写组合认证的一部分，或复制时带入空格、换行。 |
| SNI 与证书 | 按服务配置填写 TLS 名称，核对其与证书及连接目标的关系。 | 直接填 IP 后遇到名称不匹配，便关闭证书验证。 |
| 混淆 | 仅在服务端要求时设置；例如使用 Salamander 时，两端类型和密码必须一致。 | 自行添加混淆，或把混淆密码误当成认证密码。 |
| 带宽 | 按实际可用上行、下行及服务约定填写，并核对界面所用单位。 | 把数值当成提速倍率，或混淆 Mbps 与 MB/s。 |
例如，若已有配置使用 IP 作为连接地址、域名作为 TLS 身份，地址栏与 SNI 可能本来就不相同。这种情况应核对原始参数，而不是强行改成一致。出现证书错误时，先检查系统时间、SNI、证书有效性与服务配置；保持证书验证开启，避免用跳过验证掩盖错误。
在 Shadowrocket 中添加并完成首次核对
以下步骤以已经获得自己的 Hysteria2 参数为前提。若使用已有订阅，可在 Home 右上角“+”中将 Type 设为 Subscribe，填写自己的订阅链接并保存，更新后检查生成记录的 Type 与参数。订阅获取失败与 Hysteria2 握手失败是两件事：前者发生在获取配置阶段，后者发生在使用某条记录建立连接时。
-
核对已有参数
先备齐地址、UDP 端口、认证信息，以及服务要求的 SNI、混淆和带宽设置。不要把 Hysteria 的旧协议参数直接视为 Hysteria2 参数。
-
添加记录
在 Home 点击右上角“+”，进入 Type 并选择 Hysteria2。填写已有的服务器地址与 Port，确认数字没有遗漏或多输入一位。
-
填写认证
复制完整认证信息，并按原始配置填写混淆选项。认证密码与混淆密码分开核对，不要因为两处都要求密码就填入同一值。
-
检查 TLS
核对 SNI 与证书验证设置；带宽选项按界面单位填写。若已有订阅已设置这些参数，先保留原值，避免首次测试时同时改变多个变量。
-
保存并测试
保存后回到 Home，选中该记录，检查 Global Routing，再开启连接。首次启用时按系统提示允许添加 VPN 配置，随后用实际网页请求验证连接，而不只看延迟数字。
更新订阅可能改变由订阅生成的记录。为避免混淆，测试前记下当前参数与订阅更新时间提示；若做了手工调整，更新后重新核对。分享排查信息时隐藏认证内容和订阅 token，保留错误类型、网络类型以及端口即可，不应把完整凭据贴入公开讨论。
排查时如何选择 Global Routing
协议连接、路由姿态和规则命中属于不同层次。Home 中选中 Hysteria2 记录，并不表示每个请求都会使用它；Global Routing 与 Config 中的策略仍可能让请求走 DIRECT，或选择其他策略。因此，排查某一条记录时，先减少规则因素，再恢复日常配置。
Proxy：隔离规则变量
推荐短时排查时使用 Proxy，并确认当前选中的就是待测 Hysteria2 记录。它让交由客户端处理的连接按代理姿态转发，便于减少 Config 规则带来的干扰；仍应留意局域网排除等独立设置。
适合：首次验证参数、区分协议与规则问题
Config：验证日常分流
连接确认有效后切回 Config，检查实际请求命中的规则及策略。DOMAIN-SUFFIX、IP-CIDR、GEOIP 等规则影响去向，FINAL 负责未命中前序规则时的最终策略。
适合：已有规则配置、需要按目标分流
Direct：观察直连基线
Direct 用于观察直连访问是否正常，不用于证明 Hysteria2 记录可用。若在此姿态下网页可以打开，只能说明相应直连请求成功，不能据此判断代理握手已经完成。
适合：对照本地接入网络与目标站点的直连情况
若 Proxy 下可访问、切回 Config 后特定请求失败，重点检查 Config 里的规则顺序和目标策略，而不是立即修改 Hysteria2 密码。规则从上到下匹配，较早的宽泛规则可能覆盖后面的细分规则；FINAL 应位于规则列表末尾。还要核对 PROXY 实际使用的记录或策略组是否与测试时一致。
常见故障：先定位阶段，再只改一个变量
“连接开关已开启”“延迟测试有数值”“目标网页可以打开”代表不同层面的状态。系统 VPN 状态不等于每条远端连接都成功，单次延迟测试也不代表持续传输表现。下面按可观察现象处理，不预设故障一定来自协议。
Wi-Fi 一直超时，换蜂窝网络却能用？
保留同一条记录、同一端口和同一目标请求，只切换接入网络再测试。若差异能够重复出现，优先检查 Wi-Fi 路径的 UDP 可达性、限速或防火墙策略；不要先改密码，因为相同参数已在另一条路径完成连接。注意蜂窝数据消耗。
提示证书或 TLS 错误，要关闭验证吗？
先核对设备时间、记录中的 SNI 与已有服务参数，再确认域名是否解析到预期地址。名称不匹配或证书过期需要修正对应配置；不把关闭证书验证作为常规排障步骤，也不要把握手超时一概当成证书错误。
小网页正常，大文件传输却频繁停顿？
先降低过高的带宽设置，再在相同网络重复同一请求。若仍出现相同现象，记录发生时机，进一步核对路径 MTU、UDP 分片与限速条件。不要仅凭这一现象直接修改 MTU；还要排除服务端出口和目标站点本身的限制。
手动连接正常，自动连接却不符合预期？
先在 Settings → On Demand 核对开关与已设置的网络触发条件，确认当前 Wi-Fi 或蜂窝环境是否符合预期。测试协议时先使用手动连接，避免自动断开或重新连接干扰观察；确认协议和路由正常后，再单独测试 On Demand。
需要比较性能时，固定设备、接入网络、记录、目标资源与测试时段，每轮只调整一项参数。分别记录握手是否完成、网页首个响应是否出现、持续传输是否稳定，以及延迟是否随负载明显上升。不要用不同目标站点的两次下载，推导某种协议固定快多少。
- 先验证：地址、UDP 端口、认证、TLS 和混淆是否与已有配置一致。
- 再隔离：以手动连接和明确的 Global Routing 姿态排除自动化及规则干扰。
- 后比较：在可重复条件下观察吞吐量与抖动，确认调整是否真的改善体验。