Clash 运行日志怎么看:常见报错含义与问题定位方法

为什么先看日志,而不是先换节点

遇到网页打不开、连接卡顿这类问题时,很多人第一反应是切换订阅或换一个节点,试几次不行就怀疑客户端本身有问题。这条路径效率很低,因为代理链路涉及本地配置、节点可用性、跨境线路质量、目标网站响应等多个环节,盲目更换节点只能排除其中一小部分可能性。更快的办法是打开日志页,看客户端在处理这次连接请求时到底记录了什么——报错信息通常会直接指出问题出在哪一层。

Clash 系客户端的日志本质上是内核(Clash Meta / mihomo)运行过程的实时输出,客户端界面只是把这些文本渲染出来并做了着色和过滤。理解日志结构和常见字段的含义,是排查连接问题最基础也最有效的技能。

日志级别与字段结构

打开客户端的日志页(通常在侧边栏标注为 Logs 或"日志"),会看到类似下面这样的一行记录:

[Info] [TCP] 192.168.1.5:51234 --> example.com:443 match Rule(DOMAIN-SUFFIX,example.com) using Proxy-HK

这行记录包含四个关键部分:

• 日志级别:方括号里的 Info、Warning、Error 等,表示记录的严重程度。
• 协议与连接方向:TCP 或 UDP,以及本机端口指向目标域名/端口。
• 匹配到的规则:说明这条连接命中了配置文件里哪一条分流规则。
• 使用的代理节点:实际转发这条连接的节点或策略组名称。

日志级别通常分为四档,客户端设置里一般可以调整显示的最低级别:

1. Debug:最详细,包含规则匹配的完整过程,平时不需要开启,排查疑难问题时才打开。
2. Info:默认级别,记录正常的连接建立、规则匹配、节点切换等信息。
3. Warning:非致命异常,比如某次 DNS 查询走了备用解析器、某个节点探测超时但还有备选。
4. Error:连接失败、配置加载出错等需要关注的问题,通常伴随具体报错文本。

排查问题时,建议先把级别调到 Info 或 Debug,复现一次问题操作(比如打开某个打不开的网页),再回头看日志里 Error 和 Warning 级别的记录,精确对应到出问题的那次请求。

connection refused 类报错

这是最常见的报错之一,完整信息通常类似:

[Error] [TCP] dial tcp 203.0.113.10:443: connect: connection refused

它的含义是:本地已经把连接请求发送出去,但对端(可能是节点服务器,也可能是目标网站)主动拒绝了这次 TCP 连接,常见原因分三类:

• 节点服务器不可用:节点已下线、端口被服务商临时关闭,或者节点本身配置有误(端口号、加密方式与服务端不一致)。这种情况下换一个同订阅里的其他节点通常能立刻验证。
• 本地防火墙或安全软件拦截:部分安全软件会拦截客户端建立的出站连接,尤其是在开启 TUN 模式后更容易触发。可以临时关闭安全软件的实时防护做对比测试。
• 目标网站拒绝了当前节点的 IP:少数网站会针对特定 IP 段做访问限制,这种情况即便节点本身正常,访问该网站也会持续报错,换节点是唯一的处理办法。

区分这三种情况的简单方法是:同一个节点访问多个不同网站,如果全部报 connection refused,大概率是节点或本地环境问题;如果只有个别网站报错,而其他网站正常,则更可能是目标网站对该节点 IP 的限制。

DNS 超时与解析失败

DNS 相关的报错通常带有明确的关键词,例如:

[Warning] [DNS] resolve example.com failed: context deadline exceeded
[Error] [DNS] all DNS servers failed to resolve example.com

第一条表示某一次域名解析请求超时(超过了配置里设定的超时时间),如果只是偶发,通常不影响使用,内核会自动重试或切换到下一个 DNS 服务器。第二条则表示配置文件里列出的所有 DNS 服务器都解析失败,这时网页会直接打不开。

DNS 解析失败常见的排查方向:

1. 检查配置文件里的 DNS 段落:确认 nameserver 列表里的地址本身是可用的,如果用了国外 DNS(如 8.8.8.8、1.1.1.1),要确认这些地址的查询请求本身也是走代理转发的,否则在网络环境不允许直连的情况下同样会超时。
2. 确认是否开启了 Fake-IP 模式:Fake-IP 会给域名分配一个虚拟 IP,交由内核在建立连接时再做真实解析,如果这一层配置有误(比如 fake-ip-range 与本地网段冲突),会表现为域名能被"解析"但实际连接不上。
3. 排查本地 Hosts 文件或其他代理软件干扰:如果本机同时运行了其他网络工具,或者 Hosts 文件里有旧的域名映射记录,也会导致 DNS 层出现异常结果。

订阅解析失败

更新订阅时如果出现下面这类报错,说明问题发生在拉取或解析配置文件这一步,和代理节点本身没有关系:

[Error] update subscription failed: Get "https://sub.example.com/link": context deadline exceeded
[Error] parse config failed: yaml: line 42: did not find expected key

第一条是网络层面的失败:客户端没能在超时时间内从订阅服务商的服务器拿到内容,常见原因包括本地此时没有可用的代理去访问订阅链接、订阅服务商的服务器临时不可达,或者订阅链接本身已经失效。第二条是内容层面的失败:订阅内容成功下载,但 YAML 格式解析出错,通常是订阅服务商临时返回了错误页面(比如维护公告的 HTML),而不是正常的配置内容。

处理订阅解析失败,可以按下面的顺序排查:

• 先确认订阅链接是否能在浏览器里正常打开并看到文本内容,如果打开的是错误页面或空白页,说明问题在服务商一侧,需要联系订阅提供方或等待恢复。
• 检查更新订阅时使用的网络环境:部分客户端在更新订阅时会走"直连"而不是当前激活的代理,如果直连环境无法访问订阅域名,更新自然会超时。
• 确认订阅链接里是否包含特殊字符或者被截断,复制粘贴时多一个空格或少一个字符都会导致链接失效。

策略组测速与节点切换类日志

如果配置文件里使用了自动测速的策略组(比如 url-test 或 fallback 类型),日志里会持续出现类似记录:

[Info] Proxy-HK check health: 156ms
[Warning] Proxy-SG check health failed: dial tcp: i/o timeout

这类日志属于内核的健康检查机制,每隔一段时间会对策略组内的节点发起一次测速请求,记录延迟或标记为不可用。看到某个节点持续 check health failed,说明该节点当前确实存在问题,策略组会自动跳过它选择延迟较低的备选节点,这也是为什么有时候明明配置没变,访问速度却时快时慢——背后是策略组在节点间动态切换。

如果整组节点都测速失败,通常指向两种情况:一是订阅本身质量不佳,节点大批量不可用;二是本机网络环境异常,导致所有出站连接都无法建立,这时候需要先排除本地网络问题,而不是急着更换订阅。

TUN 模式相关报错

开启 TUN 模式(系统级代理,接管全局流量)后,如果启动失败,日志里通常会给出比较直接的提示:

[Error] start TUN device failed: operation not permitted
[Error] start TUN device failed: address already in use

第一条基本可以确定是权限问题:TUN 模式需要创建虚拟网卡,这个操作要求客户端以管理员权限运行,如果之前是以普通权限启动的,重新以管理员身份打开客户端通常就能解决。第二条表示虚拟网卡使用的地址段和本机现有网络配置冲突,常见于同时运行了其他基于虚拟网卡的工具(如某些 VPN 客户端),需要先关闭冲突的软件,或者在配置里调整 TUN 使用的地址段。

按报错类型定位问题的实用路径

把上面几类报错串起来,可以整理出一条相对通用的排查顺序:

1. 先确认问题发生的层次:是完全连不上网(可能是 TUN 或系统代理设置问题),还是特定网站打不开(更可能是节点或规则问题),还是所有网站都慢(更可能是节点质量或跨境线路问题)。
2. 打开日志页,复现一次操作:把日志级别调整到 Info,重新触发一次失败的访问,记下当次产生的报错文本。
3. 按关键词分类:dial tcp/connection refused 指向节点或目标站点连接问题;DNS 相关指向域名解析层;update subscription/parse config 指向订阅拉取与格式问题;TUN 相关指向系统级代理权限或网络设备冲突。
4. 逐层排除:先排除本地环境(权限、防火墙、其他代理软件冲突),再排除订阅与节点本身,最后才考虑是目标网站的个别限制。

坚持这个顺序,大多数报错都能在几分钟内定位到大致方向,不需要反复试错式地更换配置或节点。

小结

日志不是给开发者看的黑箱输出,而是客户端主动告诉你"这次连接卡在哪一步"的说明文字。花几分钟熟悉常见报错的关键词和对应含义,遇到问题时先看日志再动手调整设置,通常比反复重启客户端或盲目更换节点更节省时间,也更容易找到真正的问题根源。