Hysteria2 的优势取决于 UDP 可达性、链路丢包特征与带宽设置，并非换一个 Type 就一定更快。本文适合已经拥有服务信息的 Shadowrocket（小火箭）用户：先理解 QUIC 的可靠传输与拥塞控制，再核对参数、导入配置，并用固定条件判断当前网络是否适合。
一、QUIC 基于 UDP，但不等于放弃可靠传输
Hysteria2 使用 QUIC 承载代理通信。UDP 提供数据报传输，本身不负责按序交付、重传或连接状态；QUIC 则在其上实现加密连接、丢包恢复、流量控制和多路复用。需要可靠交付的数据仍然会进行确认与重传，因此不能把它理解为“丢了就不管，所以速度快”。
QUIC 使用 TLS 1.3 建立安全连接，并支持多个独立的可靠流。某个流等待丢失的数据时，其他流不必因同一条传输层字节序列缺口而全部停住。不过，连接仍共享网络容量和拥塞状态；同一个流内的数据也仍需有序交付。多路复用缓解的是特定形式的队头阻塞，不会消除所有等待。
- 传输基础：服务器必须能够接收指定端口的 UDP 数据；TCP 端口可达不代表同端口的 UDP 可用。
- 安全基础：QUIC 的加密握手仍需要正确的服务器身份与证书校验，不能用跳过校验代替参数核对。
- 应用映射：Hysteria2 可以承载 TCP 连接与 UDP 流量，但两类流量的可靠性处理并不相同，不能理解为所有 UDP 数据都会变成可靠流。
端口
443只是常见的配置示例，不是 Hysteria2 的固定要求。已有服务指定其他端口时，应原样使用；普通 HTTPS 网页能打开，也不能证明 UDP 443 一定可达。
二、为什么在高丢包或高延迟链路上可能更快
影响吞吐量的不只是协议头大小，还包括发送端如何判断拥塞。以丢包为重要信号的控制方式，在无线干扰造成随机丢包时，可能把并非拥塞导致的损失也当成减速理由。Hysteria2 的 Brutal 拥塞控制思路，是根据目标带宽与交付反馈调整发送，以减轻随机丢包带来的吞吐下降；实际采用的控制方式还受实现、配置以及双方协商影响。
这种思路不等于无限发送。目标带宽高于实际容量，会增加排队、丢包与其他连接的竞争，甚至使网页交互更慢。高延迟网络还需要足够的数据在途才能填满链路，但协议无法缩短物理距离，也无法保证服务器出口不拥塞。
| 网络条件 | 可能的表现 | 优先核对 |
|---|---|---|
| UDP 可达，存在随机丢包 | 可能比容易因丢包退让的传输方式维持更稳定的吞吐 | 持续传输速度与交互延迟是否同时改善 |
| 往返延迟较高 | 有机会改善带宽利用率，但首次访问仍受往返时间影响 | 首字节时间与大文件速度分别记录 |
| UDP 被限制或丢弃 | 握手超时，或开始传输后速度明显受限 | 更换 Wi-Fi 或蜂窝网络做对照 |
| 低延迟、低丢包 | 优势可能不明显，其他瓶颈更容易占主导 | 服务器负载、目标站点与本地带宽 |
用一个计算示例说明带宽与延迟的关系：若可用带宽为 50 Mbps，往返时间为 100 ms，带宽时延积约为 0.625 MB。这表示持续利用该带宽需要相应规模的数据在途，不是填写参数后的保证速度。单位也必须区分：50 Mbps 的理论字节速率约为 6.25 MB/s，实际还需扣除传输开销。
结论：先确认 UDP 可达
先在两种接入网络上测试同一条已有 Hysteria2 配置；如果只有一种网络持续超时，先排查该网络的 UDP 路径，不要反复提高带宽数值。
三、添加 Hysteria2 前需要哪些参数
本文以用户已经拥有自己的服务商与订阅为前提。优先使用服务方提供的完整配置，手动添加时再逐项核对。Hysteria2 与旧协议类型不能仅凭名称相似而混用，尤其不要把旧配置的密码、混淆参数直接拼到新条目里。
| 参数 | 填写依据 | 常见错误 |
|---|---|---|
Type | 选择 Hysteria2 | 误选其他协议类型 |
| 服务器地址 | 已有服务提供的域名或 IP 地址 | 把整条分享链接填进地址栏 |
| 端口 | 服务端实际监听的 UDP 端口，例如 443 | 按网页端口猜测或照抄示例 |
| 认证信息 | 完整复制服务方给出的认证值 | 漏掉符号、增加空格或自行拆分内容 |
SNI | 与服务端证书配置一致的名称 | 连接 IP 时忽略证书所需域名 |
| 混淆参数 | 仅在服务端启用时，按要求填写类型及密码 | 将认证密码与混淆密码视为同一字段 |
| 上行与下行带宽 | 界面提供该项时，核对单位并使用合理值 | 混淆 Mbps 与 MB/s，或填入远超实际容量的数值 |
表内是需要核对的参数含义，具体字段名称与可见项目以当前 Shadowrocket 界面为准。连接地址与 SNI 可以不同：前者决定连接到哪里，后者参与 TLS 名称协商与证书身份核对。遇到证书错误，应检查名称、设备时间与服务端证书状态，而不是直接关闭校验。
-
核对来源
确认已有服务提供的是 Hysteria2 参数或兼容订阅，并保存原始信息，方便修改后回退。不要在公开截图中展示认证值。
-
选择入口
手动添加使用 Home → 右上角“+”→ Type → Hysteria2；导入已有订阅使用 Home → 右上角“+”→ Type → Subscribe。
-
填写并保存
手动条目逐项核对地址、端口、认证与 TLS 信息；Subscribe 填入用户自己的订阅链接后保存，回到 Home 更新并检查生成的条目类型。
-
授权并测试
在 Home 选择目标条目并开启连接，首次连接按系统提示允许添加 VPN 配置。随后分别测试网页访问与持续传输，不能只看延迟数字。
四、Global Routing 决定是否真正经过目标条目
协议参数正确，不代表测试请求一定经过 Hysteria2。Home 中选择条目后，还需核对 Global Routing。日常分流与临时诊断应采用不同目的：先确认连接本身可用，再验证规则命中，避免把规则走向问题当成协议性能问题。
Config
推荐按当前配置中的规则决定请求策略。命中 DIRECT 的请求直接连接，命中代理策略的请求才按对应选择转发；未命中的请求由 FINAL 等兜底设置处理，不保证默认直连。
适合：日常使用与规则分流验证
Proxy
将进入代理处理范围的请求交给代理路径，适合暂时排除按目标分流规则的干扰。测试时还要确认实际选中的是目标 Hysteria2 条目，而非其他策略选择。
适合：短时隔离规则因素、确认连接可用性
Direct
采用直接连接路径，不能用于证明 Hysteria2 是否正常。若 Direct 能打开网页而代理路径失败，只能说明两条路径结果不同，仍需检查认证、UDP 与服务器状态。
适合：建立直接连接的对照结果
以下是配置中的规则语法示例，不是必须添加的性能优化。DOMAIN-SUFFIX 匹配域名及其子域名；规则按顺序检查，FINAL 放在末尾处理前面未匹配的请求。规则片段应放入 Config 中相应配置的规则区域，不应粘贴到服务器地址或订阅地址栏。
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT测速前如需固定连接状态，可先检查 Settings → On Demand，记录并暂时停用已有自动触发条件，测试完成后恢复。不要在同一组对照测试中同时更换条目、规则和触发条件。
五、用固定测试顺序区分速度与稳定性
Home 的延迟结果只代表对应测试方法下的响应表现。较低延迟不能证明认证后的持续传输、DNS 解析以及目标站点访问全部正常。对照测试应使用同一设备、同一目标资源和相近时段，每次只改变一个变量。
- 保存基线：记录当前网络是 Wi-Fi 还是蜂窝网络、所选条目、Global Routing，以及是否启用 On Demand。
- 验证访问：打开一个已知可访问的页面，记录是否出现解析失败、握手超时或证书错误，不要把不同错误统一归为“速度慢”。
- 观察持续传输：使用自己的固定测试资源连续观察约 60 秒，记录稳定速率、是否中断，以及传输期间页面交互是否明显变慢。
- 切换接入网络：保持条目和配置不变，仅在 Wi-Fi 与蜂窝网络之间切换，分别重复三次；注意蜂窝数据用量。
- 检查重复性：若结果只偶尔变好，不能据此判断协议优势。若同一网络持续超时，另一网络持续正常，优先检查接入网络限制。
这些数字是测试安排，不是性能结论。没有统一的“丢包超过某个百分比就必然更快”门槛：丢包发生的位置、是否成簇、往返延迟、可用带宽和服务器负载都会改变结果。持续传输变快但交互明显变慢，也不应判定为整体改善。
结论：保留可重复的改善
只有在固定条件下多次获得更稳定的传输，且日常交互没有明显退化，才保留当前设置；否则恢复原值，再单独检查带宽参数或网络路径。
六、连接与导入中的常见问题
填了 443，为什么还是一直超时？
先回到 Home 编辑条目，核对服务方指定的端口，而不是默认使用 443。随后保持配置不变切换接入网络；网页 HTTPS 可用只说明相应 TCP 路径可用，不能替代 UDP 可达性判断。
延迟正常，打开网页却失败，怎么查？
先核对 Home → Global Routing 与当前选中的条目，必要时短时使用 Proxy 隔离规则影响。若只有域名访问失败，再检查 DNS 解析；若出现 TLS 错误，检查 SNI、设备时间与证书，不要仅凭延迟结果反复更换协议。
已有订阅导入后，没有 Hysteria2 条目？
在 Home 更新该订阅，再检查订阅返回内容是否包含 Hysteria2，以及当前应用是否支持对应字段。已有订阅可能只返回其他协议，不能通过改显示名称完成转换；应向原服务方核对自己已有配置的格式。
带宽写得越大，是不是下载越快？
不是。先记录原值，核对界面标注的单位，再按实际可用带宽调整；每次只改一项并重复测试。若提高数值后延迟上升、丢包增多或其他页面明显卡顿，应恢复，而不是继续增加。
认证密码正确，为什么还报错？
回到 Home 编辑条目，检查复制内容是否包含空格或换行，并将认证信息与混淆密码分开核对。若混淆在服务端启用，双方类型与密码都需一致；订阅更新可能重新覆盖条目，更新后应再检查实际参数。
最后，将应用购买与连接服务分开管理。Shadowrocket 是闭源商业应用，采用一次性买断；客户端买断 ≠ 线路套餐。本文只解释已有服务信息的使用，不提供、不销售、不推荐连接服务。应用仅在 Apple 平台发行，iPhone、iPad 为主要使用设备，唯一获取入口是 App Store，系统要求与通用购买适用性以 App Store 页面标注为准。