使用 Clash、Mihomo、Clash Verge Rev 等客户端时，Hysteria2 节点最常见的问题之一就是：
节点一直 Timeout。
有些用户会发现：
- Hysteria2节点一直Timeout
- 延迟显示-1
- 其他VLESS、Trojan、SS节点正常
- 只有Hysteria2无法连接
- 手机热点能用，Wi-Fi不能用
- 更新订阅后Hysteria2全部超时
- Mihomo可以识别节点，但实际打不开网页
- 提示TLS Handshake Failed
- 提示Authentication Failed
- Hysteria2节点延迟测试失败
- Clash Verge Rev显示连接失败
- 同一个订阅里只有HY2节点不能用
这类问题和普通“订阅导入失败”不完全一样。
如果 Hysteria2 节点已经可以正常显示，说明配置至少已经被客户端识别。
接下来真正要排查的是：
UDP网络环境、Hysteria2参数、TLS/SNI、认证、Mihomo核心以及节点服务器状态。
本文按照实际排障顺序，一步一步判断 Hysteria2 节点 Timeout 的真正原因。
Hysteria2 节点一直 Timeout，想获取可直接导入 Clash / Mihomo 的稳定订阅线路？
获取稳定订阅线路一、先判断：是“导入失败”还是“Hysteria2节点Timeout”
这两个问题一定要分开。
如果你看到：
Unsupported Proxy Type
Invalid Config
YAML Parse Error
说明问题发生在：
配置加载阶段。
这时优先检查：
- Mihomo核心版本
- YAML格式
- Hysteria2字段兼容性
但如果：
节点已经正常显示
只是延迟：
Timeout
或者：
-1
那说明问题已经进入：
实际连接阶段。
此时排查重点应该转向：
- UDP
- server
- port
- password
- SNI
- obfs
- TLS
- 服务端
二、为什么Hysteria2特别容易出现Timeout？
Hysteria2主要基于：
QUIC / UDP
通信。
这和很多基于 TCP 的代理协议不同。
因此 Hysteria2 对网络环境更加敏感。
如果当前网络存在：
- UDP限制
- QUIC限制
- 丢包严重
- 路由器限制UDP
- 企业网络屏蔽UDP
- 酒店Wi-Fi限制UDP
就很容易出现：
Hysteria2全部Timeout。
而与此同时：
VLESS
Trojan
Shadowsocks
可能仍然正常。
三、先做最简单的测试：换手机热点
这是排查 Hysteria2 Timeout 最有效的一步之一。
如果当前使用：
家庭Wi-Fi
可以临时切换到：
手机热点
然后重新测试相同的 Hysteria2 节点。
如果手机热点正常
说明：
节点本身大概率没有问题。
优先怀疑：
原Wi-Fi或路由器UDP环境。
如果手机热点也Timeout
则继续检查：
- Mihomo核心
- 节点参数
- TLS/SNI
- 认证
- 节点服务器
四、为什么手机热点能用，Wi-Fi却不能用？
这种情况非常典型。
可能原因包括：
1. 路由器限制UDP
部分路由器或网络设备会限制UDP连接。
2. 网络运营商UDP质量差
某些网络环境下UDP丢包明显。
3. 企业或校园网络限制QUIC
部分网络会直接限制UDP/443。
4. 防火墙或安全策略
路由器防火墙、企业防火墙都可能影响UDP。
所以：
换网络能恢复，是一个非常重要的判断信号。
五、其他协议正常，只有Hysteria2 Timeout说明什么？
例如：
VLESS：正常
Trojan：正常
SS：正常
Hysteria2：全部Timeout
这种情况下通常说明：
整个订阅不是完全坏的。
客户端也不一定有问题。
更应该优先检查：
Hysteria2独有的连接链路。
排查顺序建议：
- UDP网络
- Mihomo核心
- server / port
- password
- SNI
- obfs
- 服务端
六、所有Hysteria2节点同时Timeout怎么办？
如果订阅里有多个HY2节点：
- 香港HY2
- 日本HY2
- 新加坡HY2
- 美国HY2
全部同时超时，
但其他协议正常，
优先怀疑：
第一：当前网络限制UDP
这是最常见方向。
第二：当前内核Hysteria2支持异常
例如内核版本太旧。
第三：服务端统一参数发生变化
例如订阅更新异常。
第四：转换配置丢失关键字段
如果使用了第三方订阅转换。
相比之下：
多个不同地区Hysteria2服务器同时坏掉
概率通常没有前面几项高。
七、只有一个Hysteria2节点Timeout怎么办？
如果：
日本HY2正常
香港HY2正常
只有：
美国HY2 Timeout
那么可以基本判断：
- Mihomo核心支持正常
- UDP网络正常
- Hysteria2协议本身可以使用
这时重点排查：
这个具体节点。
可能原因包括：
- 节点服务器故障
- server错误
- port错误
- password更新
- SNI变化
- 节点维护
- 节点被下线
八、检查Hysteria2的server地址
配置可能类似：
server: example.com
或者：
server: 1.2.3.4
如果 server 错误，就无法连接到节点服务器。
常见原因包括：
- 服务端换域名
- DNS解析失败
- IP发生变化
- 本地配置还是旧地址
如果节点来自远程订阅，建议：
先更新订阅。
不要优先手动修改 server。
九、为什么本地YAML里的server可能过期？
如果你之前把订阅导出成：
config.yaml
这个文件只是：
某个时间点的配置快照。
后来服务端把：
server A
改成：
server B
远程订阅已经更新。
但你的本地 YAML 不会自动变化。
于是出现：
节点还显示
但一直 Timeout。
所以本地配置突然失效时，要对比最新订阅。
十、检查port是否正确
Hysteria2配置中一般会有：
port: 443
或者：
port: 8443
如果端口错误：
配置仍然可能正常加载。
但实际连接会：
Timeout
或者：
Connection Failed。
如果服务端已经更换端口，而你仍使用旧配置，也会出现这种现象。
十一、password错误会不会显示Timeout？
有可能。
Hysteria2通常需要认证密码。
例如：
password: “abcdef123456”
如果密码错误，可能出现：
Authentication Failed
也可能表现为：
连接超时
或者：
握手失败。
尤其有些客户端界面不会直接显示详细错误，只显示：
Timeout。
所以遇到节点长期无法连接时，最好查看：
Logs / 日志。
十二、日志比延迟测试更重要
节点列表只显示：
Timeout
信息非常有限。
真正排查时建议进入：
Logs
日志。
常见关键词包括：
- timeout
- authentication failed
- tls handshake
- certificate
- quic
- udp
- connection refused
- network unreachable
不同日志对应的排查方向完全不同。
十三、出现Authentication Failed怎么办？
如果日志明确提示：
Authentication Failed
优先检查：
password。
可能原因包括：
- password复制错误
- 服务端已经更换密码
- 订阅没有更新
- 转换配置丢失认证参数
这时不要继续修改DNS或路由器。
因为错误已经明确发生在：
认证阶段。
十四、Hysteria2的SNI错误会导致什么？
配置里可能有：
sni: example.com
SNI主要用于TLS握手。
如果 SNI 错误，可能出现：
- TLS Handshake Failed
- Certificate Error
- connection closed
- timeout
所以节点：
可以显示
但无法建立TLS连接。
十五、server和SNI不同正常吗？
正常。
例如：
server: 1.2.3.4
sni: node.example.com
这种配置完全可能是正确的。
server负责：
实际连接地址。
SNI负责：
TLS证书验证使用的域名。
不要看到两者不同就手动改成一样。
十六、为什么不要随便修改SNI？
如果服务端配置本身正确，
随意把：
sni: example.com
改成：
sni: google.com
可能直接导致TLS握手失败。
所以：
Hysteria2节点来自订阅时，
SNI应该优先保持服务端原值。
十七、出现TLS Handshake Failed怎么办？
如果日志提示：
TLS Handshake Failed
重点检查：
- SNI
- 系统时间
- 服务端证书
- skip-cert-verify
- 当前网络是否存在TLS干扰
其中最容易忽略的是：
系统时间。
十八、Windows系统时间错误为什么会影响Hysteria2？
TLS证书都有有效期。
如果电脑时间错误：
例如：
2025年
或者：
2027年
可能导致证书被判断：
未生效
或者：
已经过期。
所以出现TLS错误时建议检查：
设置
→ 时间和语言
→ 日期和时间
→ 自动设置时间
确保系统时间准确。
十九、skip-cert-verify要不要改成true？
不建议作为第一解决方案。
例如：
skip-cert-verify: false
如果改成：
true
可能跳过部分证书验证。
但这并不是解决 Hysteria2 Timeout 的通用方法。
如果节点必须关闭证书验证才能使用，更应该进一步检查：
- SNI
- 证书
- 服务端TLS配置
而不是永久忽略证书问题。
二十、obfs错误也可能导致Timeout
部分 Hysteria2 节点会使用：
obfs: salamander
以及：
obfs-password
例如：
obfs: salamander
obfs-password: “xxxxx”
如果服务端启用了混淆，
但客户端：
- 没有obfs
- obfs类型错误
- obfs-password错误
连接就可能失败。
二十一、password和obfs-password不要混淆
它们可能是两个完全不同的密码。
password：
用于Hysteria2认证。
obfs-password：
用于流量混淆。
不能默认两者相同。
如果从手动配置复制参数，必须按服务端实际信息填写。
二十二、为什么订阅转换后Hysteria2全部Timeout？
如果原订阅正常，
经过第三方转换以后：
Hysteria2全部失败
就要怀疑：
转换过程中参数丢失。
可能丢失：
- password
- SNI
- obfs
- obfs-password
- TLS字段
部分旧转换器甚至会直接过滤Hysteria2。
因此如果服务端提供：
Mihomo
Clash Meta
原生订阅，
优先使用原生格式。
二十三、更新订阅后Hysteria2突然Timeout怎么办？
如果：
昨天正常
今天更新订阅后突然失败
可以先对比更新前后的节点参数。
重点检查：
- server
- port
- password
- sni
- obfs
如果服务端参数变了，
旧的本地缓存就可能无法继续使用。
二十四、为什么更新订阅后旧节点仍然显示？
部分客户端会保留缓存。
于是可能出现：
订阅实际更新失败
但旧节点仍然显示。
这时：
“节点还在列表里”
不代表：
节点配置是最新的。
可以检查：
Profiles
→ 更新时间
确认订阅是否真的更新成功。
二十五、Hysteria2延迟显示-1是什么意思？
不同客户端显示方式不同。
通常：
-1
表示：
当前测速没有获得有效结果。
可能原因包括：
- 节点不可达
- UDP受限
- 测速地址异常
- TLS失败
- 节点超时
所以：
-1 ≠ 一定是节点服务器坏了。
二十六、测速Timeout但实际网页能打开怎么办？
这种情况也可能发生。
因为：
节点延迟测试
和：
实际代理请求
不一定完全相同。
如果：
延迟显示Timeout
但启用节点后：
Google
YouTube
网页
都能正常打开，
说明节点实际上可能可用。
这种情况不要只根据延迟结果判断。
二十七、实际连接也打不开怎么办？
如果：
延迟Timeout
实际网页也打不开，
那才需要继续完整排查。
优先：
- 更换网络
- 更换其他HY2节点
- 查看日志
- 检查参数
- 更新订阅
- 升级Mihomo核心
二十八、Mihomo版本过旧会导致Timeout吗？
有可能。
尤其 Hysteria2 配置使用了较新的参数，而本地核心过旧。
可能出现：
- 某些字段解析异常
- 协议行为不完整
- 节点连接失败
所以如果长时间没有更新核心，可以检查：
Mihomo版本。
但如果日志明确是：
Authentication Failed
那就不要只靠升级内核解决。
二十九、Clash Verge Rev界面更新不等于核心已经更新
这是一个常见误区。
客户端界面：
Clash Verge Rev
可以是最新版。
但里面使用的：
Mihomo Core
可能仍然比较旧。
所以遇到Hysteria2问题时，需要确认：
核心版本
而不是只看客户端版本。
三十、防火墙会不会导致Hysteria2 Timeout？
会有可能。
尤其是：
Windows Defender防火墙
或者：
第三方安全软件
限制Mihomo的UDP连接时。
常见现象：
- TCP代理节点正常
- Hysteria2全部Timeout
- 关闭安全软件测试后恢复
这种情况下要检查：
Mihomo核心程序的网络权限。
三十一、不要长期关闭Windows防火墙
如果临时关闭防火墙后恢复，
正确处理方式是：
允许可信的Mihomo / Clash客户端正常联网。
而不是长期关闭系统防火墙。
可以检查：
Windows Defender防火墙
→ 允许应用通过防火墙
以及：
高级安全设置
→ 出站规则
三十二、第三方安全软件也可能限制UDP
例如：
- 360
- 火绒
- 腾讯电脑管家
- 企业安全软件
- 第三方防火墙
即使 Windows Defender 没问题，
第三方安全工具仍可能继续拦截。
所以如果环境复杂，应逐一排查。
三十三、DNS问题会导致Hysteria2 Timeout吗？
如果 server 使用的是：
域名
那么 DNS 解析失败当然会影响连接。
例如：
server: hy2.example.com
如果本地无法解析这个域名，
客户端就根本不知道服务器IP。
日志可能出现：
lookup failed
或者：
DNS resolve failed
这时重点检查DNS。
三十四、server直接使用IP还需要DNS吗？
如果：
server: 1.2.3.4
那么连接节点本身通常不需要解析该 server 域名。
但：
SNI
可能仍然使用域名。
所以DNS问题是否影响Hysteria2，要结合实际配置判断。
三十五、IPv6会不会影响Hysteria2？
有些域名同时返回：
IPv4
IPv6
如果当前网络IPv6异常，
客户端可能优先尝试IPv6后失败。
表现可能包括：
- Timeout
- Network Unreachable
- 连接慢
如果怀疑IPv6问题，可以对比：
IPv4网络
或者检查DNS解析结果。
三十六、路由器重启有用吗？
如果问题来自：
- UDP状态异常
- NAT异常
- 路由器缓存
- 网络拨号异常
重启路由器可能有帮助。
但如果：
所有Hysteria2节点在不同网络都失败，
重启路由器意义就不大。
还是应该回到：
配置、认证、核心
方向。
三十七、代理模式会不会影响Hysteria2？
有时会。
例如：
系统代理模式
和：
TUN模式
网络链路不同。
如果：
系统代理可以用
TUN模式下Hysteria2失败
则还要排查：
- TUN
- 虚拟网卡
- 路由
- 防火墙
不要只盯着Hysteria2节点参数。
三十八、关闭TUN测试有必要吗？
有。
尤其当：
其他环境都正常
只有开启TUN后失败
可以先：
关闭TUN
只使用：
系统代理
测试相同节点。
如果恢复：
说明问题重点在：
TUN链路。
三十九、所有节点都Timeout就不一定是Hysteria2问题
如果：
Hysteria2 Timeout
同时：
VLESS
Trojan
SS
也全部Timeout，
那就不要继续只排查HY2。
更应该检查：
- 本地网络
- 系统代理
- Mihomo核心
- 防火墙
- 订阅
- DNS
因为这是：
整个代理链路异常。
四十、Hysteria2节点Timeout标准排查顺序
以后遇到相同问题，可以直接按下面顺序处理。
第一步：测试其他协议节点
判断是不是只有Hysteria2失败。
第二步：测试其他Hysteria2节点
判断单节点还是全部HY2异常。
第三步：换手机热点
快速判断UDP网络。
第四步：查看Mihomo日志
区分：
Timeout
认证
TLS
DNS
UDP
第五步：检查server与port
确认节点地址最新。
第六步：检查password
尤其出现Authentication Failed。
第七步：检查SNI和TLS
尤其出现Handshake或Certificate错误。
第八步：检查obfs参数
如果服务端启用了混淆。
第九步：更新订阅和Mihomo核心
排除旧参数和旧核心。
第十步：最后判断服务端故障
不要一开始就认定节点坏了。
四十一、Hysteria2 Timeout快速对照表
| 现象 | 优先排查 |
|---|---|
| 所有HY2都Timeout | UDP网络、核心 |
| 只有一个HY2失败 | 单节点服务器或参数 |
| 手机热点正常 | Wi-Fi/路由器UDP |
| 所有网络都失败 | 配置、认证、节点 |
| Authentication Failed | password |
| TLS Handshake Failed | SNI、证书、系统时间 |
| DNS Resolve Failed | server域名解析 |
| 更新订阅后失败 | 参数变化、缓存 |
| 转换订阅后失败 | 转换参数丢失 |
| 延迟-1但实际能用 | 测速机制 |
| TUN下失败 | TUN、路由、防火墙 |
| 所有协议都Timeout | 整体网络/代理环境 |
四十二、最推荐的快速排查方法
如果不想进行大量复杂操作，可以先做下面四步：
第一步：
更新Mihomo核心。
第二步：
重新获取服务端原生Mihomo订阅。
第三步：
更换手机热点测试。
第四步：
查看日志中的第一条关键错误。
这四步通常就可以快速把问题缩小到：
核心
配置
UDP网络
服务端
其中一个方向。
总结
Hysteria2节点Timeout，最需要优先关注的并不是“订阅有没有导入成功”。
如果节点已经正常显示，说明问题更多发生在：
实际连接阶段。
最常见的原因包括：
UDP网络受限
server或port失效
password认证失败
SNI/TLS错误
obfs参数不一致
Mihomo核心过旧
节点服务器故障
如果：
其他协议正常
但所有Hysteria2节点都Timeout，
第一优先级建议测试：
手机热点。
如果换网络后恢复，基本可以把重点放到：
UDP / QUIC网络环境。
如果所有网络都失败，再继续检查：
参数、TLS、认证和服务端。
排查时按照：
其他节点 → 其他HY2 → 换网络 → 看日志 → 参数 → TLS → 服务端
这个顺序处理，能够最快定位Hysteria2节点Timeout、延迟-1和连接失败的真正原因。
