Clash 能连上但上不了网？hysteria 国际 UDP 链路 QoS 排查
Clash 显示已连接，浏览器却打不开任何网页；服务端日志里有 client connected，紧接着流内报 timeout: no recent network activity，整条流在 52 秒到几分钟内死亡。服务器各项健康检查全部通过。
在维护自建海外 VPS 时遇到此问题——跨境链路故障，主机无恙，记录完整的分层排查过程。
TL;DR
认证能过、流内超时、服务器健康检查全绿——问题不在主机，在路径：国际链路对长流量 UDP 五元组做了 QoS，流进入「半死」状态。
- 立即恢复：重连 Clash（客户端重新握手会换源端口，绕开被标记的五元组），实测九成场景有效
- 确认定性：
journalctl -u hysteria-server看是否反复出现client connected→timeout: no recent network activity的循环 - 长期缓解思路（概念）：服务端端口范围轮换、或下调带宽声明避免触发抑制——按需选型，本文不展开
问题现象
客户端与服务端两侧的表现拼出完整图景：
客户端：Clash 状态栏显示已连接（UDP 认证通过），但任何网站都打不开，测速无流量。
服务端（journalctl -u hysteria-server）：
client connected ← 认证成功
... (52s ~ 几分钟后)
timeout: no recent network activity ← 流级死亡
client disconnected
client connected ← 客户端自动重连，循环往复
重灾期数据：故障集中时段曾录得单日 94 / 50 / 20 次的重连风暴；一次典型案例是跑了 9 小时的旧会话进入半死状态引发。
排查链：先排除主机，再定性路径
整条排查的价值在于排除法的顺序——如果跳过主机检查直接怪运营商，结论站不住。
第一层：认证与端口。 日志有 client connected，说明 UDP 包能到服务端、端口放行正常、认证配置正确。链路的前半程（客户端 → 服务器方向）是通的。
第二层：流级超时。 timeout: no recent network activity 是 hysteria 服务端的流保活探测：一条流长时间没有有效报文，判定死亡。认证能过但流立刻饿死——后半程（服务器 → 客户端方向的回包）大概率被丢了。
第三层：主机健康检查（排除主机侧）。 全部通过，主机洗清嫌疑：
| 检查项 | 结果 |
|---|---|
| 出站 TCP（curl 大文件） | 正常，带宽跑满 |
| 网卡丢包 / 错包计数 | 0 |
| conntrack 表 | 无异常表项堆积 |
| TLS 证书有效期 | 正常 |
| 内存 / 磁盘 | 正常 |
第四层：定性。 三层证据合起来指向一个结论：本机收发正常、认证方向正常、唯独长流量流的回程报文被静默丢弃——这是典型的运营商对国际出口 UDP 长流量五元组的 QoS 行为：持续大流量的同一条 UDP 流（相同五元组）被流量识别系统标记，之后该五元组的包被降优或丢弃，流进入「半死」——没断，但再也跑不动。重连后客户端换新的源端口，等于换了一条没被标记的五元组，立即恢复。
故障源 IP 段为广东移动出口（163.179.x），不同运营商/地区的触发阈值与表现会有差异，但「长流量 UDP 五元组 → 半死 → 换端口恢复」的模式是通用的。
处置：重连恢复 + 观察判据
日常处置（90% 有效）：Clash 重连或重启。本质是换源端口绕开被标记的五元组，恢复时间秒级。
处置无效时：再上服务端日志确认模式——journalctl -u hysteria-server 里如果还是 connected → timeout 循环，且换端口无效，就要怀疑更上游的链路问题（服务器机房出口、中间运营商策略变化），那时再查服务器侧。
长期缓解（按需选型，遇到复发再做）：两条思路——服务端监听端口范围轮换（让单条五元组活得不够久，不满足被标记的时长条件），或下调带宽相关声明让流量特征不那么「大」。各自有代价，遇到高频复发时再评估。
顺带一提：如果故障发生在 WSL2 环境里，还要先排除本机代理链路的另一类坑（防火墙拦截代理端口），见 WSL2 代理频繁断网？Windows 防火墙拦了代理端口——先把本机因素排干净，再往外定性链路。
注意事项
「服务器健康检查全过」不等于「网络没问题」——健康检查覆盖的是主机与它的直连链路，而 QoS 发生在跨境的中间路径上，任何主机侧工具都测不到。两边结论冲突时（主机全绿但用户没网），优先怀疑路径，这是本案例的核心排查经验。
常见问题
hysteria 认证成功但上不了网，怎么分层排查？
按链路三层切：第一层看服务端日志有没有 client connected——有，说明认证和端口都通；第二层看流内报错——出现 timeout: no recent network activity 说明流级死亡；第三层做服务器健康检查（出站 TCP、网卡丢包、conntrack、证书、内存磁盘）——全过就排除主机侧，定性到路径，重点是跨境 UDP 链路被 QoS。
timeout: no recent network activity 是什么意思？
这是 hysteria 服务端对流级活跃度的探测报错：一条流在一段时间内没有任何有效报文通过，服务端就判定它死亡并关闭。认证握手能过、流却很快死掉，典型成因是路径中间设备（运营商 QoS）把这条 UDP 五元组标记后静默丢包——客户端以为还连着，实际通道已经半死。
UDP 长连接为什么容易被限流？
运营商对国际出口的长时大流量 UDP 五元组有流量识别与抑制策略：同一条 UDP 流持续高速传输数十分钟到数小时后，容易被降优甚至静默丢弃。这也是为什么同一条隧道「用一会儿没事、挂一天就死」——流量特征越像长连接大流量，越容易触发。