故障排查 预计阅读 12 分钟

Clash 运行日志怎么看:常见报错含义与逐条定位方法

从日志级别与字段结构讲起,逐条拆解超时、DNS 解析失败、端口占用、规则未匹配等常见报错,并给出对应的排查顺序。

先复现一次请求，再筛选对应日志

Clash 页面打不开，不一定是节点失效。请求可能根本没有进入内核，也可能停在 DNS 解析、规则选择、代理握手或目标服务器响应阶段。排查的关键是找出最后一个成功的步骤，而不是看到一条红色消息就更换整份配置。

本文同时适用于原版 Clash 与 Clash Meta（现称 mihomo）的常见日志。不同内核、版本和客户端会调整字段与展示方式，示例用于解释结构，不代表每个版本都会输出相同句子。先在客户端的「关于」或内核信息页记录客户端版本、内核名称与版本，再进行比较；客户端版本号不能代替内核版本号。

  1. 保留当前配置副本，记录系统代理、TUN、运行模式与当前策略组选择。
  2. 打开客户端的「日志」页面。菜单名称因客户端不同而异，找不到时先查看该客户端的使用说明。
  3. 暂停其他下载任务，记下当前时间，只访问一个能稳定复现问题的地址。
  4. 保留这次请求前后约 10 秒的日志，按目标域名、目标端口或源连接端口筛选。

日志级别与字段：先看匹配规则，再看失败位置

配置中的 log-level 控制详细程度。日常使用可保持 info，复现难以定位的问题时临时改为 debug。修改后应用配置，完成排查再恢复，避免大量调试信息掩盖关键错误。

log-level: info
配置值用途阅读重点
debug临时查看更细的内部处理信息结合时间与目标筛选，不逐条猜测
info观察常规连接与策略选择命中的规则、实际出站与目标地址
warning保留警告及更严重的消息连接失败是否持续影响同一目标
error减少普通消息不适合单独判断流量是否进入内核
silent关闭常规日志输出排查前先换回可观察的级别

配置值是 warning，界面却可能显示 WARN；不要把展示缩写直接当成配置值。日志级别也不是故障影响范围：一条警告可能只来自页面内的统计请求，而某个策略选错的连接仍可能显示为普通信息。

time="2026-08-06T10:20:30+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> www.example.com:443 match DomainSuffix(example.com) using 手动选择[节点-A]"
  • time：事件时间。跨设备对照前先核对时区与系统时间。
  • [TCP]：连接协议；UDP 请求需要单独观察，不能只凭 TCP 测试判断。
  • 127.0.0.1:53124：来源地址与临时端口，不是代理监听端口。
  • www.example.com:443：目标主机与端口。HTTPS 常用 443，但并非所有应用都遵循默认端口。
  • match：本次匹配到的规则；using 后面通常能看到策略组及实际选择的出站。

日志里的 using 说明选中了某个出站，不等于连接已经成功，更不等于网页完整加载。应继续观察同一目标、同一时间附近是否出现拨号失败、握手错误或连接关闭。

连接超时：区分代理服务器与目标服务器

i/o timeout、context deadline exceeded 或带有 timeout 的拨号错误，都表示某一步超过了等待时间。仅凭“超时”两个字，无法判断是本地网络、节点线路还是目标站点的问题。

按错误里的地址判断卡在哪一段

  1. 连接代理服务器超时：查看错误是否指向节点配置中的服务器地址与端口。若是，优先检查节点可达性、本机网络与服务器端口。
  2. 直连目标超时：日志使用 DIRECT，错误指向目标 IP 的 443 端口，应先确认规则是否本就应当直连。
  3. 握手或远端读取超时：TCP 连接可能已建立，但后续协议交互未完成。需要继续核对节点协议、TLS 参数及服务端状态。

用同一个 URL 做对照，比打开多个不同网站更有意义。以下命令适用于配置了 HTTP 混合端口 7890 的情况；Windows PowerShell 建议明确调用 curl.exe，macOS 与 Linux 使用 curl。

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

第一条明确经过本地代理端口，第二条绕过 curl 的代理设置。若 TUN 仍在接管路由，第二条流量依然可能进入内核，因此需要在受控条件下暂时关闭 TUN，才能把它作为真正的直连对照。返回 403 或 405 也是 HTTP 响应，不能简单等同于网络连接失败。

DNS 解析失败：先确认是谁在解析

no such host 表示解析未获得可用结果，但不一定是 DNS 服务器宕机；域名不存在、上游返回否定响应或本机解析路径异常，都可能产生类似表现。lookup 后面的域名尤其重要：如果它是代理服务器域名，失败发生在节点连接之前；如果它是目标网站域名，则要结合出站与 DNS 配置继续判断。

用明确端口测试内核 DNS

假设当前启用的配置确实包含以下 DNS 设置，可以直接查询内核监听的 1053 端口。这里的上游地址仅作诊断示例，应按实际网络的可达性选择，不要覆盖订阅中的整段 DNS 配置。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
# macOS / Linux，需已安装 dig
dig @127.0.0.1 -p 1053 example.com A

# Windows，进入 nslookup 交互模式后依次输入
nslookup
server 127.0.0.1
set port=1053
example.com
exit
  • 查询超时：先确认内核已加载这份配置、1053 端口已监听，再查上游 DNS 是否可达。
  • 返回 NXDOMAIN：检查拼写，并用已知存在的域名做对照；不要把不存在的域名当作网络故障。
  • 返回 Fake-IP：例如配置采用默认地址段时出现 198.18.0.0/16 内的映射地址，这本身不是解析失败。
  • 系统查询正常、内核查询异常：重点检查内核 DNS 的上游与路由；反过来则检查系统 DNS 是否真的指向预期路径。

普通 nslookup example.com 一般查询系统设置的 DNS，并不能直接证明内核 DNS 正常。使用 DoH 或 DoT 时，还要考虑上游域名的引导解析、TLS 验证与连接路径。mihomo 的 DNS 扩展字段并不都适用于原版 Clash，添加前应核对当前内核支持范围。字段说明可参照DNS 配置参考。

端口占用与拒绝连接：先看内核是否真正监听

bind: address already in use 通常发生在启动或重载阶段，表示某个本地地址与端口无法再次绑定。常见原因是两个客户端同时运行，或旧内核进程没有退出。应先看报错涉及的是代理端口、DNS 端口还是控制接口，而不是把所有端口一起修改。

mixed-port: 7890
external-controller: 127.0.0.1:9090

上面配置中，7890 用于混合代理入站，9090 用于控制接口。控制接口不是 HTTP 代理入口，把浏览器代理指向 9090 不会得到预期效果。下面的命令只查询进程，不会终止它：

# Windows
netstat -ano | findstr :7890

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -lntp 'sport = :7890'
  1. 确认端口对应的 PID 与程序名称，正常退出重复运行的客户端。
  2. 若改用 7891，同步修改系统代理、浏览器扩展与命令行代理设置。
  3. 重新启动内核，确认没有绑定错误，再执行一次指定代理端口的 curl 测试。

connection refused 与端口占用不同：它表示连接被拒绝，常见于目标端口没有服务监听。如果拒绝地址是 127.0.0.1:7890，优先查本地内核；如果是节点服务器地址，则检查服务器端口与服务状态。不要为了消除本地访问问题，随意把监听地址扩大到所有网卡。

规则未命中：核对模式、顺序与最终出站

Clash 的规则模式按 rules 从上到下匹配，先命中的规则决定策略。列表里“存在一条正确规则”，不代表它有机会执行。全局模式也不会按同一套规则逐条选择出站，因此排查前先确认当前运行模式。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,手动选择

此片段假设配置中已经定义名为「手动选择」的策略组。访问 www.example.com 时应命中第一条；其他未匹配请求交给最后的 MATCH。如果把 MATCH 放在第一条，后续规则就没有机会参与匹配。

按四个检查点定位

  • 看实际加载的配置：订阅源文件、本地编辑文件与客户端运行配置可能不同。确认修改已应用，而不只是保存到编辑器。
  • 看域名是否可用：应用若直接连接 IP，且内核没有恢复域名信息，DOMAIN-SUFFIX 就不一定能命中。嗅探能提供帮助，但不是所有连接都能还原域名。
  • 看规则集状态：使用 RULE-SET 时，先找规则提供器是否下载、解析成功，再核对引用名称与匹配顺序。
  • 看策略组实际选择：日志显示组名正确，但组内选择为 DIRECT 或另一个节点，结果仍会与预期不同。

测试规则修改时，请建立新连接。已有长连接可能沿用原出站，仅刷新页面未必会重建所有连接。可以先关闭测试应用再重开，或在明确影响范围后关闭相关连接。完整字段可查配置大全，订阅更新流程可查订阅使用说明。

TLS、认证与 TUN 报错：不要混成同一种网络故障

消息线索优先检查不宜直接采用的处理
x509: certificate has expired系统时间、服务端证书有效期直接跳过证书验证
certificate is valid for连接域名、证书名称与节点 TLS 参数仅更换本地代理端口
authentication failed报错来自哪个协议、账号密码与订阅状态反复更换 DNS
permission denied完整错误中的资源路径、权限与服务运行状态不看上下文就删除配置

TLS 错误要先区分是节点握手还是目标网站握手。节点使用 TLS 时，服务器地址、SNI 与证书名称之间需要符合服务端配置；系统时间明显偏差也会导致验证失败。关闭证书验证会改变安全边界，不应作为通用修复步骤。

TUN 相关错误常发生在虚拟接口创建、路由设置或 DNS 接管阶段。Windows 应核对客户端服务模式及所需权限，Linux 应检查 /dev/net/tun 是否存在以及进程权限，macOS 应检查客户端要求的系统授权。具体开关名称随客户端变化，不要套用其他客户端的菜单路径。

如果明确指定代理端口的 curl 能成功，而开启 TUN 后应用仍失败，应把排查重点移到路由、DNS 接管、其他 VPN 与安全软件的冲突，而不是继续更换节点。进一步设置见TUN 配置参考。注意，TUN 接管流量不等于所有流量都走代理，最终仍取决于模式与规则。

收尾检查：用同一请求验证修复结果

修改后，用最初记录的 URL 再测试一次。判断恢复应同时看应用结果与日志路径：页面是否完成加载、是否命中预期规则、是否使用预期节点、是否还在重复出现同类错误。仅凭节点延迟测试显示一个毫秒数，不能证明 DNS、目标站点与应用协议都正常。

  1. 内核未启动：先处理配置语法、端口与权限。
  2. 日志没有请求：在 info 级别下复现，检查系统代理、应用独立代理与 TUN 接管范围。
  3. 出现解析错误：分清节点域名与目标域名，分别测试系统 DNS 和内核 DNS。
  4. 出现连接错误：按错误地址区分本地入口、代理服务器与目标服务器。
  5. 连接成功但路径不对：检查运行模式、规则顺序、策略组选择与旧连接。
  6. 问题已恢复：恢复日常日志级别，保留本次有效修改与复现步骤。

一份有效的排查记录，应能回答“哪一个请求、经过哪条规则、在哪个阶段失败”。按这个顺序缩小范围，通常比批量替换配置更容易找到原因，也更方便在订阅更新或客户端升级后重新验证。

下载客户端