Clash 日志看不懂?常见报错信息含义与问题定位方法

先判断日志来自哪个环节

Clash、Clash Meta 与 mihomo 的日志看起来相似，但同一页面里可能混有客户端日志、内核日志和配置更新记录。定位问题前，先确认报错由谁产生。客户端负责下载订阅、写入配置和启动内核；内核负责 DNS、规则匹配、代理连接与 TUN 流量处理。订阅下载失败时，修改代理规则通常没有作用；内核根本没有启动时，测试节点延迟也不会得到有效结果。

三类记录的关注点

客户端记录：常见内容包括订阅 URL 请求、配置文件保存、内核进程启动和系统代理切换。出现 HTTP 401、403、404 或配置写入失败时，先查订阅与文件权限。
内核启动记录：会显示配置加载、DNS 模块、监听端口、规则集和 TUN 初始化状态。这里报错通常会导致内核停止，或使某一项功能不能使用。
连接记录：包含 TCP、UDP、来源地址、目标域名、命中规则和最终策略组。网页打不开、应用绕过代理、节点超时时，主要查看这一类。

不同客户端的菜单名称会略有差异。一般可从「设置」→「日志」或「内核」→「日志」打开实时记录；部分桌面客户端把入口放在「主页」→「日志」。mihomo 图形客户端通常还能在「设置」→「参数设置」中调整日志级别。复现问题时保持日志页面打开，清空旧记录，然后只执行一次失败操作，得到的样本最容易阅读。

读懂级别、连接方向与规则结果

常见日志级别包括 debug、info、warning 和 error。info 记录正常连接，不代表故障；warning 表示操作失败、回退或暂时异常，但内核通常仍在运行；error 更值得优先检查。排查规则时可临时使用 debug，完成后改回 info，避免大量 DNS 与连接细节持续写入日志。

[INFO] [TCP] 127.0.0.1:53142 --> example.com:443
match DomainSuffix(example.com) using Proxy[HK-01]

[WARNING] [TCP] dial Proxy (match DomainSuffix/example.com)
127.0.0.1:53142 --> example.com:443 error: i/o timeout

第一行表示本机进程从临时端口 53142 发起 TCP 连接，目标为 example.com:443。随后命中 DOMAIN-SUFFIX 规则，并交给名为 Proxy 的策略组；方括号里的 HK-01 是该组实际选择的节点。第二段说明连接已进入代理链路，但在规定时间内没有完成。由此可以先排除“规则没有命中”，把注意力转向节点、上游网络或目标站点。

看到日志时按这个顺序拆分

确认协议是 TCP 还是 UDP。网页 HTTPS 多数使用 TCP 443，也可能通过 QUIC 使用 UDP 443。
确认来源地址。127.0.0.1 通常是系统代理或本地应用；TUN 接管时可能显示虚拟网卡地址。
确认目标是域名还是 IP。只有 IP 时，部分域名规则无法参与匹配。
查看 match 后的规则类型和规则内容。
查看 using 后的策略组与实际节点，判断连接最后去了哪里。
最后读 error 内容，区分连接超时、拒绝、解析失败还是认证失败。

dial tcp timeout：连接在规定时间内没有建立

dial tcp 表示内核正在建立 TCP 连接。后面的 i/o timeout、connect: operation timed out 或 context deadline exceeded 都指向“等待超过期限”，但超时位置并不一定相同。可能是连接代理服务器失败，也可能是代理服务器连接目标站点失败。要结合错误前面的节点名称、目标地址和连续失败范围判断。

只有一个节点超时

若同一策略组里 HK-01 连续超时，而 SG-02 可以正常打开相同网站，问题集中在节点或节点线路。先在客户端执行一次延迟测试，再用实际网页验证。延迟测试 URL 返回 200 只能说明测试链路可达，不等于所有目标都可访问。连续 3 次出现 5 秒以上超时，比单次 800 毫秒更能说明连接不稳定。

所有节点同时超时

检查当前网络是否能直连订阅站点之外的普通网页，排除本地断网。
确认系统时间准确。时间相差数分钟可能影响 TLS 握手和带时间戳的认证协议。
检查节点服务器地址能否解析。日志若同时出现 lookup 或 DNS request failed，应先处理 DNS。
临时关闭系统中的另一套 VPN、代理软件或网络过滤工具，避免路由互相覆盖。
若启用了 TUN，先改用系统代理复测。系统代理可用而 TUN 不可用时，重点检查虚拟网卡、路由与权限。

[WARNING] dial tcp 203.0.113.20:443: i/o timeout
[WARNING] dial tcp: lookup node.example.net: i/o timeout

这两行不能按同一种方式处理。第一行已经得到服务器 IP，超时发生在 TCP 连接阶段；第二行还停留在域名解析阶段。前者查服务器端口与网络路径，后者查 DNS 服务器、DNS 路由和本机网络。

connection refused：目标明确拒绝连接

connection refused 与超时不同。超时表示迟迟没有收到有效回应；拒绝连接表示目标主机很快返回了拒绝结果。常见原因是端口没有服务监听、服务已经停止、端口填写错误，或本地应用连接到了未启动的 Clash 监听端口。

dial tcp 127.0.0.1:7890: connect: connection refused
dial tcp 198.51.100.8:8443: connect: connection refused

第一行目标是 127.0.0.1:7890，说明某个应用尝试连接本机代理端口，但该端口没有进程监听。检查客户端内核状态，并确认应用代理地址与 Clash 配置一致。常见混合代理端口是 7890，但用户配置可能改为 7897、7899 或其他值，不能只按默认值填写。

第二行是远端地址拒绝连接。若它对应节点服务器，应核对节点端口、协议类型与订阅更新时间。把 VMess 节点端口误填到 Trojan 配置，或服务器更换端口后仍使用旧订阅，都可能立即被拒绝。此时反复切换规则模式没有作用，因为错误发生在代理服务器连接阶段。

DNS 解析失败：先确认请求由谁处理

DNS 问题常表现为网页提示找不到服务器，日志中出现 lookup、no such host、all DNS requests failed、could not resolve 或上游 DNS 超时。排查关键是确认 DNS 请求走操作系统、Clash DNS 模块，还是浏览器自己的安全 DNS。三者并行时，改动其中一个不一定影响实际请求。

检查内核 DNS 配置

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
  fallback:
    - tls://1.1.1.1:853

这段配置让内核在 1053 端口监听 DNS，请求不会自动出现在系统的 53 端口上。图形客户端通常会在启用 TUN 或 DNS 接管时添加相应路由。若只复制了配置，却没有让系统 DNS 指向内核，应用仍可能使用原来的解析器。相反，如果端口已被另一个程序占用，启动日志会出现 bind: address already in use。

按现象区分处理方向

所有域名失败，但直接访问 IP 有响应：优先检查 DNS 监听、上游 DNS 和防火墙。
国内域名正常，特定域名失败：检查 nameserver-policy、fallback 与规则集是否把 DNS 请求送到了不可达链路。
浏览器失败，其他应用正常：检查浏览器的安全 DNS 设置与代理扩展，确认它是否绕过系统 DNS。
Fake-IP 地址出现但连接失败：Fake-IP 返回保留地址属于正常流程，应继续检查后续域名恢复、规则命中与代理连接，而不是把保留地址当成真实服务器。
TUN 开启后才失败：检查 DNS 劫持配置、默认路由和虚拟网卡权限，避免 DNS 请求被循环送回内核。

修改 DNS 后，应清理旧缓存再测试。Windows 可重新连接网络或在终端执行 ipconfig /flushdns；macOS 可关闭并重新打开网络接口。浏览器还可能保留自己的 DNS 与连接缓存，完全退出浏览器后复测更可靠。

规则未命中：日志可能没有 error

规则分流错误经常不会产生红色报错。连接成功，但走了 DIRECT、错误节点或最终的 MATCH，用户仍会感觉“规则失效”。Clash 与 mihomo 按配置中的顺序自上而下检查，第一条命中后停止。范围较大的规则放在前面，会遮住后面的精确规则。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN,api.example.com,Proxy
  - MATCH,Proxy

访问 api.example.com 时，第一条 DOMAIN-SUFFIX 已经命中，因此第二条精确域名规则不会执行。若希望 API 走代理，应把 DOMAIN,api.example.com,Proxy 移到更前面。日志里若显示 match DomainSuffix(example.com) using DIRECT，说明规则系统正常工作，问题是规则顺序，而不是内核忽略配置。

日志只显示 IP 时怎么查

目标显示为 142.250.0.1:443 一类 IP 时，DOMAIN 和 DOMAIN-SUFFIX 规则可能没有可用域名。原因包括应用直接连接 IP、DNS 映射未关联到连接，或流量没有完整经过内核。可查看是否命中 IP-CIDR、GEOIP 或最终 MATCH。使用 no-resolve 的 IP 规则不会为了匹配而额外解析域名，它并不是“跳过这条规则”。

规则集加载失败

远程规则集无法下载时，日志可能出现 HTTP 404、context deadline exceeded 或 provider update failed。先检查规则集 URL 与更新时间，再确认下载请求使用的策略。规则集首次加载失败可能使依赖它的规则不可用；已有缓存时，内核可能继续使用旧版本。排查时应记录失败发生在启动阶段还是定时更新阶段。

订阅、配置与内核启动错误

如果日志里完全没有 TCP 或 UDP 连接记录，先确认内核是否成功加载配置。YAML 缩进错误、策略组引用不存在的节点、端口冲突和配置字段不兼容，都可能让内核在接管流量前退出。

HTTP 状态码对应的订阅问题

日志状态	常见含义	优先检查
401 Unauthorized	请求缺少有效认证信息	订阅令牌是否完整、链接是否被截断
403 Forbidden	服务器收到请求但拒绝提供内容	订阅状态、访问限制与请求来源
404 Not Found	订阅路径不存在	链接是否过期、路径是否复制错误
429 Too Many Requests	短时间请求次数过多	暂停自动刷新，等待限制解除
5xx	订阅服务端暂时异常	稍后重试，并保留现有可用配置

YAML 与引用错误

yaml: line 42: did not find expected key
proxy group Proxy: proxy HK-01 not found
listen tcp 127.0.0.1:7890: bind: address already in use

did not find expected key 通常与缩进、缺少冒号或引号未闭合有关。YAML 应使用空格缩进，不要混入制表符。
proxy not found 表示策略组引用了不存在的节点或子策略组。检查名称的空格、大小写及订阅更新后节点是否被改名。
address already in use 表示监听地址或端口已被占用。退出旧内核进程，或在「设置」→「参数设置」中更换 mixed-port 后重新启动。
permission denied 出现在 TUN 初始化阶段时，通常与虚拟网卡权限或系统服务状态有关。系统代理可正常使用时，可先保持系统代理模式，再单独处理 TUN。

Clash Premium、Clash Meta 与 mihomo 支持的配置字段并不完全相同。配置由较新的 mihomo 生成，却交给旧内核加载时，可能出现 unknown field 或解析失败。先在客户端的「关于」或「内核」页面确认实际内核名称与版本，再对照该内核支持的字段，不要只看客户端外壳版本。

一套可复现的日志排查流程

记录现象：写下失败时间、应用名称、目标域名，以及系统代理或 TUN 是否开启。
确认内核状态：检查内核是否运行，mixed-port 是否监听，启动日志是否有配置错误。
清空日志：把级别设为 info，清除历史记录，避免旧错误干扰判断。
只复现一次：打开一个失败页面、刷新一次订阅或执行一次节点连接，不要同时操作多个应用。
先找目标：搜索域名、IP 或订阅地址，再向前后查看 10 至 20 行上下文。
划分环节：订阅 HTTP 错误归入订阅环节；YAML 和端口错误归入启动环节；lookup 归入 DNS；match 归入规则；dial 归入连接。
做单变量测试：一次只更换一个节点、一个 DNS 上游或一种接管模式。每次改动后重新清空日志。
恢复日志级别：问题处理完成后从 debug 改回 info，减少无关记录。

例如，某网站在 TUN 模式下 8 秒后失败，而系统代理模式可在 1.2 秒内打开。日志显示规则均命中同一节点，系统代理模式能完成 TCP 连接，TUN 模式却没有对应目标记录。此时节点和规则已经基本排除，检查重点应转到 TUN 路由、应用是否走虚拟网卡、DNS 劫持以及系统权限。这样的对照测试比连续更换十个节点更有效。

向他人提供日志前，可以保留时间、错误类型、目标端口、规则类型和策略组名称，同时处理订阅令牌、认证字段、完整节点地址与本机用户名。不要只截取最后一行 error；至少保留错误前后的启动信息或连接上下文，否则很难判断超时发生在 DNS、节点还是目标站点。