Clash 节点超时无法连接怎么办:按顺序排查订阅、端口与协议参数
节点全部超时或个别超时的成因不同。按订阅有效性、本地测速方式、端口与协议参数、系统时间与防火墙的顺序逐项排查,给出每一步的判断依据与对应解决办法。
节点超时是 Clash 及 mihomo 内核使用中最常见的故障现象,但"超时"背后对应的原因并不单一。同样的红色感叹号或 timeout 提示,可能来自订阅本身失效、本地测速方式不准确、端口与协议参数写错,也可能是系统时间偏差或本地防火墙拦截握手包。逐一排查前,先做一次分类判断,能省去大半无效操作。
B-01先分清是全部超时还是个别超时
打开节点列表,观察超时节点的分布范围,这一步决定了接下来该往哪个方向排查。
- 全部节点超时:通常指向本地网络环境问题、订阅整体失效、系统时间偏差,或本地防火墙/安全软件的整体拦截,而不是某个节点本身坏了。
- 个别节点超时,其余正常:大概率是对应节点的服务器端下线、该节点的协议参数与服务端不匹配,或该节点所在的中转链路本身不稳定。
- 时好时坏,反复波动:多见于测速方式本身不准确,或者服务端在高峰时段限速,并不代表节点彻底失效。
注意 NOTE
不要在没有分类之前就重新导入订阅或删除节点重建配置——这类操作会掩盖真实原因,导致下次出现同样问题时又要从头排查一遍。
B-02订阅有效性排查
如果是全部节点超时,先确认订阅本身是否仍然有效,这是最容易被忽略但发生概率最高的一环。
- 打开客户端的订阅管理页面,查看订阅的到期时间与剩余流量。多数订阅在流量用尽或套餐到期后,机场端会直接拒绝所有连接请求,表现出来就是全部节点超时。
- 手动点击"更新订阅",观察节点数量是否发生变化。若更新后节点数变为 0 或列表为空,说明订阅链接已经失效或被服务端下架。
- 在浏览器中直接打开订阅链接(去掉客户端专用的请求头限制后),确认返回的是正常的 Base64 或 YAML 文本,而不是一段错误页面或空白响应。若返回 403、404 或空内容,问题出在订阅源而不是客户端配置。
- 检查订阅链接是否包含到期参数或临时授权 Token,部分机场的订阅链接存在有效期,过期后需要在后台重新生成。
订阅本身正常但节点仍全部超时,再继续往下排查测速方式与本地环境;订阅确认失效,直接联系服务商更新链接即可,无需再检查客户端配置。
B-03本地测速方式核验
客户端界面显示的延迟数值,依赖测速方式本身是否合理。测速方式不当,会造成节点其实可用却被误判为超时。
- 测速地址选择:多数客户端默认使用
http://www.gstatic.com/generate_204或类似的连通性检测地址。若本地网络对该域名本身访问不稳定,测出的延迟会失真,可在设置中更换为其他探测地址再对比一次。 - 测速协议差异:TCP 延迟测试与实际代理流量所走的协议(如 Shadowsocks、VMess、Trojan、Hysteria2)握手方式不同,TCP 层面显示正常,不代表代理协议层面一定能建立连接,这也是"测速正常但打开网页还是慢或超时"的常见原因。
- 并发测速的干扰:一次性对全部节点批量测速时,本地带宽与并发连接数会互相挤占,导致排在后面的节点测速结果偏高。建议先对单个怀疑节点单独测速,再下结论。
curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I -m 5该命令通过本地代理端口发起一次连通性请求,若返回 HTTP/1.1 204 说明当前选中的节点与本地代理链路均正常,超时提示更可能是客户端界面测速逻辑本身的问题;若命令本身也卡住或报错,说明问题确实发生在代理链路上,继续往下排查端口与协议参数。
B-04端口与协议参数核查
个别节点长期超时,且排查过订阅与测速方式后依然如此,大多是该节点的连接参数与服务端配置不一致。
- 核对端口号:打开节点详情,确认端口号与机场后台提供的信息完全一致。手动订阅或自建节点时,复制粘贴过程中多一位或少一位数字是最常见的低级错误。
- 核对协议与加密方式:Shadowsocks 需要确认加密方式(如
aes-256-gcm、chacha20-ietf-poly1305)与服务端一致;VMess 需要核对 UUID、AlterId(新版本通常为 0)与传输方式(TCP/WS/gRPC);Trojan 与 Hysteria2 需要核对 SNI 与证书验证选项是否匹配服务端配置。任意一项写错,现象都是握手失败、表现为超时。 - 核对传输层配置:若节点使用 WebSocket 或 gRPC 传输,还需检查 Path、Host 头是否与服务端一致。这类参数在手工订阅链接解析时偶尔会被截断或转义错误。
- 核对 TLS/SNI 设置:开启 TLS 的节点若 SNI 填写错误或指向了未备案、已被拦截的域名,同样会在握手阶段直接超时,现象与端口错误几乎无法从界面上区分,需要逐项核对配置文件。
注意 NOTE
手工修改配置文件后,建议先用客户端自带的"配置校验"或重新加载功能确认 YAML 语法无误,再进行连接测试,避免把语法错误误判为网络问题。
B-05系统时间与本地防火墙排查
当前面几步都未发现问题,但仍然全部超时,系统层面的两个环境因素容易被忽略。
- 系统时间偏差:多数加密代理协议(尤其是 Shadowsocks 的 AEAD 加密与 VMess 的时间戳校验)依赖客户端与服务端的系统时间基本同步。若本地系统时间偏差超过一定范围,服务端会直接拒绝握手,表现为所有节点同时超时。检查系统时间是否已启用"自动同步网络时间",手动核对时区设置是否正确。
- 本地防火墙与安全软件:部分安全软件或系统自带防火墙会对 Clash 监听的本地端口(如
7890混合端口、TUN 模式虚拟网卡)进行拦截或限速。可临时关闭安全软件的网络防护模块进行对照测试,若关闭后恢复正常,再逐条添加对应的放行规则,而不是长期关闭防护。 - TUN 模式的驱动权限:若使用 TUN 模式接管全局流量,虚拟网卡驱动需要管理员/root 权限才能正常创建。权限不足时,流量可能仍走系统代理路径而非 TUN,导致部分应用连接异常,排查时可先切回系统代理模式做对照。
- 路由器或上级网络限制:部分家庭宽带或公司网络会对特定端口范围进行限速或封锁,若确认本机所有配置均无误,可尝试更换网络环境(如手机热点)做交叉验证。
B-06排查顺序小结
整理成表格,方便按顺序逐项核对,避免遗漏或重复操作。
| 现象 | 优先排查方向 | 判断依据 |
|---|---|---|
| 全部节点同时超时 | 订阅有效性、系统时间、本地防火墙 | 更新订阅后节点数是否异常;系统时间是否已同步 |
| 个别节点长期超时 | 端口与协议参数 | 逐项核对端口、加密方式、SNI 是否与服务端一致 |
| 时好时坏反复波动 | 测速方式、服务端限速 | 单独测速对照;更换探测地址复测 |
| 浏览器可上网但个别应用不通 | TUN 模式权限、进程规则 | 切回系统代理模式做对照测试 |
按上述顺序排查一遍后,绝大多数超时问题都能定位到具体环节。若最终确认是服务端节点本身下线或限速,更换机场或联系服务商是唯一有效的解决办法,客户端本地配置无法解决服务端侧的问题。
按图施工:下载 Clash 客户端
排查配置前,先确认使用的是正规渠道获取的客户端版本,避免因客户端本身异常导致误判。