故障排查 预计阅读 8 分钟

Clash 节点超时无法连接怎么排查:从订阅、端口到协议的检查顺序

节点全部超时不等于节点失效。按订阅有效性、本地端口占用、系统代理开关、协议与内核匹配、DNS 污染五层逐一排查,定位到底是配置问题还是链路问题,并给出每层对应的解决办法。

排查前先判断问题范围

看到延迟栏一片"超时"或"timeout"时,第一反应往往是怀疑节点失效或订阅到期,但这只是众多可能原因之一。更常见的情况是本地环境出了问题:端口被占、系统代理没生效、内核版本与协议不匹配、DNS 解析被污染。这些问题会让延迟测试整批失败,表现和"节点全灭"几乎一样,却和节点本身没有任何关系。

建议先做一个最小判断:打开系统的浏览器,直接访问一个国外站点,如果连不通且没有走代理的迹象,大概率是链路层没打通;如果代理软件界面显示"已连接"但网页依旧转圈,再往下逐层排查。避免一上来就换订阅、删节点,那样只会把简单问题复杂化。

第一层:订阅有效性检查

订阅链接本身失效是最容易被忽略的一层,尤其是免费或到期未续费的订阅。判断方法很直接:

  • 在客户端里手动点击"更新订阅",观察是否返回节点数量变化或报错提示。
  • 把订阅链接粘到浏览器地址栏直接访问,若返回的是空文本、404 或一段错误 JSON,说明服务端已经失效,而不是本地配置问题。
  • 查看订阅到期时间与剩余流量,部分面板会把这两项塞进 Subscription-Userinfo 响应头里,客户端界面通常会展示。

如果订阅确实失效,后面几层再怎么排查都不会有结果,先联系服务商或更换有效订阅链接是唯一出路。订阅正常但节点仍超时,再进入下一层。

第二层:本地端口占用与监听状态

Clash 内核会监听一组本地端口:HTTP 代理端口、SOCKS5 端口,以及用于面板通信的外部控制端口(默认 9090)。如果这些端口被其他程序占用,内核会启动失败或代理功能不完整,表现出来就是节点看似在线但流量根本没有经过它。

排查方法:

  1. 查看客户端设置里的端口号,记下 HTTP 端口(常见 7890)与混合端口(常见 7891)。
  2. 用系统命令检查该端口是否被其他进程占用,Windows 下用 netstat -ano | findstr 7890,macOS/Linux 下用 lsof -i:7890。
  3. 若发现被占用,关闭冲突程序,或在客户端配置里把端口改成未被占用的号段,重启客户端后重试。

同一台电脑同时运行两个代理工具是常见诱因,例如另一款科学上网工具的进程没有完全退出,残留在后台继续占用端口。

第三层:系统代理与 TUN 模式开关

端口正常监听不代表流量真的会流向 Clash。系统层面的代理开关同样关键:

  • 系统代理模式:客户端会自动写入系统的 HTTP/HTTPS 代理设置,如果这个开关被误关闭,浏览器与大多数应用会直接绕过 Clash,走原始网络出去。检查客户端界面的"系统代理"开关是否处于开启状态。
  • TUN 模式:TUN 模式通过虚拟网卡在系统网络层接管全部流量,不依赖单个应用的代理设置,适合处理不遵循系统代理的程序。开启 TUN 模式在部分系统上需要额外授权(网络扩展权限、管理员权限),如果授权被拒绝,TUN 会启动失败但界面未必给出明显提示。
  • 某些应用不走系统代理:命令行工具、部分游戏客户端不读取系统代理设置,这类场景必须依赖 TUN 模式或单独配置该程序的代理参数。
提示

判断流量是否真的经过 Clash,可以打开客户端的连接面板(Connections),访问网页时观察是否出现对应的连接记录。没有记录出现,说明流量根本没有进入 Clash,问题在这一层,而不是节点。

第四层:协议与内核匹配

Clash 原版内核只支持有限的几种代理协议,而 Clash Meta(即 mihomo)扩展支持了 Hysteria、Hysteria2、TUIC、VMess 的部分变体等更多协议。如果订阅里包含了原版内核不认识的协议类型,对应节点会直接被标记为不可用或延迟测试恒定超时,这不是网络问题,是内核能力不足导致的。

排查方法:

  1. 确认客户端底层使用的内核版本,大多数现代客户端(如 Clash Verge Rev、FlClash、Clash Plus)默认已经切换到 Meta/mihomo 内核。
  2. 查看订阅节点列表中的协议字段,如果出现 hysteria2、tuic 等关键字,而客户端仍在使用旧版原生 Clash 内核,需要更换支持这些协议的客户端。
  3. 协议本身对网络环境也有要求,例如基于 QUIC 的协议在部分网络下会被运营商针对性限速或阻断,表现为该协议节点普遍超时,而其他协议节点正常,这种情况需要换用其他协议的节点,而不是继续排查本地配置。

第五层:DNS 污染与解析异常

就算前四层全部正常,DNS 解析环节出问题同样会让节点表现为超时。原因在于:客户端在测速或建立连接前,需要先把节点的域名解析成 IP 地址,如果这一步被污染,解析结果就是错误 IP 或空结果,后续连接自然失败。

常见处理方式:

  • 在配置文件的 dns 字段里启用 enhanced-mode: fake-ip,并配置可信的上游 DNS(如加密 DoH/DoT 服务器),避免走本机默认的、可能被污染的 DNS。
  • 检查 nameserver 列表是否包含国内运营商默认 DNS,如果有,替换为独立的加密解析地址。
  • 开启 TUN 模式后,DNS 请求同样会被接管,若仍解析异常,检查 TUN 配置块里的 dns-hijack 设置是否正确劫持了 53 端口的请求。
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-range: 198.18.0.1/16

配置好上游 DNS 后重启内核生效,再次测速观察节点延迟是否恢复正常数值。

五层排查顺序小结

整理成一句话:先确认订阅本身能不能拉到数据,再确认端口没被占用、系统代理或 TUN 有没有真正接管流量,然后检查协议是否被当前内核支持,最后排查 DNS 解析是否被污染。这五层从"外部数据源"到"本地网络栈"层层递进,任何一层出问题都会造成表面一致的"全部超时"现象,但对应的解决办法完全不同,按顺序排查能避免在错误的方向上反复折腾配置文件。

如果按以上五层逐一核对后节点依旧超时,可以换一条网络环境测试(如手机热点),用于隔离本机与所在网络环境的干扰因素,进一步缩小问题范围。

下载客户端