Clash 节点超时无法连接怎么办:按这个顺序排查最快

先分型：全部超时还是个别节点超时

排查前先停止反复点击延迟测试。节点超时只是结果，不直接说明节点已经失效。订阅过期、当前网络断流、系统时间错误、DNS 异常、端口冲突和配置参数不兼容，都可能显示为 timeout。先确认故障范围，后面的检查才能缩短。

全部节点超时

如果同一订阅里的香港、日本、美国等不同地区节点都在同一时间超时，优先检查公共环节。公共环节包括订阅状态、直连网络、Clash 内核是否运行、系统代理或 TUN 是否建立，以及当前网络是否限制了相关协议。几十个节点同时故障的概率通常低于本地环境整体异常。

切换任意策略组后，所有节点都显示 timeout。
延迟测试等待 5 至 10 秒后统一失败。
日志中连续出现网络不可达、DNS 解析失败或连接被拒绝。
关闭 Clash 后，普通网页也无法通过直连网络打开。

只有部分节点超时

如果同一订阅中仍有节点能测出 45 ms、120 ms 等延迟，说明客户端内核、基本网络和订阅格式大概率可用。此时重点转向故障节点本身：服务器离线、端口更换、协议参数变化、线路被当前运营商阻断，或者健康检查地址对该节点不可达。

现象	优先检查层	下一步
所有节点同时超时	订阅、直连网络、内核运行状态	按本文顺序从第一步开始
同一地区少数节点超时	节点服务器与地区线路	换同地区其他节点交叉测试
延迟正常但网页打不开	规则、策略组、DNS、系统代理	检查请求实际命中的出口
Wi-Fi 超时，手机热点正常	路由器、局域网 DNS、运营商线路	保留热点结果并检查当前网络

第一步：确认订阅仍有效且配置已更新

先进入客户端的订阅或配置页面。常见入口名称是「订阅」「配置」「Profiles」或「配置管理」。查看当前配置的更新时间、剩余流量和到期时间。不同客户端菜单略有差异，例如可沿「配置」→「订阅管理」或「Profiles」→ 当前配置 →「更新」查找。

确认订阅没有到期，剩余流量不是 0 GB。
手动更新一次订阅，记录更新成功或失败的提示。
更新成功后重新加载该配置，不要只停留在旧配置上。
进入代理组，确认节点列表确实发生刷新。
不要把订阅地址粘贴到公开测速网站或截图中。

订阅更新失败怎么判断

更新时出现 HTTP 401 或 403，通常表示订阅凭据失效、链接被重置或访问受到服务端限制。HTTP 404 表示地址不存在。持续返回 5xx，则要考虑订阅服务端暂时异常。若提示 connection timeout，需要继续检查直连网络能否访问订阅地址，因为不少客户端默认使用直连方式更新配置。

更新成功也不等于节点参数一定有效。打开配置详情，检查节点数量是否异常变成 0，或者新配置是否仍引用旧的 provider 缓存。使用代理集合的配置可能包含如下结构，真正的节点列表来自 provider 文件，而不是主配置本身：

proxy-providers:
  provider-main:
    type: http
    url: "订阅地址"
    path: ./providers/provider-main.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

interval: 3600 表示每 3600 秒尝试更新一次；健康检查的 interval: 600 表示每 600 秒检测一次。主配置更新了，但 provider 缓存仍旧，也可能继续看到已失效节点。可在客户端的代理提供者页面手动更新一次，再重启内核。

第二步：关闭代理，验证直连网络

Clash 依赖当前网络建立到代理服务器的连接。底层网络已经断流时，节点自然全部超时。先在客户端中关闭「系统代理」，如果正在使用 TUN 模式，也暂时关闭 TUN。完全退出浏览器后重新打开，访问一个日常可直连的网站。

做两组最小测试

关闭系统代理和 TUN，使用当前 Wi-Fi 打开直连网站。
保持 Clash 配置不变，把电脑或手机切换到手机热点，再测同一批节点。

如果当前 Wi-Fi 下全部超时，手机热点下立刻恢复，例如节点延迟从 timeout 变成 80 至 250 ms，故障层就在原网络、路由器或运营商路径，不在 Clash 配置。此时先重启光猫或路由器，检查路由器的上网状态和 DNS 设置，再询问网络管理员是否启用了出口限制。

Windows 还可打开终端执行基础连通测试。这里测试的是本地网络和 DNS，不是代理节点速度：

ping 1.1.1.1
nslookup example.com

ping 被禁不一定代表断网，但如果域名解析失败、浏览器直连也打不开网页，就应先修复网络。macOS 和 Linux 可在终端使用相同命令；部分系统需要用 dig example.com 替代 nslookup。

公共 Wi-Fi 的额外检查

酒店、机场和校园网常有认证页。连接 Wi-Fi 后看似已联网，实际仍需浏览器完成登录。关闭代理后访问一个普通 HTTP 页面，确认是否跳转到认证入口。认证完成前，Clash 发出的连接通常会被拦截或重定向，表现为节点全超时。

第三步：校准系统时间，再检查内核与本地端口

系统时间误差会破坏握手

TLS 证书验证依赖日期和时间。系统时间相差数分钟甚至数小时，可能导致订阅请求、WebSocket TLS、gRPC TLS 或其他加密连接失败。进入 Windows「设置」→「时间和语言」→「日期和时间」，打开自动设置时间和自动设置时区，然后点击立即同步。macOS 可进入「系统设置」→「通用」→「日期与时间」，开启自动设置。

同步后完全退出客户端，再重新启动。不要只切换节点，因为旧连接和 DNS 缓存可能仍留在内核进程中。若日志出现 certificate has expired、not yet valid 或 handshake failure，时间和证书链应列为重点。

确认 Clash 或 mihomo 内核正在运行

图形界面能打开，不代表内核进程正常。进入「设置」→「内核」或「设置」→「Clash 内核」，检查状态是否为运行中。采用 Clash Meta 后续内核 mihomo 的客户端，日志和进程名称可能显示 mihomo。若内核反复启动失败，先打开日志查看第一条 error，而不是只看最后一条重试信息。

检查端口是否冲突

常见本地 HTTP 与 SOCKS 混合端口是 7890，控制端口常见为 9090。具体值以当前 YAML 和客户端设置为准。下面是常见配置形式：

mixed-port: 7890
external-controller: 127.0.0.1:9090
allow-lan: false
mode: rule
log-level: info

若另一个代理程序已经占用 7890，Clash 可能无法监听该端口。Windows 可在终端执行：

netstat -ano | findstr :7890
netstat -ano | findstr :9090

macOS 或 Linux 可执行：

lsof -nP -iTCP:7890
lsof -nP -iTCP:9090

发现端口被旧进程占用后，先退出旧代理程序，或在「设置」→「端口设置」中把 mixed port 改为未占用端口，例如 7891。修改后还要让系统代理同步使用新端口。只改 YAML、不更新系统代理，会导致浏览器继续连接旧的 127.0.0.1:7890。

第四步：核对节点协议参数与配置兼容性

当订阅有效、直连正常、内核也在运行时，再检查节点参数。不要根据节点名称手工猜测协议。应以服务端下发内容为准，重点核对服务器地址、端口、UUID 或密码、传输方式、TLS、SNI、ALPN 和 Reality 参数。

容易造成超时的参数差异

server 与 port：服务器迁移后仍使用旧地址或旧端口。
network：服务端使用 WebSocket，客户端却按 TCP 直连。
servername 或 sni：TLS 握手使用了错误域名。
ws-opts.path：WebSocket 路径缺少前导斜杠或仍是旧值。
grpc-opts.grpc-service-name：gRPC 服务名与服务端不一致。
Reality 参数：public-key、short-id 或 servername 不匹配。
UDP：节点未启用 UDP，却被用于依赖 UDP 的请求。

旧版 Clash 内核不认识部分新字段时，可能在载入配置阶段直接报错，也可能跳过不兼容节点。遇到配置包含 Reality、Hysteria2、TUIC 等类型时，应确认客户端使用支持对应协议的 mihomo 版本。版本过旧时，优先通过客户端内置的「设置」→「内核」→「更新内核」完成更新，并在更新后重新载入配置。

如果日志中出现 unsupported proxy type、field not found 或配置解析失败，问题发生在配置载入层，还没有进入节点连接层。此时反复延迟测试没有意义，应先处理内核兼容性或订阅格式。

健康检查超时不等于所有网站都不可用

客户端延迟测试通常访问指定 URL，例如返回 HTTP 204 的轻量页面。测试地址可能被节点出口、DNS 或当前网络单独限制。可以把测试 URL 临时换成另一个稳定的 HTTPS 地址进行交叉验证，但不要用大文件下载地址作为健康检查，否则会增加流量和测试时间。

判断节点是否真能使用，应同时看三项：健康检查延迟、日志中的连接结果、实际网页请求。单次 5000 ms 超时只能说明该测试在限定时间内没有完成。连续三次超时，并且实际请求也失败，才更接近节点或线路故障。

第五步：检查系统代理、TUN 与 DNS 所在层

系统代理模式

系统代理模式主要接管遵循系统代理设置的应用。先进入客户端「设置」→「系统代理」，关闭后再开启一次，并核对代理地址是 127.0.0.1、端口与 mixed port 一致。浏览器扩展、其他代理软件和手工 PAC 配置可能覆盖系统设置，排查时应暂时停用这些额外入口。

若节点测试正常，但只有某个应用无法联网，故障通常不在节点。检查该应用是否读取系统代理，或者是否自行指定了代理端口。可先用浏览器验证，再与故障应用对比。

TUN 模式

TUN 模式通过虚拟网络接口接管更多流量，通常需要管理员权限。开启失败时，客户端日志可能出现 interface、route、permission 或 device 相关错误。Windows 可用管理员权限启动客户端；macOS 首次启用时需要批准网络扩展或 VPN 配置。若系统内还有其他 VPN，先完全退出，避免路由表和虚拟网卡冲突。

排查 TUN 时使用二分法：关闭 TUN，仅开启系统代理。如果浏览器恢复，节点本身可用，问题集中在 TUN 权限、路由或 DNS；如果两种模式都超时，继续查看节点与线路层。

DNS 异常的识别方法

节点延迟正常，但输入域名打不开；直接访问已知 IP 却有响应，这类现象应检查 DNS。mihomo 配置中常见 dns.enable、nameserver、fallback、fake-ip 等字段。不要在不理解原配置的情况下同时改动全部 DNS 项。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

端口 1053 也必须未被占用。若使用 TUN 与 fake-ip，关闭 TUN 后应重新测试，避免旧路由和缓存干扰。Windows 可执行 ipconfig /flushdns 清理系统 DNS 缓存；macOS 可在重启网络或系统后复测。清缓存只是辅助动作，不能修复错误的上游 DNS 配置。

第六步：最后再换节点，并用日志确认结论

前面公共环节均正常后，才进入换节点阶段。先在同一地区选择 2 至 3 个不同节点，每个节点连续测试三次，间隔约 10 秒。不要一次测试几十个节点，因为并发健康检查可能触发网络限速，也会让日志难以阅读。

选择节点 A，测试延迟并打开一个实际网页。
选择同地区节点 B，重复相同操作。
切换到另一地区节点 C，判断是否为地区线路问题。
再切换手机热点，保留一组不同网络的对照结果。

如果节点 A、B 在家庭宽带超时，在手机热点正常，结论偏向当前运营商路径。如果同一节点在两种网络都超时，而同订阅其他节点正常，结论偏向节点服务器或端口。如果所有地区在两种网络都超时，则应回到订阅和协议参数层重新核对。

日志里看哪些关键词

i/o timeout：连接或读写在限定时间内未完成。
connection refused：目标地址可达，但对应端口拒绝连接。
network is unreachable：本机路由或网络接口无法到达目标。
no such host：域名解析失败。
TLS handshake timeout：TLS 握手超时，需检查线路、SNI、时间和服务端。
authentication failed：认证参数不一致或凭据失效。

日志级别先用 info。只有在信息不足时短暂切换到 debug，复现一次后恢复。分享日志前应移除订阅地址、UUID、密码、令牌、服务器凭据和个人网络信息。

常见误判与最快处理路径

误判一：看到 timeout 就立即重装

重装只能重置客户端文件，无法修复订阅到期、服务器离线、运营商线路和系统时间错误。还可能丢失原有日志，使问题更难定位。应先导出必要配置，再完成基础分层检查。

误判二：延迟数字越小就一定能连接

延迟测试只反映特定测试请求。40 ms 的健康检查不保证目标网站一定可访问，也不保证规则把请求发到该节点。网页失败时进入连接日志，确认域名命中了哪条规则、进入哪个策略组、最终选择了哪个节点。

误判三：只切换策略组，不确认实际选择

规则模式下，请求先匹配规则，再进入指定策略组。手工切换了名为「节点选择」的组，但目标域名可能命中另一个「自动选择」组。日志中应能看到类似 DOMAIN-SUFFIX、MATCH 等规则结果。排查时可临时使用全局模式做交叉测试，但测试完成后应恢复原来的规则模式。

十分钟分诊清单

第 1 分钟：确认全部超时还是个别超时。
第 2 分钟：查看订阅到期时间、剩余流量和更新时间。
第 3 分钟：关闭代理与 TUN，验证直连网络。
第 4 分钟：切换手机热点做网络对照。
第 5 分钟：同步系统时间并重启内核。
第 6 分钟：核对 7890 等本地端口是否被占用。
第 7 分钟：查看日志中的第一条错误。
第 8 分钟：核对协议、TLS、SNI 和传输参数。
第 9 分钟：关闭 TUN，仅用系统代理复测。
第 10 分钟：选择不同地区节点做最终交叉测试。

这套顺序的核心是先查所有节点共享的环节，再查单个节点。全部超时优先处理订阅、网络、内核和端口；个别超时优先处理节点服务器、协议参数与线路。每一步保留测试结果，下一次出现同类故障时就能直接跳到对应层。