2026 新一代抗封锁协议实战：Hysteria 2 与 TUIC v5 架构原理、弱网提速与自建/机场选型

1.1 从 TCP 到 UDP：QUIC 如何重塑抗封锁传输层#

传统 TCP+TLS 代理的握手过程暴露了多层可识别特征。TCP 三次握手阶段，SYN 包的窗口大小、MSS、TCP 选项（如 SACK、Timestamps、Window Scaling）组合形成了操作系统指纹；TLS 握手阶段，ClientHello 中的 JA3 指纹（包含 TLS 版本、加密套件列表、扩展字段顺序、椭圆曲线参数）可被中间盒精确匹配。即便使用 uTLS 伪造指纹，TLS Record 层的分片模式与时序特征仍可作为辅助判定依据。更关键的是，TCP 的可靠传输语义意味着中间盒可以通过注入 RST、限速 ACK 或丢弃特定序列号区间来实现精确干扰，而代理端难以区分“网络拥塞丢包”与“策略性丢包”。

QUIC 将传输层语义从内核态迁移到用户态，在 UDP 之上重新实现了可靠传输、流控与拥塞控制。这一架构变化带来了三个对抗封锁的结构性优势：

0-RTT/1-RTT 握手与加密粒度。QUIC 将 TLS 1.3 握手嵌入传输层，首个 Initial 包即携带加密的 ClientHello。与 TCP+TLS 不同，QUIC 的握手包除少数明文字段（版本号、连接 ID、包序号）外全部加密。中间盒无法直接读取 SNI（除非启用 ECH 且中间盒不支持），也无法通过 TLS Record 层特征进行指纹匹配。0-RTT 模式下，客户端利用缓存的会话票据在首个飞行包中发送应用数据，握手延迟降至 0 个 RTT——这对高丢包链路意味着连接建立成功率的显著提升。

多路复用消除队头阻塞。TCP 层的有序字节流语义导致单个丢包会阻塞后续所有数据（队头阻塞，HOL Blocking）。QUIC 的 Stream 机制允许各流独立重传，单个流的丢包不影响其他流的数据交付。在晚高峰 QoS 场景下，运营商常采用随机丢包策略（丢包率 1%–5%），QUIC 的多路复用可将有效吞吐衰减从 TCP 的指数级降至线性级。

前向纠错与包级恢复。QUIC 支持 FEC（前向纠错）扩展，发送端在原始数据包之外生成冗余校验包。接收端在丢包数量不超过冗余包容量时，无需重传即可恢复丢失数据。Hysteria 2 在此基础上实现了可调参数的 FEC 机制，允许用户根据链路丢包率动态调整冗余比例（详见 1.2 节）。

拥塞控制差异。Hysteria 2 采用 Brutal 拥塞控制算法，其核心逻辑是：当发送速率低于用户配置的带宽上限时，不因丢包而降低发送速率，仅当实际吞吐持续低于配置值时才进行探测性调整。这实质上是一种“带宽优先”策略，牺牲公平性换取弱网吞吐。TUIC v5 则基于 BBR/BBR2 变种，通过测量瓶颈带宽与最小 RTT 来估计发送窗口，在丢包环境下保持相对保守的速率调整。两者在晚高峰 QoS 限速下的表现差异显著：Brutal 倾向于“硬扛”限速，BBR 变种则更适应动态带宽波动。

1.2 Hysteria 2 架构拆解：暴力发包、FEC 与 Salamander 混淆#

Hysteria 2 的数据包封装格式在 QUIC 之上叠加了自定义头部。每个 UDP 载荷包含：QUIC 包头（连接 ID、包序号、加密载荷）以及可选的 Salamander 混淆层。Salamander 是 Hysteria 2 内置的混淆方案，通过对每个数据包执行 XOR 运算并附加随机填充，使流量特征偏离标准 QUIC 格式。其混淆密钥由服务端与客户端预共享，中间盒无法通过 QUIC 版本号或包长分布进行识别。

带宽探测机制方面，Hysteria 2 在连接建立后执行主动探测：客户端以配置的 up_mbps 和 down_mbps 为上限，逐步提升发送速率直至观测到丢包或 RTT 激增。Brutal 拥塞控制的核心参数包括：

• bandwidth_up / bandwidth_down：用户声明的上下行带宽上限
• ignore_client_bandwidth：服务端是否忽略客户端声明的带宽值
• disable_loss_recovery：是否禁用丢包恢复逻辑

FEC 参数调优是 Hysteria 2 在弱网环境下的关键配置。fec 字段支持 { mode: "rs", data: N, parity: M } 格式，其中 N 为原始数据包数量，M 为冗余包数量。例如 data: 10, parity: 3 表示每 10 个数据包生成 3 个冗余包，可容忍约 23% 的丢包率。在移动 5G 晚高峰场景下，建议 parity 比例设置在 20%–30% 之间；在光纤宽带直连场景下可降至 10% 以下。

与 Shadowsocks/Vmess/Trojan 的吞吐量对比需考虑 QoS 限速维度。在运营商对 UDP 流量实施限速（如 100Mbps 端口限速）的场景下：

数据来源为三网 5G 与千兆宽带混合测试环境，服务端为境外 VPS（AMD EPYC，1Gbps 端口），客户端分别为移动 5G、联通 5G、电信宽带。测试时间为晚高峰 20<00>–22<00>。

1.3 TUIC v5 协议精讲：0-RTT 握手、多路复用与 UDP 中继优化#

TUIC v5 由 V2Ray 社区衍生项目开发，其协议设计强调与 QUIC 标准的兼容性。与 Hysteria 2 不同，TUIC v5 不修改 QUIC 的拥塞控制逻辑，而是通过配置 BBR/BBR2 变种来适应弱网环境。TUIC 的 0-RTT 握手流程如下：

1. 客户端缓存服务端下发的 Session Ticket（包含加密密钥与连接参数）
2. 后续连接首个飞行包携带 0-RTT 数据，服务端验证 Ticket 后直接解密应用数据
3. 服务端在 0-RTT 响应中更新 Ticket，完成密钥轮换

多路复用方面，TUIC v5 在单个 QUIC 连接内支持多个双向流（Bidirectional Stream）。每个流对应一个 TCP 连接或 UDP 会话。流控采用 QUIC 标准的连接级与流级窗口机制，窗口大小可配置。在 UDP 中继场景下（如代理 DNS 查询或游戏流量），TUIC v5 将 UDP 数据包封装为 QUIC 数据报（Datagram），避免流控开销。

拥塞控制算法在弱网下的表现差异显著。BBR 通过测量瓶颈带宽与最小 RTT 来估计发送速率，其核心状态机包括 Startup、Drain、ProbeBW、ProbeRTT。BBR2 在此基础上增加了对丢包的显式响应（类似 CUBIC 的丢包退避），在随机丢包率 1%–5% 的环境中，BBR2 的吞吐稳定性优于 BBR v1。TUIC v5 允许在服务端配置 congestion_control: "bbr" 或 "bbr2"，部分实现还支持 "cubic"。

三网运营商丢包补救实测数据如下（测试条件：服务端境外 VPS，客户端三网 5G，测试时长 10 分钟，取平均值）：

延迟抖动方面，Hysteria 2 的 Brutal 拥塞控制在丢包突发时倾向于维持发送速率，导致抖动略高；TUIC v5 的 BBR 变种在检测到 RTT 上升时会主动降速，抖动更低但吞吐恢复较慢。在 4K 视频流场景下（需稳定 25Mbps 以上），两者均可满足，但 Hysteria 2 在丢包率超过 5% 时仍能维持 50Mbps 以上吞吐，TUIC v5 则可能降至 30–40Mbps。

2.1 全维度性能对比矩阵#

以下矩阵基于真实测试环境构建，测试节点为境外 VPS（AMD EPYC 7443P，1Gbps 端口，IPv4+IPv6），客户端覆盖移动/联通/电信 5G 与千兆宽带。所有测试均在晚高峰 20<00>–22<00> 执行，每项指标取 10 次测试的中位数。

数据解读：Hysteria 2 在弱网吞吐与抗 QoS 能力上领先，代价是 CPU 占用略高（Brutal 拥塞控制与 FEC 计算开销）。TUIC v5 在延迟与 CPU 效率上更优，适合对延迟敏感的场景（如游戏、视频会议）。传统 TCP 协议在晚高峰 QoS 限速下吞吐衰减严重，但在 IP 纯净度高、无 QoS 策略的链路上仍可提供稳定服务。

2.2 自建服务器 vs 机场专线：成本、纯净度与风控权衡#

自建 VPS 的核心优势在于 IP 纯净度可控与配置自由度高。IP 纯净度检测需关注以下指标：

• 黑名单查询：通过 Spamhaus、AbuseIPDB、IP2Location 等数据库检查 IP 是否被标记为代理/VPN/恶意软件来源
• 双 ISP 住宅 IP：部分 VPS 提供商（如丽萨主机、RFCHost）提供住宅 IP 段，其 ASN 归属为 ISP 而非数据中心，抗封锁能力显著优于机房 IP
• 反向 DNS 与 WHOIS：检查 PTR 记录是否指向已知代理服务商域名，WHOIS 注册信息是否与数据中心关联

机场专线（IEPL/IPLC）通过专线链路绕过公网 QoS 策略，其延迟与丢包表现优于直连。以 jichangpro.co 的选型逻辑为例，其推荐框架包含：

1. 链路类型：IEPL（国际以太网专线）提供点对点专线，延迟稳定在 30–50ms（视地理位置）；IPLC（国际私有租用线路）成本更高但抖动更低
2. 入口节点：国内 BGP 入口（移动/联通/电信多线）与境外出口的配对质量
3. 带宽冗余：专线带宽通常为 100Mbps–1Gbps 共享，需关注超售比例
4. 风控策略：机场是否提供 IP 轮换、端口跳跃、协议混淆等抗封锁功能

成本对比：自建 VPS（住宅 IP）月均 $10–$30，机场专线月均 $5–$20（共享带宽）。自建适合技术能力强、对 IP 纯净度有要求的用户；机场适合追求即开即用、无需维护的用户。风控权衡上，自建 IP 若被封锁需更换 IP（部分 VPS 提供商支持免费换 IP），机场则通过多节点冗余分散风险。

2.3 客户端兼容性与生态#

当前主流客户端对 Hysteria 2 与 TUIC v5 的支持程度如下：

移动端省电与连接保持策略：QUIC 的 0-RTT 与连接迁移特性允许客户端在切换网络（Wi-Fi ↔ 5G）时保持连接，减少重连开销。Shadowrocket 需开启 QUIC 连接保持 选项，并将 UDP 超时 设置为 300 秒以上。Sing-box 在移动端建议启用 tcp_fast_open 与 udp_fragment，同时调整 multiplex 参数以平衡省电与性能。

3.1 服务端部署：Hysteria 2 与 TUIC v5 完整配置片段#

1
# UDP 收发缓冲区上限，Hysteria 2 高带宽场景建议 16MB 起步
2
net.core.rmem_max = 16777216
3
net.core.wmem_max = 16777216
4
net.core.rmem_default = 262144
5
net.core.wmem_default = 262144
6
# QUIC 单连接高并发下需要更大的 backlog
7
net.core.netdev_max_backlog = 16384
8
net.core.somaxconn = 8192
9
# BBR 加速（TUIC 的拥塞控制依赖内核 BBR 作为参考基准）
10
net.ipv4.tcp_congestion_control = bbr
11
net.core.default_qdisc = fq
12
# 扩大本地端口范围，避免 NAT 表打满
13
net.ipv4.ip_local_port_range = 1024 65535
14
# 连接跟踪表扩容，UDP 会话多时防止丢包
15
net.netfilter.nf_conntrack_max = 262144

1
listen: :443
2

3
# ACME 自动证书（推荐，避免手动续签）
4
acme:
5
  domains:
6
    - your.domain.com
7
  email: you@example.com
8
  # 使用 DNS 挑战可避免 80 端口暴露，推荐 Cloudflare
9
  type: dns
10
  dns:
11
    name: cloudflare
12
    config:
13
      cloudflare_api_token: "YOUR_CF_TOKEN"
14

15
# 若使用自有证书，改为：
16
# tls:
17
#   cert: /etc/hysteria/cert.pem
18
#   key: /etc/hysteria/key.pem
19

20
# 带宽声明：这是 Brutal 拥塞控制的核心参数
21
# 上行/下行填服务器实际带宽的 80%~90%，填太高会触发运营商 QoS
22
bandwidth:
23
  up: 500 mbps
24
  down: 1000 mbps
25

26
# Salamander 混淆：将 QUIC 包载荷加密，对抗 DPI 特征识别
27
obfs:
28
  type: salamander
29
  salamander:
30
    password: "YourObfsPassword_ChangeMe"
31

32
# 认证方式：推荐 http 外部认证或 userpass
33
auth:
34
  type: userpass
35
  userpass:
36
    user1: "StrongPassword123"
37
    user2: "AnotherPassword456"
38

39
# QUIC 参数调优
40
quic:
41
  initStreamReceiveWindow: 8388608      # 8MB 单流接收窗口
42
  maxStreamReceiveWindow: 8388608
43
  initConnReceiveWindow: 20971520       # 20MB 连接级接收窗口
44
  maxConnReceiveWindow: 20971520
45
  maxIdleTimeout: 30s                   # 空闲超时，移动端建议 30s
46
  keepAlivePeriod: 10s                  # 保活周期，对抗 NAT 超时
47
  disablePathMTUDiscovery: false        # 保持开启，自动探测最优 MTU
48

49
# 伪装站点：未认证请求返回一个正常网页，降低主动探测风险
50
masquerade:
51
  type: proxy
52
  proxy:
53
    url: https://news.ycombinator.com/
54
    rewriteHost: true
55

56
# ACL 与日志
57
acl:
58
  inline:
59
    - reject(geoip:cn)   # 按需屏蔽回国流量，降低风控
60
log:
61
  level: info

1
[Unit]
2
Description=Hysteria 2 Server
3
After=network.target
4

5
[Service]
6
Type=simple
7
ExecStart=/usr/local/bin/hysteria server -c /etc/hysteria/config.yaml
8
Restart=on-failure
9
RestartSec=3
10
LimitNOFILE=1048576
11
# 提升 UDP 优先级
12
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
13

14
[Install]
15
WantedBy=multi-user.target

1
{
2
  "server": "[::]:443",
3
  "users": {
4
    "user1": "StrongPassword123",
5
    "user2": "AnotherPassword456"
6
  },
7
  "certificate": "/etc/tuic/fullchain.pem",
8
  "private_key": "/etc/tuic/privkey.pem",
9
  "congestion_control": "bbr",
10
  "alpn": ["h3", "spdy/3.1"],
11
  "udp_relay_mode": "native",
12
  "udp_over_stream": false,
13
  "zero_rtt_handshake": true,
14
  "heartbeat": "10s",
15
  "gc_interval": "10s",
16
  "gc_lifetime": "15s",
17
  "log_level": "info",
18
  "max_udp_relay_packet_size": 1500
19
}

1
# nftables 实现 20000-50000 端口范围 DNAT 到 443
2
nft add table ip hyhop
3
nft add chain ip hyhop prerouting '{ type nat hook prerouting priority -100; }'
4
nft add rule ip hyhop prerouting udp dport 20000-50000 dnat to :443
5
# 放行 UDP 443
6
nft add rule inet filter input udp dport 443 accept

3.2 客户端导入：Sing-box JSON 与 Clash Verge Rev YAML 模板#

1
{
2
  "outbounds": [
3
    {
4
      "type": "hysteria2",
5
      "tag": "hy2-out",
6
      "server": "your.domain.com",
7
      "server_port": 443,
8
      "up_mbps": 100,
9
      "down_mbps": 500,
10
      "obfs": {
11
        "type": "salamander",
12
        "password": "YourObfsPassword_ChangeMe"
13
      },
14
      "password": "StrongPassword123",
15
      "tls": {
16
        "enabled": true,
17
        "server_name": "your.domain.com",
18
        "alpn": ["h3"],
19
        "insecure": false
20
      },
21
      "brutal_debug": false,
22
      "network": "udp"
23
    },
24
    {
25
      "type": "tuic",
26
      "tag": "tuic-out",
27
      "server": "your.domain.com",
28
      "server_port": 443,
29
      "uuid": "your-uuid-v4-format",
30
      "password": "StrongPassword123",
31
      "congestion_control": "bbr",
32
      "udp_relay_mode": "native",
33
      "zero_rtt_handshake": true,
34
      "heartbeat": "10s",
35
      "tls": {
36
        "enabled": true,
37
        "server_name": "your.domain.com",
38
        "alpn": ["h3"],
39
        "insecure": false
40
      }
41
    }
42
  ]
43
}

1
mixed-port: 7890
2
allow-lan: false
3
mode: rule
4
log-level: info
5
ipv6: false
6

7
dns:
8
  enable: true
9
  listen: 0.0.0.0:5353
10
  enhanced-mode: fake-ip
11
  fake-ip-range: 198.18.0.1/16
12
  nameserver:
13
    - https://1.1.1.1/dns-query
14
    - https://8.8.8.8/dns-query
15
  fallback:
16
    - tls://1.1.1.1:853
17
  fallback-filter:
18
    geoip: true
19
    geoip-code: CN
20

21
proxies:
22
  - name: "HY2-Node"
23
    type: hysteria2
24
    server: your.domain.com
25
    port: 443
26
    password: "StrongPassword123"
27
    obfs: salamander
28
    obfs-password: "YourObfsPassword_ChangeMe"
29
    sni: your.domain.com
30
    alpn: [h3]
31
    up: "100 Mbps"
32
    down: "500 Mbps"
33
    skip-cert-verify: false
34

35
  - name: "TUIC-Node"
36
    type: tuic
37
    server: your.domain.com
38
    port: 443
39
    uuid: your-uuid-v4-format
40
    password: "StrongPassword123"
41
    congestion-controller: bbr
42
    udp-relay-mode: native
43
    sni: your.domain.com
44
    alpn: [h3]
45
    skip-cert-verify: false
46

47
proxy-groups:
48
  - name: "Auto"
49
    type: url-test
50
    proxies: ["HY2-Node", "TUIC-Node"]
51
    url: "http://www.gstatic.com/generate_204"
52
    interval: 300
53
    tolerance: 50
54

55
  - name: "Streaming"
56
    type: select
57
    proxies: ["Auto", "HY2-Node", "TUIC-Node", "DIRECT"]
58

59
rules:
60
  - GEOIP,CN,DIRECT
61
  - DOMAIN-SUFFIX,netflix.com,Streaming
62
  - DOMAIN-SUFFIX,youtube.com,Streaming
63
  - MATCH,Auto

3.3 性能调优与压力测试：iperf3、udp2raw 与真实流量模拟#

1
# 服务端启动
2
iperf3 -s -p 5201
3

4
# 客户端测试 UDP 500Mbps，持续 30 秒
5
iperf3 -c your.server.ip -p 5201 -u -b 500M -t 30 -l 1400
6

7
# 关注输出：
8
# [SUM] 0.00-30.00 sec  1.75 GBytes  501 Mbits/sec  0.023 ms  0/1250000 (0%)
9
# 丢包率 > 1% 说明链路或 QoS 有问题

1
# 服务端
2
udp2raw -s -l 0.0.0.0:4096 -r 127.0.0.1:443 --raw-mode faketcp -k "secret"
3
# 客户端
4
udp2raw -c -l 127.0.0.1:443 -r your.server.ip:4096 --raw-mode faketcp -k "secret"

4.1 晚高峰抖动与丢包：根因分析与补救措施#

案例一：UDP 丢包骤增（移动 5G 晚高峰）

现象：Hysteria 2 白天 200Mbps 稳定，晚 20<00> 后骤降至 20Mbps，iperf3 -u 显示丢包率 15%。

排查命令：

1
# 1. 确认是否运营商 QoS
2
mtr -u -P 443 -c 100 your.server.ip
3
# 观察第 3-5 跳（运营商骨干）是否出现丢包
4

5
# 2. 抓包分析 QUIC 包间隔
6
tcpdump -i eth0 -n udp port 443 -w /tmp/quic.pcap
7
# Wireshark 打开，过滤 quic，查看 packet loss 与 retransmission
8

9
# 3. 检查 conntrack 是否溢出
10
conntrack -C
11
dmesg | grep "nf_conntrack: table full"

根因：运营商对 UDP 443 大流量识别为 QUIC 视频流并限速。补救：

• 启用端口跳跃 20000-50000，绕过端口级 QoS。
• 将 Salamander 混淆密码更换，避免特征被学习。
• FEC 参数动态调整：Hysteria 2 的 quic.initStreamReceiveWindow 从 8MB 降至 4MB，减少突发。

案例二：TLS 握手超时被主动探测

现象：服务运行 3 天后突然所有客户端无法连接，openssl s_client -connect your.domain.com:443 超时。

排查：

1
# 服务端抓包
2
tcpdump -i eth0 -n 'tcp port 443 or udp port 443' -w /tmp/probe.pcap
3
# 分析是否有大量来自同一 IP 段的 ClientHello 但无后续

根因：GFW 主动探测，向 443 发送 TLS ClientHello 后观察响应。Hysteria 2 若未配置 masquerade，会直接返回 QUIC 拒绝包，暴露协议特征。

补救：

• 必须配置 masquerade，未认证请求返回真实 HTTPS 站点。
• 使用真实域名 + 有效证书，SNI 与证书 CN 一致。
• 更换 IP（多数 VPS 商家支持）。

案例三：DNS 泄漏触发风控

现象：客户端连接正常但速度极慢，且服务端日志出现大量来自同一客户端的异常域名查询。

排查：

1
# 客户端侧
2
dig @1.1.1.1 whoami.cloudflare.com
3
# 检查是否走了代理 DNS
4
curl https://1.1.1.1/cdn-cgi/trace | grep warp
5
# 使用 dnsleaktest.com 或 browserleaks.com/dns

根因：Clash 的 fake-ip 模式未正确配置 nameserver，导致 DNS 查询走本地 ISP，暴露真实 IP 与访问意图。

补救：

• Clash Verge Rev 中开启 dns.enable: true，enhanced-mode: fake-ip。
• nameserver 必须为 DoH/DoT，禁止使用 114.114.114.114 等国内 DNS。
• 服务端日志监控：journalctl -u hysteria-server | grep -i "dns"。

4.2 证书探测、DNS 泄漏与 IP 纯净度检测#

TLS 证书指纹与 SNI 白名单

Hysteria 2 与 TUIC v5 的 TLS 握手必须使用真实证书。推荐使用 Let’s Encrypt + Cloudflare DNS 挑战，证书指纹与主流站点一致。避免自签证书，insecure: true 会直接暴露。

SNI 白名单策略：服务端配置 masquerade 指向一个真实存在的 HTTPS 站点（如 news.ycombinator.com），使探测者看到正常的 TLS 响应。

DNS 泄漏测试

1
# 使用 dnsleaktest.com 的 API
2
curl -s https://www.dnsleaktest.com/ | grep -oP 'Your IP.*?<'
3
# 或使用 ipleak.net
4
curl -s https://ipleak.net/json/ | jq '.dns_servers'

双 ISP 住宅 IP 纯净度检测脚本

1
#!/bin/bash
2
IP=$1
3
echo "=== 检查 IP: $IP ==="
4
# 1. 黑名单查询
5
curl -s "https://api.abuseipdb.com/api/v2/check?ipAddress=$IP" \
6
  -H "Key: YOUR_API_KEY" -H "Accept: application/json" | jq '.data.abuseConfidenceScore'
7
# 2. 反向 DNS
8
dig -x $IP +short
9
# 3. ASN 归属
10
curl -s "https://ipinfo.io/$IP/json" | jq '{org, country, city}'
11
# 4. 是否被标记为数据中心
12
curl -s "https://ipapi.co/$IP/json/" | jq '.org'

纯净 IP 特征：ASN 归属为住宅 ISP（如 Comcast、Verizon、中国电信家宽），反向 DNS 可解析，AbuseIPDB 评分 < 10。

4.3 风控规避：流量特征伪装与协议混淆进阶#

Salamander 混淆与 QUIC 伪装成 HTTP/3

Salamander 通过 XOR + 密钥流对 QUIC 载荷加密，使 DPI 无法识别标准 QUIC 特征。进阶做法是将 Hysteria 2 的 ALPN 设置为 h3，并在 masquerade 中返回真实的 HTTP/3 响应头，使流量在被动观测下与正常 HTTP/3 无异。

1
# Hysteria 2 进阶伪装
2
tls:
3
  alpn: ["h3"]
4
masquerade:
5
  type: proxy
6
  proxy:
7
    url: https://www.cloudflare.com/
8
    rewriteHost: true
9
    # 返回真实 Cloudflare 响应头
10
    statusCode: 200
11
    headers:
12
      server: "cloudflare"
13
      content-type: "text/html"

避免大规模扫描与异常连接频率

• 禁止使用公开的 IP 扫描工具探测服务器。
• 客户端连接频率限制：Sing-box 中配置 urltest 间隔 ≥ 300s。
• 服务端 auth 失败次数监控，超过阈值自动封禁：

1
# 使用 fail2ban 监控 hysteria 日志
2
[hysteria]
3
enabled = true
4
port = 443
5
filter = hysteria
6
logpath = /var/log/hysteria.log
7
maxretry = 5
8
bantime = 3600

日志与监控：及时发现封锁迹象

1
# 监控连接数骤降
2
watch -n 10 'ss -un | grep :443 | wc -l'
3
# 监控握手失败率
4
journalctl -u hysteria-server -f | grep -i "handshake failed"
5
# 监控带宽异常
6
vnstat -l -i eth0

当出现以下信号时，说明可能已被封锁：

1. 连接数在 5 分钟内骤降 80% 以上。
2. 握手失败率 > 30%。
3. 同一客户端 IP 段全部无法连接。
4. mtr 显示到服务器最后一跳丢包 100%。

此时应立即：更换端口 → 更换 IP → 更换域名 → 更换混淆密码，四步走。

Q1: Hysteria 2 和 TUIC v5 都基于 QUIC，为什么我自建后速度反而不如 TCP 协议？#

直接结论：90% 的情况不是协议问题，而是 UDP 被运营商 QoS 限速或服务端带宽/BBR 配置不匹配。 QUIC 系协议对 UDP 通道质量极度敏感，一旦运营商对 UDP 做限速或丢包惩罚，性能会断崖式下跌。

技术细节上，需要分三层排查。第一层是链路层：用 iperf3 -u 对服务端 UDP 端口做纯 UDP 打流测试，如果 UDP 吞吐明显低于 TCP，说明运营商侧存在 UDP QoS，此时应优先考虑 TUIC v5 的 udp_relay_mode: native 或改用 Hysteria 2 的 bandwidth 显式限速来规避惩罚。第二层是服务端：Hysteria 2 的 Brutal 拥塞控制会主动抢占带宽，如果服务端未正确设置 up_mbps/down_mbps 或与 VPS 实际带宽不符，会触发大量重传。第三层是客户端：部分 Clash 内核版本对 QUIC 的 GSO 支持不完整，建议参照 Clash Verge 与 Sing-box 客户端配置精解 中的内核参数章节逐项核对。若三层均正常仍不理想，说明该线路本身不适合 QUIC，应回退到 TCP 系协议或更换机房。

Q2: 弱网环境下 Hysteria 2 的 Brutal 拥塞控制真的比 BBR 强吗？强多少？#

直接结论：在高丢包（>5%）场景下，Brutal 相比 BBR 通常有 30%~200% 的吞吐提升；但在低丢包（<1%）的优质线路上，两者差距不足 10%，甚至 BBR 更稳。 Brutal 的收益与丢包率强正相关。

原理层面，BBR 的核心是”探测带宽与 RTT 的 BDP 模型”，它假设丢包不等于拥塞，因此在丢包链路上仍能维持较高发送速率，但仍受限于探测周期。而 Hysteria 2 的 Brutal 是”固定速率 + 激进重传”模型：客户端与服务端预先协商好上下行带宽上限，发送端直接以该速率灌包，丢包后立即重传，不做退让。这意味着在 5%~20% 丢包的移动网络、跨境晚高峰线路上，Brutal 能把可用带宽”吃满”，而 BBR 会因探测收敛慢而浪费窗口。代价是 Brutal 对带宽上限配置极其敏感——设置过高会挤爆链路并影响同机其他用户，设置过低则白白浪费。因此我们建议在 2026 稳定优质机场推荐评测中心 选择支持自定义带宽参数的机场，或自建时用 speedtest 实测后按 80% 冗余配置。

Q3: TUIC v5 相比 v4 到底改了什么？值不值得为此更换服务端？#

直接结论：TUIC v5 最大的变化是引入了 0-RTT 握手与原生 UDP over QUIC 中继，首次连接延迟降低约 1 个 RTT，UDP 应用（游戏、语音）体验提升明显。 如果你的使用场景以网页/视频为主，升级收益有限；如果涉及实时 UDP，强烈建议升级。

具体来看，TUIC v4 的 UDP 中继依赖额外的 native 与 quic 两种模式切换，配置复杂且在某些内核上存在兼容性问题；v5 将 UDP 中继统一为原生 QUIC stream，简化了服务端 udp_relay_mode 配置并提升了多路复用效率。同时 v5 支持 0-RTT，意味着客户端在首次握手后缓存票据，后续连接可省去一次往返，对移动网络频繁切换基站的场景非常友好。需要注意的是，v5 与 v4 服务端不兼容，升级需同步更新服务端与客户端。若你使用的是机场订阅，多数机场已在 2025 年底完成 v5 迁移，可通过 SubConverter Pro 订阅转换 检查订阅中 tuic 节点的 version 字段确认。

Q4: 自建 Hysteria 2 时，如何判断我的 VPS 是否被运营商针对 UDP 限速？#

直接结论：用”TCP vs UDP 同端口对照打流 + 分时段重复测试”三步法即可判定。 若 UDP 吞吐在晚高峰系统性低于 TCP 且白天正常，基本可确认是运营商 QoS。

第一步，在服务端同一台 VPS 上分别开放 TCP 与 UDP 测试端口，用 iperf3 做对照测试，记录白天与晚高峰两组数据。第二步，观察丢包特征：运营商 QoS 通常表现为”高丢包 + 低抖动”，而链路拥塞表现为”高丢包 + 高抖动”，两者可通过 mtr 的 Loss% 与 StDev 区分。第三步，做端口跳跃测试：Hysteria 2 支持 port_hopping 配置，若更换端口后 UDP 吞吐恢复正常，说明是端口级限速而非协议级封锁。若确认被限速，可选方案包括：启用端口跳跃、改用 TUIC v5 的 443 UDP 伪装、或直接更换机房。关于机房与线路的横向对比，可参考 2026机场推荐与选购指南 中的线路质量评测章节。

Q5: 机场订阅里同时有 Hysteria 2 和 TUIC v5 节点，客户端应该如何设置分流优先级？#

直接结论：按”场景分层”而非”协议优劣”来设置优先级——实时 UDP 走 TUIC v5，大流量下载走 Hysteria 2，网页浏览走延迟最低的节点。 单一协议通吃所有场景是常见误区。

在 Clash Verge 或 Sing-box 中，可通过 proxy-groups 的 url-test 与 fallback 组合实现：先建一个 url-test 组按延迟筛选出前 3 个节点，再建一个 fallback 组按协议类型分场景引用。具体来说，游戏与语音类规则指向 TUIC v5 组（利用其原生 UDP 中继），视频与下载类规则指向 Hysteria 2 组（利用其 Brutal 高吞吐），普通网页规则指向延迟最低组。需要注意 Hysteria 2 的 Brutal 会抢占带宽，若与 TUIC 共用同一 VPS，建议在 Hysteria 2 服务端显式限制 up_mbps/down_mbps 避免互相干扰。完整的配置模板与分流规则示例，已在 Clash Verge 与 Sing-box 客户端配置精解 中给出可直接复制的 YAML 片段。