Hysteria2不稳定怎么办:UDP被限速的判断与回退

这个故障有个很好认的开场:测速跑出一个漂亮的数字,实际用起来却前几秒飞快、随后骤降,过一会儿又恢复,循环往复。很多人第一反应是节点坏了,于是开始换节点、换地区、换机场,换了一圈发现每家都这样。

问题多半不在远端。UDP 和 TCP 在网络设备眼里是两类不同的流量,而 UDP 在大多数管理策略里的优先级更低——它承载的传统上是游戏、语音这类可以丢一点的东西,不是网页和下载。于是当一台设备需要限制带宽时,先压 UDP 是很自然的选择。Hysteria2、TUIC 这类协议恰好全部跑在 UDP 上。

更麻烦的是,限速和阻断的表现完全不同。彻底阻断反而好判断——一直连不上,五秒钟就能得出结论。限速不会让你连不上,它只是让你一会儿好一会儿坏,把人拖进「到底是谁的问题」的泥潭里。

先分清:协议的问题,还是本地在限 UDP#

这一步不做,后面全是白费力气。用现象对照来定位:

注意第三行:切到手机热点是最省事的对照实验,几十秒就能出结果。前提是热点用的是另一家运营商的移动网络,而不是同一条被限的宽带。

三步验证 UDP 通道到底通不通#

这三步的顺序是有讲究的,由粗到细,每一步都排除掉一类可能:

1. **做同机同时段的协议交叉测试。**在同一个机场里挑地区相同、序号相邻的一组节点,一个 UDP 类、一个 TCP 类,交替各用五分钟,记录中途是否断流。它们大概率跑在同一台服务器同一条线路上,所以只有协议这一个变量在变。结果如果是「TCP 稳、UDP 抖」,方向就确定了。
2. **换一条接入网络重复第一步。**用手机蜂窝数据开热点,电脑连上去再测一遍。这一步把「本地网络」这个变量换掉。如果换网之后 UDP 恢复正常,证据链就完整了:问题在你原先接入的那条网络上。
3. **观察限速的时间规律。**连续两三天,在白天空闲时段和晚高峰各测一次,记录下来。表现出明显时段差异的是限速策略,全天候不通的是阻断。两者的应对方式不同,值得分清。

一份简单的记录格式就够用:

日期      时段     接入网络   协议      5分钟内断流次数   速率中位数
08-15    14:30    校园网     TCP系     0                 稳定
08-15    14:35    校园网     UDP系     3                 先高后崩
08-15    21:10    校园网     UDP系     6                 基本不可用
08-15    21:20    手机热点   UDP系     0                 稳定

以上为记录格式示例,数值需要你自己填。判断的依据是同一行之间的对比关系,不是任何绝对数字。

换端口、换地区节点还有没有用#

有一点,但很有限。这类补救措施能否奏效,取决于对方是按什么维度做的限制:

值得说明的是第四行:很多人在这一步换了机场,然后发现新机场同样不行,于是得出「这家也不行」的结论。实际上换掉的是唯一没有问题的那个部件。

什么时候该直接回退#

不要无限期排查,给自己设一个止损点。满足下面任意两条,就直接回退到 TCP 系协议:

• 同机同时段交叉测试里,TCP 类稳定而 UDP 类反复断流。
• 换到手机热点后 UDP 类立刻正常。
• 端口和地区都换过,现象没有变化。
• 这条网络是你无权更改策略的环境(学校、公司、酒店)。
• 问题呈现明显的时段规律,晚高峰尤其严重。

回退的选择很直接:同一个机场里通常都有 Trojan 或 VLESS 节点跑在同一批服务器上,切过去即可。两者的伪装思路差别见 Shadowsocks 与 Trojan 的对比。至于回退后损失多少吞吐,取决于链路丢包情况——这正是 Hysteria2 与 TUIC 的取舍里讨论的那个变量。

不同网络环境的典型表现#

同样是限 UDP,不同场所的表现形态差别很大:

家庭宽带那一行值得单独试一下:有些路由器的 QoS 或「游戏加速」功能会对 UDP 做整形,关掉之后问题就没了。这是少数几个你真正有权限修改的场景。

客户端里哪些设置会放大问题#

同样的网络环境下,配置不当会让症状严重得多:

• 带宽值填得过高。Hysteria2 按你声明的速率发包,声明值远高于实际可用带宽时,多出来的部分全部堆在已经被限窄的通道里,抖动成倍放大。往低了填。
• 开着并发探测或频繁测延迟。客户端周期性对全部节点发起测试,在被限速的通道上会额外占用本就稀缺的配额。把探测间隔调长或关掉。
• 多设备同时跑 UDP 节点。同一条被限的网络上,几台设备会互相挤压。
• 自动切换节点开得太激进。断流触发切换,切换又造成新的握手风暴,形成循环。把切换阈值放宽。

这些设置的具体位置各客户端不同,可以对照 Clash 配置教程与 Shadowrocket 使用教程。若回退之后仍然连不上,那就不是本文这个问题了,按连接失败的分层排查重新走一遍。

看到什么现象才算真正解决#

给自己一个明确的验收标准,避免「好像好点了」这种模糊结论:

1. 连续三十分钟使用中没有出现断流,而不是刚切换完的头几分钟很快。
2. 晚高峰时段单独复测一次,表现与白天相比没有断崖式下降。
3. 一次长时间下载或长视频播放中途不中断,速率曲线是平的而不是锯齿状。
4. 长连接类应用(在线文档、AI 对话、远程终端)不再出现莫名其妙的中途掉线。

四项都满足才算稳住。只满足第一项就下结论,往往会在当天晚上被打回原形。

小结#

「换了最快的协议反而更卡」在多数情况下是本地网络对 UDP 做了限速,而不是协议或机场的问题。判断方法只有一个核心:在同机同时段的条件下,把协议作为唯一变量做交叉测试,再换一条接入网络复现一次。换端口、换地区、换机场对本地侧的限制基本无效,不值得反复尝试。确认之后回退到 Trojan 或 VLESS 是最省事的解法,损失的吞吐远小于反复断流的代价。回退后按三十分钟无断流、晚高峰不塌方、长连接不掉线三条来验收,再判断是否稳定。