看懂 Clash 运行日志：常见报错信息的含义与问题定位思路

日志为什么是排障的第一手材料

遇到「打不开网页」「订阅用不了」「某个应用连不上」这类问题时，很多人第一反应是换节点、重启客户端，试几次不行就放弃。其实这类问题的答案，往往已经写在日志里了。Clash 内核（无论是原版 Clash 还是现在更常用的 Clash Meta / mihomo 内核）在处理每一条连接时都会记录一行日志：这条流量从哪来、走了哪条规则、最终试图连向哪里、连接是成功还是失败、失败的具体原因是什么。

换句话说，日志把「网络不通」这个笼统的现象拆成了具体的环节：是本地没发出请求，是 DNS 解析没成功，还是握手时被目标或节点拒绝了。学会读日志之后，排障就从「盲试」变成了「按线索定位」，效率会明显提升。

日志级别与打开方式

Clash 的日志分为几个级别，级别从低到高大致是 debug、info、warning、error、silent。级别越低，记录的内容越详细：

• debug：几乎所有内部动作都会记录，包括每一次 DNS 查询、每一次连接尝试，排查疑难问题时最有用，但输出量很大。
• info：日常使用推荐的级别，会记录连接建立、规则匹配、连接关闭等关键节点，不至于刷屏。
• warning / error：只记录出现异常的连接，日常安静，排障时信息量偏少。

大多数图形化客户端把日志面板放在主界面的侧边栏或底部标签，标题通常写作「日志」或「Logs」，界面上一般能直接切换级别。排查具体问题时，建议临时切到 debug 级别，复现一次问题后再切回 info，避免长期产生过多日志文件。

常见日志条目逐条对照

日志的格式因内核版本略有差异，但核心信息大同小异：时间、级别、协议类型、来源地址、目标地址、匹配到的规则与策略、以及成败结果。下面按报错类型逐一说明。

连接类报错：connection refused / timeout

[TCP] 192.168.1.5:51234 --> example.com:443 match RuleSet(proxy) using 节点A
dial tcp 203.0.113.10:443: connect: connection refused

connection refused 表示三次握手请求被目标端明确拒绝了，通常意味着对端端口没有监听服务、节点服务端已下线，或者是节点本身出现故障。i/o timeout（超时）则不同，它表示请求发出去后既没有被拒绝也没有回应，常见于线路拥塞、目标服务器无响应，或者节点所在网络被限速甚至封锁。二者的区别很关键：被拒绝通常该换节点，超时则要先怀疑线路质量。

DNS 解析报错：no such host

dial tcp: lookup example.com: no such host

这行日志出现在建立连接之前，说明域名解析这一步就没有成功，根本没走到连接节点那一步。常见原因是 DNS 服务器不可用、配置文件里的 nameserver 写错、或者启用了某些需要特定 DNS 模式配合的分流规则却没配套开启 fake-ip 或 enhanced-mode。如果绝大多数域名都报这个错，先检查 DNS 配置本身；如果只是个别域名报错，更可能是该域名在部分 DNS 服务器上确实解析异常。

规则匹配记录：确认流量走向

[TCP] 10.0.0.8:60021 --> api.example.com:443 match DomainSuffix(example.com) using DIRECT

这类日志不是报错，而是「流量走向说明书」。match 后面写的是命中的具体规则，using 后面写的是最终使用的策略（DIRECT 直连、某个节点或策略组）。如果访问明明该走代理的网站却发现日志里 using DIRECT，说明规则没有生效或者顺序排在了直连规则后面；反过来，如果本该直连的国内地址走了代理，也能在这里第一时间发现。规则命中记录是判断「配置是否按预期工作」最直接的证据。

TLS 与握手类报错

remote error: tls: handshake failure
EOF

握手失败或连接中途收到 EOF（对端主动关闭连接），常见于节点的传输协议配置和服务端不一致（比如 TLS 参数、SNI 伪装域名对不上），或者节点服务端本身在做流量清洗时误判了连接。这类问题通常不是本地配置问题，建议先在订阅或节点列表里换一个节点验证，如果多个节点都出现同类报错，再回头检查本地配置文件里对应协议字段的写法。

按时间线定位问题：从发起请求到数据返回

拿到一段日志后，建议按下面的时间顺序去看，而不是一眼扫过去找红色字样：

1. 请求是否被本地捕获。确认日志里出现了这条连接的记录，如果完全没有记录，问题可能出在系统代理没生效或 TUN 模式没有正确接管流量，而不是节点问题。
2. DNS 解析是否成功。看是否出现 no such host 一类记录，解析失败的话，后面的连接环节根本不会发生。
3. 规则匹配是否符合预期。确认 match 和 using 字段指向的策略是不是你想要的，走错策略组比走错节点更容易被忽略。
4. 连接是否建立成功。看是否出现 connection refused、timeout 或 TLS 相关报错，这一步的报错基本能对应到「换节点」还是「查线路」。
5. 连接建立后是否正常关闭。正常访问结束后应该有连接关闭的记录，如果连接长时间挂起没有关闭记录，可能是目标服务响应慢，而不是网络层面的问题。

把这五步在脑子里过一遍，基本能把「连不上」这个模糊的说法，精确到某一个具体环节。

常见场景与对照速查表

排查时的几个建议

把日志当作证据链去看，而不是当作「哪里标红了就是哪里坏了」的信号灯。多个节点同时出现同一类报错，通常指向本地配置或 DNS；只有个别节点出问题，通常是节点本身的状态。养成先看日志再动手改配置的习惯，能省掉大量来回试错的时间。

如果日志里的报错反复出现同一种类型，且已经排除了本地配置和网络环境的问题，也可以对照官方的快速上手说明重新走一遍基础设置，确认订阅、DNS 模式与规则配置都处在推荐的默认状态。