Clash 节点超时、无法连接怎么办：由近到远的排查顺序

一、先区分节点测速失败与实际连接失败

Clash 里的 Timeout 只表示某次操作没有在规定时间内完成，不能直接等同于节点已经失效。节点延迟测试通常是经由节点请求一个测试 URL，测量的是整条请求链路，而不只是到服务器的网络延迟。测试站点不可达、域名解析失败、TLS 握手异常，都可能让结果变成超时。

本文以 Clash Verge Rev 配合 mihomo 内核为例。先打开「代理」页，记下当前运行模式、目标策略组和选中的节点；再打开「连接」与「日志」页，保留故障发生时的记录。界面名称随版本可能略有变化，端口和配置以实际运行值为准。

• 只有一个节点失败：优先核对该节点的地址、端口、协议参数及服务状态。
• 全部节点失败：优先检查本机入口、订阅账户、DNS 和当前网络，不要立即批量修改节点。
• 测速失败但网页可用：检查测试 URL 与超时阈值，不要仅凭测速颜色删除节点。
• 测速正常但网页打不开：检查应用是否进入内核、规则命中和实际选用的策略链。

二、检查系统代理、监听端口与本机入口

确认应用是否把请求交给了内核

先在「设置」中查看「系统代理」状态与当前代理端口，再到系统网络设置中核对实际写入的地址。以 Windows 11 为例，路径是「设置」→「网络和 Internet」→「代理」→「手动设置代理」。正常的本机代理地址通常为 127.0.0.1，端口必须与客户端监听值一致。

不要假定端口一定是 7890 或 7897。下面仅以当前配置的 mixed-port: 7897 为例；mixed-port 是同时接受 HTTP 和 SOCKS 请求的混合代理入口。Windows PowerShell 可以执行：

Get-NetTCPConnection -LocalPort 7897 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

curl.exe --noproxy "" --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/

macOS 或 Linux 可用以下命令检查相同入口；如果配置端口不同，先修改命令中的数字。

lsof -nP -iTCP:7897 -sTCP:LISTEN
curl --noproxy "" --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/

• 立即提示连接本机端口失败：内核可能未启动，或实际端口不同。先解决本机监听，不必继续排查远端节点。
• 日志出现 address already in use：端口被其他进程占用。核对进程名称，关闭重复运行的代理客户端，或在客户端中更换端口并重新同步系统代理。
• 命令可用，浏览器不可用：检查浏览器代理扩展、独立代理设置和缓存的旧连接；关闭旧连接后重试。

这条 curl 命令只验证请求能进入本地代理，并不保证规则最终选中了远端节点。请求仍可能命中 DIRECT，必须结合「连接」页核对。出现 HTTP 响应也不等于目标业务可用，但可以证明请求已推进到响应阶段。

把 TUN 与系统代理分开验证

系统代理只影响遵循系统设置的应用；TUN 则通过虚拟网卡和路由接管流量。若问题仅在 TUN 开启时发生，先记录原设置，再关闭 TUN，用系统代理和上面的显式代理命令建立基线。若基线正常，再检查 TUN 的服务权限、路由以及是否与其他 VPN 冲突。

修改前保留配置备份。不要用长期关闭系统防火墙的方法代替排查，也不要在不清楚用途时删除虚拟网卡。企业设备上的路由和安全策略应先向管理员确认。

三、检查订阅更新、账户状态与当前配置

打开「配置」页，确认正在使用的是预期订阅，而不是旧的本地配置。对该订阅执行一次更新并查看结果。订阅下载成功只代表配置文件取得成功，不代表账户仍有流量、所有节点都在线，也不代表新配置已成为当前活动配置。

1. 检查服务商账户的到期时间、剩余流量和连接数限制；流量显示缺失时，以账户面板为准。
2. 比较更新前后的节点数量与名称，确认服务商是否调整了节点入口或协议。
3. 确认配置已经激活，随后在「代理」页重新检查策略组的选项。
4. 若更新失败，区分订阅请求的 HTTP 错误、下载超时与配置解析错误，不要将它们统称为节点超时。

HTTP 401 或 403 可能涉及凭据失效、访问限制或账户状态，需要结合服务商说明判断；YAML 解析错误则通常发生在内核载入配置之前。此时应修复订阅内容或兼容性，而不是反复测速。

四、检查 DNS：失败的是节点域名还是目标域名

代理连接至少可能涉及两类解析：一类是节点服务器域名，另一类是要访问的网站域名。前者失败时，内核连远端服务器地址都无法取得；后者失败时，节点本身可能正常，但特定网站仍然打不开。日志中的具体域名比一句“DNS 有问题”更有用。

先查看系统解析，再查看内核解析

Windows 可执行 Resolve-DnsName example.com，macOS 或 Linux 可执行 nslookup example.com，确认系统解析是否返回结果。检查真实节点时，应使用订阅中服务器字段对应的域名，不要把含凭据的订阅链接当成节点域名。

这些命令默认检查系统解析路径，并不能直接证明 mihomo 内部 DNS 正常。如果配置启用了 dns.enable，还要检查实际配置中的 nameserver、proxy-server-nameserver 和相关策略。后者用于指定节点域名解析所用的上游；使用 DoH 时，还需要考虑 DoH 服务自身域名的初始解析。

• 日志提示 lookup 或 no such host：核对域名拼写和上游 DNS 可达性，区分系统解析失败与内核解析失败。
• 解析返回地址但仍超时：继续查对应地址与端口的连接，不要把所有超时都归因于 DNS。
• 出现 198.18.0.0/16 地址：在 Fake-IP 模式下可能属于正常映射；应检查请求是否被内核接管，而不是仅凭地址判断解析错误。

不要一次塞入大量公共 DNS 地址。先保留原配置，核对上游能否在当前网络访问；如果 DNS 请求必须经过代理，而节点启动又依赖同一路径解析，就可能形成循环依赖。DNS 与分流的基础概念可参照协议手册。

五、按日志阶段定位连接中断点

打开「日志」页，在复现前清理视图或记下时间，只发起一次请求。若普通日志不足，可临时将日志级别调整为 debug；完成排查后恢复 info，避免持续产生大量记录。日志可能包含访问域名与服务器地址，分享前需要脱敏。

单条错误通常不足以确定责任方。例如 EOF 既可能来自协议不匹配，也可能来自远端主动断开。重点是找到最早出现的相关错误，而不是最后一条“请求失败”。如果所有请求都在载入配置时失败，应先解决配置错误，再分析网络。

六、核对节点协议参数与远端端口

如果本机入口、订阅和 DNS 都正常，再检查节点的 server、port 与协议类型。TCP 端口探测只能证明连接是否能建立，不能证明认证、加密或代理转发成功。Windows 的 Test-NetConnection 可在指定真实服务器与端口后测试 TCP；UDP 协议不能用同样结果作结论。

• Shadowsocks：核对加密方法、密码及插件要求；方法名称必须与服务端一致。
• VMess / VLESS：核对 UUID、传输方式与 TLS 相关配置。VLESS 的 flow 等字段必须匹配服务端设置。
• TLS / WebSocket：核对 SNI、Host 和路径。服务器连接地址、TLS 名称、HTTP Host 可能不同，不能机械地全部改成同一个 IP。
• REALITY：核对服务商提供的公钥、short-id、server-name 等参数，不要仅复制一个服务器地址。
• Hysteria2 / TUIC：通常依赖 UDP。若同网络的 TCP 节点可用而这些节点失败，应检查网络是否限制 UDP，以及本机安全策略是否阻断。

遇到证书错误，先同步系统日期、时间和时区，再确认服务端证书及名称匹配。不建议把跳过证书验证当作长期修复。若配置含内核不支持的字段，记录客户端与内核的实际版本，再根据服务商要求判断兼容性；不要只依据界面的客户端版本号推断所有协议能力。

七、用规则命中和交叉测试收尾

最后回到「连接」页，重新打开目标网站，查看匹配规则、策略组与最终节点。Rule 模式下，一部分请求命中 DIRECT 本来就是预期行为；REJECT 则表示规则拒绝，并非节点超时。策略组还可能嵌套自动选择组，因此在外层选中一个组，不等于固定到了某个节点。

保留最小对照，避免扩大修改范围

1. 固定同一节点、同一目标，比较系统代理与显式代理请求，确认应用接管问题。
2. 在合规且允许的网络环境中，比较当前网络与手机热点；若只有一个网络失败，优先查该网络的 DNS、端口或 UDP 限制。
3. 保持网络不变，切换另一个已知可用节点；若只有单节点失败，向服务商提交该节点与故障时间。
4. 如需临时使用 Global 模式排除规则影响，测试后恢复原模式，并再次核对连接链。

向支持人员反馈时，提供操作系统版本、客户端版本、内核版本、故障时间与时区、节点协议、是否使用 TUN、脱敏日志，以及两组对照测试结果。不要只发送一张全部红色的测速截图：它缺少请求在哪个阶段失败的信息。