Clash 运行日志怎么看:常见报错含义与定位思路

客户端连不上的时候,反复拨动系统代理开关、闭着眼睛挨个点节点,是最常见的第一反应。其实内核日志里已经把失败原因写得相当具体,只是格式紧凑、英文报错居多,很多人扫一眼就关掉了。本文按报错关键词把常见日志条目分成五类,逐条说明它发生在哪个环节、通常是什么原因、下一步该查什么。

先读懂一行日志的结构

Clash 内核(包括 Clash Meta / mihomo)的连接日志格式基本固定。以一条典型的 TCP 记录为例:

[TCP] 127.0.0.1:52310 --> www.google.com:443 match DomainSuffix(google.com) using 节点选择[香港 01]

拆开看是五个字段:

• [TCP] / [UDP]:这条连接走的传输协议。网页浏览绝大多数是 TCP;QUIC、部分游戏与语音通话会走 UDP。
• 127.0.0.1:52310:本机哪个来源发起的连接。系统代理模式下通常是 127.0.0.1;TUN 模式下能看到更具体的内网来源地址。
• --> www.google.com:443:目标地址与端口。这里如果显示的是 IP 而不是域名,说明程序直接用 IP 发起连接,规则里的域名匹配对它是无效的。
• match DomainSuffix(google.com):命中的规则。显示 match Match() 说明一路漏到了最后一条兜底规则,前面的规则集全没匹配上。
• using 节点选择[香港 01]:实际出口。显示 DIRECT 表示这条流量没走代理——目标本该走代理却显示 DIRECT,问题出在规则而不在节点。

日志详细程度由配置里的 log-level 控制,可选 silent、error、warning、info、debug,多数客户端默认 info。排查问题时先调到 debug,能看到 DNS 查询、规则匹配细节与握手过程:

log-level: debug

图形客户端(Clash Verge Rev、Clash for Windows 等)都带日志页面,可以直接切换级别;纯内核部署时日志走标准输出,配置 external-controller 后也能通过控制器的 /logs 接口实时拉取。

节点连接阶段的报错

日志里出现 dial 字样,说明 Clash 正在向节点服务器发起连接,问题发生在本机到节点之间的链路上。

[TCP] dial 香港 01 --> www.google.com:443 error: dial tcp 198.51.100.7:443: connect: connection refused

• connect: connection refused:服务器拒绝了连接,节点端口上没有服务在监听。常见于节点已下线、端口被改动、订阅信息过期。先换同订阅里的其他节点,全部失败就更新一次订阅。
• i/o timeout / context deadline exceeded:连接超时,请求发出去没有任何回应。相比 refused,这更像链路被阻断或服务器宕机。把本机从 Wi-Fi 切到手机热点再测,能快速区分是本地运营商的问题还是节点的问题。
• connection reset by peer:连接建立之后被对方中途切断。偶发一次可以忽略;持续出现说明节点负载过高,或传输过程受到了干扰。

这一阶段与本地代理设置无关——只要日志里已经出现 dial 节点的记录,说明流量已经成功进入 Clash,不必再回头折腾系统代理开关。

TLS 与协议握手阶段的报错

连上了服务器但握手失败,报错关键词会变成 tls、x509、EOF 一类。

• x509: certificate has expired or is not yet valid:证书时间校验失败。先查本机系统时间是否准确,时间偏差过大时几乎所有 TLS 类协议都会失败;系统时间正常,再去怀疑节点证书配置。
• tls: first record does not look like a TLS handshake:对端端口上跑的不是 TLS 服务。通常是订阅里的端口或协议类型填错,比如把 Trojan 节点指到了非 TLS 端口上。
• EOF / tls: handshake failure:握手进行到一半连接被掐断。SNI、ALPN 与服务器不匹配时常见,检查节点配置里的 servername / sni 字段是否被改动。
• Shadowsocks 报 cipher: message authentication failed:AEAD 校验失败,密码或加密方式与服务器不一致,回订阅来源核对这两项。
• VMess 节点配置看着没错却认证失败:核对系统时间。VMess 按时间戳做校验,本机时间与服务器偏差超过允许窗口就会被拒绝。
• WebSocket 类节点报 websocket: bad handshake:路径(path)或 Host 与服务器不符,CDN 回源配置变更之后尤其常见。

握手阶段的报错基本与本地网络质量无关,集中在两件事上:节点参数是否被改、订阅信息是否过期。

配置与订阅加载阶段的报错

这类报错出现在启动内核或更新订阅时,日志里带 yaml、unmarshal、proxy provider 等词。

• yaml: line X: ... / unmarshal errors:配置文件第 X 行附近语法错误。YAML 不允许用 Tab 缩进,冒号后面必须有空格,含特殊字符的值要加引号。按行号回去检查即可。
• proxy [xxx] not found:策略组引用了不存在的节点。改名或删节点之后忘了同步修改策略组,把引用名对齐就能解决。
• rules[X] ... error:第 X 条规则解析失败。常见原因是规则类型写错,或参数数量不对,比如漏写了最后的去向策略。
• proxy provider ... error、更新订阅返回 404 或超时:订阅链接失效,或者订阅地址本身在当前网络下不可达。客户端一般带"通过代理更新订阅"的开关,订阅地址需要代理才能访问时,打开它再更新。

配置加载失败时内核往往直接退出或拒绝启动,所以这类报错其实是最好定位的:报错信息里行号、字段名都给得很具体,照着改就行。

DNS、端口占用与 TUN 的报错

• dns resolve failed、DNS 查询超时:Clash 内置 DNS 没配好,或上游服务器不可达。确认配置里 dns.enable: true,nameserver 列表里有可达的上游;开 fake-ip 模式出现异常时,先切回 redir-host 验证是不是 fake-ip 缓存的问题。

dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

• bind: address already in use、监听 7890 失败:混合端口被占用。多数情况是有另一个内核进程或同类软件还在运行,结束旧进程即可;也可以改 mixed-port 换端口,但系统代理设置里的端口要同步改。
• TUN 模式启动失败(permission denied、找不到 utun / wintun 设备):TUN 需要管理员权限,Windows 还依赖 wintun 驱动。用管理员身份运行客户端;仍然报错时,把 tun.stack 在 system 与 gVisor 之间切换试试,个别协议栈与特定系统版本不兼容。
• 系统代理设置失败:macOS 需要授权才能修改网络设置;Windows 下检查是否有安全软件拦截了代理开关的写入。

一套固定的排查顺序

1. 把日志级别调到 debug,完整复现一次故障,让报错新鲜地出现在日志末尾。
2. 从下往上找第一条 error 或 warning,不要盯着最后一条——后面刷屏的内容往往只是第一条错误的连锁反应。
3. 按关键词把第一条报错归类到五个环节之一:配置加载、订阅更新、DNS 解析、节点连接、协议握手,再对照前面几节处理。
4. 交叉验证。绕过系统代理,直接走 Clash 端口测一次:

curl -x http://127.0.0.1:7890 https://www.google.com -I

1. 能通,说明内核与节点正常,问题在系统代理或浏览器;不通,问题在内核到节点之间。每次只改一处再测,一次改三处就永远不知道是哪一处起的作用。

报错关键词速查表

日志是 Clash 给出的第一手证词。先读日志、再动手改,排查顺序固定下来之后,大多数连接问题都能在几分钟内定位到具体环节。