Appearance
Hysteria 2 协议深度解析，基于 Brutal 拥塞控制算法如何在垃圾网络中跑满千兆带宽？
⚡ 实测结论速览
Hysteria 2 是专门为应对极其恶劣的高丢包、高延迟跨境公网环境而诞生的杀手级协议。 它基于定制优化的 QUIC 协议栈开发，核心技术在于彻底摒弃了传统 TCP 将丢包与网络拥塞强行绑定的退避逻辑。
其自研的 Brutal 拥塞控制算法 允许用户根据自身物理带宽直接指定传输速率。即便在丢包率高达 25% 至 40% 的晚高峰严重劣质线路上，Hysteria 2 依然能以恒定速率持续推送数据并快速重传丢失分片，实现秒开 4K 乃至 8K 超清视频。
配合 端口跳跃（Port Hopping） 技术，Hysteria 2 能够每隔数秒或几十秒在服务端成千上万个连续 UDP 端口之间动态切换，从容破解国内部分省份运营商对单一 UDP 连接施加的暴力限速与断流惩罚。
跨境高丢包环境下传统 TCP 拥塞控制的死局
要理解 Hysteria 2 为什么能在糟糕的网络环境中创造吞吐速度奇迹，必须先看清传统 TCP 协议在长距离国际海缆互联中遇到的物理天花板。
TCP 协议诞生于数十年前的局域网与低速广域网互联时代。为了维护整个互联网的秩序，TCP 的核心设计哲学建立在谦逊克制的基础之上。
在 TCP 的世界里，传输两端的操作系统始终将数据包的丢失视为网络管道发生拥堵的绝对信号。无论是早期经典的 Reno、Cubic 算法，还是后来的复合型算法，一旦发送端连续检测到重传超时或重复确认，就会自动触发拥塞避免机制，将发送拥塞窗口直接减半甚至归零重新开始慢启动。
TCP Cubic / Reno 在丢包环境下的拥塞窗口退避折线：
拥塞窗口 (CWND)
▲
│ /│ /│ /│
│ / │ / │ / │
│ / │ (丢包退避) / │ (丢包退避) / │
│ / │ 窗口减半 / │ 窗口减半 / │
│ / └───┐ / └───┐ / └───┐
│ / │ / │ / │
│ / └───/ └───/ └───
└─────────────────────────────────────────────────► 时间
[网络明明带宽充足，仅因随机干扰丢包导致传输速率长期趴在谷底]在普通的同城光纤网络中，这种退避机制是合理的，因为现代局域网极少出现无故丢包，丢包通常意味着交换机缓冲区确实溢出了。
但在跨境跨洋网络通信中，情况发生了根本性逆转。数据包需要跨越数千公里的海底光缆，途经多个国家的骨干网自治系统（AS）。
在晚高峰时段，国际出口交换节点存在巨大的物理排队延迟，再加上境内各省骨干网的随机干扰、线路衰减以及审查过滤器的状态检测开销，丢包的产生往往是随机丢包，绝非两端主机的带宽被耗尽。
面对 10% 乃至 20% 的随机物理丢包，传统的 TCP 客户端会陷入惊恐失措的自我怀疑中。发送端不断主动减小发包速率，原本一条物理带宽高达 500Mbps 的联通或电信出口线路，在 Cubic 算法的反复折半退避下，实际可用吞吐量往往被压制在不足 5Mbps，连播放最基础的 1080P 视频都会频繁转圈缓冲。
为什么 Google BBR 依然无法拯救劣质线路
为了解决传统 TCP 算法只看丢包不看带宽的盲目性，Google 在多年前推出了革命性的 BBR 拥塞控制算法。
BBR 的核心改进在于不再将随机丢包作为减少发包的直接触发条件。它通过持续探测链路的最小往返时延（MinRTT）和最大交付速率（BtlBw），计算出一个理论上最佳的发包节奏，引导数据流在刚好填满网络管道而不在交换机堆积缓冲区的前提下高速运行。
在国际直连精品线路（如 CN2 GIA、AS9929、CMIN2）上，BBR 能够发挥极其出色的提速效能。
然而，在面对晚高峰大面积严重拥堵的普通线路（如普通电信 163 骨干网）时，BBR 也存在难以逾越的局限。
主流拥塞控制算法在不同跨境丢包率下的吞吐保持率实测对比：
实际吞吐量 (相对千兆带宽占比)
100% ┌───────────────────────────────────────┐
│ ===== Hysteria 2 (Brutal 固定发包速率) │
80% │ ═══════════════════════════╗ │
│ ╚════════╗ │
60% │ ----- Google BBR v3 (探测式) ╚═│
│ -------------------\ │
40% │ \ │
│ \ │
20% │ ..... TCP Cubic (传统折半退避) │
│ ........\ │
0% └───────────┴───────────┴───────────┴───┴───────► 链路随机丢包率
5% 15% 30% 40%BBR 依然受到标准 TCP 协议框架的严密束缚。
第一，BBR 在其内部状态机的 ProbeRTT 阶段，必须定期将传输通道排空以重新测算最小物理延迟。当链路丢包率超过 15% 时，丢包引发的确认包（ACK）延迟到达会严重扰乱 BBR 对链路交付速率的估算，导致 BBR 误判物理带宽已经收窄，从而被迫调低目标运行速率。
第二，TCP 的序列号确认机制决定了它存在严重的队头阻塞（Head-of-Line Blocking）。如果编号靠前的一个数据包在海缆中丢失，后方已经成功到达接收端网卡的大量数据包只能停留在内核套接字缓冲区中苦苦等待，无法递交给上层应用程序消费。这种等待重传的时间差直接抵消了 BBR 的发包优势。
Hysteria 2 与 Brutal 拥塞控制的暴力美学
面对传统 TCP 在劣质网络中的束手无策，Hysteria 项目走出了一条完全不同的技术路径。它直接抛弃了操作系统的内核态 TCP 协议栈，全面基于 UDP 协议构建自己的用户态传输引擎。
在 2.0 版本中，Hysteria 引入了专门设计的 Brutal 拥塞控制算法。
Brutal 这个词在英文中直译为野蛮、残酷。这个命名极其传神地概括了该算法的运行性格。它完全不理会传统学术界关于拥塞避免的各种试探性假说，采取了一种绝对务实的暴力发包策略。
Brutal 拥塞控制算法发包节奏控制模型：
[用户在客户端本地显式配置：物理下载 500Mbps / 上传 50Mbps]
│
▼
[计算每秒应发送的总数据量目标]
│
▼
┌──────────────────────────────────┐
│ Brutal 高精度微秒级定速发包器 │
└──────────────────────────────────┘
│
┌───────────────────────┴───────────────────────┐
▼ ▼
【发送全新应用数据包】 【检测到历史丢包重传】
│ │
按照固定时钟周期均匀喷射 利用预留冗余带宽插队重发
│ │
└───────────────────────┬───────────────────────┘
│
▼
[完全无视海缆丢包率，哪怕丢包 30%，依然以满速 500Mbps 强行灌入]
│
▼
[接收端只要收到 70% 的数据即可，丢失的 30% 借助极速插队补齐]1. 放弃盲目猜测，由用户精确告知物理带宽
传统算法之所以总是猜不准带宽，是因为算法运行在两端，隔着重重大洋，只能通过发包和回包的时间差来反推管道宽度。
Brutal 彻底颠覆了这种模式。在 Brutal 的运行逻辑中，网络两端不再猜测。使用者的家庭宽带究竟是多少兆（例如签约下行 500Mbps、上行 50Mbps），直接通过配置文件白纸黑字明确写入。
服务端与客户端在握手初期就同步了这个数值。服务端获知客户端的物理下行能力是 500Mbps 后，便直接将内部的定时器频率调校到每秒必须均匀发送对应体量的数据包。
2. 丢包不减速，以速率补偿压垮丢包
当海缆或中间路由器丢包时，Brutal 绝对不会做出任何降速动作。
如果链路发生了 20% 的丢包，按照 Brutal 的计算模型，为了让客户端最终完整拿到 500Mbps 的有效载荷，服务端甚至会更加积极地调度发包引擎，在主干数据流中以极高优先级插入丢失分片的重传数据，以持续不断的数据流填满整个网络间隙。
对于接收端而言，只要物理光纤没有彻底被切断，连续的高频 UDP 数据包就会像暴雨一样倾泻而入。依靠用户态协议栈快速组装分片，应用程序几乎感受不到任何因为等待丢包重传而引发的卡顿。
3. 微秒级数据包平滑调度（Pacing）
暴力发包并不等于毫无章法的瞬时洪水。如果将几千个数据包在几毫秒内同时抛向网卡，本地路由器或运营商的光猫交换芯片会因瞬间队列溢出而自行丢包。
Brutal 的核心工程难点在于平滑发包（Pacing）。它利用现代操作系统的高精度事件循环，将每秒需要发送的数据均匀切割为微秒级的发送单元。
每个微秒窗口只发出限定数量的 UDP 报文，使得数据流在网线上呈现出极其均匀的流水状，既吃满了链路的全部物理潜能，又规避了突发微突发（Micro-burst）对网络硬件缓冲区的冲击。
端口跳跃（Port Hopping）对抗运营商 UDP QoS 实测
然而，国内各省运营商针对 UDP 流量实施的策略性限制（即 QoS，服务质量调度），给长距离传输带来了更直接的挑战。
在许多省份的电信、联通以及移动宽带中，网络运维系统部署了深度流量分析设备。在运营商眼中，正常的公网 UDP 流量主要由两部分构成，一是 DNS 查询（请求极小且瞬时结束），二是语音通话或网络对战游戏（带宽通常仅有几百 Kbps，且码率极其稳定）。
如果运营商的网关设备监测到某个国内家庭 IP 正在向境外单一 VPS 的特定 UDP 端口（例如固定 443 端口），持续进行长达数分钟、带宽高达 100Mbps 以上的狂暴传输，系统会立即触发防范异常 UDP 泛洪或封锁非法代理的流控规则。
运营商对单端口 UDP 流量的典型流控惩罚曲线：
传输带宽 (Mbps)
▲
│ ┌────────────┐ (启动连接前 30 秒跑满 300Mbps)
│ │ │
│ │ └─────────┐ (第 60 秒触发单五元组流量限额)
│ │ │
│ │ └──────────┐ (第 90 秒限速至 10Mbps)
│ │ │
│ │ └─── (降至 1Mbps 甚至直接丢弃阻断)
└───┴───────────────────────────────────────► 持续连接时间 (秒)常见的惩罚手段包括两类。轻则直接将该连接的传输速率强行打压至 1Mbps 以下，重则直接向客户端伪造 ICMP 端口不可达报文，切断该五元组的全部通信长达数十分钟。
为了彻底摧毁运营商基于五元组的流控策略，Hysteria 2 在协议核心原生引入了 端口跳跃（Port Hopping） 机制。
1. 端口跳跃的工作逻辑
端口跳跃的本质是打一枪换一个地方。
在传统代理中，客户端与服务端的连接始终固定在同一个端口上。而在启用了端口跳跃的 Hysteria 2 架构中，服务端会向客户端开放一个巨大的端口范围（例如从 20000 端口一直到 50000 端口，涵盖整整三万个可用端口）。
Hysteria 2 端口跳跃动态切换拓扑图：
[客户端 Hysteria 2 内核]
│
├── [00:00 - 00:30] 通过端口 21450 发送大流量数据 ───> [运营商 QoS 策略刚准备激活限速]
│ │ (切换时限已到)
├── [00:31 - 01:00] 自动瞬时跳跃至端口 48920 ────────> [运营商识别为全新连接，限速重置]
│ │ (再次切换)
└── [01:01 - 01:30] 自动瞬时跳跃至端口 32115 ────────> [持续逃脱状态检测窗口]客户端与服务端在初次握手时协商一个伪随机跳跃算法和时间窗口（例如每 30 秒跳跃一次）。
当时间到达设定的间隔时，客户端会在毫秒级别内将后续发送的 UDP 数据包的目标端口无缝切换到新的端口上。
由于 Hysteria 2 的 QUIC 连接内部依靠 Connection ID（连接唯一标识符）来辨识会话归属，底层物理端口的变更完全不会中断上层的传输会话。TCP 握手如果更换端口必须断开重连，而 QUIC 原生支持连接迁移（Connection Migration），这种切换对浏览器和视频流而言是完全无感的。
对于运营商的网关监控系统而言，前一个端口的流量刚刚开始累积，连接就已经主动结束了。新出现的流量是一个全新的目的端口，防火墙的限速计数器必须重新开始累积计算，从而永远无法对你的大流量施加有效的限速处罚。
端口跳跃 Linux 服务端网络重定向实战配置
要在服务端实现成千上万个端口的监听，最愚蠢的做法是在应用程序中真正创建几万个 Socket，这会瞬间耗尽系统的文件描述符与内存。
优雅高效的做法是，Hysteria 2 服务端依然只监听一个主端口（例如 443），随后利用 Linux 内核自带的高性能数据包过滤引擎（iptables 或新一代 nftables），在数据包刚进入网卡内核态（PREROUTING 链）时，将整个大端口区间的全部 UDP 报文瞬间重定向至主监听端口。
以下为两种主流防火墙体系的具体配置实操。
1. 基于 iptables 的端口映射规则写入
如果你的 Linux 系统（如 Ubuntu 20.04 / Debian 11）仍然使用传统的 iptables 管理网络，只需执行一条 NAT 表转发规则。
假设你的服务器外网物理网卡名称为 eth0，Hysteria 2 监听的主端口为 443，希望对外开放的跳跃端口范围为 20000 至 50000。
bash
# 将 20000 到 50000 端口收到的全部 UDP 数据包重定向到本地 443 端口
sudo iptables -t nat -A PREROUTING -i eth0 -p udp --dport 20000:50000 -j REDIRECT --to-ports 443
# 保存 iptables 规则以防止重启失效
sudo apt-get install -y iptables-persistent
sudo netfilter-persistent save2. 基于现代 nftables 的高效配置写法
在较新的 Debian 12 或 Ubuntu 22.04+ 系统中，nftables 已经全面取代 iptables 成为底层默认引擎。nftables 的规则评估速度更快，且对范围匹配有原生优化。
编辑 /etc/nftables.conf 文件，在相应位置添加 NAT 重定向表。
text
table inet nat {
chain prerouting {
type nat hook prerouting priority dstnat; policy accept;
iifname "eth0" udp dport 20000-50000 redirect to :443
}
}修改完成后，在终端中执行加载命令使其立即生效。
bash
sudo nft -f /etc/nftables.conf此时外部网络只要向这台服务器的 20000 至 50000 之间的任意 UDP 端口发送数据，Linux 内核都会在零开销下直接把数据送入运行在 443 端口上的 Hysteria 2 进程中。
真实生产级 Hysteria 2 服务端与客户端配置全解
编写一份规范且经过安全加固的配置文件，是发挥 Hysteria 2 全部性能的基石。
1. 官方生产级 server.yaml 配置文件
在服务器的 /etc/hysteria/server.yaml 路径下，写入以下标准配置。
yaml
# 监听的主端口
listen: :443
# 证书配置：推荐使用合规的自有域名并申请正式证书，或在此处指定已有证书路径
tls:
cert: /etc/letsencrypt/live/myhy2.mydomain.com/fullchain.pem
key: /etc/letsencrypt/live/myhy2.mydomain.com/privkey.pem
# 认证机制：配置高强度密码防盗刷
auth:
type: password
password: "MySuperStrongPassword_998811"
# 流量混淆配置：混淆密码能彻底打碎 QUIC 协议原生的 ClientHello 握手报文特征
obfs:
type: salamander
salamander:
password: "MyObfsSalamanderPass_665544"
# QUIC 底层参数调优
quic:
initStreamReceiveWindow: 8388608
maxStreamReceiveWindow: 8388608
initConnReceiveWindow: 20971520
maxConnReceiveWindow: 20971520
maxIdleTimeout: 30s
keepAlivePeriod: 10s
# 伪装网站设置：针对非法 HTTP 探测返回标准的防盗伪装页面
masquerade:
type: proxy
proxy:
url: https://www.bing.com
rewriteHost: true
# 日志输出等级
log:
level: warn2. 客户端标准配置文件写法（带端口跳跃与带宽约束）
客户端配置是 Brutal 拥塞控制能否跑满千兆带宽的关键。客户端必须诚实告诉服务端自己的上下行极限。
以下是客户端的标准 config.yaml 示例。
yaml
# 目标服务器地址：在此处直接启用端口跳跃范围
server: myhy2.mydomain.com:20000-50000
# 身份鉴权信息
auth: "MySuperStrongPassword_998811"
# 混淆密码：必须与服务端完全一致
obfs:
type: salamander
salamander:
password: "MyObfsSalamanderPass_665544"
# TLS 协商安全设定
tls:
sni: myhy2.mydomain.com
insecure: false
# 核心 Brutal 拥塞控制带宽配置
# 根据本地实际宽带能力填写（假设本地为千兆下行、50兆上行宽带）
bandwidth:
up: 45 mbps
down: 850 mbps
# 本地监听接口（供浏览器或系统代理使用）
socks5:
listen: 127.0.0.1:10808
http:
listen: 127.0.0.1:10809
# 优雅处理连接超时与快速重连
fastOpen: true
lazy: true在客户端配置中，有两个参数需要严密把握。
其一，server 字段中的端口写法。通过使用类似 20000-50000 的范围语法，Hysteria 2 客户端会自动在内部激活端口跳跃子程序，按照内置的动态时间步长在各个端口间无缝跃迁。
其二，bandwidth 字段的上下行速率数值设定。许多初学者存在一个致命误区，认为直接填上 10000 mbps（万兆）就能获得极速。这种做法会导致灾难性的反噬。
如果你的本地家庭物理带宽实际只有 300Mbps，而你强行告诉服务端按照 1000Mbps 发包，服务端会以每秒 1000Mbps 的极高密度持续向你的光猫倾泻 UDP 报文。
由于物理网线和光猫芯片无法处理如此庞大的吞吐量，多余的数据包会在光猫入口被硬件直接丢弃。结果是人为造成高达 70% 的虚假丢包率，不仅本地网络完全瘫痪，发出的网页请求也会因严重的网卡队列阻塞而彻底打不开。
正确的做法是测算本地日常的物理带宽，将 down 设为物理签约下行速率的 85% 至 90%，将 up 设为物理签约上行速率的 90%，为网络抖动留出少许缓冲余量，这才是实现跑满千兆且丝滑稳定的黄金法则。
主流代理协议全维度参数横向对比
为了让读者在自建协议选型中具备全局视角，以下将 Hysteria 2 与目前常见的其他主流协议进行深度对比。
| 评估维度指标 | Hysteria 2 (Brutal) | TUIC v5 (BBR/Cubic) | VLESS-Reality (Vision) | WireGuard (标准UDP) | Shadowsocks 2022 |
|---|---|---|---|---|---|
| 底层通信协议栈 | 定制高性能 QUIC (UDP) | 标准 QUIC 协议栈 (UDP) | 原生 TCP (XTLS 零拷贝) | 内核态虚拟网卡 UDP | 原生 TCP 或标准 UDP |
| 拥塞控制算法机制 | Brutal 固定速率发包 | 依赖 BBR 或 Cubic 探测 | 依赖操作系统原生 TCP 算法 | 内核固定拥塞算法 | 依赖系统底层 TCP 栈 |
| 抗恶劣丢包能力 | 极强（35% 丢包仍满速） | 强（20% 丢包较平稳） | 较弱（丢包超 10% 剧烈减速） | 较差（丢包无补偿机制） | 极差（丢包引发 TCP 阻塞） |
| 对抗运营商 QoS 限速 | 极强（原生端口跳跃） | 较弱（依赖固定单端口） | 不适用（TCP 流量无此限制） | 极差（极易触发持续封锁） | 极差（单一端口持续高吞吐） |
| 流量混淆隐蔽能力 | 极高（Salamander 混淆） | 中等（标准 TLS 1.3 握手） | 极高（借用正规大站证书） | 极低（特征明文完全裸奔） | 中等（全密文特征已被打标） |
| CPU 与硬件资源开销 | 中等（用户态重传调度） | 中等（QUIC 加解密负载） | 极低（硬件 AES 与流控直通） | 极低（直接运行在内核态） | 极低（轻量对称加密指令） |
| 最佳推荐应用场景 | 晚高峰严重丢包的低配线路 | 跨境延迟相对稳定的直连线 | 高墙严密监控的常规直连 VPS | 境内专线内网互通与穿透 | 机场企业中转专线网络出口 |
流量混淆 Salamander 与主动探测防御策略
除了在吞吐能力上碾压传统协议，Hysteria 2 在抵御审查系统主动识别与端口测绘方面同样部署了多重防御手段。
1. Salamander 混淆机制的工作机理
标准的 QUIC 协议在公网传输时，尽管应用数据完全由 TLS 1.3 进行高强度加密，但其握手初期的初始数据包（Initial Packet）头部依然保留了少量的固定标记与明文标志位，以便网络中间的合法路由器了解会话状态。
然而，审查系统正是利用这些细微的明文特征来归类识别 QUIC 流量的。一些省份的防火墙一旦发现未知的境外 QUIC 握手包，就会直接实施丢弃策略。
Hysteria 2 独创的 Salamander 混淆技术，在标准 QUIC 报文的最外层引入了一套极轻量的对称密码置换算法。
经过 Salamander 混淆后的数据包，其原有的 QUIC 协议头特征被彻底抹去，整个数据包在中间路由设备看来完全就是一串毫无规律的纯随机二进制噪音。审查系统的深度数据包检测（DPI）引擎无法将其解析为任何已知的协议，只能将其当作无害的随机 UDP 报文放行。
2. 伪装网站反向代理与探针陷阱
在服务端的 masquerade 配置中，Hysteria 2 提供了完备的反代伪装能力。
当审查系统或安全公司的网络测绘脚本通过 HTTP 或 HTTPS 协议主动向你的服务器 443 端口发起探测时，Hysteria 2 会首先尝试剥离外层鉴权。
如果发现请求中没有正确的认证密码，服务端的伪装引擎会自动将该请求反向代理到你在配置中指定的合规大站（如必应搜索 https://www.bing.com），并将必应的真实页面内容与 HTTP 状态码原封不动返还给探测器。
探测者看到的完全是一个正常的公共 Web 页面，无法取得任何证据来判定这是一个运行了代理后门的私人服务器。
常见故障排查与性能调优指南
在部署和运行 Hysteria 2 的过程中，如果遇到连接异常或速度未达预期，可以依序按以下步骤排查。
1. 客户端频繁提示 timeout: no recent network activity
这种现象代表客户端发出的 UDP 数据包未能成功送达服务端，或者服务端的应答数据包无法送回客户端。
第一步，检查服务端的云安全组。登录云服务商后台控制台，确保实例安全组中已经将对应的 UDP 端口（或端口跳跃范围，如 UDP 20000-50000）明确加入入站放行规则中。许多人仅放行了 TCP 协议，而遗漏了 UDP 协议。
第二步，检查本机是否开启了可能劫持网络驱动的杀毒软件或第三方防火墙。部分 Windows 安全管家会默认静默拦截未签名的本地 UDP 高频外发数据包，需要在安全软件中为 Hysteria 2 客户端程序添加信任。
2. 测速延迟极低但无法加载任何大图片或视频流
这通常是网络链路的最大传输单元（MTU）设置过大导致的路径分片丢弃。
UDP 报文如果体积超过了中间路由器的 MTU 上限，会被强行分片。而在某些劣质公网路由器上，分片后的 UDP 报文常常被直接丢弃，导致大流量数据帧无法完整组装。
解决办法是在客户端配置文件中显式降低 MTU 数值。默认情况下 Hysteria 2 尝试协商较大的传输单元，可以尝试在配置文件中添加 hopInterval 以及手动调整系统的网卡 MTU，或者在配置中将 UDP 最大数据包大小约束在 1200 字节至 1280 字节的安全区间内，即可立即化解大包被丢弃的困境。
常见问题解答 (FAQ)
为什么说 Brutal 算法在某些人看来是不讲道德的？
传统互联网的健康运行依赖所有终端都遵循 TCP 的退避礼仪。当网络堵车时，大家都主动放慢车速，道路就能逐渐恢复畅通。而 Brutal 拥塞控制算法则是特权模式，无论前方道路多拥挤，它依然按照设定的满速持续向前冲刺，并通过高频插队重传来保证自己的通过效率。这在客观上会进一步挤占同线路上其他正常使用 TCP 协议用户的可用带宽，因此在网络工程学术界常被称为自私型拥塞控制。但对于处于恶劣跨境网络环境中的普通网民而言，这是突破线路人为劣化限制的最强手段。
端口跳跃会增加服务端的 CPU 和内存消耗吗？
完全不会。得益于 Linux 内核强大的 netfilter 架构，端口跳跃的重定向工作在操作系统底层内核态的 PREROUTING 阶段就已经瞬间完成。所有的端口变换只是修改了数据包头部的几个字节的目标端口信息，随后直接交付给原本就在监听主端口的单一进程。服务端并没有创建几万个独立的应用程序监听线程，因此即使在只有 512MB 内存的入门级 VPS 上运行，整体内存占用通常也只有区区二三十兆。
Hysteria 2 跑满千兆带宽会对服务器 VPS 产生什么负面影响吗？
必须特别关注 VPS 的月度流量限额。由于 Brutal 算法在丢包环境下会持续进行强力发包与重传，如果你的 VPS 每月只有 500GB 或 1TB 的流量配额，全天候挂载大流量下载或长时间跑超清流媒体，可能在短短几天内就会将当月流量额度彻底耗尽。此外，某些廉价 VPS 厂商对持续的单机高网卡吞吐有严格的限速策略（如连续跑满 100Mbps 超过 15 分钟触发降速），建议选购不限流量或流量宽裕的主机产品。
在公司的内网环境下为什么 Hysteria 2 经常完全连不上？
许多大型跨国企业、金融机构或高校的园区内网部署了极其严格的企业级企业防火墙。出于内网安全与防止数据外泄的考虑，这类防火墙在出口网关处采取了严格的默认拒绝策略，通常只放行 TCP 80（HTTP）、TCP 443（HTTPS）以及极少数已知的业务端口，对所有未经报备的对外 UDP 流量直接实施全阻断。在完全封死 UDP 协议的企业内网中，所有基于 UDP 的方案（包括 Hysteria 2、TUIC、WireGuard）都会彻底失效。此时只能退回至使用标准的基于 TCP 的 VLESS-XTLS-Reality 协议。
Hysteria 2 与 TUIC 协议同为基于 QUIC 的方案，它们的核心区别是什么？
核心区别在于拥塞控制算法和流量调度哲学。TUIC 协议力求在标准 QUIC 规范框架内做优化，它主要依赖 BBR 或 Cubic 算法来平滑发包，追求的是协议规范性和对多路复用连接的精细调度，更适合延迟相对平稳、丢包率较低的高端直连专线。而 Hysteria 2 则是一台纯粹为了突破恶劣环境而深度改装的重装战车，它彻底解除了发包限制，通过 Brutal 暴力定速和端口跳跃，专门解决高丢包、晚高峰大拥堵与运营商 QoS 恶劣限速等棘手场景。