Clash运行日志查看与分析指南

2026-07-26 故障排查 阅读约 12 分钟

当Clash出现连接失败、规则不生效、DNS污染等问题时,日志是最重要的排查工具。很多用户遇到问题只会说"上不了网",但日志里其实写着清清楚楚的原因。

这篇文章带你从零理解Clash的日志系统,学会读日志、分析日志、用日志定位问题。

日志级别说明

Clash的日志分为5个级别,从高到低依次为:

日志级别一览
  • SILENT:静默模式,不输出任何日志。适合日常使用,减少性能开销
  • ERROR:仅输出错误信息。当连接失败、配置解析出错时产生
  • WARNING:输出警告信息。包含潜在问题提醒,如节点超时、证书异常等
  • INFO:输出常规运行信息。包括连接建立、规则匹配、DNS查询等
  • DEBUG:输出最详细的调试信息。包括底层网络交互、内存分配、完整的数据包流向等

日志级别是向上包含的:设置为INFO会同时输出INFO、WARNING和ERROR级别的日志。只有SILENT会完全关闭日志输出。

日常使用建议

平时使用设置为INFO即可,既能看到关键运行信息,又不会产生过多日志影响性能。只有在排查问题时才临时切换到DEBUG级别。

在配置文件中设置日志级别:

# 设置日志级别
log-level: info

# 可选值:silent / error / warning / info / debug

各客户端查看日志的方法

Clash for Windows / Clash Verge Rev(Windows)

Windows客户端查看日志
  1. 打开Clash Verge Rev主界面
  2. 点击左侧菜单栏的"日志"(Logs)标签
  3. 日志会实时滚动显示
  4. 顶部有日志级别过滤器,可选择显示的最低级别
  5. 使用搜索框可以过滤包含特定关键词的日志条目
  6. 点击日志区域的右上角图标可以将日志导出为文件

也可以通过命令行查看Clash内核日志文件。日志默认保存在用户目录下:

# Clash Verge Rev 日志路径
%USERPROFILE%\.local\share\clash-verge-rev\logs\

# 旧版 Clash for Windows 日志路径
%USERPROFILE%\.config\clash\logs\

Clash Meta for Android(Android)

Android客户端查看日志
  1. 打开Clash Meta for Android
  2. 滑动到左侧菜单或直接点击底部"日志"标签
  3. 日志实时显示,可以通过顶部的下拉菜单选择日志级别
  4. 长按日志条目可以复制内容
  5. 在设置中可以开启"日志保存到文件"

Android端的日志文件保存路径通常为:

# Android 日志路径(需要文件管理器访问)
/sdcard/Android/data/com.github.metacubex.clash.meta.for.android/files/logs/

ClashX Pro / Clash Meta(macOS)

macOS客户端查看日志
  1. 点击菜单栏的Clash图标
  2. 选择"日志""Log"
  3. 在弹出窗口中查看实时日志
  4. 也可以通过Finder直接访问日志文件:
# macOS 日志路径
~/.config/clash/logs/

# 或者通过 ClashX Pro
~/Library/Logs/ClashX/

通过RESTful API获取日志

所有支持外部控制的Clash客户端都可以通过API获取日志流:

# 使用curl获取实时日志(需要配置external-controller)
curl -X GET http://127.0.0.1:9090/logs?level=info

# 使用WebSocket获取实时日志流
wscat -c ws://127.0.0.1:9090/logs?level=info
API参数说明
  • level:指定最低日志级别(silent/error/warning/info/debug)
  • 返回的JSON格式日志包含type(级别)和payload(内容)字段

日志格式解读

Clash的每条日志都有固定的格式,理解各字段含义是分析日志的基础。

标准日志格式

time="2026-07-26T14:32:18+08:00" level=info msg="HTTP proxy request" caller="proxy/http.go:123"
time="2026-07-26T14:32:18+08:00" level=info msg="[Rule] match domain-keyword google" caller="engine/rule.go:456"
time="2026-07-26T14:32:19+08:00" level=error msg="dial tcp 104.21.32.1:443: i/o timeout" caller="proxy/socks5.go:78"
字段拆解
  • time:日志产生的时间戳,ISO 8601格式,包含时区信息
  • level:日志级别(info/warning/error/debug)
  • msg:日志的主要内容,描述发生了什么事
  • caller:产生这条日志的代码位置(文件名:行号),调试时用于定位源码

常见的msg模式

以下是你在日志中会频繁看到的消息类型:

# 连接请求
msg="TCP Connection"          -- 新的TCP连接建立
msg="HTTP proxy request"      -- HTTP代理请求
msg="SOCKS5 proxy request"    -- SOCKS5代理请求

# 规则匹配
msg="[Rule] match ..."        -- 规则匹配结果
msg="[DNS] resolve ..."       -- DNS解析过程

# 代理选择
msg="[Proxy] selected ..."    -- 策略组选择了某个节点
msg="dial ..."                -- 正在连接目标地址

# 错误信息
msg="dial tcp ... i/o timeout"   -- 连接超时
msg="connection refused"         -- 连接被拒绝
msg="no such host"               -- 域名无法解析
msg="certificate error"          -- TLS证书错误

常见日志错误类型分析

1. 连接超时(i/o timeout)

level=error msg="dial tcp 104.21.32.1:443: i/o timeout"

含义:Clash尝试连接目标服务器,但在规定时间内未收到响应。

常见原因

解决方案:切换节点、检查节点服务器状态、尝试更换端口。

2. DNS解析失败(no such host)

level=error msg="dial tcp: lookup example.com: no such host"

含义:域名无法被解析为IP地址。

常见原因

3. 连接被拒绝(connection refused)

level=error msg="dial tcp 192.168.1.1:7890: connect: connection refused"

含义:目标地址没有服务在监听对应端口。

常见原因

4. TLS/SSL错误

level=error msg="tls: failed to verify certificate: x509: certificate signed by unknown authority"

含义:TLS握手过程中证书验证失败。

常见原因

5. 订阅下载失败

level=error msg="GET https://sub.example.com/api/v1/xxx error: context deadline exceeded"

含义:配置文件的远程订阅链接无法访问。

常见原因

通过日志排查连接问题的步骤

当你遇到"上不了网"或"某些网站打不开"时,按以下步骤通过日志排查:

步骤1:切换日志级别到DEBUG

将log-level临时设为debug,获取最完整的运行信息。这会产生大量日志,但对排查问题至关重要。

步骤2:复现问题

在日志级别切换后,重新尝试你之前失败的操作(访问某个网站、打开某个应用)。注意观察日志中的新条目。

步骤3:查找关键错误

在日志中搜索以下关键词:

  • error — 所有错误信息
  • timeout — 超时相关
  • refused — 连接被拒绝
  • no such host — DNS解析失败
  • not found — 找不到相关资源
步骤4:追踪请求链路

一条完整的请求在日志中会经历以下阶段:

  1. DNS查询[DNS] resolve xxx.com
  2. 规则匹配[Rule] match ...
  3. 代理选择[Proxy] selected ...dial ...
  4. 连接结果:成功建立或出现错误

如果某个阶段缺失或出现异常,就能精确定位问题所在环节。

步骤5:定位并修复

根据日志给出的错误信息,对应到具体原因并修复。常见问题对应方案:

  • 如果是节点超时 → 切换节点
  • 如果是DNS失败 → 检查dns配置段
  • 如果是规则没匹配 → 检查rules段是否缺少对应规则
  • 如果是连接被拒绝 → 检查端口和代理设置

通过日志分析流量走向

日志不仅能排查错误,还能帮你理解流量的实际走向——哪些网站走了代理,哪些走了直连。

识别规则匹配结果

info级别以上的日志中,每次规则匹配都会记录匹配类型和结果:

# 域名匹配
msg="[Rule] match domain-keyword google → 选择代理节点 HK-01"

# IP-CIDR匹配
msg="[Rule] match ip-cidr 192.168.0.0/16 → DIRECT"

# GEOIP匹配
msg="[Rule] match geoip CN → DIRECT"

# 最终未匹配
msg="[Rule] match final → DIRECT"
流量分析技巧

将日志保存为文件后,可以用文本处理工具快速统计:

  • 搜索DIRECT关键词查看直连流量
  • 搜索代理节点名称查看走代理的流量
  • 搜索final查看未被任何规则匹配到的流量(这些流量走了兜底规则)

使用命令行分析日志

# 统计各规则的匹配次数(Linux/macOS)
cat clash.log | grep "\[Rule\]" | grep -oP "match \K[^→]+" | sort | uniq -c | sort -rn

# 查看走了代理的域名
cat clash.log | grep "proxy" | grep -oP "domain \K[^ ]+" | sort -u

# 查看哪些流量走了DIRECT
cat clash.log | grep "DIRECT" | grep -oP "domain-keyword \K[^ ]+" | sort -u

日志持久化配置

默认情况下,Clash日志只在内存中保留(客户端关闭后丢失)。要持久化日志,需要进行配置。

方法1:配置文件设置

# 在config.yaml中添加
log-level: info

# Clash Premium / Meta 支持将日志输出到文件
# 通过启动参数指定日志文件
# clash -f config.yaml 2> clash.log

方法2:客户端内置功能

各客户端日志持久化方式
  • Clash Verge Rev:设置 → 日志 → 开启"保存日志到文件",可设置日志目录和文件大小上限
  • Clash Meta for Android:设置 → 日志 → 开启"Log to file"
  • ClashX Pro:高级设置中开启日志持久化

方法3:使用systemd管理日志(Linux服务器)

如果你在Linux服务器上用systemd运行Clash,可以利用journalctl管理日志:

# /etc/systemd/system/clash.service
[Unit]
Description=Clash Daemon
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/clash -f /etc/clash/config.yaml
Restart=on-failure
StandardOutput=journal
StandardError=journal
SyslogIdentifier=clash

[Install]
WantedBy=multi-user.target
# 查看Clash日志
journalctl -u clash -f

# 查看最近的错误
journalctl -u clash -p err --since "1 hour ago"

日志轮转配置

长期运行的Clash实例需要配置日志轮转,避免日志文件无限增长:

# /etc/logrotate.d/clash
/var/log/clash/*.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

高级技巧:用日志定位DNS解析问题

DNS问题是Clash使用中最隐蔽的故障类型。很多"连不上"的问题根源都在DNS环节。

开启DNS调试日志

将日志级别设为debug后,你会看到完整的DNS解析过程:

# DNS查询开始
level=debug msg="[DNS] resolve example.com"

# 查询缓存
level=debug msg="[DNS] cache miss for example.com"

# 向上游DNS发起查询
level=debug msg="[DNS] query example.com IN A from tls://8.8.8.8:853"

# 收到响应
level=debug msg="[DNS] answer example.com IN A 93.184.216.34"

# fake-ip分配
level=debug msg="[DNS] fakeip example.com → 198.18.0.10"

# 真实IP解析(用于规则匹配)
level=debug msg="[DNS] resolved example.com → 93.184.216.34"

常见DNS问题诊断

场景1:fake-ip模式下的DNS异常

如果使用fake-ip模式,日志会显示分配了198.18.x.x范围的虚假IP。如果某些应用无法访问,检查日志中是否有resolve exchange错误——这表示fake-ip到真实IP的反向解析失败。

场景2:DNS泄漏排查

在日志中搜索UDP Connectionport 53。如果你看到大量直接发往公共DNS(如114.114.114.114)的UDP请求,说明这些DNS查询没有经过Clash的DNS模块处理,可能存在DNS泄漏。

场景3:DNS污染检测

对比日志中[DNS] answer给出的IP和实际正确IP。如果Clash解析到的IP是错误的(被污染的),说明上游DNS配置不当。确保对国外域名使用DoH/DoT加密DNS。

DNS配置优化建议

# 推荐的DNS配置(防污染)
dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.localdomain"
    - "*.example"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - "tls://dns.alidns.com:853"
    - "https://dns.alidns.com/dns-query"
  fallback:
    - "tls://1.1.1.1:853"
    - "https://cloudflare-dns.com/dns-query"
    - "tls://dns.google:853"
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4

实战案例:3个典型问题的日志分析过程

案例1:YouTube网页打不开,但Google可以

用户描述:Google搜索正常,YouTube一直转圈加载不出来。

日志分析过程

将日志级别切换为info,打开YouTube,观察日志输出:

msg="[Rule] match domain-suffix google.com → Proxy"
msg="dial tcp 142.250.x.x:443 via proxy HK-01"
-- Google连接成功 --

msg="[Rule] match domain-suffix youtube.com → Proxy"
msg="dial tcp 142.250.x.x:443 via proxy HK-01"
msg="dial tcp 142.250.x.x:443: i/o timeout"
-- YouTube连接超时 --

msg="[DNS] resolve googlevideo.com"
msg="[DNS] resolve r1---sn-xxx.googlevideo.com"
msg="[Rule] match domain-suffix googlevideo.com → DIRECT"
-- YouTube视频分片走了DIRECT --

定位问题:YouTube网页走代理没问题,但视频分片域名googlevideo.com被规则匹配到了DIRECT直连。由于直连无法访问Google视频服务器,导致视频加载失败。

解决方案

在规则段中,将googlevideo.com的规则改为走代理:

rules:
  # 添加以下规则(放在DIRECT规则之前)
  - DOMAIN-SUFFIX,googlevideo.com,Proxy
  - DOMAIN-SUFFIX,youtube.com,Proxy
  - DOMAIN-SUFFIX,ytimg.com,Proxy

案例2:间歇性断网,每30分钟断开一次

用户描述:Clash运行正常,但每隔大约30分钟会断网几分钟,然后自动恢复。

日志分析过程

切换到debug级别,持续观察日志30分钟以上:

-- 正常运行中 --
msg="[Health Check] ping HK-01: 45ms"
msg="[Health Check] ping US-01: 180ms"
msg="[Health Check] ping JP-01: timeout"
msg="[Health Check] JP-01 failed: context deadline exceeded"

-- 断网时刻 --
msg="[Health Check] ping HK-01: timeout"
msg="[Health Check] ping US-01: timeout"
msg="[Health Check] all proxies failed"
msg="[Proxy] fallback to DIRECT"

-- 恢复时刻 --
msg="[Health Check] ping HK-01: 48ms"
msg="[Health Check] proxy recovered"

定位问题:健康检查(url-test/fallback策略组的容差检测)在某一时刻将所有节点判定为不可用,导致流量回退到DIRECT。几分钟后节点恢复。这通常是因为健康检查的测试URL被暂时封锁,或者所有节点同时出现网络波动。

解决方案
  1. 更换健康检查的测试URL,使用不易被封的域名:
    proxy-groups:
      - name: "Proxy"
        type: select
        proxies:
          - HK-01
          - US-01
          - JP-01
        url: "http://cp.cloudflare.com/generate_204"
        interval: 120
        tolerance: 100
  2. 增大健康检查间隔(interval从60改为120-300秒)
  3. 增加容差值(tolerance从50改为100-150ms),避免节点轻微波动就被剔除

案例3:特定应用无法联网(微信/钉钉)

用户描述:浏览器正常,但微信消息发送失败、钉钉无法连接。

日志分析过程

开启info级别日志,打开微信发送消息,观察日志:

msg="TCP Connection from 192.168.1.100:54321"
msg="[DNS] resolve short.weixin.qq.com"
msg="[DNS] resolved short.weixin.qq.com → 120.232.x.x"
msg="[Rule] match geoip CN → DIRECT"
msg="dial tcp 120.232.x.x:443"
msg="dial tcp 120.232.x.x:443: connection established"

msg="TCP Connection from 192.168.1.100:54322"
msg="[DNS] resolve long.weixin.qq.com"
msg="[DNS] resolved long.weixin.qq.com → 120.232.x.x"
msg="[Rule] match geoip CN → DIRECT"
msg="dial tcp 120.232.x.x:8080"
msg="dial tcp 120.232.x.x:8080: i/o timeout"

定位问题:微信的短连接服务(short.weixin.qq.com)正常,但长连接服务(long.weixin.qq.com:8080)超时。由于这些是国内域名,走了DIRECT直连。问题可能出在本地网络到微信服务器的8080端口被运营商或路由器拦截。

解决方案
  1. 确认路由器或防火墙是否拦截了8080端口的出站流量
  2. 尝试将这些域名改为走代理:
    rules:
      # 在GEOIP CN规则之前添加
      - DOMAIN-SUFFIX,weixin.qq.com,Proxy
      - DOMAIN-SUFFIX,wechat.com,Proxy
      - DOMAIN-SUFFIX,dingtalk.com,Proxy
  3. 如果使用TUN模式,检查stack设置,尝试在system/gvisor/mixed之间切换
日志分析总结

日志是Clash问题排查的第一手资料。掌握日志阅读能力,你就能独立解决90%以上的问题。核心思路:

  • 先看错误级别,定位是否有明确报错
  • 追踪请求链路:DNS → 规则 → 代理 → 连接结果
  • 对比预期行为和实际行为,找出差异点
  • 针对性修改配置并验证