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

为什么日志是排查问题的第一手材料

Clash 系客户端(包括原版内核与 mihomo 内核)在运行时会持续输出结构化文本日志,记录连接建立、规则匹配、DNS 查询、代理选择等每一步的执行结果。相比"能不能上网"这种模糊的现象描述,日志给出的是具体到某一条连接、某一次查询的失败原因,这也是官方文档和社区排障流程里反复强调"先看日志"的原因。

大多数客户端(Clash Verge、Clash for Windows 系衍生版、mihomo party 等)在主界面都提供"日志"或"Logs"标签页,部分还支持按级别筛选和按关键字搜索。命令行运行内核时,日志会直接输出到终端标准输出,也可以通过配置文件里的 log-level 字段控制输出到指定文件。无论用哪种客户端,理解日志格式和常见报错类型,都能把排查时间从"反复重启试运气"压缩到"定位具体环节"。

日志级别怎么设置,该看哪一级

Clash 配置文件中的 log-level 字段决定了输出的详细程度,常见取值从粗到细依次为:

• silent:不输出任何日志,仅用于生产环境完全静默运行,排查问题时不要用这一级。
• error:只记录连接失败、配置解析错误等严重问题,信息量最少,容易漏掉中间过程。
• warning:在 error 基础上增加潜在异常提示,例如规则集加载耗时过长、证书即将过期等。
• info:默认推荐级别,记录代理选择结果、DNS 查询摘要、连接建立与关闭,信息密度适中,日常排障够用。
• debug:输出最完整的执行细节,包括每条规则的匹配尝试过程、协议握手的具体字节交互摘要,排查疑难问题时临时开启,日常不建议长期使用(日志量大、可能影响性能)。

配置方式是在 YAML 配置文件里设置:

log-level: info

高频报错逐条解析

DNS 解析失败类

这类日志通常包含 dns resolve failed、no such host 或类似字样,表示客户端尝试将域名解析为 IP 地址时未成功。常见成因包括:

• 配置文件中 DNS 服务器地址填写错误或该服务器已失效;
• 启用了 fake-ip 模式但目标域名被错误地划入了直连(direct)分组,导致真实 DNS 请求未经过代理通道;
• 使用 DoH/DoT 加密 DNS 时,上游加密 DNS 服务器本身需要经过代理才能访问,形成"先有鸡还是先有蛋"的死锁;
• 域名本身不存在或已过期,这种情况属于域名问题而非客户端问题。

定位思路:先确认配置里的 nameserver 字段是否为有效地址,再检查该域名对应的规则分组是否命中了预期节点。如果是加密 DNS 死锁问题,可以给 DNS 服务器地址单独配置直连或指定一个稳定可用的落地节点。

握手超时类

日志中出现 handshake timeout、dial tcp: i/o timeout 或 context deadline exceeded,表示客户端已经尝试与代理节点建立连接,但在规定时间内未完成 TLS 握手或 TCP 连接建立。这类报错的成因分三个层面:

• 节点侧:服务器已下线、端口被临时封锁,或服务器所在地区网络质量差;
• 协议参数侧:客户端与服务器的加密方式、传输协议(如 WebSocket 路径、gRPC 服务名)配置不一致,握手请求格式不被对端接受;
• 本地网络侧:本地出口网络本身对目标端口做了限速或干扰,尤其常见于某些运营商对特定端口的 QoS 策略。

定位思路:先用同一订阅下的其他节点测试,如果全部节点都超时,问题大概率在本地网络;如果只有个别节点超时,优先怀疑该节点本身状态或协议参数填写有误。

规则未命中类

日志里出现 match RuleSet(...) 或 final rule 但代理走向与预期不符,并非报错,而是规则匹配逻辑生效但结果不是用户预想的分组。常见原因:

• 规则文件按从上到下顺序匹配,前面某条更宽泛的规则先命中,导致后面精确的规则未被执行到;
• 规则集(rule-provider)未及时更新,仍在使用旧版本的域名/IP 列表;
• 最终兜底规则(MATCH)指向了非预期的分组,所有未命中前面规则的流量都会落到这里。

定位思路:开启 debug 级别日志后,针对具体域名发起一次连接,在日志中搜索该域名,查看它实际匹配到了哪一条规则、落到了哪个代理分组,再对照规则文件逐条核对顺序。

连接被拒绝与协议错误类

connection refused 表示目标端口没有服务在监听,通常是服务器配置的端口与客户端填写的端口不一致,或服务端服务未启动。invalid header、unexpected EOF 一类的协议层报错,多数指向客户端与服务器两端的加密方式、混淆参数(如 obfs 类型)不匹配,需要逐项核对订阅中的协议字段。

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

拿到一条报错日志后,建议按下面的顺序缩小排查范围,而不是逐个尝试所有可能原因:

1. 第一步,区分报错发生的阶段。是在 DNS 解析阶段、还是握手连接阶段、还是规则匹配阶段?日志里的关键字(resolve / dial / handshake / rule)通常已经标明了阶段,先按阶段分类能排除大半无关方向。
2. 第二步,判断是否为单一节点问题。切换到同订阅下的另一个节点重试,如果问题消失,说明是该节点的服务端状态或参数问题;如果依旧存在,继续第三步。
3. 第三步,判断是否为本地网络问题。临时关闭代理直接访问目标站点,或用手机热点等不同网络环境测试,排除本地运营商、路由器策略造成的干扰。
4. 第四步,核对配置文件本身。检查 DNS 设置、规则顺序、rule-provider 更新时间,以及订阅是否为最新版本,很多"看似节点问题"最终定位为配置文件过期或字段拼写错误。
5. 第五步,升级日志级别复现问题。如果前四步都没定位到,把 log-level 临时调整为 debug,完整复现一次故障,保存相关日志片段用于进一步分析或提交社区求助。

日常查看日志的几个实用习惯

• 连接出问题时先看时间戳,定位到故障发生的具体时刻,再回溯前后几秒的日志上下文,避免在长日志里漫无目的地翻找。
• 善用客户端日志页的关键字过滤功能,直接搜索出问题的域名或 IP,能快速定位相关的所有日志行。
• 规则改动后,建议开一次 debug 级别验证新规则确实按预期生效,再切回 info 级别长期运行。
• TUN 模式下的问题往往同时涉及系统网络栈和内核日志两部分,遇到 TUN 模式连不上的情况,除了看 Clash 自身日志,也要留意客户端是否有单独的 TUN 状态提示。
• 保留最近一次正常工作时的配置文件备份,遇到升级后突然报错增多的情况,可以直接对比配置差异定位改动点。