Hysteria2 是什么？QUIC 协议特点、速度与适用网络环境分析

传统 TCP 协议的物理枷锁与队头阻塞#

自 1980 年代确立以来，TCP 协议一直作为互联网可靠传输的核心基石。然而，TCP 的所有设计前提均基于一个历史假设：“丢包必然意味着网络链路发生了拥塞，发送端必须立刻降速退让”。

在跨国长途网络中，这一假设造成了灾难性的后果：

1. 拥塞控制窗口暴跌惩罚：传统的 Cubic 算法一旦检测到丢包，立即将慢启动拥塞窗口减半；哪怕是较为先进的 BBR 算法，在高丢包率环境下也会因为往返时延（RTT）采样失真而大幅收缩发包步调；
2. 多路复用下的致命队头阻塞（Head-of-Line Blocking）：为了节省握手开销，现代代理协议普遍采用多路复用技术将用户的几十个网页请求合并进一条 TCP 连接。然而在 TCP 内部，所有数据流共享单一序列号空间。一旦排在前面的某个数据包发生偶发丢失，接收端操作系统协议栈必须将后续到达的所有有效数据包全量扣留在内核缓冲区中，直到丢失的那个数据包经过漫长的跨洋往返重传成功后，才允许向应用层交付。这意味着单个数据包的丢失会导致整条代理连接瞬间假死。

QUIC 协议的救赎与 Hysteria 的重构#

为了彻底砸碎 TCP 历史包袱的枷锁，Google 与 IETF 联合推出了基于 UDP 构建的全新传输层协议：：QUIC（RFC 9000），并将其确立为下一代 HTTP/3 的核心载体。

开源极客团队敏锐地捕捉到了 QUIC 协议在网络代理领域的无限潜力，推出了专为恶劣网络对抗而生的 Hysteria 协议。而在经历了初代版本的技术探索后，团队推出了完全重构的 Hysteria 2：

• 完全解除了对传统 HTTP 伪装库的依赖：重新设计了更加干净精简的传输层协议头；
• 全量标准化 QUIC 帧：完全内嵌 TLS 1.3 原生安全握手，兼具极高的密码学安全性与抗指纹能力；
• 独树一帜的暴力吞吐哲学：将 QUIC 协议的灵活控制机制发挥到了极致，创造性地引入了基于用户带宽主动声明与恒定速率步调的 Brutal 拥塞控制算法。

QUIC 多流复用消灭队头阻塞#

在 Hysteria 2 的架构中，每个由客户端发起的代理连接（例如打开一个网页中的单独图片），都会在底层的 QUIC 隧道中被映射为一个独立的 QUIC Stream（单向或双向流）：

1. 流级别独立序列号：每个 Stream 拥有独立的字节偏移量标识，流与流之间在逻辑上完全隔离；
2. 丢包零波及：当某个 Stream 的数据包在公网遭遇丢包时，QUIC 仅触发该特定流的数据重传，其他正在并行传输视频或文字的 Stream 完全不受任何干扰，数据能够被对端操作系统毫秒级提取并交付给上层应用；
3. 极速 0-RTT / 1-RTT 握手：QUIC 将传输层握手与 TLS 1.3 密码学握手合并为单一时序阶段，使得连接建立仅需 1 个甚至 0 个往返时延（RTT），消除了传统 TCP+TLS 繁琐的多轮握手折磨。

原生集成 TLS 1.3 与连接迁移（Connection Migration）#

Hysteria 2 的安全层并非像传统代理那样在外层套接第三方程序，而是由 QUIC 规范原生深度内嵌：

• 全密文报头防护：除了极少量的底层路由字段外，QUIC 报文的大部分标志位与序列号全部处于强加密保护之下，公网中间人与审查设备根本无法通过明文报头嗅探会话状态；
• 连接迁移特性（Connection Migration）：这是 QUIC 协议最震撼的移动端体验提升。在传统的 TCP 代理下，当手机从 Wi-Fi 切换为 5G 移动蜂窝网络时，手机的公网 IP 发生变更，底层的 TCP 套接字会瞬间断开，正在下载的文件或视频必须从头重连；而 QUIC 使用不依赖于 IP 地址的 64 位 Connection ID（连接标识符） 追踪会话。无论用户的物理网络接口如何在 Wi-Fi、4G、5G 之间频繁跳跃切换，底层的 Hysteria 2 代理长连接均能保持绝对在线且无缝流转，彻底消除了网络切换时的卡顿断连。

传统拥塞控制被动退让的逻辑破绽#

在公共国际出口网络中，丢包的成因极其复杂。除了真正的“路由器缓冲区溢出”之外，还有大量的丢包是由**“跨洋长途海缆物理光衰”、“国际路由跨网抖动”以及“运营商骨干网故意针对国际出口实施的被动丢包整形”**所引发的。

传统算法无法区分丢包的真实原因，只要遇到丢包一律视为严重拥塞并主动减速退让。这就掉入了恶劣公网的陷阱：公网稍微抖动一下丢了两个包，客户端就主动把速度从 100Mbps 降到了 5Mbps，导致大好物理宽带被彻底闲置。

Brutal 算法的恒定速率步调与主动补偿机制#

Brutal 算法彻底打破了这种被动退让的陈旧逻辑。其核心逻辑建立在**“精准的恒定速率发包（Fixed Pacing Rate）与动态丢包补偿模型”**之上：

1. 客户端主动宣告物理带宽：在建立连接时，客户端明确告知服务端自身的本地下载带宽能力（例如 up: 50 mbps, down: 300 mbps）；
2. 服务端恒定速率灌流：服务端完全忽略任何基于丢包惩罚的拥塞窗口收缩逻辑，而是严格按照用户声明的物理带宽速率，以极高精度的纳秒级硬件定时器（Pacing Timer）持续向用户下发 UDP 数据报；
3. 动态丢包超额补偿公式：当服务端通过 QUIC ACK 反馈检测到当前链路存在丢包率 $P_{loss}$ 时，为了保证客户端的应用层实际收到足额的有效载荷，服务端会动态调整实际的发包速率 $R_{send}$：

R_{send} = rac{R_{target}}{1 - P_{loss}}

举例说明：如果用户购买了 300 Mbps 的下行宽带，而当前跨洋公网的物理丢包率高达 20%，传统 BBR 算法可能只能跑出不到 10 Mbps 的可怜速度；而 Hysteria 2 服务端会直接以近 375 Mbps 的暴力发包速率全速倾泻数据报，在剔除掉途中丢失的 20% 报文并毫秒级补发缺失分片后，用户本地实际有效吞吐依然能够稳稳跑满 300 Mbps 物理满速！

运营商 UDP 封锁状态机的工作原理#

国内部分省份的运营商在国际出口部署了智能流量分析网关。当网关检测到某个本地 IP 正在向境外服务器的单个固定 UDP 端口持续以几百兆的速率疯狂倾泻数据时，网关内的状态机便会报警，并在几分钟内对该四元组（源IP、源端口、目的IP、目的端口）执行惩罚性策略：

• 将该端口的丢包率强行提升至 70% 至 90%；
• 甚至直接重置 NAT 映射表，导致该端口的 UDP 数据报彻底无法进出。

端口跳跃的四两拨千斤#

为了瓦解这种针对固定端口的限速模型，Hysteria 2 创新性地引入了 动态端口跳跃（Port Hopping） 机制：

1. 服务端多端口范围监听：服务端通过 Linux 内核的 iptables 或 nftables 端口重定向功能，将庞大的高位端口池（例如 20000 到 50000 之间的数万个端口）全部透明重定向至 Hysteria 2 的实际监听端口；
2. 客户端自适应随机跳跃：客户端配置相同的端口范围，并在后台每隔设定的时间周期（如 30 秒到 60 秒）随机挑出一个全新端口，或者在检测到底层丢包率突发飙升时主动发起跳跃；
3. QUIC 连接无缝自愈：由于 QUIC 是基于 Connection ID 识别连接，底层的 UDP 物理端口切换对于上层长连接完全没有任何破坏。运营商的防火墙只能看到用户在不断向不同的高位端口发送短促的 UDP 数据包，原本蓄势待发的单端口 QoS 限制规则彻底扑空。

蝾螈（Salamander）混淆机制与 UDP 协议指纹擦除#

在极端严苛的网络监管环境中，部分先进的深度包检测设备不仅会针对流量端口进行追踪，还会针对标准 QUIC 协议的首包特征（如 Client Hello 内部固有的版本协商标识与初始数据包大小特征）进行启发式特征标记。为此，Hysteria 2 官方原生集成了代号为 Salamander（蝾螈） 的高级混淆扩展机制。

Salamander 混淆模块工作在 QUIC 报文进入物理网卡前的最外层：

1. 消除标准 QUIC 协议魔数：标准 QUIC 数据包头部通常包含公开已知的版本号字段（如 0x00000001 表示 RFC 9000 QUIC v1）。Salamander 混淆模块在发包前，利用由混淆密码派生出的伪随机掩码对整个数据包首部进行异或打散，使得外部嗅探器在解构报头时只能读到一团混乱的伪随机数据，无法命中任何已知 QUIC 协议特征码；
2. 计算开销极低：不同于重量级的二次对称加密，Salamander 核心采用极其轻量的流式异或扰动算法，在软路由或低功耗设备上运行几乎不产生额外的 CPU 算力损耗；
3. 服务端动态无损还原：服务端在接收到该数据报后，首先读取前置盐值并调用相同的混淆密钥逆向展开掩码，瞬间还原为合规的 QUIC 原始数据报并递交给底层 QUIC 状态机处理。

动态带宽自适应探测机制与长肥网络吞吐模型#

虽然 Brutal 算法在默认状态下依赖用户的主动带宽宣告，但在真实的异构网络环境中，用户的实际可用物理带宽可能随着网络环境的变化而发生剧烈波动（例如从千兆家庭宽带切换为移动热点）。为了避免在带宽骤降时由于盲目灌流引发恶性拥塞，Hysteria 2 引入了先进的 带宽自适应探测（Bandwidth Probing） 机制。

在连接建立初期与稳态运行过程中，Hysteria 2 客户端通过在数据流中穿插微型的探测采样帧，精确测量连续数据包之间的到达时延差（Inter-arrival Time）。当链路达到最大承载负荷时，中间路由器的硬件队列会开始堆积，导致 RTT 出现显著的非线性抬升。通过捕获该物理拐点，协议能够自适应将 Brutal 算法的发包上限动态锚定在物理容量的临界线上，从而在榨干带宽的同时彻底避免缓冲区膨胀导致的局域网假死。

Linux 内核 UDP 环形缓冲区与软中断负载深度调优#

在高吞吐量的 Hysteria 2 生产环境中，当单机 UDP 传输速率突破 500 Mbps 甚至千兆满载时，Linux 操作系统的网络子系统极易在底层套接字层遭遇丢包。默认的 Linux 内核配置中，每个 UDP 套接字的读写缓冲区（rmem/wmem）通常仅有几十到两百 KB，面对突发到达的 UDP 报文洪峰，网卡中断处理函数（NAPI poll）若无法在纳秒级时间内将数据包交付给用户态的 Hysteria 2 进程，内核套接字缓冲区便会瞬间溢出并发生无声丢包（UDP Socket Drops）。

为了彻底根治高吞吐下的操作系统内核丢包，运维团队必须在系统层面将全局套接字缓冲区最大上限扩容至 8MB 以上，并开启网卡多队列与多核心软中断均衡绑定（RPS / RFS）。通过将网络处理中断均匀分发至各个 CPU 物理核心，彻底消除了单核软中断满载导致的算力瓶颈，确保万兆网络接口在面对海量高频 UDP 小包冲击时依然能够稳如磐石。

实战一 借助 iptables 部署服务端全范围端口跳跃重定向规则#

在配置 Hysteria 2 动态端口跳跃前，必须在 Linux 服务端配置内核级端口重定向：

1
# 1. 开启 Linux 内核 IPv4 数据包转发机制
2
sudo sysctl -w net.ipv4.ip_forward=1
3

4
# 2. 将外部 20000 到 50000 范围内的所有 UDP 入站报文重定向至 Hysteria 2 实际监听的 443 端口
5
sudo iptables -t nat -A PREROUTING -i eth0 -p udp --dport 20000:50000 -j REDIRECT --to-ports 443
6

7
# 3. 检查当前 iptables NAT 表重定向规则是否正确生效
8
sudo iptables -t nat -L PREROUTING -n -v --line-numbers
9

10
# 4. 调整内核 UDP 接收与发送套接字缓冲区最大上限，支持数万并发高带宽爆发
11
sudo sysctl -w net.core.rmem_max=8388608
12
sudo sysctl -w net.core.wmem_max=8388608

实战二 Hysteria 2 生产级服务端标准配置文件（带 HTTP 站点伪装）#

以下展示标准的 Hysteria 2 服务端配置（config.yaml），采用原生 TLS 证书并配置异常流量伪装：

1
# Hysteria 2 服务端标准生产配置
2
listen: :443
3

4
tls:
5
  cert: /etc/letsencrypt/live/hy2.example.com/fullchain.pem
6
  key: /etc/letsencrypt/live/hy2.example.com/privkey.pem
7

8
auth:
9
  type: password
10
  password: "SuperSecretHysteria2Password_2026_99x!"
11

12
masquerade:
13
  type: proxy
14
  proxy:
15
    url: https://news.ycombinator.com/
16
    rewriteHost: true
17

18
bandwidth:
19
  up: 1 gbps
20
  down: 1 gbps
21

22
speedTest: true

实战三 客户端 Clash / Mihomo 生产级 Hysteria 2 节点规范#

现代客户端中标准的 Hysteria 2 节点配置示例，包含多端口范围跳跃与带宽上限参数：

1
proxies:
2
  - name: 🇺🇸 美国 01 [Hy2 暴力突破高丢包]
3
    type: hysteria2
4
    server: hy2.example.com
5
    # 填入与服务端 iptables 对应的动态跳跃端口范围
6
    port: 20000-50000
7
    password: "SuperSecretHysteria2Password_2026_99x!"
8
    sni: hy2.example.com
9
    skip-cert-verify: false
10
    # 严格按照本地物理宽带实际能力申报，避免过度发包造成本地路由器拥塞
11
    up: "50 Mbps"
12
    down: "300 Mbps"
13
    obfs: ""
14
    client-fingerprint: chrome

实战四 运维排障命令行工具链深度巡检与 UDP 链路实测#

当 Hysteria 2 出现握手超时或网速不符合预期时，运维工程师应快速使用终端原生命令进行排查：

1
# 1. 检验 Hysteria 2 守护进程是否正常监听 UDP 443 端口
2
ss -ulpn | grep -E "443|hysteria"
3

4
# 2. 抓取网卡上针对跳跃端口池的 UDP 报文交互，确认端口跳跃是否正常流转
5
sudo tcpdump -i eth0 -nn "udp and (portrange 20000-50000 or port 443)" -c 10
6

7
# 3. 使用 iperf3 测量本地到服务器之间的基础 UDP 吞吐与单向物理丢包率
8
iperf3 -u -c hy2.example.com -p 5201 -b 100M -t 10
9

10
# 4. 实时查看 Linux 守护日志输出，追踪 Brutal 算法发包反馈与握手记录
11
journalctl -u hysteria-server.service -f -n 50

案例一 客户端带宽参数严重虚标导致本地软路由彻底死锁假死#

某用户在百兆家庭宽带环境下部署了 Hysteria 2 节点，为了追求所谓的极致速度，他在客户端配置中将下行带宽随意填写为 down: 2000 Mbps（2 Gbps）。在后续使用多线程下载大文件时，家庭网络突然全部瘫痪，软路由后台无法打开，所有手机和电脑断网长达两分钟。

故障深度排查： 排查团队分析发现：由于该用户虚标了 2 Gbps 的下载能力，Hysteria 2 服务端的 Brutal 算法便以高达 2000 Mbps 的恐怖恒定速率，疯狂向该用户的公网 IP 倾泻庞大的 UDP 数据包。 然而该用户的光纤猫和家用路由器仅具备百兆网口与极小的硬件数据包接收缓冲区。面对突如其来的每秒数十万个超额 UDP 报文冲击，家用路由器的内存和网卡接收环形缓冲区在几毫秒内被彻底打爆，触发了严重的缓冲区膨胀（Bufferbloat）甚至 Linux 内核套接字丢包风暴，导致整个局域网彻底假死崩溃。

最终解决方案： 指导该用户客观根据自己向电信运营商购买的真实物理带宽进行填写（修改为 down: 100 Mbps, up: 20 Mbps）。Brutal 算法的发包速率被精准限制在物理硬件承载能力之内，下载速度稳稳跑满百兆且家用路由器 CPU 负载恢复到 5% 以下。

案例二 跨网 UDP MTU 黑洞引发长视频加载超时#

某企业工程师在自建 Hysteria 2 节点用于跨国研发数据拉取时，在本地测试一切正常，但在拉取几百兆的大型 Docker 镜像层时，连接总是传输了几兆后便突发卡死，最终提示连接超时。

故障深度排查： 排查人员通过抓包发现：在传输大文件时，服务端发出的 UDP 报文接近标准以太网的 1500 字节 MTU 上限。然而该工程师本地宽带使用的是 PPPoE 拨号上网，其物理链路的最大传输单元（MTU）仅为 1492 字节，中途某些跨网路由甚至进一步缩减到了 1440 字节，且沿途有部分路由器关闭了 ICMP 差错回包通知（所谓的 MTU 黑洞）。 过大的 UDP 数据报在经过中间网络时由于无法分片被沿途路由器直接静默丢弃，导致大尺寸应用数据包根本无法送达客户端。

最终解决方案： 在客户端与服务端的配置文件中显式调小最大传输单元，设置客户端全局的传输单元限制（如将底层 QUIC 的 UDP MTU 显式限制为 1350 字节，预留充足的隧道封装余量），大文件下载卡死现象彻底杜绝。

案例三 运营商严厉 QoS 限速导致未开端口跳跃的单端口断流#

某用户在公网 VPS 上搭建了单端口运行在 UDP 443 上的 Hysteria 2 节点。每天晚上 20<00> 至 23<00> 的用网高峰期，节点只要看一分钟 4K 视频，延迟便瞬间从 150ms 飙升至 800ms，丢包率飙升至 90%，网速直接跌零，断开连接等待五分钟后重连又能恢复正常。

故障深度排查： 这是最典型的运营商级单端口智能 QoS 限速模型：晚间高峰期运营商针对跨国 UDP 大流量施加了极为激进的单连接监管。由于该用户一直固定使用 443 单个 UDP 端口，运营商的流量分析引擎在识别到高带宽特征后，自动对其 IP+Port 执行临时封禁降速 5 分钟。

最终解决方案： 服务端配合 iptables 放行 20000 到 50000 的跳跃端口池，客户端配置多端口范围支持。开启端口跳跃后，客户端每隔数十秒自适应切换全新通信端口，运营商防火墙的单端口追踪惩罚策略彻底失效，晚高峰 4K 视频全速丝滑播放。

案例四 使用自签名证书导致客户端频繁报安全阻断#

某初学者在配置 Hysteria 2 时，由于觉得申请域名和配置 Let’s Encrypt 证书太繁琐，便使用 OpenSSL 生成了本地自签名的 SSL 证书，并在客户端开启了 skip-cert-verify: true 强行跳过证书检验。运行三天后，该海外节点的 UDP 端口遭遇无差别全阻断。

故障深度排查： QUIC 协议原生深度内嵌了 TLS 1.3 握手流程。当使用自签名证书时，虽然客户端可以通过跳过校验强行通信，但公网中间审查设备同样具备实时解包比对证书的能力。 审查网关在嗅探到跨国 QUIC 流量出示的竟然是一个未经全球根证书机构（Root CA）签发、具备明显随机字符的自签名数字证书时，直接判定该节点为私有非法加密隧道，从而立即将其 IP 下发黑洞路由。

最终解决方案： 绑定正规独立域名，并通过 ACME 脚本申请全球受信任的 Let’s Encrypt 权威证书挂载到 Hysteria 2 中，节点再未遭遇针对性异常封锁。

问题一 为什么我的 Hysteria 2 节点测速很猛但偶尔打不开网页#

这通常是由 UDP MTU（最大传输单元）黑洞 引起的。测速工具通常发送固定大小的小包进行速率统计，因此能跑出极高成绩；但在实际浏览网页时，某些复杂的图片或脚本可能会被打包进接近 1500 字节的巨型 UDP 数据报中。如果你的本地宽带（如 PPPoE 拨号）链路 MTU 较小，这些超长 UDP 报文在中途被路由器无声丢弃，导致浏览器一直卡在首屏加载。在客户端中将底层 MTU 参数显式调低至 1350 字节即可彻底解决。

问题二 Hysteria 2 相比初代 Hysteria 有什么重大重构升级#

初代 Hysteria 协议是基于修改版的 QUIC-Go 库构建，协议层面夹杂了大量针对 HTTP/3 的伪装与复杂的报头，配置繁琐且在高并发下内存回收压力大；而 Hysteria 2 对底层协议进行了彻底的推倒重构：完全移除了多余的伪装层、将协议握手与安全模型全量对齐现代标准 QUIC、内存分配优化了 50% 以上，并正式将独创的 Brutal 拥塞控制算法固化为协议级核心标准，稳定度与性能呈现出代际跨越。

问题三 为什么配置 Hysteria 2 时必须填写的带宽参数不能乱填#

因为 Hysteria 2 的 Brutal 拥塞控制算法是基于**“发送端恒定速率调度”**运行的。如果你本地只有 100 Mbps 的实际宽带，却虚荣地填了 1000 Mbps，服务端就会按照千兆的恐怖速率持续向你的路由器倾泻 UDP 数据报。这不仅不会让你变快，反而会瞬间打爆你的光猫和本地路由器缓冲区，引发灾难性的局域网雪崩与死锁。务必根据本地真实的测速下行能力如实申报。

问题四 端口跳跃（Port Hopping）到底是如何实现防封和防 QoS 的#

端口跳跃利用了“打一枪换一个地方”的战术。运营商防火墙的限速规则是挂载在具体的端口套接字状态机上的。当防火墙监测到某个固定端口持续存在异常大流量时，需要数秒乃至数分钟的统计周期才会下发封锁限速规则。Hysteria 2 客户端在达到时间阈值或丢包激增时，瞬间跳跃到数万个端口范围内的全新随机端口继续发包，使得防火墙积累的限速规则全量失效。

问题五 Hysteria 2 会不会严重消耗服务器的 CPU 算力#

相比极其精简的 Shadowsocks，Hysteria 2 对 CPU 的消耗确实会明显更高。因为 UDP 数据包在 Linux 操作系统内核中默认不具备像 TCP 那样的硬件分段卸载（TSO/GSO）优化，高频大吞吐的 UDP 小包收发会触发大量的内核软中断（Softirq）与上下文切换；再加上 Brutal 算法毫秒级的定时器轮询，单核廉价 VPS 在跑满千兆带宽时 CPU 占用可能会达到 70% 至 90%。

问题六 为什么说物理内网专线（IPLC/IEPL）根本不需要 Hysteria 2#

因为 Hysteria 2 的全部核心优势（QUIC 多流解阻塞、Brutal 暴力发包、丢包动态补偿）都是为了**“在恶劣的高丢包公网环境中挣扎求生”**而量身设计的。而在昂贵的物理内网专线中，网络丢包率本身就是 0%，网络抖动小于 1ms，根本不存在任何需要补偿的公网丢包；在此类完美网络环境下，架构最轻、首包耗时为零、CPU 开销几乎为零的 Shadowsocks-2022 才是性能无可争议的王者。

问题七 Hysteria 2 协议自身安全吗能不能防御网络中间人窃听#

绝对安全。Hysteria 2 的传输通道完全内嵌了目前公认最安全的 TLS 1.3 传输层密码学加密规范。所有的应用数据、目标地址乃至 QUIC 大部分报头元数据全部经过了工业级对称加密（AES-128-GCM 或 ChaCha20-Poly1305）的保护，外部的任何黑客、运营商中间人哪怕截获了全量 UDP 数据包，在数学上也绝对无法解密任何明文内容。

问题八 Hysteria 2 支持像 VMess 那样挂在 Cloudflare CDN 后面吗#

原生不支持。因为目前全球主流的免费 CDN（如 Cloudflare）仅支持代理面向连接的标准 HTTP/TCP/WebSocket 流量，根本不提供针对私有长连接 QUIC/UDP 代理流量的反向代理中继服务。此外，CDN 的边缘 Anycast 路由会人为拉长数据传输路径并对 UDP 实施严厉限速，这与 Hysteria 2 追求极限吞吐与低延迟的底层初衷背道而驰。

问题九 手机端使用 Hysteria 2 节点会不会比普通协议更费电#

在相同下载数据量的前提下，Hysteria 2 的电池消耗确实会略高于基于 TCP 的原生协议。因为高频的无状态 UDP 发包会导致手机的基带射频芯片与操作系统网络栈保持极高的唤醒频率，无法频繁进入深度休眠状态。但在弱网环境或 Wi-Fi/移动数据频繁切换的通勤场景下，其带来的零卡顿与无缝连接迁移体验完全足以弥补微小的电量损耗。

问题十 为什么有的公司或学校 Wi-Fi 连上 Hysteria 2 节点直接无法上网#

因为许多企业内网、高校校园网以及公共场所（如酒店、星巴克）的边界防火墙，出于网络安全考虑实施了极度严厉的默认网络策略：“阻断除常用 UDP 53（DNS）之外的所有外网出站 UDP 流量”。在这种将 UDP 全网丢弃的物理防火墙环境下，任何基于 UDP/QUIC 架构的协议都将彻底丧失通信基础。此时必须在客户端回退切换为基于 TCP+TLS 的 VLESS-Reality 或 Trojan 协议。