Clash 节点全红、全部超时的六种成因与排查顺序

一整列节点齐刷刷变红,写着 TIMEOUT,这个画面的信息量其实比看起来大。当所有节点同时失败,故障点几乎必然在它们的共用路径上——不同国家、不同机房、不同服务商的服务器不会在同一秒集体宕机,能让它们一起失效的东西只有那么几样:你的本地网络、你的系统设置、客户端进程本身,或者机场的调度服务端。

这也解释了为什么换节点没用。换节点只能绕开单个节点的问题,而共用路径上的故障,换一百个节点仍然是一百个红色。

排查的正确姿势是做交叉验证:固定变量,一次只改一个条件,看现象是否跟着变。下面这棵判定树按「排除成本从低到高」排序,照着走通常十分钟内能定位到具体那一层。

先确认:是延迟测不出来,还是真的连不上?#

这两件事在界面上长得一样,含义完全不同。

延迟测试是客户端主动发起的一次探测请求,它有自己的超时阈值和测试地址。测试地址本身不可达、超时阈值设得太短、或者客户端在批量测试时并发过高,都会导致「显示超时但节点其实能用」。

所以第一个动作不是相信那列红色,而是直接挑一个节点点上去,然后打开一个网页试试。

最后一行要优先处理:如果连国内网站都不通,先退出客户端并确认系统代理开关已关闭,把基础网络恢复了再谈其他。这种情况在开过 TUN 之后特别常见,处理方法见开启 TUN 后整机断网的恢复流程。

换一条网络复测,能说明什么?#

这是整棵判定树里性价比最高的一步,通常两分钟,能一刀切掉一半的可能性。

做法很简单:用手机开个热点,把电脑连过去,不改任何客户端设置,重新测速。

如果手上有第二台设备(比如手机装了客户端、导入同一份订阅),还可以再加一维,构成一张更完整的矩阵。

这张矩阵是整篇文章的核心。两个额外条件(换网络、换设备)就能把六类成因压缩到一两类,比逐项猜测快得多。校园网、公司网和部分酒店网络是「换热点就好」的高发场景。

系统时间偏差为什么会让所有节点握手失败?#

如果换网络、换设备都没用,下一个要查的就是本机时间——它是少数几个能让全部节点同时失效的本地因素。

原因有两条独立的路径。一是走 TLS 的协议(如 Trojan、以及套了 TLS 的 VLESS)在握手时要校验服务器证书的有效期,本机时间偏差过大会让证书被判定为「尚未生效」或「已过期」,握手直接终止。二是部分协议自带基于时间戳的身份校验机制,双方时间差超出容许窗口,服务端会主动拒绝这次连接。

# 结构示例:先看本机时间,再与任意可信来源核对,误差控制在一分钟以内
date

高发人群是虚拟机、长期休眠不重启的笔记本、双系统机器和主板电池老化的旧台式机。处理办法是打开系统的自动对时并强制同步一次,同步完直接重测。

顺带一提,时间偏差也会让订阅拉不下来,原理相同。如果你同时遇到更新失败,可以对照订阅更新失败的四层排查一起处理。

防火墙、杀毒软件和企业管控会怎么表现?#

安全软件造成的超时有几个很好认的特征。

时间点特征:昨天还好好的,今天全红,中间发生过安全软件更新、系统更新或客户端版本升级。安全软件的规则库更新后重新识别了客户端进程,是最常见的触发点。

范围特征:客户端里全部超时,但其他联网软件一切正常。因为拦截是按进程做的,只掐这一个。

日志特征:客户端日志里出现大量连接被主动重置的记录,而不是超时无响应。被拦截和连不通,在日志里的措辞不一样。

验证方式是临时关闭安全软件的实时防护(注意是临时),重测一次。恢复正常就说明找对了,然后立刻把防护打开,改用添加信任的方式解决:把客户端主程序、它的服务组件、以及配置目录一并加入例外列表。

企业统一管控的电脑是另一回事。这类设备上的终端管理软件通常不允许用户自行添加例外,也可能在网络层直接封禁非白名单流量。遇到这种情况,自查到此为止,继续折腾没有意义。

端口冲突和残留代理设置怎么查?#

Clash 在本机监听几个端口对外提供代理服务,如果这些端口被别的程序先占了,客户端可能启动失败,也可能启动了但服务不可用,表现同样是全部超时。

# 结构示例:查看某个端口被哪个进程占用,端口号替换成你客户端里配置的那个
netstat -ano | findstr :7890

拿到进程号后在任务管理器里对号入座。常见的占用者是:上一次异常退出后残留的客户端进程、另一个同时开着的代理软件、以及某些自带本地代理的开发工具。

残留代理设置是另一个坑,而且更隐蔽。客户端崩溃退出时不一定会还原系统代理开关,于是系统还指着一个已经没有程序在监听的端口。这时候所有流量都被送进一个黑洞,现象是全网不通;而重新打开客户端后,如果它的端口和上次不同,问题依然存在。

处理顺序是:任务管理器里结束掉所有相关的残留进程 → 到系统的代理设置里手动关掉那个指向本机端口的开关 → 确认国内网站能打开 → 再重新启动客户端。关于系统代理这一层的完整机制,可以看代理模式与系统代理的关系。

怎么判断这是机场侧的大面积故障?#

走到这一步,前面的本地因素都已排除。判断机场侧故障需要同时满足几个条件,少一条就不成立:

1. 换网络无效,手机热点、公司网、移动数据都试过,现象一致。
2. 换设备无效,同一份订阅在另一台设备、另一个客户端上同样全红。
3. 订阅能正常更新,说明账号有效、链接有效,只是节点连不上。
4. 有旁证,机场的公告页、通知渠道或用户社群里出现同类反馈。

第三条特别关键。订阅能更新说明你和机场的服务器之间是通的,账号也是活的,问题只在节点服务端;订阅同时也更新不了,那更可能是账号到期或链接失效——两条路的处理方式完全不同。

第四条如果拿不到旁证,可以退一步:等三十分钟再测一次。机场侧的临时故障、节点批量重启、以及大规模封锁后的换 IP 操作,通常在几十分钟到几小时内会有变化。持续超过一天且客服没有任何说明,才值得考虑换服务商这件事,可以从机场对照表重新筛一遍。

反复换节点为什么解决不了问题?#

回到开头那句话。全部超时这个现象本身,就已经排除了「某个节点坏了」这种可能性——不同地区、不同机房、不同上游的服务器不会同时出问题,除非它们共用的某样东西坏了。

换节点这个动作只在一种情况下有意义:部分节点红、部分节点绿。那说明共用路径是通的,问题在个别节点上。而全红意味着共用路径断了,你换的每一个节点都要走同一条断掉的路。

最后一行是另一类故障,别混进来。节点有延迟数字而网页打不开,属于已连接却打不开网页的范畴,排查方向完全不同。刚装好客户端、还没确认基础设置的,建议先按Clash Verge Rev 的初始化流程走一遍再来排查。

小结#

全部超时说明故障在共用路径上,所以第一反应不该是换节点。先分清是测试失败还是真的连不上,再用「换网络、换设备」两个动作做交叉验证,六类成因立刻能压缩到一两类。本机时间是最容易被跳过又最容易中招的一项,顺手校一次成本极低。判定机场侧故障要同时满足换网无效、换设备无效、订阅能更新、有旁证四条,少一条都可能是误判。