全站智能检索

直接说出你的问题

AI 会理解问题含义,并从本站机场档案和实用文章中找出最相关的内容。

试试:

输入问题后按回车搜索。

故障排查

Hysteria2 节点 handshake timeout 怎么办?别先把等待时间拉满

Mihomo v1.19.30 新增 Hysteria2 handshake-timeout。它只分开控制握手等待,不会修复服务器离线、UDP 受阻、地址端口或认证错误。

先看重点`handshake-timeout` 只控制 Hysteria2 握手最多等多久,默认 `0` 表示沿用外层连接超时。遇到 `timeout: no recent network activity`,先确认服务器、地址端口、UDP 路径与混淆密码;只有连接偶尔能完成、证据指向握手确实需要更久时,才在 Mihomo v1.19.30 或更高版本中单独设置,并把 30 秒当作官方示例而不是通用答案。

官方入口 · 已于 2026/9/2 核验

直接下载软件

版本会变化,请在官方页面选择标有 Latest 的稳定版;不要从网盘或不明镜像下载安装包。

节点列表里只有 Hysteria2 一批反复超时,普通 SS 或 Trojan 节点却能连。继续点测速,日志只留下 timeout: no recent network activity。这时把等待时间从几秒拉到一分钟,看起来像最直接的修复,实际上可能只是让同一个错误晚一点出现。

handshake-timeout 只改变握手可以等待多久,不会把失败的 UDP 路径变通,也不会修正服务器、端口、密码或证书。 先分清连接为什么没有完成,才知道这个新字段有没有用。

no recent network activity 还没有指出根因

Hysteria 2 官方排障文档把这类连接超时的常见原因列为:服务端没有运行、端口被防火墙阻断、服务器地址或端口不一致。完整客户端文档还说明,混淆密码不正确也可能表现为连接超时,而不是一条直白的“密码错误”。

因此,一行 timeout 只能证明握手在时限内没有完成。它不能单独证明机场节点离线,也不能证明本机超时时间太短。把现象拆开会更有用:

观察结果 更值得检查的方向 延长握手等待的意义
同一节点在不同网络、不同设备都持续失败 服务状态、地址、端口、认证或混淆参数 通常只是更晚报错
同一设备换网络后恢复 当前网络的 UDP、防火墙或路由路径 不会解除阻断
日志明确是证书或认证错误 SNI、证书校验、密码 与握手等待无关
保持配置和网络不变,连接有时在较长等待后成功 路径波动或握手耗时 可以作为单一对照变量

如果网页能开、只有 Hysteria2 或其他 QUIC/UDP 节点失败,可继续对照UDP 路径受限的判断方法。所有类型的节点都超时,则应回到节点超时与全网故障的分层排查,不要把问题锁死在一个协议字段上。

这个字段控制的是哪一段等待

Mihomo 当前 Hysteria2 文档写明,handshake-timeout 的单位是秒。设置后,握手超时可以独立于外层连接超时;默认值为 0,表示握手仍只使用外层连接超时。

这不是一个“数值越大越稳定”的性能开关。握手早已不可能完成时,更长的值只会拖延失败反馈;连接原本正常时,它也不会增加带宽、降低延迟或改变节点线路。

文档示例使用:

handshake-timeout: 30

它应放在对应的 type: hysteria2 节点配置中。30 秒只是官方配置示例,不是本站实测出的推荐值,更不是所有网络都该套用的默认答案。订阅由服务商维护时,直接改远程内容还可能在下一次更新后消失;没有自定义配置能力,就把完整错误和时间交给配置提供方核对,不要公开订阅 URL、密码或节点凭据。

先确认实际运行的内核支持它

Mihomo 官方提交显示,这个字段在代码中以秒转换为握手时长,并随 v1.19.30 的稳定发布记录出现。客户端窗口上的版本号不一定是内核版本;需要在“内核”“Core”“关于”或启动日志里确认实际运行的 Mihomo。

独立内核用户可以从本文前部的官方发布页取得对应系统和处理器架构的资产。Clash Verge Rev、FlClash 或软路由插件等由各自维护者封装内核,使用它们自己的官方更新入口更稳妥,不要为了一个字段从陌生网盘下载所谓新内核,也不要随意覆盖客户端内部文件。

Mihomo v1.19.30 官方 GitHub 发布页,What's Changed 列表显示为 Hysteria2 新增 handshake-timeout
官方 v1.19.30 发布记录明确列出“add handshake-timeout for hysteria2”。截图于 2026-08-18,源页面于 2026-09-02 复核。官方来源 ↗

旧内核没有这项能力时,不要用“配置文件里已经写了”代替版本确认。升级后也应从日志核对新内核确实启动、原配置能够加载;本文没有在你的客户端、节点或网络上执行兼容性测试。

改动一次,只回答一个问题

服务器地址、节点、网络、混淆参数和超时时间同时变化,最后即使恢复,也无法知道是哪一项起作用。更清楚的做法是保留原配置副本,固定同一节点和网络,只把 handshake-timeout 作为一次对照。

较长等待后稳定完成握手,只能说明等待窗口与现象相关,不能证明线路质量已经变好。仍然持续 timeout,就把字段恢复,转去检查服务端、端口、UDP 路径和认证。日志变成 TLS 证书类错误时,按握手超时与证书错误的区别处理,两类错误不该用同一个旋钮解决。

分享排查结果时,保留内核版本、错误原文、节点协议、发生时间,以及“同一节点换网络是否恢复”这些信息。订阅链接、服务器密码和完整配置要遮住;可直接套用代理日志脱敏清单

handshake-timeout 的价值是把握手等待从外层超时里单独分出来,方便在证据吻合时做一次干净对照。它不是把所有 Hysteria2 超时都延长到消失。

资料来源

以下来源于 2026/9/2 复核。版本、支持平台和发布状态以后续官方页面为准。

  1. Mihomo 官方文档:Hysteria2 与 handshake-timeout
  2. Mihomo v1.19.30 官方发布页
  3. Mihomo 官方提交:为 Hysteria2 增加 handshake-timeout
  4. Hysteria 2 官方文档:连接超时排查
  5. Hysteria 2 官方文档:完整客户端配置与混淆说明

持续更新

收到新教程,也欢迎纠错

想收到新文章,可以关注 TG 频道;发现下载失效、套餐变化或步骤不一致,请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。