QUIC传输与代理请求分别记录
Hysteria 官方把它描述为基于 QUIC 的 TCP、UDP 代理，规范要求建立在标准 QUIC 及不可靠数据报扩展上。记录时保留外层 QUIC，不把它改成 TCP 隧道。
规范描述从 2.0.0 起的协议，内部有时称为 v4。这个内部称呼与 Hysteria 2 名称各有语境，不能看到 v4 就把分享改成另一个产品或另外一代配置。
| 读取项目 | 公开说明里的内容 |
|---|---|
| 外层传输 | QUIC |
| 代理对象 | TCP与UDP请求 |
| 规范起点 | 2.0.0起使用的协议 |
| 分享简称 | hy2与hysteria2 |
| 省略端口 | 默认443 |
| 混淆名称 | Salamander与Gecko |
2.0.0 被写为 Hysteria 2 的首个正式版本，但该更新页没有写发布日期，没查到公开说明。不能从版本号推算一个日期，也不由新协议文字补成完整互通结论。
分享内容先看认证位置与端口条件
分享结构允许认证内容放在主机前，端口可省略，也有多端口跳跃形式。查询项目列有 obfs、obfs-password、sni、insecure、pinSHA256 和 ech，各自按来源说明读取。
- 保留提供方给出的端口形态，不把多端口截成单值。
- 认证、混淆和TLS参数分别对应，不用同一密码代填全部项目。
- 安全相关参数只记录当前值，不为了导入随意关校验。
省略端口按规范有默认值，明确写出的端口仍是当前配置的一部分。
Realm 还使用另一分享形式，不能只删掉名称后半部分当成普通节点。识别前缀以后仍要按对应模式读取内容，不从类型相似推定参数可以互换。
认证的两种文字按各自出处并排留下
Hysteria 规范把认证放在 HTTP/3 的 /auth 请求中，客户端发送认证头，成功返回状态码 233。Xray 文档却说 hysteria protocol 本身无认证，并将代理控制与 QUIC 传输分开描述。
两种表述都保留，具体差异原因未明确，不解释成某个版本已经移除认证。所用核心与配置对象写清楚后，再对应它自己的字段，不跨实现删掉必要内容。
核心类型名按实现而不是简称填写
Xray 出站类型写 hysteria，version 必须为 2；sing-box 有 hysteria2，也另列 hysteria。mihomo 把 Hysteria 和 Hysteria2 分列，不能只看到 hy2 就填同一类型名。
- 确定来源指的是哪一代协议及哪种模式。
- 对照核心类型、认证和传输字段，保留各自条件。
- 记录实际导入与连接结果，不由协议能力作速度结论。
还需其他服务时可在下面了解
若想改选机场，可通过下方收录入口继续查看配置来源。
常见问题解答
Hysteria2代理TCP请求，外层也变成TCP了吗？
请求与外层传输分开，官方描述它基于标准 QUIC 代理 TCP 和 UDP。不能从承载的请求类型改写协议传输，也不把请求支持范围写成速度结果。
认证规范和Xray表述不同要保留哪一边？
并列保留，规范写 HTTP/3 的 /auth 认证，Xray 写控制协议本身无认证并区分传输部分。差异原因未明确，不能替它解释成认证已经取消。
端口没写时与多端口形式该怎么记？
规范省略端口默认 443，明确提供的多端口则按原形态保留。不要把多端口改成单值，也不把默认值覆盖到已经写出端口的配置里。