故障排查 预计阅读 13 分钟

Clash 运行日志怎么看：从 DNS 报错到连接超时的定位思路

日志级别怎么调、每行字段代表什么、dial tcp timeout 和 dns resolve failed 分别指向哪里出了问题。整理常见报错的含义对照与排查顺序，让日志真正帮你缩小故障范围。

先确认日志来自界面、内核还是操作系统

Clash 客户端出现“连接失败”时，界面通知通常只给出结果，真正能用于定位的是内核运行日志。Clash Meta（现名 Mihomo）负责 DNS、规则匹配、节点连接和 TUN 数据转发，桌面客户端则负责启动内核、修改系统代理并展示日志。两层组件可能分别报错，因此第一步不是搜索某一行英文，而是确认报错发生在哪一层。

日志来源 常见内容 优先检查对象
客户端界面日志 内核启动失败、配置保存失败、服务模式安装结果 客户端权限、内核路径、配置文件
Mihomo 内核运行日志 DNS 查询、规则命中、代理拨号、连接超时 订阅配置、节点、DNS 与网络出口
操作系统日志 TUN 网卡创建失败、端口占用、权限被拒绝 管理员权限、防火墙、已有进程

多数桌面客户端可从侧栏的「日志」页面直接查看内核输出。以常见的 Mihomo 桌面客户端为例，可进入「设置」→「Clash 设置」→「日志等级」，将等级从 info 临时调为 debug，然后回到「日志」页面复现问题。不同客户端的菜单名称略有差异，但配置文件中的标准字段通常都是 log-level。

log-level: debug

复现问题时要保留完整时间线

不要只截取最后一条红色报错。一次连接通常会依次经过域名解析、规则匹配、策略组选择、节点拨号和 TLS 握手，最后一行只代表流程停止的位置。建议先清空当前日志，记录系统时间，再执行一次失败操作，并保留错误前后至少 10 秒的内容。

  1. 关闭正在持续联网的视频、同步和下载程序，减少无关日志。
  2. 清空客户端日志，确认当前配置已经成功加载。
  3. 只访问一个用于测试的地址，例如 https://example.com。
  4. 记录访问时间、所选策略组和节点名称。
  5. 导出或复制从 DNS 查询开始到连接结束的完整片段。

一行 Clash 日志应该拆成哪些字段

Mihomo 不同版本和客户端包装后的显示格式会有差异，但核心信息基本一致：时间、等级、网络类型、来源地址、目标地址、命中的规则以及最终使用的出站策略。下面是一条典型的 TCP 连接记录。

time="2026-07-27T14:32:18.412+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> example.com:443 match DomainSuffix(example.com) using PROXY[HK-01]"

如果日志显示 using DIRECT，说明该连接被规则判定为直连；如果显示 using REJECT，则是配置主动拒绝请求。此时切换节点通常不会改变结果，应先检查规则顺序、规则集内容和当前运行模式。规则从上到下匹配，前面已命中的连接不会继续检查后面的规则。

info、warning、error 和 debug 怎么看

等级 用途 是否一定代表故障
info 配置加载、连接建立、规则命中 否，主要用于还原流程
warning 重试、兼容性回退、规则集更新异常 不一定，要看功能是否受影响
error 拨号失败、解析失败、配置无法加载 通常需要处理
debug 更详细的 DNS、连接和协议状态 否，信息量较大

DNS 报错：先区分上游失败与本地监听失败

dns resolve failed、lookup failed 或 exchange failed 都表示域名解析链路没有正常返回结果，但原因可能完全不同。常见路径是：应用把查询交给系统或 Mihomo，Mihomo 再访问配置中的 nameserver，收到结果后按 fake-ip 或 redir-host 模式处理。任何一段断开，界面都可能只显示“DNS 失败”。

看到 timeout 时检查上游 DNS

level=error msg="dns resolve failed: lookup example.com: i/o timeout"
level=warning msg="[DNS] exchange failed: context deadline exceeded"

i/o timeout 或 context deadline exceeded 表示请求在截止时间前没有拿到有效响应。先检查配置中的 DNS 地址能否从当前网络访问。若使用 DoH，还要确认其域名自身可被 default-nameserver 解析，否则可能形成“需要先解析 DoH 域名，但可用解析器正是该 DoH”的循环依赖。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

这段示例让本地 DNS 监听在 127.0.0.1:1053，并为 DoH 域名准备基础解析器。实际使用时要结合所在网络调整上游地址；某个上游在另一张网络可达，不代表在当前 Wi-Fi、公司网络或移动热点中也能稳定访问。

确认本地 DNS 端口是否真的在监听

如果日志出现 bind: address already in use，表示配置要求的监听端口已被其他进程占用。端口 53 常被系统 DNS 服务使用，普通用户进程在部分系统上也没有绑定低位端口的权限。桌面环境可改用 1053，再由客户端或 TUN 的 DNS 劫持功能接管查询。

dig @127.0.0.1 -p 1053 example.com

nslookup example.com 127.0.0.1

dig 命令明确指定了 1053 端口，适用于安装了对应工具的 macOS 或 Linux。Windows 自带的 nslookup 不便直接指定非 53 端口，因此更适合先检查默认监听；若配置使用 1053，可从客户端日志确认监听成功，或用端口检测工具验证。

dial tcp timeout：节点、网络还是目标站点

dial tcp timeout 表示 TCP 拨号阶段在限定时间内没有完成。重点是看它正在拨向哪里：如果目标是代理服务器的 IP 和端口，问题多半位于本机到节点之间；如果已经通过代理并在连接目标站点，则可能是节点出口、目标站点或规则选择的问题。

level=error msg="dial tcp 203.0.113.20:443: i/o timeout"
level=error msg="connect failed: dial tcp: lookup node.example.net: i/o timeout"
level=error msg="dial tcp 127.0.0.1:7890: connect: connection refused"

用本地代理端口做一组可重复测试

假设配置中的 mixed-port 是 7890，可先确认端口，再让命令行请求明确经过 Clash。下面的请求把连接超时设为 5 秒，总时限设为 15 秒，便于区分“立即拒绝”和“持续等待后超时”。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 5 \
  --max-time 15 \
  -I https://example.com

若命令在不到 1 秒内返回 Connection refused，优先检查内核进程与本地端口。若等待约 5 秒后出现连接超时，本地端口通常已接收请求，故障更可能发生在节点拨号阶段。若返回 HTTP/2 200 或 HTTP/1.1 200 OK，说明该测试地址能够通过当前代理建立连接，原应用的问题可能来自代理设置覆盖、QUIC、证书或独立 DNS。

Windows PowerShell 可先执行以下命令检查本地端口是否可连接：

Test-NetConnection 127.0.0.1 -Port 7890

看到 TcpTestSucceeded : True 只代表本机能连到 Clash 的监听端口，不代表远端节点可用。接下来仍需结合内核日志中的策略组、节点名称和远端错误继续判断。

connection refused 与 network unreachable 的差异

报错 直接含义 优先动作
connection refused 目标主机明确拒绝连接，或本地没有进程监听 核对 IP、端口、内核进程和节点服务状态
i/o timeout 截止时间内没有完成读写 测试网络出口，换节点并比较耗时
network is unreachable 系统没有可用路由到达目标网络 检查网卡、IPv4/IPv6 路由与 TUN 状态
TLS handshake timeout TCP 之后的 TLS 握手未按时完成 检查链路质量、时间、协议参数和中间网络
EOF 对端提前关闭连接 查看是否持续发生，并比较其他节点

TUN 模式相关日志怎么判断

系统代理只影响主动读取代理设置的应用，TUN 模式则通过虚拟网卡接管更广泛的流量。浏览器正常、游戏或终端失败时，日志中是否出现对应进程的连接记录非常关键：完全没有记录，通常表示流量尚未进入 Mihomo；有规则命中但随后拨号失败，才属于代理链路内部问题。

TUN 启动阶段常见错误包括 operation not permitted、failed to create tun device 和路由写入失败。它们通常指向权限、服务模式或虚拟网卡状态。在 Windows 客户端中可检查「设置」→「服务模式」是否正常，再重新启用 TUN；macOS 与 Linux 则需要确认客户端或内核具备创建虚拟接口和修改路由的权限。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-detect-interface 会让 Mihomo识别当前默认出口。频繁切换 Wi-Fi、有线网络、VPN 或移动热点后，如果日志仍显示旧接口，可先关闭 TUN，再等待系统路由稳定后重新开启。不要同时让两个网络工具写入默认路由和 DNS 劫持规则，否则日志可能交替出现接口不可达与 DNS 超时。

日志里没有目标连接意味着什么

配置与订阅错误要在启动阶段处理

如果内核没有完成配置加载，后续 DNS 和节点测试都没有意义。YAML 对缩进敏感，列表项、冒号和字符串格式错误都可能导致启动失败。日志中的 parse config error、yaml: line 42 或 mapping values are not allowed 通常会指出接近错误的位置，但真正的问题也可能位于上一行。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Auto
      - DIRECT

同一层级保持一致的空格，不要混用制表符。名称包含冒号、井号或其他 YAML 特殊字符时，使用引号包裹。订阅更新后若出现 provider not found、策略组引用不存在或规则集加载失败，应核对引用名称是否与 proxy-providers、rule-providers 中的键完全一致，包括大小写和空格。

HTTP 状态码能缩小订阅更新范围

一套从现象到结论的排查顺序

日志的价值不是把所有错误都列出来，而是找到第一处偏离正常流程的位置。一次失败可能同时产生 DNS 超时、节点测速失败和规则集更新失败；如果本机已经断网，三类错误只是同一个根因的不同表现。按固定顺序检查，可以减少在无关设置之间来回切换。

  1. 确认基础网络：关闭系统代理和 TUN 后，测试当前网络能否访问本地允许直连的站点。
  2. 确认配置加载：查看启动阶段是否出现 YAML 解析、端口占用或 provider 引用错误。
  3. 确认本地监听：核对 mixed-port: 7890 等实际端口，并测试本机是否能连接。
  4. 确认 DNS：观察节点域名和目标域名能否解析，区分本地监听失败与上游超时。
  5. 确认规则命中：检查目标究竟走 DIRECT、REJECT 还是预期策略组。
  6. 确认节点拨号：比较两个不同地区节点的错误与耗时，判断是否为单节点故障。
  7. 确认应用接管：日志中没有目标记录时，回查系统代理、环境变量、TUN 路由和应用内代理。
  8. 恢复常用设置：结束测试后把日志级别改回 info，并清理临时代理环境变量。

例如，浏览器提示无法连接，日志先出现 lookup node.example.net: i/o timeout，随后多个节点全部测速失败。此时共同故障点是节点域名解析，不应逐个修改节点协议。另一个例子是日志明确显示 match MATCH using PROXY[US-02]，随后只有 US-02 出现 connection refused，切换到 HK-01 后立即成功，那么范围已缩小到单个节点或其端口。

最终记录至少应包含客户端版本、Mihomo 内核版本、操作系统、网络类型、当前模式、日志等级、复现时间和完整错误片段。版本信息可以解释配置字段是否受支持，网络类型则能帮助判断 IPv6、公司网络限制或热点切换问题。只要把“流量有没有进入 Clash、DNS 有没有完成、命中了哪条规则、拨向哪个出口”四个问题回答清楚，多数运行故障都能从模糊的“代理不工作”缩小到一个可验证的环节。

下载Clash