Clash 节点超时无法连接：按顺序排查的七个环节

节点列表延迟显示 timeout、连接时提示「无法连接到代理服务器」、浏览器一直转圈打不开网页，这三种情况在用户眼里都叫「节点超时」，成因却完全不同。多数人的第一反应是逐个切换节点，换了几十个依然是 timeout——因为问题根本不在节点上。

下面的七个环节按「从客户端内部到外部链路」的顺序排列，每一步都给出可以直接执行的验证动作和判断标准。建议按顺序走一遍，不要跳步：前一步的结论会决定后一步是否需要执行。

先分清四种超时，再动手排查

开始之前先做一次分类。同样是 timeout，落在哪个环节是可以提前缩小的范围。

现象	大概率原因	优先排查环节
所有节点延迟测试都 timeout	订阅失效、DNS 解析失败、本地端口冲突	环节一 → 二 → 三
只有个别节点 timeout	该节点已下线或临时不可用	环节一
延迟有数值，浏览器打不开网页	系统代理未生效、规则命中 REJECT	环节四 → 五
单个应用超时，其他应用正常	该应用不读系统代理、分流规则未覆盖	环节四 → 五

判断依据很简单：延迟测试走的是内核自己的探测通道，浏览器走的是系统代理或 TUN 网卡。前者失败，说明内核到节点这一段有问题；前者正常而后者失败，说明问题出在流量接管或规则分流上。

环节一：订阅更新与节点信息是否过期

订阅链接有有效期和流量上限。到期之后客户端通常不会弹错误提示，只是节点列表里的延迟全部变成 timeout。所以第一步永远是手动更新一次订阅，而不是切换节点。

具体操作顺序

打开客户端的「订阅」或「配置」页面，找到当前使用的配置，执行「更新」，不要只点「重新载入」——重新载入读的是本地旧文件，节点信息不会变。
更新完成后确认节点数量没有变成 0，列表里能看到具体的节点名称与延迟列。
打开生成的配置文件，检查 proxies 段里节点的 server 字段是否还是有效域名或 IP，服务商换节点域名后旧配置会整段失效。

用一条命令验证订阅链接

curl -sI -o /dev/null -w '%{http_code}\n' "你的订阅链接"

返回 200 说明地址可访问；403、404、410 说明订阅地址已失效或需要重新获取；返回 200 但配置内容为空，通常是流量耗尽。

订阅能取回不等于节点可用

部分服务商在流量耗尽后仍会返回一个只含基础字段的配置文件，客户端能正常加载、节点也能显示出来，但连接全部超时。这种情况下必须回到服务商后台确认剩余流量与到期时间。

环节二：DNS 解析与节点域名

节点域名解析失败是 timeout 的高频原因，而且很容易被误判成「节点挂了」。Clash 内核用自己的 dns 段解析节点域名，和系统 DNS 是两套独立配置，改系统 DNS 不一定影响内核。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:      # mihomo 专有：解析节点域名时使用
    - https://1.1.1.1/dns-query

proxy-server-nameserver 是 mihomo（Clash Meta）新增的字段，作用是把「解析节点域名」这个动作单独交给可信 DNS，避免国内 DNS 返回被污染的 IP，导致 TCP 握手阶段就超时。原版 Clash 内核没有这个字段，只能用 nameserver-policy 为节点域名逐条指定服务器。

验证方法

执行 nslookup 节点域名 与 nslookup 节点域名 1.1.1.1，两次结果差异过大说明存在 DNS 污染。
内核日志里出现 [DNS] resolve xxx failed，或反复重试同一个域名，可以直接确认是解析问题。
使用 fake-ip 模式时，连接列表里目标地址显示为 198.18.x.x 属于正常现象，不是故障。

环节三：端口占用与本地监听

内核默认监听 7890（mixed-port，HTTP 与 SOCKS 混合）、7892（redir-port）、7893（tproxy-port），控制接口默认在 127.0.0.1:9090。任何一个端口被占用，内核可能启动失败或只启动一部分，而部分客户端界面仍显示「运行中」。

检查端口占用的命令

Windows：netstat -ano | findstr :7890，拿到 PID 后到任务管理器确认是哪个进程。
macOS：lsof -i :7890
Linux：ss -lntp | grep 7890

两种处理方式

结束占用进程后重启内核。常见占用者是上一次没有完全退出的内核进程、其他代理软件、以及会监听本地端口的开发工具。
修改配置里的 mixed-port（例如改成 7897），同时把系统代理、浏览器扩展、命令行工具的代理端口一起改掉。

只改配置不改系统代理会出现组合故障

内核实际监听在 7897，系统代理仍指向 7890，表现就是「节点延迟测试正常、浏览器全部超时」。这类现象看起来像节点问题，实际是端口不一致。

环节四：系统代理与 TUN 是否真正接管流量

内核在运行，不等于流量被接管。系统代理和 TUN 是两种不同的接管方式，排查前先确认当前用的是哪一种。

系统代理的检查位置

Windows：「设置」→「网络和 Internet」→「代理」，确认「使用代理服务器」已开启，地址为 127.0.0.1，端口与配置里的 mixed-port 一致。
macOS：「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」，确认 HTTP 与 HTTPS 两项都已勾选并指向同一端口。
Linux：GNOME 在「设置」→「网络」→「网络代理」；终端里的命令行工具需要另外设置 http_proxy 环境变量。

TUN 模式的检查位置

TUN 需要管理员或 root 权限，多数客户端通过安装系统服务来实现（Clash Verge Rev 的「服务模式」、Clash for Windows 的 Service Mode）。开启后可以从路由表确认：

Linux / macOS：ip route 应能看到 TUN 网卡与 198.18.0.0/16 的路由条目。
Windows：route print 中应出现 TUN 适配器对应的路由。

一条命令判断整条链路是否通

curl -x http://127.0.0.1:7890 -o /dev/null -s -w '%{http_code} %{time_total}s\n' https://www.gstatic.com/generate_204

返回 204 且耗时在几百毫秒内：内核、节点、规则这条链路正常，问题在系统代理设置或具体应用。
返回 000 或长时间无响应：内核侧就没走通，回到环节一重新排查。

对比项	系统代理	TUN 模式
接管范围	读取系统代理设置的应用	全部 TCP / UDP 流量
权限要求	普通用户即可	管理员 / root 或安装系统服务
DNS 处理	多数情况仍走系统 DNS	由内核 `dns` 段统一处理
典型问题	应用不读系统代理、端口不一致	服务未安装、路由未写入

环节五：规则命中与分流结果

规则自上而下短路匹配，第一条命中的规则决定这条连接的走向。规则写错或规则集没更新，同样会表现为超时。

rules:
  - DOMAIN-SUFFIX,example.com,REJECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

三种常见写错方式

MATCH 写在中间：它匹配所有流量，写在它后面的规则永远不会执行。
IP-CIDR 漏写 no-resolve：每条连接都要先做一次 DNS 解析，解析慢或失败时整体表现为超时。
目标域名被 REJECT 或落到 DIRECT，而本地直连本身被当前网络拦截。

如何确认命中了哪条规则

打开 Dashboard 的「连接」页面，可以看到每条连接对应的「规则」与「代理链」两列；内核日志里也会打印类似 [TCP] 1.2.3.4:443 → match GEOIP,CN => DIRECT 的记录。如果某条连接命中的是 REJECT，浏览器侧的表现就是请求一直没有响应，而不是立刻报错。

环节六：内核日志与延迟测试方式

日志级别默认是 info，排查超时时先调到 debug，再复现一次问题，看日志停在哪一步。

log-level: debug
external-controller: 127.0.0.1:9090
unified-delay: true
tcp-concurrent: true

unified-delay: true：延迟按完整握手耗时计算，数值更接近实际体验，也更容易看出哪一类节点在超时。
tcp-concurrent: true：同一域名并发探测多个 IP，避免因为个别 IP 不可达而整体超时。
external-controller：Dashboard 的接入地址，配置后可以在浏览器打开本地面板查看实时日志与连接列表。

日志里四类关键行

日志片段	含义	回到哪个环节
`dial tcp 1.2.3.4:443: i/o timeout`	内核到节点的握手失败	环节一至三
`[DNS] resolve xxx failed`	节点域名解析失败	环节二
`match GEOIP,CN => DIRECT` 之后无响应	走了直连，但直连被网络拦截	环节五
`listen tcp 127.0.0.1:7890: bind: address already in use`	端口被其他进程占用	环节三

统一延迟测试地址

把测试地址固定为 https://www.gstatic.com/generate_204。不同客户端默认的测试地址不一样，统一之后各平台的延迟数值才有可比性，也方便跨设备对照。

环节七：网络环境与链路质量

前面六个环节都在本机，最后一个环节在链路。判断方法很直接：把同一份配置换到手机热点下测试一次。

公共 WiFi、校园网、公司网络常做出站端口封锁或 SNI 干扰。同一配置在热点下正常、在当前网络下全部超时，基本可以确认是网络侧限制。
系统时间偏差：VMess 等协议依赖时间戳，偏差超过 90 秒会直接握手失败，现象同样是 timeout。Linux / macOS 用 date -u 对比标准时间，Windows 用 w32tm /resync 重新同步。
IPv6 优先：节点域名同时存在 A 与 AAAA 记录，而本地 IPv6 不可达时，部分客户端会先尝试 IPv6 再回退，表现为首包超时。可以在配置里加 ipv6: false 验证。
MTU 与路由器：部分 PPPoE 环境需要把 TUN 的 MTU 从 9000 下调到 1500 或更低，否则大包被丢弃，表现为「网页能打开、视频和下载一直卡住」。

七个环节速查表

顺序	环节	确认方式	判断标准
1	订阅更新	`curl -sI "订阅链接"`	返回 200 且节点数不为 0
2	DNS 解析	`nslookup 节点域名 1.1.1.1`	与默认解析结果一致
3	端口占用	`netstat -ano \| findstr :7890`	没有其他进程占用该端口
4	系统代理 / TUN	`curl -x http://127.0.0.1:7890 …`	返回 204
5	规则命中	Dashboard「连接」页	命中的规则与代理符合预期
6	内核日志	`log-level: debug`	无 dial timeout 与 DNS 失败记录
7	网络环境	换手机热点复测	热点下恢复正常

排查过程中不要做的三件事

不要一边改配置一边测试。每次只改一项，保存后重启内核再复现，否则无法判断是哪一项起了作用。
不要用切换节点代替定位。所有节点都超时，说明问题在客户端或本地链路，换节点不会改变结果。
不要直接编辑订阅生成的配置文件。下次更新订阅会覆盖改动，自定义内容应写进客户端的扩展配置或 Merge 覆盖层。

按这七个环节走一遍，大部分超时问题都能落到一个具体位置：订阅、DNS、端口、接管方式、规则、日志或网络环境。先定位再修改，比逐个试节点快得多。