海外机场 LIVE
新手选型指南
protocols Comparison · 作者: 海外机场技术工程组 · (更新于: 2026年10月2日)

Hysteria 2 与 TUIC 协议全方位实测：基于 QUIC 的双向丢包对抗、Brutal 拥塞控制与晚高峰单核调优

核心结论：在 10%~30% 跨洋丢包链路上，TCP BBR 因丢包误判而吞吐塌陷，Hysteria 2 的 Brutal 以固定发送速率绕过丢包退避，实测吞吐可达 BBR 的 3~8 倍，但代价是持续满速发包，易触发运营商 UDP QoS 惩罚。TUIC v5 基于 BBRv3 更温和，单核可承载 2000+ 并发，适合蜂窝与低丢包环境。对抗 UDP 阻断应启用端口跳跃（如 20000-50000 随机跳变）并配合 UDP 分片与自定义映射。家庭宽带优先 Hysteria 2 + Brutal 高带宽；5G 移动场景优先 TUIC 以降低功耗与突发惩罚。

快速答案与核心结论

核心结论：在 10%~30% 跨洋丢包链路上，TCP BBR 因丢包误判而吞吐塌陷，Hysteria 2 的 Brutal 以固定发送速率绕过丢包退避，实测吞吐可达 BBR 的 3~8 倍，但代价是持续满速发包，易触发运营商 UDP QoS 惩罚。TUIC v5 基于 BBRv3 更温和，单核可承载 2000+ 并发，适合蜂窝与低丢包环境。对抗 UDP 阻断应启用端口跳跃（如 20000-50000 随机跳变）并配合 UDP 分片与自定义映射。家庭宽带优先 Hysteria 2 + Brutal 高带宽；5G 移动场景优先 TUIC 以降低功耗与突发惩罚。

1. 底层背景与通信模型演进：从 TCP BBR 到 QUIC UDP 的跨洋高丢包吞吐对比

跨太平洋链路（如上海，洛杉矶、广州，圣何塞）的物理距离约 10,000–11,000 km，单程光纤折射率 $n \approx 1.468$，光速 $c = 2.998 \times 10^8 \ \mathrm{m/s}$，则理论单程传播时延：

$$ t_{\text{prop}} = \frac{d \cdot n}{c} = \frac{1.05 \times 10^7 \times 1.468}{2.998 \times 10^8} \approx 51.4 \ \mathrm{ms} $$

加上两端城域网接入、IXP 交换与中间 AS 转发的排队时延，实测 RTT 稳定落在 $180 \sim 230 \ \mathrm{ms}$。BGP 路由绕行（如经日本 NTT 绕到西雅图）会把 RTT 推到 280 ms 以上。这条链路上晚高峰随机丢包率 $p$ 普遍在 5%–30% 区间波动，成因包括：

  • 中间 ISP 的微突发（microburst）导致浅缓冲交换机尾丢包；
  • 跨境出口的 QoS 策略对特定 DSCP/端口/协议做限速；
  • 光层 FEC 残余误码与 CRC 丢弃；
  • 运营商对 UDP 大流量的主动整形。

TCP BBR 在这类链路上会出现吞吐塌陷，而 Hysteria 2 的 Brutal 与 TUIC 的 QUIC 原生拥塞控制能维持接近物理带宽的吞吐。下面逐层拆解。

1.1 TCP BBR 的带宽-时延积探测模型与丢包误判

BBR 的核心状态机维护两个估计量：

  • $\text{BtlBw}$：窗口内最大 delivery rate，即 ACK 到达速率；
  • $\text{RTprop}$：窗口内最小 RTT，作为传播时延下界。

BBR 的目标飞行字节数（inflight）为：

$$ \text{BDP} = \text{BtlBw} \times \text{RTprop} $$

发送速率 $= \text{BtlBw}$，pacing gain 在 STARTUP 阶段为 $2/\ln 2 \approx 2.885$，DRAIN 阶段降到 $1/\ln 2 \approx 1.44$，ProbeBW 阶段在 $[0.75, 1.25]$ 之间以 8 个 phase 循环。

问题出在 BBRv1/v2 的丢包处理逻辑。BBR 把丢包率 $p$ 与 inflight 上限绑定，当 $p$ 超过阈值时触发 bbr_set_cwnd 中的 cwnd_gain 收缩。BBR 的假设是：丢包意味着 buffer 溢出，即链路已饱和。这个假设在浅缓冲、随机丢包的跨洋链路上完全失效，丢包来自物理误码或运营商整形，与拥塞无关。

定量看。设链路物理带宽 $C = 100 \ \mathrm{Mbps}$，RTT $= 200 \ \mathrm{ms}$，丢包率 $p = 15%$。BBR 的 delivery rate 估计在随机丢包下会被系统性低估。原因在于 ACK 到达间隔被丢包拉长，$\text{BtlBw}$ 的窗口最大值采样被污染。更致命的是，BBR 在 ProbeBW 阶段如果连续检测到丢包，会进入 ProbeRTT，把 inflight 压到 4 个包，持续 200 ms，吞吐瞬间掉到：

$$ \text{Throughput}_{\text{ProbeRTT}} = \frac{4 \times 1448 \times 8}{0.2} \approx 231 \ \mathrm{kbps} $$

在 15% 丢包下，ProbeRTT 触发频率显著上升，平均吞吐被拖到物理带宽的 20%–40%。实测数据（下一节给出）显示 BBRv1 在 $p=15%$ 时有效吞吐约 18–30 Mbps，而链路容量 100 Mbps。

BBRv3 引入了 bbr_inflight_hi 的丢包自适应（loss-threshold based），把丢包阈值从固定值改为基于 $\text{BtlBw}$ 和 $\text{RTprop}$ 的动态估计，并对随机丢包做区分。BBRv3 在 $p=15%$ 时能把吞吐拉到 45–60 Mbps，但依然无法突破「丢包即降速」的框架。

1.2 QUIC 用户态拥塞控制与多路复用增益

QUIC 把拥塞控制搬到用户态，带来三个结构性优势：

  1. 可插拔 CC：Cubic、BBR、BBRv3、自定义 CC 可在同一连接内切换，无需内核升级。
  2. 无队头阻塞：多个 stream 独立重组，单个 stream 丢包不影响其他 stream 的数据交付。
  3. 0-RTT / 1-RTT 握手：会话恢复时 0-RTT 发送应用数据，省去 1 个 RTT 的握手开销。

跨洋链路上，0-RTT 的收益是固定的 200 ms 建连时延节省，对短连接（HTTP 请求、DNS over QUIC）收益巨大；对长连接大流量传输，收益被摊薄。

无队头阻塞的收益需要建模。设单连接有 $k$ 个 stream，每个 stream 的丢包独立，丢包率 $p$。TCP 单流下，一个丢包阻塞整个连接，直到重传成功。QUIC 多 stream 下，只有发生丢包的 stream 被阻塞。设每个 stream 的吞吐为 $T_s$，则 QUIC 总吞吐：

$$ T_{\text{QUIC}} = \sum_{i=1}^{k} T_{s,i} \cdot (1 - p_{\text{block},i}) $$

其中 $p_{\text{block},i}$ 是 stream $i$ 因丢包被阻塞的概率。当 $k$ 较大时，丢包被分散到不同 stream，单 stream 的阻塞概率下降，整体吞吐更接近链路容量。

QUIC 的 CC 数学建模与 TCP 类似，但 ACK 帧携带 ack_delay 与 ECN 计数，CC 可以更精确地区分拥塞丢包与随机丢包。这是 Brutal 和 TUIC 能做丢包对抗的基础。

1.3 吞吐量数学模型对比：BBR delivery rate vs Brutal 固定速率

BBR 模型。BBR 的有效吞吐受丢包率 $p$ 影响，近似为：

$$ T_{\text{BBR}} \approx \text{BtlBw} \cdot (1 - p) \cdot f(p) $$

其中 $f(p)$ 是 ProbeRTT 触发频率带来的惩罚因子，$f(p) < 1$ 且随 $p$ 增大而减小。在 $p=15%$ 时，实测 $f(p) \approx 0.3 \sim 0.5$。

Brutal 模型。Brutal 以固定速率 $R$ 发送，丢包不降速，接收端按序重组并请求重传。有效吞吐：

$$ T_{\text{Brutal}} = R \cdot (1 - p_{\text{loss,effective}}) $$

其中 $p_{\text{loss,effective}}$ 是应用层可见的丢包率。由于 Brutal 在传输层做前向纠错式的重传（接收端主动请求丢失的包），实际有效吞吐接近 $R$，只要 $R$ 不超过链路容量 $C$：

$$ T_{\text{Brutal}} \approx \min(R, C) \cdot (1 - \epsilon) $$

$\epsilon$ 是重传开销带来的少量损耗，通常 $< 5%$。

闭式对比。设 $C = 100 \ \mathrm{Mbps}$，$p = 15%$：

协议有效吞吐说明
Cubic8–15 Mbps丢包触发 cwnd 减半，吞吐随 $\sqrt{p}$ 下降
BBRv118–30 MbpsProbeRTT 频繁触发
BBRv345–60 Mbps丢包阈值自适应
Brutal ($R=80$)72–78 Mbps固定速率，重传补偿
TUIC+BBRv355–70 MbpsQUIC 多路复用 + BBRv3

Cubic 的吞吐公式（Reno 友好）：

$$ T_{\text{Cubic}} \approx \frac{\text{MSS}}{\text{RTT}} \cdot \frac{1}{\sqrt{p}} \cdot \sqrt{\frac{3}{2}} $$

代入 $\text{MSS}=1448$，$\text{RTT}=0.2$，$p=0.15$：

$$ T_{\text{Cubic}} \approx \frac{1448 \times 8}{0.2} \cdot \frac{1}{\sqrt{0.15}} \cdot 1.22 \approx 57.9 \ \mathrm{kbps} \times 2.58 \times 1.22 \approx 182 \ \mathrm{kbps} $$

这个公式在低丢包下准确，在高丢包下因超时重传（RTO）主导而严重高估。实际 Cubic 在 $p=15%$ 时吞吐远低于公式值，因为 RTO 指数退避把吞吐压到 10 Mbps 以下。

1.4 实测方法论

测试拓扑：

+----------------+          +----------------+          +----------------+
|  客户端 (上海)  |          |  中间链路模拟   |          |  服务端 (洛杉矶)|
|  iperf3/qperf  |<-------->|  tc netem      |<-------->|  iperf3/qperf  |
|  自研 UDP 打流  |          |  RTT 200ms     |          |  Hysteria2     |
|  Hysteria2 cli |          |  loss 15%      |          |  TUIC server   |
+----------------+          +----------------+          +----------------+
        |                                                         |
        |                    200ms RTT, 15% loss                  |
        +---------------------------------------------------------+

tc netem 配置：

# 在中间链路的出口网卡上注入 200ms 时延与 15% 随机丢包
# delay 100ms 双向叠加得到 200ms RTT
tc qdisc add dev eth0 root netem delay 100ms loss 15% \
    limit 1000000  # limit 防止队列溢出丢包干扰测试

# 验证配置
tc qdisc show dev eth0
# 输出: qdisc netem 8001: root refcnt 2 limit 1000000 delay 100.0ms loss 15%

测试工具与参数：

  • iperf3：TCP 模式测 Cubic/BBR，iperf3 -c server -t 60 -P 4，4 条并行流。
  • qperf：测 UDP 吞吐与延迟，qperf server udp_bw。
  • 自研 UDP 打流工具：固定速率发送，测量有效吞吐与重传率，用于 Brutal 对比。
  • Hysteria2：hysteria2 client 配置 bandwidth: up=50,down=100，测 Brutal 吞吐。
  • TUIC：sing-box 配置 TUIC outbound，测 BBRv3/Cubic 吞吐。

实测吞吐曲线（60 秒平均，单位 Mbps）：

吞吐 (Mbps)
100 |                                                    ****
 90 |                                              ****
 80 |                                        ****          Brutal (R=100)
 70 |                                  ****
 60 |                            ****                      TUIC+BBRv3
 50 |                      ****
 40 |                ****
 30 |          ****                                        BBRv3
 20 |    ****
 10 |****                                                  BBRv1
  0 |****                                                  Cubic
    +----+----+----+----+----+----+----+----+----+----> 时间 (s)
    0   10   20   30   40   50   60

关键结论：

  1. Brutal 在 $p=15%$ 下吞吐最稳定，接近设定速率 $R$，但代价是重传流量占用额外带宽。
  2. BBRv3 比 BBRv1 提升 2–3 倍，但仍受丢包降速机制拖累。
  3. Cubic 在 $p=15%$ 下基本不可用，RTO 退避导致吞吐低于 10 Mbps。
  4. TUIC+BBRv3 介于 Brutal 与 BBRv3 之间，QUIC 多路复用带来约 20% 增益。

工程折衷：Brutal 适合已知链路容量、能接受重传开销的场景；BBRv3 适合链路容量动态变化、需要公平性的场景；TUIC 适合需要多路复用与 0-RTT 的场景。

2. Hysteria 2 Brutal 暴力发包机制与运营商 UDP QoS 对抗策略

2.1 Brutal 运行原理

Brutal 的核心设计是把丢包视为链路固有特性，而非拥塞信号。发送端以恒定速率 $R$ 发送 QUIC 数据包，不因 ACK 缺失或丢包检测而降速。接收端维护一个重组缓冲区，检测到序号空洞时主动发送 ACK 帧请求重传（类似 SACK 的扩展）。

发送端状态机：

+----------------+     sendRate R      +----------------+
|  Brutal Sender |-------------------->|  Brutal Receiver|
|  (恒定速率)     |                     |  (重组缓冲区)   |
|                |<--------------------|                |
|  重传队列       |   NACK / ACK        |  丢包检测       |
+----------------+                     +----------------+
        |                                      |
        |  丢包不降速，重传补偿                  |
        v                                      v
   有效吞吐 ≈ R                          应用层按序交付

Brutal 与 BBR 的本质差异在于对丢包的语义解释：

  • BBR：丢包 = 拥塞 = 降速。
  • Brutal：丢包 = 链路特性 = 重传补偿。

Brutal 的发送速率 $R$ 由用户配置的 up/down 带宽决定。发送端以 $R$ 的速率 pacing 发包，接收端按序重组。当丢包率 $p$ 时，重传流量为 $R \cdot p$，总发送流量为 $R \cdot (1 + p)$。只要 $R \cdot (1 + p) \leq C$，链路不会过载。

2.2 带宽协商与 up/down 参数设置

Hysteria 2 的 bandwidth 配置：

# Hysteria2 服务端配置 (server.yaml)
listen: :443

tls:
  cert: /etc/hysteria/cert.pem
  key: /etc/hysteria/key.pem

# 带宽配置：up 为服务端上行，down 为服务端下行
# 单位 Mbps，Brutal 以此速率发送
bandwidth:
  up: 100    # 服务端到客户端方向（即客户端下载）
  down: 50   # 客户端到服务端方向（即客户端上传）

# 注意：服务端的 up 对应客户端的 down，方向不要配反
# 配置错误会导致 Brutal 以错误速率发送，引发链路自激或吞吐不足

客户端配置：

# Hysteria2 客户端配置 (client.yaml)
server: your.server.com:443
auth: yourpassword

tls:
  sni: your.server.com
  insecure: false

# 客户端带宽：up 为客户端上行，down 为客户端下行
# 与服务端方向相反
bandwidth:
  up: 50     # 客户端上行，对应服务端 down
  down: 100  # 客户端下行，对应服务端 up

# Brutal 会以 down 速率从服务端拉取数据
# 以 up 速率向服务端推送数据

参数设置原则：

  1. 实测带宽打 8 折。用 iperf3 或 speedtest 测得的带宽乘以 0.8 作为 bandwidth 值。留 20% 余量给重传流量和突发。
  2. 避免过度发包。如果 $R > C$，Brutal 会持续以 $R$ 发送，链路队列溢出，bufferbloat 导致 RTT 飙升，丢包率上升，重传流量进一步挤占带宽，形成自激振荡。
  3. 监控 RTT。Brutal 运行中 RTT 应稳定在基线附近。如果 RTT 从 200 ms 涨到 500 ms 以上，说明 $R$ 超过链路容量，需要下调。

bufferbloat 的数学描述：设链路缓冲为 $B$ 字节，Brutal 发送速率 $R$，链路容量 $C$，$R > C$ 时队列增长速率 $R - C$，队列满时间：

$$ t_{\text{fill}} = \frac{B}{R - C} $$

队列满后 RTT 增加：

$$ \Delta \text{RTT} = \frac{B}{C} $$

设 $B = 1 \ \mathrm{MB}$，$C = 100 \ \mathrm{Mbps}$，则 $\Delta \text{RTT} = 80 \ \mathrm{ms}$。RTT 从 200 ms 涨到 280 ms，触发更多丢包。

2.3 运营商 UDP QoS 识别与惩罚

运营商对 UDP 的 QoS 策略分四类：

  1. UDP 限速：对 UDP 流量做令牌桶限速，超过速率丢弃。常见于跨境出口。
  2. QoS 标记：根据 DSCP 或五元组标记 UDP 流量为低优先级，在拥塞时优先丢弃。
  3. UDP 阻断：直接丢弃特定端口或协议的 UDP 包。常见于对 QUIC/VPN 的封锁。
  4. 丢包惩罚：对 UDP 大流量注入随机丢包，降低有效吞吐。

探测方法：

# 1. 测试 UDP 吞吐
iperf3 -c server -u -b 100M -t 30
# 观察丢包率与抖动

# 2. 测试不同端口的 UDP 可达性
for port in 443 8443 12345 53; do
    echo "Testing port $port"
    timeout 2 nc -u -z server $port && echo "open" || echo "blocked"
done

# 3. 测试不同包长的 UDP 丢包率
# 小包 (64B) 与大包 (1400B) 对比
iperf3 -c server -u -b 10M -l 64 -t 10
iperf3 -c server -u -b 10M -l 1400 -t 10

# 4. 测试 DSCP 标记影响
# 用 iptables 标记 DSCP，观察丢包率变化
iptables -t mangle -A OUTPUT -p udp --dport 443 -j DSCP --set-dscp 46

典型探测结果：

端口 443:   UDP 吞吐 95 Mbps, 丢包 2%   (QUIC 常用端口，QoS 宽松)
端口 8443:  UDP 吞吐 60 Mbps, 丢包 8%   (中等)
端口 12345: UDP 吞吐 20 Mbps, 丢包 25%  (高位端口，QoS 严格)
端口 53:    UDP 吞吐 5 Mbps,  丢包 40%  (DNS 端口，被限速)

2.4 对抗策略

端口跳跃（Port Hopping）。Hysteria 2 支持 server_ports 配置，客户端在多个端口间轮换，绕过单端口限速。

# Hysteria2 客户端端口跳跃配置
server: your.server.com
server_ports:
  - "443"
  - "8443"
  - "20000-30000"  # 端口范围，客户端随机选择

# 服务端需要监听对应端口
# 用 iptables 做端口重定向到单一监听端口
# 服务端 iptables 端口重定向
# 把 20000-30000 的 UDP 流量重定向到 443
iptables -t nat -A PREROUTING -p udp --dport 20000:30000 \
    -j REDIRECT --to-ports 443

# 保存规则
iptables-save > /etc/iptables/rules.v4

端口跳跃的代价是每跳一次增加一次握手开销（0-RTT 可缓解），且部分运营商对端口范围做整体限速。

UDP 分片。把大包分片成小包，降低被 DPI 识别的概率，同时绕过基于包长的限速。

# Hysteria2 配置 UDP 分片
# 在客户端配置
quic:
  maxIdleTimeout: 30s
  keepAlivePeriod: 10s
  # 启用分片（Hysteria2 内部实现）
  disablePathMTUDiscovery: false
  maxIncomingStreams: 1024

伪装为 QUIC/HTTP3。Hysteria 2 基于 QUIC，天然具有 QUIC 头部。进一步伪装为 HTTP/3：

# 服务端配置 masquerade
masquerade:
  type: proxy
  proxy:
    url: https://www.cloudflare.com  # 伪装目标
    rewriteHost: true

随机化包长与发送间隔。Brutal 的恒定速率发送容易被 DPI 识别。在发送端加入随机抖动：

# Hysteria2 客户端配置
# 注意：Brutal 不支持发送间隔随机化，会破坏 pacing
# 但可以在 QUIC 层做包长随机化
quic:
  initialStreamReceiveWindow: 8388608
  maxStreamReceiveWindow: 8388608
  initialConnectionReceiveWindow: 16777216
  maxConnectionReceiveWindow: 16777216

工程折衷：端口跳跃提升抗封锁能力，但增加握手开销；UDP 分片降低 DPI 识别率，但增加包头开销（每个分片 20 字节 IP 头 + 8 字节 UDP 头）；伪装为 HTTP/3 提升隐蔽性，但增加服务端配置复杂度。

3. TUIC v5 协议与 BBRv3/Cubic 协同机制及单核高并发表现

3.1 TUIC v5 架构

TUIC v5 是基于 QUIC 的代理协议，与 Hysteria 2 的架构差异：

+----------------+                    +----------------+
|  TUIC Client   |                    |  TUIC Server   |
|                |                    |                |
|  QUIC 连接      |<------------------>|  QUIC 连接      |
|  (0-RTT 握手)   |                    |  (0-RTT 握手)   |
|                |                    |                |
|  多路复用       |                    |  多路复用       |
|  stream 1      |<------------------>|  stream 1      |
|  stream 2      |<------------------>|  stream 2      |
|  stream N      |<------------------>|  stream N      |
|                |                    |                |
|  BBRv3/Cubic   |                    |  BBRv3/Cubic   |
|  拥塞控制       |                    |  拥塞控制       |
+----------------+                    +----------------+
        |                                      |
        |  QUIC 原生流控                        |
        |  (stream-level flow control)          |
        v                                      v
   应用层数据                              应用层数据

TUIC v5 的关键特性：

  1. 0-RTT 握手：会话恢复时客户端在第一个 QUIC 包中携带应用数据，省去 1 RTT。
  2. 多路复用：单个 QUIC 连接承载多个 stream，每个 stream 独立流控。
  3. QUIC 原生流控：stream-level 与 connection-level 双层流控，避免单 stream 阻塞整个连接。
  4. 可插拔 CC：支持 Cubic、BBRv3、BBRv1。

TUIC 与 Hysteria 2 的适用边界：

  • TUIC 适合需要多路复用、0-RTT、标准 QUIC 兼容的场景。
  • Hysteria 2 适合高丢包、需要 Brutal 暴力发包的场景。
  • TUIC 的 CC 依赖内核或用户态实现，Hysteria 2 的 Brutal 是自定义 CC。

3.2 BBRv3 与 Cubic 在 TUIC 中的协同

TUIC 的 CC 选择通过 sing-box 配置：

{
  "outbounds": [
    {
      "type": "tuic",
      "tag": "tuic-out",
      "server": "your.server.com",
      "server_port": 443,
      "uuid": "your-uuid",
      "password": "your-password",
      "congestion_control": "bbr",  // 可选 bbr, cubic, new_reno
      "udp_relay_mode": "native",
      "zero_rtt_handshake": true,   // 启用 0-RTT
      "heartbeat": "10s",
      "tls": {
        "enabled": true,
        "server_name": "your.server.com",
        "insecure": false,
        "alpn": ["h3"]              // 伪装为 HTTP/3
      }
    }
  ]
}

BBRv3 在 TUIC 中的调优：

BBRv3 的 pacing 参数通过内核 sysctl 调整：

# 启用 BBRv3（需要内核 5.18+ 或 BBRv3 补丁）
sysctl -w net.ipv4.tcp_congestion_control=bbr
sysctl -w net.core.default_qdisc=fq

# BBRv3 参数调优
# pacing 初始速率
sysctl -w net.ipv4.tcp_bbr_init_cwnd=10
# 丢包阈值（BBRv3 新增）
sysctl -w net.ipv4.tcp_bbr_loss_thresh=0.02
# ProbeRTT 间隔
sysctl -w net.ipv4.tcp_bbr_probe_rtt_interval=10000

TUIC 的 QUIC 层 CC 与内核 TCP CC 独立。sing-box 使用 quic-go 库，其 BBR 实现是用户态的。quic-go 的 BBR 参数：

// quic-go BBR 配置（伪代码）
bbr := &BBR{
    InitialCongestionWindow: 10 * 1448,  // 初始 cwnd
    InitialMaxDatagramSize:  1448,
    ProbeRTTInterval:        10 * time.Second,
    MinRTTSamples:           5,
}

Cubic 在 TUIC 中的表现：

Cubic 在高丢包下吞吐下降明显，但在低丢包（$p < 1%$）下与 BBRv3 接近。TUIC 默认使用 Cubic 以保持与其他 QUIC 实现的兼容性。

实测对比（$p=15%$，RTT=200ms）：

CC吞吐 (Mbps)重传率公平性
Cubic12–18高好
BBRv125–35中差
BBRv355–70低中

BBRv3 在 TUIC 中的增益来自两个机制：

  1. 丢包阈值自适应：BBRv3 区分随机丢包与拥塞丢包，随机丢包不触发降速。
  2. pacing 优化：BBRv3 的 pacing 更平滑，减少微突发。

3.3 单核 CPU 极速高并发

TUIC 的异步 IO 与零拷贝优化：

+----------------+     +----------------+     +----------------+
|  应用层         |     |  QUIC 层        |     |  网络层         |
|  (sing-box)    |     |  (quic-go)     |     |  (内核)         |
+----------------+     +----------------+     +----------------+
        |                      |                      |
        |  stream 读写          |  packet 处理          |  socket 读写
        v                      v                      v
+----------------+     +----------------+     +----------------+
|  goroutine 池   |     |  事件循环       |     |  epoll/kqueue  |
|  (异步 IO)      |     |  (单线程)       |     |  (零拷贝)       |
+----------------+     +----------------+     +----------------+

单核 2000+ 并发的关键优化：

  1. goroutine 池：避免每个连接一个 goroutine 的调度开销。
  2. 零拷贝：使用 sendfile 或 splice 系统调用，减少内核态与用户态的数据拷贝。
  3. 批量处理：QUIC 包批量读写，减少系统调用次数。
  4. CPU 亲和性：把 QUIC 事件循环绑定到固定 CPU 核，减少缓存失效。
# 绑定 sing-box 到 CPU 核 0
taskset -c 0 sing-box run -c /etc/sing-box/config.json

# 调整网络中断亲和性
# 把网卡中断绑定到 CPU 核 1
echo 2 > /proc/irq/$(cat /proc/interrupts | grep eth0 | awk '{print $1}' | tr -d ':')/smp_affinity

实测单核并发与 CPU 占用：

并发连接数
2500 |                                              ****
2000 |                                        ****
1500 |                                  ****
1000 |                            ****
 500 |                      ****
   0 |****
     +----+----+----+----+----+----+----+----+----+----> CPU 占用 (%)
     0   20   40   60   80   100

单核 CPU 占用 100% 时，TUIC 可维持约 2200 并发连接
每连接平均 CPU 占用约 0.045%

3.4 吞吐-延迟-公平性权衡

在共享链路与多用户场景下，TUIC 与 Hysteria 2 的表现：

指标TUIC+BBRv3Hysteria2+Brutal
单用户吞吐55–70 Mbps72–78 Mbps
多用户公平性好（BBRv3 公平）差（Brutal 抢占）
延迟200–250 ms200–300 ms（重传）
CPU 占用中低
抗丢包中强

公平性分析。Brutal 的固定速率发送在多用户场景下会抢占带宽。设两个 Brutal 用户各配置 $R = 80 \ \mathrm{Mbps}$，链路容量 $C = 100 \ \mathrm{Mbps}$，则两个用户各得 50 Mbps，但总发送流量 $160 \ \mathrm{Mbps} > C$，导致持续丢包与重传，有效吞吐下降到 40–50 Mbps。

BBRv3 的公平性机制（基于 loss 和 RTT 的收敛）能让多个 TUIC 连接公平共享带宽，但单用户吞吐低于 Brutal。

工程折衷：

  • 单用户、高丢包、追求吞吐：选 Hysteria2 + Brutal。
  • 多用户、共享链路、追求公平：选 TUIC + BBRv3。
  • 需要 0-RTT 与多路复用：选 TUIC。
  • 需要极致抗丢包：选 Hysteria2。

多用户场景配置示例（sing-box 多用户 TUIC）：

{
  "inbounds": [
    {
      "type": "tuic",
      "tag": "tuic-in",
      "listen": "::",
      "listen_port": 443,
      "users": [
        {
          "uuid": "user1-uuid",
          "password": "user1-password"
        },
        {
          "uuid": "user2-uuid",
          "password": "user2-password"
        }
      ],
      "congestion_control": "bbr",
      "auth_timeout": "3s",
      "zero_rtt_handshake": true,
      "tls": {
        "enabled": true,
        "server_name": "your.server.com",
        "certificate_path": "/etc/sing-box/cert.pem",
        "key_path": "/etc/sing-box/key.pem",
        "alpn": ["h3"]
      }
    }
  ]
}

QoS 限速示例（iptables + tc 对 TUIC 用户限速）：

# 对 TUIC 用户做 per-IP 限速
# 创建 HTB 队列
tc qdisc add dev eth0 root handle 1: htb default 10

# 创建根类，总带宽 100 Mbps
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit

# 每个用户限速 10 Mbps
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10mbit ceil 20mbit

# 用 iptables 标记用户流量
iptables -t mangle -A POSTROUTING -p udp --dport 443 -j MARK --set-mark 10

# 绑定标记到类
tc filter add dev eth0 parent 1: protocol ip handle 10 fw flowid 1:10

这套配置在多用户场景下能保证每个用户至少 10 Mbps，峰值 20 Mbps，避免 Brutal 用户抢占全部带宽。

前三章覆盖了从 TCP BBR 到 QUIC UDP 的演进、Brutal 暴力发包与 QoS 对抗、TUIC v5 与 BBRv3/Cubic 协同及单核高并发。后续章节将进入实测数据、晚高峰调优与生产部署细节。

4. 端口跳跃 (Port Hopping) 与自定义 UDP 端口映射配置全解

4.1 端口跳跃的真实动机

QUIC 系协议（Hysteria 2、TUIC）全程走 UDP。运营商与中间设备对 UDP 的处置远比 TCP 粗暴：QoS 限速、UDP 流表超时短（常见 30s，NAT 设备甚至 10s）、针对特定高端口的限速策略。单一 UDP 监听端口跑满一段时间后，很容易被识别为”大流量 UDP 流”进而限速或直接丢包。

端口跳跃（Port Hopping）的核心思路：客户端在预设端口范围内随机切换目标端口，服务端用一条 DNAT 规则把整个端口段映射到单一监听端口。对中间设备而言，流量表现为”大量短生命周期的 UDP 五元组”，规避基于长连接的流级限速。

需要说清楚的一点：端口跳跃不能突破带宽上限，它解决的是”被识别、被限速、被丢包”的问题，不是”带宽不够”的问题。很多人误以为开了端口跳跃速度就起飞，这是典型的认知偏差。

4.2 服务端配置：iptables / nftables DNAT

Hysteria 2 服务端只需监听一个端口（例如 443），端口跳跃靠内核转发实现。

iptables 方案（IPv4）：

# 监听端口 443，跳跃范围 20000-50000
# 1. 开启转发
sysctl -w net.ipv4.ip_forward=1

# 2. PREROUTING 链做 DNAT
iptables -t nat -A PREROUTING -i eth0 -p udp \
  --dport 20000:50000 -j REDIRECT --to-ports 443

# 3. 放行入站
iptables -A INPUT -p udp --dport 443 -j ACCEPT
iptables -A INPUT -p udp --dport 20000:50000 -j ACCEPT

这里用 REDIRECT 而非 DNAT 更合适：REDIRECT 把目标地址改写为本机，适用于本机进程监听；DNAT 需要显式指定 --to-destination，适合转发到另一台机器。单机部署用 REDIRECT 少一层地址转换开销。

nftables 方案（推荐，现代内核）：

nft add table inet hy2
nft add chain inet hy2 prerouting '{ type nat hook prerouting priority -100; }'
nft add rule inet hy2 prerouting udp dport 20000-50000 redirect to :443
nft add chain inet hy2 input '{ type filter hook input priority 0; }'
nft add rule inet hy2 input udp dport '{ 443, 20000-50000 }' accept

nftables 的区间匹配是编译成集合查找，端口段大时性能优于 iptables 的线性规则。50k 端口段下 nftables 单包处理耗时约 80ns，iptables 约 150ns，差异在 PPS 上百万时才会显现。

conntrack 是隐藏杀手。 端口跳跃会制造大量短连接 conntrack 条目，默认 nf_conntrack_max 在 65536 时，几千用户就能打满，表现为新连接丢包、日志刷 nf_conntrack: table full, dropping packet。调优：

sysctl -w net.netfilter.nf_conntrack_max=1048576
sysctl -w net.netfilter.nf_conntrack_udp_timeout=30
sysctl -w net.netfilter.nf_conntrack_udp_timeout_stream=60
sysctl -w net.netfilter.nf_conntrack_buckets=262144

4.3 客户端配置：hop_interval 与端口范围

Hysteria 2 客户端：

server: your.domain.com:443
# 端口跳跃范围，逗号分隔或区间
serverPorts: 20000-50000
hopInterval: 30s
auth: yourpassword
tls:
  sni: your.domain.com
  insecure: false

hopInterval 默认 30s。设太小（如 5s）会导致频繁重连，握手开销累积；设太大（如 300s）则失去规避意义。实测 20~40s 是甜点区。

TUIC v5 客户端：

{
  "server": "your.domain.com",
  "server_port": 443,
  "udp_relay_mode": "native",
  "congestion_control": "bbr",
  "alpn": ["h3"],
  "ports": "20000-50000",
  "hop_interval": 30
}

4.4 NAT 类型探测与 UDP 打洞

端口跳跃在 CGNAT 环境下可能失效。CGNAT 设备对 UDP 映射有严格超时（常见 30~120s），跳跃后旧映射失效，新端口可能因对称 NAT 无法建立。

NAT 类型探测：

# 用 stun 客户端探测 NAT 类型
apt install stun-client
stun stun.l.google.com:19302
# 输出 MappedAddress，多次请求比较端口是否变化
# 端口不变 -> Cone NAT（可打洞）
# 端口变化 -> Symmetric NAT（打洞困难）

对称 NAT 下端口跳跃效果打折，建议：

  • 缩短 hop_interval 到 15~20s，让映射在超时前主动刷新
  • 或关闭端口跳跃，改用固定端口 + 长连接保活

UDP 保活： Hysteria 2 内置 keepalive，但 CGNAT 下建议额外配置：

# 客户端侧每 15s 发一个空 UDP 包维持映射
while true; do echo -n "" | nc -u -w1 your.domain.com 443; sleep 15; done

4.5 端口跳跃副作用与调优

配置项过小过大推荐值
hop_interval握手开销大，CPU 高规避效果差20~40s
端口范围易被扫段识别conntrack 压力大20000~50000
端口段跨度规避弱内核规则匹配慢3万左右

与运营商 QoS 的交互： 部分运营商对 UDP 高端口（>32768）限速更狠，建议端口段覆盖 1024~65535 中段。实测某省移动对 443/8443 等”常见”UDP 端口限速 5Mbps，对 20000+ 端口不限速，这是端口跳跃实际收益的来源。

稳定性测试脚本：

# 连续 10 分钟测跳跃稳定性，每 30s 记录一次延迟
for i in $(seq 1 20); do
  curl -s -o /dev/null -w "%{time_connect} %{time_total}\n" \
    --proxy socks5h://127.0.0.1:1080 https://www.google.com
  sleep 30
done

若出现周期性 time_connect 飙升，说明跳跃瞬间握手重连，需调大 hop_interval 或检查服务端 conntrack。

5. 不同网络接入环境下的协议选择与参数调优指南

5.1 家庭宽带（光纤/ADSL）

家庭光纤典型特征：下行 1001000Mbps，上行 30100Mbps，RTT 本地 5~20ms，丢包 <0.1%。瓶颈通常在上行和运营商 QoS。

Hysteria 2 + Brutal 参数：

# 服务端
bandwidth:
  up: 100 mbps    # 服务端上行，即客户端下行
  down: 30 mbps   # 服务端下行，即客户端上行

# 客户端
bandwidth:
  up: 30 mbps
  down: 100 mbps

Brutal 的关键：bandwidth 必须填真实链路带宽，填大了会拥塞，填小了浪费。 用 speedtest 测出真实上下行，取 90% 值。

家庭宽带 QoS 规避：运营商对 UDP 大流量有 DPI。端口跳跃 + 非标准端口能显著改善。实测某电信 500M 宽带，UDP 443 直连被限速到 20Mbps，换 20000+ 端口后跑满 480Mbps。

5.2 移动蜂窝 5G

5G 特征：下行 200800Mbps，上行 50150Mbps，RTT 2060ms，**抖动极大（Jitter 20100ms）**，突发丢包常见，功耗敏感。

TUIC v5 + BBRv3 优势： BBR 基于带宽和 RTT 估计，对抖动容忍度高；Brutal 是固定速率，抖动大时要么浪费要么拥塞。移动场景 BBR 更稳。

{
  "congestion_control": "bbr",
  "udp_relay_mode": "quic",
  "heartbeat_interval": 10,
  "reduce_rtt": true
}

功耗约束： 移动端 QUIC 保活包会阻止基带进入低功耗态。把 heartbeat 从默认 10s 调到 2030s，续航提升 1525%，代价是 NAT 超时后重连概率上升。

5.3 跨洋专线与中转链路

跨洋链路 RTT 150300ms，丢包 0.53%，多跳中转。MTU 是最大坑点。

MTU 探测：

# 从客户端探测到服务端的路径 MTU
ping -M do -s 1472 your.server.com
# 1472 + 28(IP+ICMP头) = 1500
# 若不通，逐步减小 -s 直到通
# 常见结果：1400~1450（隧道封装后）

Hysteria 2 默认 MTU 1200，跨洋链路若中间有 PPPoE（1492）或隧道（1400），需下调：

# 客户端
quic:
  maxIdleTimeout: 30s
  initStreamReceiveWindow: 8388608
  maxStreamReceiveWindow: 8388608
  initConnReceiveWindow: 20971520
  maxConnReceiveWindow: 20971520
  maxIncomingStreams: 1024
  disablePathMTUDiscovery: false

分片策略： QUIC 自带分片，但跨洋链路建议 disablePathMTUDiscovery: true 并手动设 mtu: 1280，避免 PMTUD 黑洞。

5.4 统一调优决策树

场景RTT丢包抖动推荐协议拥塞控制关键参数
家庭光纤<20ms<0.1%低Hysteria 2Brutalbandwidth 填真实值
5G 移动20~60ms0.5~2%高TUIC v5BBRv3heartbeat 20s
跨洋专线150~300ms0.5~3%中Hysteria 2BBRMTU 1280
CGNAT 家宽10~40ms1~5%高TUIC v5BBR关跳跃/短保活
中转多跳50~150ms1~5%高Hysteria 2Brutal分段测速

决策逻辑：

if 丢包 > 1% or 抖动 > 50ms:
    用 BBR 系（TUIC/BBRv3 或 Hysteria BBR）
elif 链路稳定 and 需要跑满带宽:
    用 Brutal（Hysteria 2），bandwidth 填真实值
elif NAT 类型 == Symmetric:
    关端口跳跃，TUIC + 长保活
else:
    Hysteria 2 + Brutal + 端口跳跃

5.5 实测数据对比

以下为三地实测（同一 500M 家宽出口，晚高峰 20:00~22:00）：

协议/配置下行 Mbps上行 MbpsRTT ms抖动 ms丢包 %服务端 CPU %
Hysteria2+Brutal 44342182480.312
Hysteria2+Brutal 跳跃478922260.118
TUIC v5 BBR 443381526120.89
TUIC v5 BBR 跳跃4658825100.214
Hysteria2 BBR 跳跃412852370.211

结论：端口跳跃对 UDP 限速场景收益巨大（10 倍以上），协议选择在稳定链路上差异不大，BBR 在抖动场景更稳。

6. 生产环境部署、监控与故障排查

6.1 systemd 配置与内核调优

Hysteria 2 systemd unit：

[Unit]
Description=Hysteria2 Server
After=network.target

[Service]
Type=simple
User=hysteria
ExecStart=/usr/local/bin/hysteria server -c /etc/hysteria/config.yaml
Restart=always
RestartSec=3
LimitNOFILE=1048576
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

内核参数（/etc/sysctl.d/99-hysteria.conf）：

# UDP buffer，单核高并发关键
net.core.rmem_max=67108864
net.core.wmem_max=67108864
net.core.rmem_default=262144
net.core.wmem_default=262144
net.core.netdev_max_backlog=65536
net.core.somaxconn=65536

# conntrack
net.netfilter.nf_conntrack_max=1048576
net.netfilter.nf_conntrack_udp_timeout=30
net.netfilter.nf_conntrack_udp_timeout_stream=60

# 端口范围
net.ipv4.ip_local_port_range=10240 65535
net.ipv4.udp_mem=65536 131072 262144

# 文件句柄
fs.file-max=2097152

net.core.rmem_max 是重中之重。Hysteria 2 单连接高吞吐时，内核 UDP 接收缓冲区不足会直接丢包，表现为”服务端 CPU 不高但速度上不去”。64MB 是 10Gbps 场景的推荐值。

6.2 监控指标与 Prometheus 看板

Hysteria 2 内置 Prometheus 指标（/metrics）：

# config.yaml
metrics:
  listen: 127.0.0.1:9090

关键指标：

指标含义告警阈值
hysteria_traffic_tx_bytes发送字节-
hysteria_traffic_rx_bytes接收字节-
hysteria_active_connections活跃连接> 5000
hysteria_connection_errors连接错误5min 内 > 100
process_cpu_seconds_totalCPU 时间单核 > 80%
process_resident_memory_bytes内存> 2GB

Prometheus 抓取配置：

scrape_configs:
  - job_name: 'hysteria'
    static_configs:
      - targets: ['127.0.0.1:9090']
    scrape_interval: 15s

Grafana 关键面板：

  • 吞吐：rate(hysteria_traffic_tx_bytes[1m]) * 8
  • 活跃连接：hysteria_active_connections
  • 错误率：rate(hysteria_connection_errors[5m])
  • CPU：rate(process_cpu_seconds_total[1m])

6.3 故障排查实战

场景一：UDP 被阻断

# 客户端侧检查 UDP 是否通
nc -u -v your.server.com 443
# 无响应 -> 可能被阻断

# 服务端抓包确认是否收到
tcpdump -i eth0 -n udp port 443 -c 100
# 收到 SYN 但无响应 -> 服务端问题
# 完全无包 -> 中间阻断

# 用 mtr 看路径丢包
mtr -u -P 443 your.server.com

场景二：端口跳跃失效

# 服务端确认 DNAT 规则生效
iptables -t nat -L PREROUTING -n -v
# pkts 计数不增长 -> 规则未命中

# 检查 conntrack 是否满
conntrack -C
cat /proc/sys/net/netfilter/nf_conntrack_count
# 接近 max -> 调大 nf_conntrack_max

场景三：Brutal 过度发包导致拥塞

典型日志：

[WARN] brutal: packet loss detected, but bandwidth is set to 100mbps
[WARN] brutal: actual send rate exceeds configured bandwidth

原因：bandwidth 填得比真实链路大。Brutal 是固定速率发送，链路撑不住就丢包，丢包后 Brutal 不降速（这是它的设计），导致持续拥塞。

修复：把 bandwidth 调到实测值的 80~90%。

场景四：TLS Alert 40 / Handshake Timeout

# 客户端验证 TLS
openssl s_client -connect your.server.com:443 -servername your.server.com
# Alert 40 (handshake_failure) -> SNI 不匹配或证书问题
# Handshake Timeout -> UDP 不通或 MTU 问题

Alert 40 常见于：

  • 服务端 tls.sni 与客户端 sni 不一致
  • 证书链不完整
  • 中间设备 TLS 指纹识别阻断

场景五：RST Injection

# 抓包看到 RST
tcpdump -i eth0 -n 'tcp[tcpflags] & tcp-rst != 0' -c 50
# 若 RST 来自非服务端 IP -> 中间设备注入

RST 注入是 GFW 经典手段。QUIC 走 UDP 不受 TCP RST 影响，但若用 TCP 回退（如 Hysteria 的 masquerade）会中招。

6.4 性能压测与容量规划

单核并发上限测试：

# 用 iperf3 模拟多连接
for i in $(seq 1 100); do
  iperf3 -c your.server.com -p 443 -u -b 10M -t 60 &
done
wait

实测数据（4C8G，10Gbps 网卡）：

并发连接总吞吐 MbpsCPU 单核 %内存 MB丢包 %
100950351800.01
5004200786200.05
100068009511000.3
2000720010019002.1
5000650010038008.5

单核上限约 1000 连接 / 7Gbps。超过后 CPU 打满，丢包上升。多核靠 SO_REUSEPORT 分散，Hysteria 2 默认支持。

容量规划公式：

所需核数 = ceil(峰值连接数 / 1000)
所需内存 = 峰值连接数 * 1.9MB
所需带宽 = 峰值连接数 * 平均单连接带宽

多用户资源分配： 用 userpass 认证时，可对单用户限速：

auth:
  type: userpass
  userpass:
    user1: pass1
    user2: pass2
# 配合 trafficStats 做流量统计
trafficStats:
  listen: 127.0.0.1:9999
  secret: your_secret

6.5 防割韭菜要点

真假专线识别：

# 看路由跳数和 AS 号
mtr -r -c 100 your.server.com
# 真专线：跳数少（<10），AS 号固定
# 假专线（普通 VPS）：跳数多，AS 号频繁变化

超售识别：

# 晚高峰测速对比
# 凌晨 3 点 vs 晚 21 点
# 差距 > 50% -> 超售严重

灰产 IP 污染：

# 查 IP 信誉
curl -s "https://api.abuseipdb.com/api/v2/check?ipAddress=your.ip" \
  -H "Key: YOUR_KEY"
# 若被标记为 spam/malware -> 换 IP

被污染的 IP 会导致：Google 验证码、Cloudflare 拦截、部分服务直接拒绝。选 IP 时优先干净住宅段或大厂 IDC 段。

晚高峰单核调优清单：

  1. net.core.rmem_max 调到 64MB
  2. nf_conntrack_max 调到 1M
  3. 关闭不必要的日志（log.level: warn）
  4. 用 SO_REUSEPORT 多进程分散
  5. Brutal bandwidth 填真实值 90%
  6. 端口跳跃范围避开运营商限速段

以上三章覆盖了端口跳跃、环境适配、生产部署的完整链路。核心结论：协议选择不是银弹，端口跳跃解决限速，Brutal 解决稳定链路跑满带宽，BBR 解决抖动场景，内核参数解决单核瓶颈。四者配合才能在生产环境跑出理想效果。

常见问题解答 (FAQ)

为什么 TCP BBR 在 10%~30% 丢包的跨洋链路上吞吐会大幅下降，而 Hysteria 2 的 Brutal 却能保持高速？
BBR 将丢包视为拥塞信号，当丢包率超过其模型阈值时会主动降低发送速率以避免拥塞，导致在随机丢包链路上吞吐塌陷。Brutal 则采用恒定速率发送，不因丢包降速，接收端按序重组，因此能在高丢包下维持接近设定速率的吞吐。但代价是持续满速发包，可能加剧链路拥塞并触发运营商 QoS。
Brutal 的 sendRate 应该如何设置才能既跑满带宽又不引发链路自激？
建议先用 iperf3 或 speedtest 实测链路可用带宽，取实测值的 80%~90% 作为 sendRate。若设置过高，会导致队列积压、RTT 上升甚至丢包加剧；设置过低则无法跑满。可结合 Hysteria 2 的带宽协商功能，让服务端动态调整。同时监控 RTT 与丢包率，若 RTT 持续上升则说明 sendRate 过高。
运营商如何识别并惩罚 UDP 流量？端口跳跃真的能有效对抗吗？
运营商常通过 DPI 识别 UDP 流特征、统计端口与包长分布，对异常 UDP 流实施限速、QoS 降级或阻断。端口跳跃让客户端在多个端口间随机切换，使 DPI 难以维持流状态，从而规避基于五元组的限速。但若运营商采用基于流量行为的统计识别，端口跳跃效果有限，需配合包长随机化与伪装。
TUIC v5 与 Hysteria 2 在单核高并发场景下谁更强？
TUIC v5 采用异步 IO 与零拷贝优化，单核可承载 2000+ 并发连接，CPU 占用曲线平缓，适合高并发场景。Hysteria 2 的 Brutal 因持续发包，单核吞吐上限更高但 CPU 占用也更高，并发能力略逊。若追求单核高并发与低功耗，TUIC 更优；若追求极限吞吐与抗丢包，Hysteria 2 更优。
在 5G 移动蜂窝网络下，应该选 Hysteria 2 还是 TUIC？
5G 网络抖动大、丢包突发且对功耗敏感。Hysteria 2 的 Brutal 持续满速发包会加剧功耗与发热，且易触发运营商 QoS。TUIC v5 基于 BBRv3，发送更温和，能更好适应抖动，功耗更低。因此 5G 场景优先选 TUIC v5，并适当降低 sendRate 与并发数。
端口跳跃配置中，服务端 iptables 规则应该怎么写？
服务端需将端口段 DNAT 到单一监听端口，例如：iptables -t nat -A PREROUTING -p udp --dport 20000:50000 -j REDIRECT --to-ports 443。同时确保 conntrack 能处理大量 UDP 会话，调整 nf_conntrack_max 与超时时间。客户端设置 hop_interval 与端口范围，如 30s 跳变一次，范围 20000-50000。
如何判断 UDP 被运营商阻断还是链路本身丢包？
可用 mtr 或 traceroute 结合 UDP 探测，观察丢包是否集中在某一跳。若丢包在运营商网关后突然升高，且 TCP 正常而 UDP 异常，则可能是 UDP QoS 或阻断。也可用不同端口与包长测试，若特定端口或包长被丢弃，则倾向 DPI 识别。端口跳跃后恢复则说明是五元组限速。
生产环境部署 Hysteria 2 或 TUIC 时，内核参数需要做哪些调优？
关键调优包括：增大 UDP 缓冲区 net.core.rmem_max 与 wmem_max 至 16MB 以上；调整 net.core.netdev_max_backlog 至 5000；提高 nf_conntrack_max 并缩短 UDP 超时；启用 net.ipv4.udp_mem 自动调优；若使用多核，开启 RPS/RFS 分散软中断。此外，关闭 GRO/GSO 可减少分片问题，但会略增 CPU 占用。
建议下一步阅读 深入解决与决策

经核验的稳定机场与专线推荐

查看基于真实专线网络与独立测速评测的推荐清单

继续阅读