QUIC 协议与 Hysteria2 进阶调优：Brutal 算法、Realm 穿透与 2026 实战

引言：为什么需要「进阶」调优#

基础篇已经讲清楚：Hysteria2 基于 QUIC，用 Brutal 算法在丢包环境下比 TCP 方案快 30-50%。

但把 Hysteria2 跑起来，和把它调优到极致，是两回事。

实际部署中，90% 的用户只改了 up / down 两个参数就完了——这等于买辆跑车只挂了一档。本文从协议栈原理出发，把 Hysteria2 的每个可调参数、每种抗封锁手段、每个 2026 年新增特性讲透。

一、QUIC 协议栈：不止是「UDP 版 TCP」#

1.1 QUIC 的核心创新#

QUIC 由 Google 在 2012 年提出，2018 年成为 IETF 标准（RFC 9000），是 HTTP/3 的底层传输协议。它与 TCP 的本质区别不止于传输层：

1
TCP 协议栈：
2
应用层 → TLS（可选）→ TCP → IP
3

4
QUIC 协议栈：
5
应用层 → HTTP/3 → QUIC（内置 TLS 1.3）→ UDP → IP

关键差异：

维度	TCP + TLS 1.3	QUIC + TLS 1.3
握手延迟	2-3 RTT	1 RTT（首次）/ 0 RTT（恢复）
队头阻塞	连接级阻塞（一个包丢失阻塞所有流）	流级独立（一个流丢包不影响其他流）
连接迁移	不支持（NAT 重绑定 = 断连）	Connection ID 机制，IP 变化不中断
加密层	可选，应用层协商	强制，握手即加密
拥塞控制	内核态（修改需改内核）	用户态（随意定制算法）

1.2 连接迁移：移动网络的杀手锏#

TCP 的最大弱点之一：你的手机从 Wi-Fi 切换到 5G，NAT 重新分配 IP，TCP 连接瞬间断开。

QUIC 用 Connection ID（CID） 解决这个问题：

1
TCP：  [客户端 IP:端口] ←→ [服务端 IP:端口]  （IP 变了 = 连接失效）
2
QUIC： [CID] ←→ [服务端]                  （IP 变了，CID 不变 = 连接保持）

这对代理场景意义重大：你在家用 Wi-Fi 开着代理，出门切到 4G，Hysteria2 连接不中断。

1.3 Hysteria2 对标准 QUIC 的修改#

Hysteria2 并未使用标准 QUIC 实现（如 Google quiche 或 Cloudflare quiche）。它在 quic-go 库基础上做了两处关键修改：

替换拥塞控制算法 → Brutal（核心）
重新设计认证和伪装层 → 兼容 HTTP/3 握手

标准 QUIC 实现使用 BBR 或 Cubic 拥塞控制，遇到丢包仍会降速。Hysteria2 的修改使得它可以无视丢包、按预设速率全速发送。

二、Brutal 拥塞控制：数学机制详解#

2.1 核心公式#

Brutal 算法的设计基于一个简单假设：代理场景中的丢包，大多不是因为网络拥塞。

设：

B_target = 目标带宽（用户配置）
P_loss = 当前丢包率（实时测算）
B_send = 实际发送速率

1
B_send = B_target / (1 - P_loss)

举例：

目标带宽	丢包率	实际发送速率	对端有效接收
100 Mbps	0%	100 Mbps	100 Mbps
100 Mbps	5%	~105 Mbps	~100 Mbps
100 Mbps	10%	~111 Mbps	~100 Mbps
100 Mbps	20%	~125 Mbps	~100 Mbps

关键点：Brutal 通过「过量发送」来补偿丢包，确保对端收到的有效数据量等于目标带宽。

2.2 与传统算法的本质区别#

1
BBR 行为：
2
  1. 慢启动：指数增长发送窗口
3
  2. 探测带宽：周期性探测最大带宽
4
  3. 丢包检测：降速（认为网络拥塞）
5
  4. 恢复：缓慢爬升
6

7
Brutal 行为：
8
  1. 按目标带宽发送（固定速率）
9
  2. 实时测算丢包率
10
  3. 丢包 → 增加发送速率（补偿）
11
  4. 持续维持目标速率

2.3 为什么不能设得太高#

Brutal 的「过量发送」机制有一个前提：目标带宽 ≤ 实际可用带宽。

如果设得过高：

1
实际情况：链路最大可用带宽 = 100 Mbps
2
错误配置：B_target = 500 Mbps
3
结果：
4
  - 发送速率 = 500 / (1 - P_loss) ≈ 500-625 Mbps
5
  - 实际可用只有 100 Mbps
6
  - 超出部分全部被丢弃
7
  - 对端有效接收 << 100 Mbps（因为大量重传包也挤占了带宽）
8
  - 延迟飙升（bufferbloat）

正确做法：用 Speedtest 或 iperf3 测出实际国际出口带宽，乘以 0.8-0.9 作为 up / down 值。

2.4 带宽协商流程（服务端 vs 客户端）#

Hysteria2 的带宽协商是一个容易混淆的点：

1
决策树：
2

3
服务端配置了 bandwidth？
4
  ├─ 是 → 服务端强制使用 Brutal，客户端带宽设置被忽略
5
  │         （服务端 ignoreClientBandwidth 默认 false，即不忽略客户端）
6
  └─ 否 → 以客户端设置的带宽为准
7

8
两端都没配置 bandwidth？
9
  └─ 双方都使用 BBR 拥塞控制（非 Brutal）

推荐配置策略：

场景	服务端 bandwidth	客户端 bandwidth	说明
自用节点	不配置	配置（按实际带宽）	灵活，客户端控制
多人共享	配置（限速）	可选	服务端强制限速
VPS 带宽有限	配置（≤VPS 带宽）	不配置	防止跑满 VPS

三、QUIC 底层参数调优#

3.1 流控窗口（Flow Control）#

Hysteria2 的 QUIC 层有两个关键的接收窗口参数：

1
quic:
2
  initStreamReceiveWindow: 8388608    # 8 MB，单流初始接收窗口
3
  maxStreamReceiveWindow: 8388608     # 8 MB，单流最大接收窗口
4
  initConnReceiveWindow: 20971520     # 20 MB，连接级初始接收窗口
5
  maxConnReceiveWindow: 20971520      # 20 MB，连接级最大接收窗口

这些参数控制什么？

接收窗口决定了「在不等待确认的情况下，最多能发送多少数据」。

窗口太小 → 高速网络下发送端频繁等待确认，带宽利用率低
窗口太大 → 高丢包环境下，大量在途数据需要重传，浪费带宽

调优建议：

网络环境	流窗口	连接窗口	说明
低延迟（<50ms）+ 高带宽（>500Mbps）	16 MB	40 MB	避免窗口成为瓶颈
普通跨境（100-200ms）+ 中带宽	8 MB	20 MB	默认值，适合大多数场景
高延迟（>300ms）+ 低带宽（<50Mbps）	4 MB	10 MB	减少在途数据量

⚠️ 修改这些参数需要重启服务，且两端都要改。大多数用户不需要动。

3.2 maxIdleTimeout：连接保活#

1
quic:
2
  maxIdleTimeout: 30s

这个参数决定：「当连接上没有数据传输时，多久后断开」。

设置太短 → 频繁断连重连，浏览体验差
设置太长 → 大量空闲连接占用服务端资源

推荐值：

使用场景	maxIdleTimeout
手机移动网络（频繁切换）	60s
桌面浏览器	30s（默认）
服务器间隧道	120s

3.3 disablePathMTUDiscovery#

1
quic:
2
  disablePathMTUDiscovery: false  # 默认 false（开启）

MTU 发现允许 QUIC 自动探测路径最大传输单元，避免 IP 分片。

除非遇到兼容性问题，否则保持默认（开启）。某些老旧路由器对大型 UDP 包处理不当，此时可尝试设为 true。

四、Realm 模式：无公网 IP 也能跑服务端（2026 新特性）#

4.1 什么是 Realm？#

传统 Hysteria2 部署要求：服务端必须有公网 IP + 开放 UDP 端口。

Realm 模式打破了这个限制。它让 Hysteria2 服务端可以运行在：

家庭宽带（NAT 后面，无公网 IP）
手机热点
公司内网
无公网 IP 的廉价 VPS（LXC 容器）

核心机制：通过牵手（Rendezvous）服务器帮助客户端和服务端进行 UDP 打洞，打洞成功后流量直连，不经过牵手服务器。

1
传统模式：
2
客户端 → [互联网] → 服务端（需要公网 IP）
3

4
Realm 模式：
5
客户端 → [牵手服务器] ←→ 服务端（NAT 后面）
6
           ↓
7
        打洞成功后：
8
客户端 ←→ 服务端（直连，不经过牵手服务器）

4.2 牵手服务器#

官方牵手服务器：realm.hy2.io（密码：public）

也可以自建牵手服务器（推荐，隐私更好）。

4.3 服务端配置（Realm 模式）#

1
# 关键：listen 改为 realm:// URI
2
listen: realm://[email protected]/my-home-server
3

4
auth:
5
  type: password
6
  password: your-strong-password
7

8
masquerade:
9
  type: proxy
10
  proxy:
11
    url: https://www.bing.com
12
    rewriteHost: true
13

14
# Realm 可选调优参数（2026 ver1.09+）
15
realm:
16
  stunServers:
17
    - stun.nextcloud.com:3478
18
    - global.stun.twilio.com:3478
19
  stunTimeout: 5s
20
  punchTimeout: 5s
21
  heartbeatInterval: 30s
22
  insecure: false
23
  ipMode: dual               # dual / ipv4 / ipv6
24
  portMapping:
25
    enabled: true            # UPnP/NAT-PMP 自动端口映射（2026 新功能）
26
    timeout: 30s
27
    lifetime: 10m

4.4 客户端配置（Realm 模式）#

1
{
2
  "type": "hysteria2",
3
  "server": "realm://[email protected]/my-home-server",
4
  "password": "your-strong-password",
5
  "tls": {
6
    "enabled": true,
7
    "server_name": "my-home-server"  // 可自定义，用于 TLS SNI
8
  }
9
}

4.5 Realm + WARP：隐藏真实 IP（进阶玩法）#

这是 2026 年最具创新性的用法之一：

原理：

服务端安装 Cloudflare WARP（WireGuard 协议）
WARP 为服务端分配一个 Cloudflare 边缘网络的 IP
Realm 使用 WARP IP 进行打洞
客户端实际连接到 Cloudflare 边缘节点

效果：

服务端真实 IP 被隐藏（客户端只知道 Cloudflare IP）
变相在 Cloudflare CDN 上运行 Hysteria2
对抗服务端 IP 被封的概率大幅降低

前提条件：VPS 需支持 WireGuard 内核模块。

五、OBFS 混淆：2026 年的对抗升级#

5.1 为什么需要 OBFS？#

Hysteria2 的流量在默认情况下伪装成 HTTP/3——这对被动 DPI（深度包检测）是有效的。

但主动探测可以发一个 HTTP/3 请求到你的服务器端口，如果返回的是正常网站内容，那就是代理服务器。

OBFS 混淆通过以下方式对抗检测：

OBFS 类型	原理	抗检测效果	CPU 开销
无（默认）	标准 HTTP/3 握手	★★☆☆	无
salamander	所有包内容加密为随机字节	★★★☆	低（+20-30% CPU）
gecko（实验性，2026）	salamander + 握手包分片随机化	★★★★	中（+40-50% CPU）

5.2 salamander 配置#

1
# 服务端
2
obfs:
3
  type: salamander
4
  salamander:
5
    password: your-obfs-password-here
6

7
# 客户端（sing-box）
8
"obfs": {
9
  "type": "salamander",
10
  "password": "your-obfs-password-here"
11
}
12

13
# 客户端（Clash Meta）
14
obfs: salamander
15
obfs-password: your-obfs-password-here

💡 服务端和客户端 OBFS 密码必须相同，否则握手失败。

5.3 gecko 配置（推荐 2026 墙内使用）#

gecko 在 salamander 基础上，额外将 QUIC 握手包拆分为多个大小随机的分片：

1
# 服务端
2
obfs:
3
  type: gecko
4
  gecko:
5
    password: your-obfs-password-here
6
    minPacketSize: 512    # 分片最小字节数
7
    maxPacketSize: 1200   # 分片最大字节数（必须 ≥ minPacketSize 且 ≤ 2048）

效果：

DPI 看到的 UDP 流量包大小完全随机
无法通过分析包长特征识别 Hysteria2 流量
对抗主动探测的能力显著增强

代价：

握手阶段延迟增加（分片 + 重组）
CPU 开销比 salamander 更高

5.4 OBFS 选择建议#

网络环境	推荐 OBFS	原因
墙外 VPS	无	性能最优，HTTP/3 伪装已足够
墙内，UDP 未限速	salamander	平衡安全性和性能
墙内，UDP 疑似限速	gecko	最强抗检测，牺牲部分性能
移动网络（4G/5G）	salamander	移动网络 DPI 相对宽松

六、端口跳跃（Port Hopping）：防端口级封锁#

6.1 工作原理#

GFW 可以通过「端口指纹」识别代理流量，然后封锁该端口。

端口跳跃让服务端监听一个端口范围（如 20000-30000，共 10001 个端口），客户端每 30 秒随机切换一个端口。GFW 难以全部封锁。

1
服务端：监听 20000-30000/udp（通过 iptables/nftables 重定向到主端口）
2
客户端：每 30 秒在 20000-30000 范围内随机选一个端口发包

6.2 服务端配置#

1
listen: :20000-30000   # 监听 10001 个 UDP 端口

前置要求：

Linux 系统
已安装 nftables 或 iptables
Hysteria2 以 root 或 CAP_NET_ADMIN 权限运行
VPS 防火墙放行整个 UDP 端口范围

1
# 防火墙放行示例（20000-30000 UDP）
2
ufw allow 20000:30000/udp
3
# 或使用 iptables 直接配置
4
iptables -A INPUT -p udp --dport 20000:30000 -j ACCEPT

6.3 客户端配置#

sing-box：

1
{
2
  "server_ports": "20000:30000",
3
  "password": "your-password"
4
}

Clash Meta：

1
proxies:
2
  - name: "hysteria2-port-hopping"
3
    type: hysteria2
4
    server: your-domain.com
5
    port: 443              # 初始端口（会被 server_ports 覆盖）
6
    server_ports: "20000:30000"
7
    password: your-password

6.4 端口跳跃 + OBFS 组合#

这是 2026 年推荐的最强抗封锁配置：

1
# 服务端
2
listen: :20000-50000
3
obfs:
4
  type: gecko
5
  gecko:
6
    password: your-obfs-password
7
    minPacketSize: 512
8
    maxPacketSize: 1200

端口跳跃 → 防端口级封锁
gecko OBFS → 防流量特征识别
组合使用 → GFW 难以同时对抗

七、2026 年中国运营商 UDP 限速现状与对抗#

7.1 三大运营商 UDP 限速情况（2026 Q2）#

运营商	UDP 限速策略	影响程度	应对方案
电信	国际出口 UDP 限速至 1-2 Mbps（部分地区）	严重	OBFS + 端口跳跃，或切换 TCP 方案
联通	相对宽松，国际 UDP 限速不明显	轻微	正常使用 Hysteria2
移动	部分地区国际 UDP 完全阻断	严重	必须切换 VLESS+Reality
教育网	对 UDP 流量 QoS 较严重	中等	端口跳跃 + 降低 obfs 开销

7.2 检测 UDP 是否被限速#

1
# 在服务端跑 iperf3 UDP 测试
2
# 服务端：
3
iperf3 -s
4

5
# 客户端：
6
iperf3 -c your-server.com -u -b 100M -t 30
7
# 观察 UDP 实际吞吐量，如果远低于 TCP，说明被限速

7.3 对抗策略#

策略一：降低 UDP 包发送速率

1
# 调低 up/down，让 UDP 流量看起来不那么「激进」
2
bandwidth:
3
  up: 30 mbps    # 原本可能设 100 mbps
4
  down: 50 mbps

策略二：开启 OBFS

OBFS 不改变 UDP 流量的网络层特征，但能让 DPI 无法识别为代理流量，降低被针对性限速的概率。

策略三：端口跳跃

某些运营商按「目的端口」进行 QoS。端口跳跃让流量分散到多个端口，降低单一端口被限速的概率。

策略四：终极方案——切回 TCP

如果 UDP 限速严重且无法避开，Hysteria2 不适合当前网络环境。切换到 VLESS+Reality 或 Trojan。

八、全平台客户端配置详解#

8.1 sing-box（推荐，功能最完整）#

1
{
2
  "outbounds": [
3
    {
4
      "type": "hysteria2",
5
      "tag": "hy2-main",
6
      "server": "your-domain.com",
7
      "server_port": 443,
8
      "password": "your-password",
9
      "obfs": {
10
        "type": "salamander",
11
        "password": "your-obfs-password"
12
      },
13
      "tls": {
14
        "enabled": true,
15
        "server_name": "your-domain.com",
16
        "insecure": false
17
      },
18
      "up_mbps": 50,
19
      "down_mbps": 200,
20
      "lazy": false
21
    }
22
  ]
23
}

关键字段说明：

字段	说明
`up_mbps`	客户端上传速度（= 服务端下载速度）
`down_mbps`	客户端下载速度（= 服务端上传速度）
`lazy: false`	2026 新默认，启动即建连（改为 true 则首次请求才建连）
`obfs`	必须与服务端配置匹配

6.2 Clash Meta（mihomo，最流行）#

1
proxies:
2
  - name: "hysteria2-jp"
3
    type: hysteria2
4
    server: your-domain.com
5
    port: 443
6
    password: your-password
7
    up: "50 Mbps"
8
    down: "200 Mbps"
9
    obfs: salamander
10
    obfs-password: your-obfs-password
11
    sni: your-domain.com
12
    # skip-cert-verify: false  # 生产环境必须为 false
13

14
  - name: "hysteria2-port-hopping"
15
    type: hysteria2
16
    server: your-domain.com
17
    port: 443
18
    server_ports: "20000:50000"   # 端口跳跃
19
    password: your-password
20
    up: "50 Mbps"
21
    down: "200 Mbps"

8.3 Shadowrocket（iOS，最方便）#

图形界面配置步骤：

点击右上角「+」→ 选择「Hysteria2」
填写：
- Server：服务器域名或 IP
- Port：端口（或端口范围 20000-50000）
- Password：认证密码
- OBFS Password：如果服务端开启了 OBFS
- Up / Down：带宽设置（单位 Mbps）
- SNI：TLS SNI（通常是域名）
保存后点击测试

8.4 Hysteria2 官方客户端（最简单）#

1
server: your-domain.com:443
2
auth: your-password
3

4
bandwidth:
5
  up: 50 mbps
6
  down: 200 mbps
7

8
obfs:
9
  type: salamander
10
  salamander:
11
    password: your-obfs-password
12

13
socks5:
14
  listen: 127.0.0.1:1080
15

16
http:
17
  listen: 127.0.0.1:8080
18

19
# TUN 模式（需要 root / 管理员权限）
20
tun:
21
  enabled: true
22
  device: tun0
23
  auto_route: true

九、ACL 高级用法：精细化流量控制#

9.1 为什么需要 ACL？#

默认情况下，Hysteria2 服务端转发所有客户端请求。但实际应用中，你可能需要：

禁止访问某些网站（如 P2P 下载，节省流量）
国内域名直连（不走代理）
特定网站走特定出口（如 Netflix 走美国住宅 IP）

9.2 内联 ACL 规则#

1
acl:
2
  inline:
3
    # 国内 GeoIP 直连（不走代理）
4
    - reject(geoip:cn)
5

6
    # 屏蔽 P2P
7
    - reject(suffix:torrent.com)
8
    - reject(keyword:bt)
9

10
    # Netflix 走专用出口
11
    - proxy(geosite:netflix, outbound:netflix-proxy)
12

13
    # 默认放行
14
    - allow(all)

9.3 出站规则（Outbounds）配合 ACL#

1
outbounds:
2
  - name: default      # 第一个是默认出站
3
    type: direct
4

5
  - name: netflix-proxy
6
    type: socks5
7
    socks5:
8
      addr: us-residential-proxy.com:1080
9
      username: user
10
      password: pass
11

12
  - name: china-direct
13
    type: direct
14
    direct:
15
      mode: 4        # 仅 IPv4

9.4 GeoIP / GeoSite 数据库#

Hysteria2 使用 v2ray 格式的 GeoIP / GeoSite 数据库：

1
acl:
2
  inline:
3
    - reject(geoip:cn)
4
    - reject(geosite:netflix)
5
  # 自动下载最新数据库（取消注释以自定义路径）
6
  # geoip: /path/to/geoip.dat
7
  # geosite: /path/to/geosite.dat
8
  # geoUpdateInterval: 168h   # 每周更新

十、性能调优实战：从参数到硬件#

10.1 带宽参数调优步骤#

第一步：测速

1
# 在服务端跑 iperf3 测国际带宽
2
# 服务端：
3
iperf3 -s
4

5
# 本地（需要能连到服务端的机器）：
6
iperf3 -c your-server.com -p 5201 -t 30

第二步：计算 80-90% 值

1
实测国际带宽：120 Mbps
2
设置值：120 × 0.85 ≈ 100 Mbps

第三步：分方向配置

1
# 服务端（限制每个客户端的最大速度）
2
bandwidth:
3
  up: 100 mbps    # 服务端 → 客户端（客户端下载）
4
  down: 50 mbps   # 客户端 → 服务端（客户端上传）

10.2 服务端硬件选型#

QUIC 在用户态执行加密计算，对 CPU 要求比 TLS/TCP 方案更高：

并发用户数	推荐 CPU	推荐内存	开启 OBFS 后
1-5	1 vCPU	1 GB	+20% CPU
10-20	2 vCPU	2 GB	+30% CPU
50+	4 vCPU	4 GB	+50% CPU

⚠️ ARM 架构（如 Oracle Cloud ARM）的 QUIC 性能明显优于 x86，同等预算下优先选 ARM。

10.3 协议嗅探（Sniff）调优#

协议嗅探能让服务端从流量中提取真实域名，配合 ACL 做域名级路由：

1
sniff:
2
  enable: true
3
  timeout: 2s
4
  rewriteDomain: false
5
  tcpPorts: 80,443
6
  udpPorts: all

注意事项：

嗅探有轻微性能开销（约 1-2% CPU）
rewriteDomain: true 会修改请求中的域名（某些场景会出问题）
如果 ACL 里没有域名规则，可以关闭嗅探以提升性能

十一、Hysteria2 vs TUIC v5：2026 年 QUIC 协议对决#

11.1 协议对比#

维度	Hysteria2	TUIC v5
拥塞控制	Brutal（固定速率）	BBR（标准 QUIC）
高丢包表现	极好（Brutal 专为丢包设计）	好（BBR 也能适应）
协议伪装	HTTP/3	QUIC（标准）
OBFS 支持	salamander / gecko	无（依赖外部工具）
端口跳跃	原生支持	需外部工具
客户端支持	Clash Meta / sing-box / SR / v2rayN	sing-box / TUIC 官方客户端
开发活跃度	活跃（apernet 维护）	中等
适合场景	速度优先，恶劣网络	平衡，标准 QUIC

11.2 2026 年实测：GFW 对 QUIC 的对抗#

根据多个来源的实测数据（2026 Q2）：

Hysteria2 + gecko OBFS：在国内大部分地区可稳定使用 30+ 天
TUIC v5（无 OBFS）：部分地区 7-14 天内被针对性限速
标准 QUIC（无伪装）：平均 3-7 天内被识别

结论：2026 年使用 QUIC 协议，必须配合 OBFS 混淆（Hysteria2 的 gecko 是当前最佳选择）。

十二、常见问题诊断#

问题一：速度不如预期#

排查步骤：

检查 up / down 是否设置过低
用 iperf3 测实际国际带宽，对比 Hysteria2 速度
检查是否开启 OBFS（CPU 瓶颈会导致速度下降）
用 tcpdump 抓包，确认是否是 UDP 被限速

1
# 服务端抓 UDP 包，看是否有丢包
2
tcpdump -i eth0 udp port 443 -vv

问题二：连接频繁断开#

可能原因：

原因	排查方法	解决方案
NAT 超时	检查 `maxIdleTimeout`	增大到 60s
UDP 被运营商阻断	用 TCP 方案对比测试	切换 VLESS+Reality
端口被封	换端口测试	开启端口跳跃
OBFS 密码不匹配	检查服务端和客户端配置	确认为相同密码

问题三：iOS Shadowrocket 连接成功但无流量#

常见原因：

up / down 未设置或设置过低（Shadowrocket 不会自动测算）
TLS SNI 配置错误
服务端证书问题（尝试开启 skip-cert-verify 排查）

总结：进阶调优检查清单#

把以下清单保存为书签，部署 Hysteria2 时逐项核对：

up / down 设置为实际带宽的 80-90%
服务端开启 ACME 自动证书（或手动配置有效证书）
墙内使用开启 OBFS（推荐 gecko）
开启端口跳跃（防端口级封锁）
ACL 配置国内 GeoIP 直连规则
maxIdleTimeout 根据使用场景调整
用 sing-box 或 Clash Meta 最新版（支持所有新特性）
如果是 NAT 后面，使用 Realm 模式
定期更新 Hysteria2 到最新版（bash <(curl -fsSL https://get.hy2.sh/)）

一句话总结：Hysteria2 的速度优势来自 Brutal 算法，但要把速度真正发挥出来，需要正确的带宽设置 + 对抗 UDP 限速的策略 + 最新的 OBFS 混淆。三者缺一不可。

进阶调优系列持续更新。下期预告：VLESS+Reality 终极伪装指南——把代理流量伪装成普通 HTTPS 浏览。