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

日志级别与阅读顺序

基于 mihomo 内核的客户端在启动与运行期间会持续输出日志,日志级别通常分为 silent、error、warning、info、debug 五档,由配置文件中的 log-level 字段控制。级别之间是包含关系:选择 info 会同时输出 info、warning、error 三类内容,选择 debug 则包含全部信息,数据量最大也最详细。

排查问题时不建议一开始就翻 debug 日志,信息密度过高反而拖慢定位速度。合理的顺序是:先看启动阶段是否有 error 级别的红色报错,确认内核能否正常拉起;再看连接请求时的 warning,判断是网络层问题还是规则层问题;最后如果前两步都看不出线索,才切到 debug 级别复现一次具体请求,逐行核对域名解析、节点选择与规则命中的顺序是否符合预期。

常见报错逐条解读

以下几类报错在日志中出现频率最高,理解它们的触发条件比死记文案更有用。

DNS 解析失败

日志中出现类似"resolve host failed"或"dns resolve error"的内容,通常意味着配置里的 nameserver 无法正常响应,或者目标域名本身不在解析范围内。这类问题常见于三种场景:自定义 DNS 服务器不可达、DNS over HTTPS 地址写错、以及规则里对某个域名设置了 no-resolve 却仍需要出网解析。核对方式是先用系统自带的网络工具单独测试 nameserver 列表中的地址是否可用,再确认规则集里涉及的域名匹配类型是否正确。

握手超时

"handshake timeout"或"dial tcp timeout"类报错,指的是客户端与代理节点之间的连接建立阶段超时,还没进入真正的数据传输。常见原因包括节点服务端已下线、订阅链接里的端口信息过期、本地网络对特定端口有限制,以及节点所在地区的网络链路本身不稳定。遇到这类报错先切换到订阅内的其他节点测试,如果多个节点都超时,问题大概率出在本机网络环境而不是订阅本身。

规则未命中与兜底策略

日志里如果频繁出现某个域名最终落到 MATCH 或 FINAL 规则对应的策略组,说明前面所有规则都没有命中,这不一定是错误,但如果这个域名本应走某条特定规则,就说明规则顺序或匹配类型写错了。mihomo 的规则匹配是自上而下的顺序匹配,一旦某条规则命中就不再继续往下比对,所以范围更宽的规则应当放在范围更窄的规则之后,否则窄规则永远没有机会生效。

连接被拒绝与端口占用

"connection refused"多半是目标端口没有服务在监听,或者本地代理端口与其他程序冲突。启动阶段如果日志提示端口已被占用,先检查是否有多个客户端实例同时运行,或者系统里其他工具占用了同一个混合端口。

从日志反推配置问题的定位路径

日志报错本身只是现象,真正需要做的是把现象和配置文件里的具体字段对应起来。一条可行的排查路径是:

1. 确认报错发生的阶段——是内核启动时就报错,还是发起某次连接请求时才报错,两者对应的排查范围完全不同。
2. 记录报错涉及的域名或 IP,回到配置文件里搜索这个域名可能匹配到的规则条目,核对匹配类型是否符合预期。
3. 如果怀疑是节点问题,单独在策略组里切换到唯一一个节点做测试,排除策略组内多节点轮询带来的干扰。
4. 如果日志显示的是 DNS 层报错,单独验证 dns 配置块中的 nameserver、fallback 字段,必要时临时换成公共 DNS 地址做对比测试。
5. 问题定位后,每次只改一处配置再重启验证,避免同时改多处导致无法判断到底是哪个改动解决了问题。

提升日志可读性的配置建议

日常使用建议将 log-level 保持在 info,这个级别既能看到关键的连接状态,又不会被大量调试细节淹没。如果客户端支持在界面内直接查看运行日志,优先使用界面内的实时日志面板,它通常会按时间顺序滚动显示,比手动打开日志文件更直观。遇到间歇性问题时,可以先固定复现步骤,记录复现前后的时间戳,再回头在日志里按时间段筛选,能大幅缩短翻找范围。

另外,规则集与订阅内容更新后,建议重新观察一轮日志,确认新规则是否按预期顺序生效,而不是等到实际使用中偶然发现分流结果不对再回头排查。把日志检查作为配置变更后的固定一步,能提前发现大部分因为规则顺序或字段拼写导致的问题。