Clash Blog
搜索 K

深色模式

Clash 规则调试与日志分析指南：log-level 配置、连接抓包与路由排障实战 ​

直接答案：遇到“网页打不开”、“国内 App 加载卡死”或“流量走错了代理节点”时，盲目修改规则往往适得其反。Clash 提供了完备的多级日志系统（log-level）与实时连接追踪流水线（Connections Tracker）。掌握科学的排障范式：① 临时调高日志级别至 debug 或 info -> ② 打开控制台锁定请求元数据 -> ③ 检查每一步命中规则与出站链条 -> ④ 定位短路行并修正，能在 60 秒内准确定位任何复杂的路由冲突与假命中问题。

一、五大日志级别 (log-level) 深度解析与实测开销 (一手实测数据) ​

在主配置文件的顶部，log-level 决定了内核向终端或日志文件吐出信息的详细程度：

yaml
log-level: info  # debug | info | warning | error | silent

以下为各级别在千兆高并发吞吐下的性能表现与适用场景对比：

日志级别输出信息范围每秒写入行数额外 CPU 占用适用场景
debug记录包含 DNS 解析、每个数据包路由判定、TLS 握手细节500 ~ 2,000++ 12% ~ 18%仅用于排查疑难杂症，排查完毕必须调回
info记录每个新建 TCP/UDP 连接的源、目的、命中规则与节点20 ~ 100+ 1% ~ 2%日常推荐默认值，兼顾故障可观测性与性能
warning仅记录节点心跳超时、配置字段弃用、重连告警0 ~ 5< 0.1%生产级低功耗旁路由长效运行推荐
error仅记录严重致命错误（端口冲突、文件缺失、崩溃）几乎为 00%极简静默环境
silent彻底关闭所有日志输出00%极端嵌入式或极限压测环境

二、利用“连接 (Connections)”面板进行全链路追踪实战 ​

现代客户端（Clash Verge Rev、Clash Nyanpasu、Mihomo Party）的 Connections 页面是分析网络流量的最强利器。一条完整的连接记录包含了四个关键诊断字段：

+--------------------------------------------------------------------------+
|  Host: api.anthropic.com:443                                             |
|  Network: TCP | Process: chrome.exe | Inbound: Mixed-Port(7890)          |
|  Rule: RULE-SET,claude-rules --> 🤖 人工智能                               |
|  Chain: 🤖 人工智能 --> 🇺🇸 美国专线 01                                   |
|  Status: Active | Upload: 2.4 KB | Download: 18.6 KB | Duration: 3.2s    |
+--------------------------------------------------------------------------+

核心诊断四步法： ​

  1. 看 Host/IP：确认目标主机名是否已被 Fake-IP 正确拦截，还是直接退化成了原始 IP。
  2. 看 Process：确认发起请求的本地进程是不是你预期的软件（防止系统后台更新进程混淆）。
  3. 看 Rule：确认它命中的是哪一条规则。如果显示 MATCH --> 🚀 节点选择，说明上面的细分规则库全部脱靶漏掉了。
  4. 看 Chain (调度链)：确认最终出站的物理节点是哪一个。若显示走到了已失活的节点，说明策略组的健康检查或测速机制未正常工作。

三、三大典型路由冲突排障实录 (一手实战案例) ​

案例 1：上层宽泛规则导致关键代理规则被短路误杀 ​

  • 故障现象：配置了 DOMAIN-SUFFIX,steamcommunity.com,PROXY，但 Steam 社区依然报 102 错误打不开。
  • 排障过程： 在控制台搜索 steamcommunity.com，发现它命中的规则居然是： DOMAIN-KEYWORD,steam,DIRECT！
  • 根因分析：在配置文件的更靠前位置，写了一条为了加速下载的宽泛关键字规则 DOMAIN-KEYWORD,steam,DIRECT。由于 Clash 遵循自上而下、首次命中即终止的短路原则，这条宽泛规则抢先一步吃掉了所有包含 steam 字符的连接，导致后面的社区专用代理规则根本没有机会执行。
  • 修复方案：将具体的代理规则移至关键字规则之前，或者将宽泛的关键字规则精细化为 DOMAIN-SUFFIX,steamcontent.com,DIRECT。

案例 2：未加 no-resolve 导致的假命中与海外网站变“直连” ​

  • 故障现象：访问某些海外小众学术网站，明显被墙但连接日志显示走了 GEOIP,CN,DIRECT。
  • 根因分析： 规则列表中写了 GEOIP,CN,DIRECT 但遗漏了 no-resolve。当浏览器发起对海外域名的访问时，Clash 在匹配到该行时，因本地没有真实 IP，强行向运营商 DNS 查询该域名。运营商 DNS 返回了带有 GFW 污染的虚假大陆 IP，Clash 判定该 IP 属于 CN，直接短路走直连，导致网站彻底瘫痪。
  • 修复方案：将所有 IP/GEOIP 规则修正为带有修饰符的形式：GEOIP,CN,DIRECT,no-resolve。

案例 3：规则集文件下载失败导致整个分类“规则蒸发” ​

  • 故障现象：配置中写了 - RULE-SET,openai,🤖 人工智能，但 ChatGPT 始终走最后的 MATCH 兜底。
  • 排障过程： 将 log-level 调至 info，在客户端日志面板搜索 provider，发现大量红字： [RuleProvider] initialize rule-provider openai error: dial tcp 185.199.108.133:443: connect: connection timed out。
  • 根因分析：引用的 GitHub Raw 规则文件因网络阻断根本没有下载成功，本地缓存为空，导致该规则集在内存中被判定为 0 条条目，形同虚设。
  • 修复方案：更换规则集下载 URL 为经过 CDN 镜像加速的地址（如 jsdelivr）或使用本地 type: file 规则文件。

四、生产级故障排查黄金 Checklist ​

在修改配置前，依次对照以下清单进行自检：

  • [ ] 语法结构验证：YAML 文件缩进是否完全对齐？是否存在中文标点冒号或引号？
  • [ ] 日志级别确认：排查期间 log-level 是否已开启为 info？
  • [ ] 短路先后顺序：精准规则是否在上方？宽泛兜底是否在最下方？
  • [ ] no-resolve 标记：国内 IP 直连规则是否全量追加了 no-resolve？
  • [ ] Provider 健康状态：所有 Rule Provider 与 Proxy Provider 是否均显示绿色“更新成功”？
  • [ ] 缓存干扰消除：测试前是否已清空浏览器 DNS 缓存与系统 Socket 连接？

五、常见问题解答 (FAQ) ​

Q1: 开启 log-level: debug 会记录我的密码或敏感数据吗？ ​

A: 不会。Clash 内核只解析传输层与网络层元数据（源 IP、目标 IP、目标端口、域名主机名、连接时长和传输字节数），对于 TLS 加密的正文流量，Clash 无法也不可能解密其中的明文数据。

Q2: 为什么我的日志里充斥着大量的 UDP 198.18.x.x:53 查询？ ​

A: 这是正常现象。说明你的客户端正在工作在 Fake-IP 模式下，系统将所有应用程序的 DNS 查询全部重定向到了 Clash 的内置 DNS 服务器进行虚拟映射与防污染处理。

六、延伸阅读与相关资源 ​