看懂 Clash 运行日志:info/warning/error 级别与常见报错含义速查

日志级别是什么,先设对再看

Clash 内核(无论是原版 Clash 还是 Mihomo,即 Clash Meta)都用统一的日志级别体系,从详细到简略依次是 debug、info、warning、error、silent。配置文件里对应字段是 log-level,大多数客户端在设置界面也有同名开关。日常排查建议先切到 info 观察连接是否正常建立,再遇到具体问题时临时切到 debug 看更细的握手过程,处理完记得切回去,debug 级别日志量很大,长期开着会占用磁盘和影响阅读效率。

log-level: info
# 排查连接问题时临时改为
log-level: debug

四个级别的含义不是随意划分的,理解清楚能帮你快速判断一条日志是否值得关注:

debug:最细粒度,包含 DNS 解析细节、握手过程、连接池状态等,正常运行时噪音很大。
info:记录每条连接的规则匹配结果、使用的节点、目标地址,日常观察用这个级别最合适。
warning:表示出现了异常但内核仍在尝试自行处理,比如某个节点健康检查失败但还有其他节点可用。
error:明确的失败结果,连接没有建立成功,通常需要人工介入。

客户端图形界面里的日志面板一般会用颜色区分级别,warning 常显示为黄色、error 显示为红色,这与设计系统里语义色的用法是一致的思路:颜色只是提示优先级,具体原因还得看文字内容。

连接类报错逐条解读

这一类日志出现在内核尝试与目标服务器或代理节点建立 TCP/UDP 连接的阶段,是排查"能不能连上"问题时最先要看的内容。

dial tcp timeout

表示内核发起连接后,在超时时间内没有收到任何响应。常见原因有三种:目标服务器本身响应慢或已下线;所选代理节点到目标服务器的链路存在丢包;本机到代理服务器之间的网络本身就不通(比如节点服务器已过期或被封锁)。排查顺序建议是先换一个代理组内的其他节点测试同一个目标地址,如果换节点后立刻恢复,说明问题出在那个节点,不是本机配置;如果换哪个节点都超时,再检查本机到代理服务器出口的基础连通性。

connection refused

这条和 timeout 不同,它表示对方明确拒绝了连接请求,说明网络链路是通的,只是目标端口没有服务在监听,或者被防火墙主动拒绝(而不是丢弃)。如果日志里这条报错指向的是 127.0.0.1 加某个本机端口,通常是内核自身没有正常启动监听,或者混合端口配置被改动后客户端界面没有同步刷新,值得检查一下 mixed-port 的设置值和进程是否真的在监听该端口。

no route to host

这是网络层面的报错,系统路由表里没有到达目标 IP 的路径。开启 TUN 模式后如果路由表被写坏或者与系统原有路由冲突,很容易出现这条日志,重启一次 TUN 服务或者检查是否有其他网络工具同时接管了默认路由通常能解决。

i/o timeout 与 EOF

i/o timeout 多出现在已经建立连接之后的读写阶段,说明连接建立成功但数据传输中断,常见于节点带宽不足或长连接被中间设备强制断开。EOF 则表示对端主动关闭了连接,如果只是偶尔出现一两次通常不用管,如果频繁出现在同一个节点上,可以考虑把该节点从代理组里临时剔除。

规则匹配日志怎么读

info 级别下,每一条新连接都会打印一行规则匹配结果,格式大致是"匹配到的规则类型加使用的策略"。这类日志不是报错,但是排查"为什么这个网站没走代理"或者"为什么速度不对"的关键线索。

[TCP] example.org:443 match DomainSuffix(example.org) using PROXY
[TCP] cn.example.com:443 match GEOIP(CN) using DIRECT
[TCP] 10.0.0.5:8080 match Match() using REJECT

第一行说明这条连接命中了域名后缀规则,走的是 PROXY 策略组;第二行说明目标 IP 被识别为中国大陆地址,按 GEOIP 规则直连;第三行说明没有命中任何具体规则,落到了兜底的 MATCH 规则上,而这条兜底规则的策略是 REJECT,也就是直接拒绝。如果发现大量本应正常访问的连接都落到了兜底规则并被拒绝,通常是规则列表顺序有问题,或者兜底规则本该写 DIRECT 却误写成了 REJECT,回头检查配置文件里 rules 的最后一行最容易发现问题。

注意

规则是按从上到下顺序匹配的,一旦命中就不再往下看。如果一条本该走代理的域名却被前面某条更宽泛的规则提前拦截为直连,日志里的 match 信息会直接告诉你是哪条规则起了作用,不需要靠猜测。

节点与代理组相关的警告

除了单条连接的报错,Clash 还会周期性输出代理组健康检查的结果,这类日志级别通常是 warning,不代表连接彻底失败,但值得留意。

health check failed / url-test 超时:代理组配置了自动测速(url-test 或 fallback 类型),某个节点没能在设定时间内完成到测试地址的请求,内核会把它标记为不可用并暂时跳过,等下一轮检测再重新尝试。偶尔一两次属于正常波动。
all proxies unavailable / no proxy available:代理组里所有节点都被判定不可用,这时该组下的所有连接都会失败。原因可能是订阅节点整体过期,也可能是测速地址本身在你的网络环境下不通,导致误判所有节点都失败。可以先手动切换到组内某个节点直接测试,如果手动能连上,说明是测速逻辑误判,可以调整测速地址或间隔。
proxy group has no selected proxy:策略组下没有任何可选节点,通常是订阅解析后节点列表为空,回到订阅管理里检查节点数量和过滤规则是否把节点全部筛掉了。

DNS 相关日志与排查思路

不少看起来像连接问题的报错,根源其实是 DNS 没解析成功。日志里如果出现 could not resolve host 或者解析结果异常缓慢,先确认配置文件里 dns 字段是否启用,以及使用的上游 DNS 服务器是否可达。开启了 fake-ip 模式后,如果某些应用无法正确处理虚拟 IP,也会在日志里表现为连接目标地址异常,这种情况通常需要在 fake-ip-filter 里把相关域名加入例外,让这类流量走真实 IP 解析而不是虚拟地址。

整体排查思路可以归纳为三步:先看级别判断严重程度,error 才需要马上处理;再看报错文本判断是网络层问题(timeout、refused、no route)还是逻辑层问题(match、health check);最后结合上下文的目标地址和节点名称,把问题精确定位到具体的节点、规则或者本机网络环节,而不是笼统地怀疑"整个代理坏了"。