Clash 节点全部超时的排查顺序:从订阅有效性到端口占用逐项定位

节点列表里一片红,第一反应往往是"这批节点全废了"。但真正因为节点本身失效导致全部超时的情况并不算多——更常见的原因藏在订阅、时间、端口、内核版本这四个环节。本文按固定顺序逐项排查,每一步给出确认方法和对应处理。

先分清"全部超时"和"部分超时"

排查之前先做一个分类判断,方向不同,后面省一半时间。

  • 部分节点超时,部分正常:大概率是节点本身或落地线路的问题,换其他正常节点用即可,不必怀疑本地配置。
  • 全部节点同时超时,包括平时稳定的老节点:这才是本文要处理的情况——问题几乎肯定出在本地环境或订阅层面,而不是几十个节点同时集体故障。

如果测速界面直接显示"超时"或数值为 0ms 且长期不变,先别急着删节点、换订阅商,按下面的顺序走一遍。

第一步:确认订阅本身没有过期

订阅链接背后对应的是机场或服务商生成的一份配置快照,大多数服务在到期后不会立刻删除链接,而是让链接继续可访问、但返回的节点全部失效或直接返回空列表,这种"假装还在"的状态最容易被误判成客户端故障。

  1. 打开机场/服务商的用户面板,核对套餐到期时间,不要只看订阅链接是否还能打开。
  2. 在客户端里手动执行一次"更新订阅",观察节点数量和节点名称是否发生变化——如果更新前后节点列表一字不差,说明服务端没有推送新数据。
  3. 检查订阅是否有流量耗尽限速或断流的条款,部分服务商在流量用尽后会保留链接但停止服务,而不是直接报错。

订阅到期后节点名称、分组结构往往原样保留,只是延迟测试全部失败。这种"外观正常、内部空转"的状态最容易被误认为是客户端或网络问题,浪费大量排查时间。

第二步:核对本地系统时间

这一条经常被忽略,却是排查清单里性价比最高的一步。多数代理协议(尤其是基于 AEAD 加密的 Shadowsocks、VMess,以及依赖 TLS 证书有效期校验的协议)在握手阶段会校验时间戳,本地系统时间与真实时间偏差过大时,服务端会直接判定请求非法并拒绝连接,表现出来就是"全部节点超时",和网络本身是否通畅无关。

  • Windows 用户检查右下角时间是否已启用"自动设置时间",并确认时区正确。
  • macOS/Linux 用户可以在终端执行 date 命令,和手机上的网络时间对比是否一致。
  • 虚拟机、旧路由器、长期休眠后唤醒的设备最容易出现时间漂移,重新同步一次网络时间(NTP)后再测试。

时间偏差通常不需要精确到秒,但如果偏差超过几分钟,就足以让加密握手失败。这一步排查成本极低,建议放在订阅检查之后第一优先执行。

第三步:检查端口是否被占用或冲突

Clash / Clash Meta(mihomo 内核)启动时需要监听混合端口、HTTP 端口、SOCKS5 端口以及控制面板端口。如果这些端口已经被其他程序占用,客户端可能表现为"看似正常运行,但所有请求都超时",而不是直接报错退出。

  1. 确认本机是否同时运行了其他代理软件、旧版本客户端残留进程,或此前没有正常退出的同类程序。
  2. Windows 下用 netstat -ano | findstr 7890(端口号替换为实际配置的端口)查看该端口是否已被别的进程占用。
  3. macOS/Linux 下可用 lsof -i:7890 查看端口占用情况。
  4. 如果发现冲突,先结束占用进程,或在配置里改用其他空闲端口,重启客户端后再测试。

多开客户端、系统重启后旧进程未被完全清理,是端口冲突最常见的两个诱因。任务管理器/活动监视器里搜索客户端进程名,确认没有残留的旧进程在后台占着端口。

第四步:协议与内核版本是否匹配

部分节点使用较新的协议特性(例如 Hysteria2、某些 VMess 的 AEAD 变体、特定的 Trojan 扩展参数),而客户端使用的内核版本较旧、不认识这些字段时,可能不会明确报错,而是直接把该节点标记为不可用或连接超时。这类问题的典型特征是:同一份订阅,在新内核客户端上正常,在旧内核客户端上全部失败。

  • 确认当前使用的客户端内核是 Clash Premium(已停止更新)还是 Clash Meta / mihomo 内核,新协议基本只在 Meta 系内核中获得支持。
  • 在客户端关于页面或设置页确认内核版本号,和官方发布的最新版本对比是否明显滞后。
  • 如果订阅商说明支持某个较新协议,而本地内核版本较旧,先升级客户端到最新版本再重新测试。

反过来,如果配置文件里出现了当前内核不支持的字段或代理类型,一些客户端的处理方式是跳过该节点而不是报错提示,同样会造成"节点全部消失或超时"的错觉,实际是解析阶段就被过滤掉了。

第五步:测速与延迟测试的正确姿势

确认前四步都没问题后,再回头看延迟测试本身。延迟测试用的测速地址(如 http://www.gstatic.com/generate_204 一类)本身也可能在特定网络环境下不稳定,如果测速地址本身访问受阻,会导致所有节点显示超时,但节点其实是可用的。

  1. 在客户端设置里查看当前使用的测速地址,尝试更换为其他常用测速地址。
  2. 手动选中一个节点、切换到全局模式,直接打开一个网页验证是否能正常加载,不要只依赖延迟数字判断。
  3. 如果延迟数字异常但网页能正常打开,说明测速链路本身有问题,节点其实工作正常,不必继续排查节点配置。

排查顺序小结

把上面五步整理成固定顺序,遇到"节点全部超时"时按此执行,基本能在几分钟内定位到问题所在环节:

  1. 订阅是否过期或流量耗尽——去服务商面板核对,不只看链接能否打开。
  2. 本地系统时间是否偏差——检查自动同步是否开启、时区是否正确。
  3. 端口是否被占用或冲突——用 netstat/lsof 确认,清理残留进程。
  4. 协议与内核版本是否匹配——升级客户端内核,核对协议支持范围。
  5. 测速地址本身是否可用——更换测速地址,以实际打开网页为准。

五步走完仍无法解决,再考虑订阅商侧的问题(机房被封、落地线路故障),这时候联系服务商反馈会比继续本地排查更有效率。

下载 Clash 客户端

排查完本地环境问题后,建议使用最新版本客户端重新导入订阅测试。

下载Clash