Clash 运行日志怎么看:常见报错含义与定位步骤

先判断日志记录的是哪一段连接

Clash、Clash Meta（mihomo）及其图形客户端通常会同时处理系统代理、DNS、规则匹配、节点连接、TUN 转发和订阅更新。日志里出现 error，不等于整个客户端已经停止工作；一条连接失败，也不等于当前节点完全不可用。定位时应先确认报错属于哪一层，再处理对应设置。

一条常见的连接日志通常包含时间、日志级别、入站类型、目标地址、匹配规则、策略组、实际节点和错误文本。不同客户端的排列方式略有差异，但核心信息相同。例如：

20:14:08 INF [TCP] 127.0.0.1:53142
--> api.example.com:443
match DomainSuffix(example.com)
using Proxy[HK-01]

20:14:13 ERR dial HK-01
198.51.100.20:443
dial tcp 198.51.100.20:443: i/o timeout

这段记录说明：本机程序从 127.0.0.1 发起 TCP 请求，目标是 api.example.com:443；域名命中一条后缀规则，策略组选择了 HK-01；随后 Clash 连接节点服务器 198.51.100.20:443 超时。问题发生在“本机到节点服务器”这一段，而不是目标网站主动拒绝访问。

读日志时固定提取五项信息

1. 时间点：报错是否与刚才的操作一致。先复现一次，再查看同一分钟内的记录。
2. 协议与入站：TCP、UDP、HTTP、SOCKS 或 TUN。部分问题只影响 UDP，网页仍可能正常打开。
3. 目标地址：确认日志中的域名或 IP 是节点服务器、订阅地址、DNS 服务器，还是最终网站。
4. 规则与策略：检查连接命中了哪条规则，以及策略组最后选择了 DIRECT、REJECT 还是具体节点。
5. 错误末尾：Go 网络错误通常把最具体的原因放在最后，例如 i/o timeout、connection refused 或 no such host。

info、warning、error 分别表示什么

日志级别描述的是事件严重程度，不直接等同于处理优先级。后台健康检查产生的 error 可能只影响一个备用节点；一条 info 级规则记录却可能直接说明当前网站被 REJECT 规则拦截。应把级别与目标地址、策略结果一起阅读。

正常日志里也会出现失败记录

浏览器可能同时尝试 IPv4、IPv6、HTTP/3 和普通 HTTPS。某一路连接失败后，浏览器可能立即切换到另一条路径，因此页面仍能打开。节点健康检查也会定时访问测试地址；某个节点超时只表示该次检查未完成，不代表当前正在使用的节点中断。

判断是否需要处理，可以观察三个信号：相同错误是否连续出现；错误对应的目标是否正是无法访问的服务；切换节点或关闭某项功能后，错误是否立即消失。只出现一次、没有可见影响的后台错误可以先记录，不必同时修改多个配置项。

dial tcp timeout：连接在规定时间内没有完成

dial tcp ...: i/o timeout 表示 TCP 连接在超时时间内没有建立。若错误中的地址是节点服务器 IP，优先检查本机到节点的网络；若地址是最终网站，则检查代理节点到目标站点的路径。超时与“端口明确拒绝”不同：远端没有在规定时间内返回可用响应。

常见原因

• 节点服务器暂时离线，或节点端口已变更。
• 当前 Wi-Fi、移动网络或上游路由无法到达该服务器。
• 防火墙丢弃了特定端口的流量。
• IPv6 路由不可用，但节点域名优先解析到 AAAA 记录。
• TUN 接口路由形成回环，节点连接又被送回 Clash。
• 节点可连接，但 TLS 握手或后续传输持续超时。

按顺序执行四次对照

1. 在客户端节点列表中切换到另一个节点，再重复相同请求。如果新节点正常，问题集中在原节点或原节点线路。
2. 切换网络，例如从家庭 Wi-Fi 改为手机热点。若同一节点恢复，检查路由器、防火墙和当前运营商线路。
3. 暂时关闭 TUN，只保留系统代理，再访问相同地址。系统代理正常而 TUN 超时，重点检查路由、DNS 劫持和接口选择。
4. 查看超时地址。节点 IP 超时与目标域名超时是两条不同路径，不要只根据网页名称判断。

Clash 常见本地代理端口包括 HTTP 端口 7890、SOCKS 端口 7891，也可以统一使用 mixed-port: 7890。这些数字可以被配置修改。排查前应在客户端「设置」→「端口设置」或「设置」→「参数设置」中确认实际值，并核对系统代理是否引用了同一端口。

connection refused：地址可达，但端口拒绝连接

connect: connection refused 或 dial tcp ...: connect: connection refused 通常表示数据已经到达目标主机，但指定端口没有服务监听，或防火墙主动返回拒绝。它往往比 timeout 更快出现。

ERR dial tcp 127.0.0.1:7890:
connect: connection refused

ERR dial tcp 203.0.113.8:443:
connect: connection refused

第一条指向 127.0.0.1:7890，说明本机应用尝试连接本地代理端口，但该端口没有可用监听。可能是 Clash 内核未启动、端口已经改成其他值，或客户端只启用了 SOCKS 端口。第二条指向远端 IP，通常是节点端口配置错误、节点服务停止，或服务器防火墙主动拒绝。

本地端口拒绝时检查这些位置

• 确认客户端状态页显示内核正在运行，而不是停留在启动失败状态。
• 进入「设置」→「端口设置」，核对 HTTP、SOCKS 和 Mixed Port 的实际数字。
• 在浏览器或应用的手动代理设置中，将地址设为 127.0.0.1，端口与 Clash 当前监听值保持一致。
• 如果配置使用 mixed-port: 7890，HTTP 与 SOCKS 客户端都可连接该端口；不要再假定 7891 必然启用。
• 检查日志前部是否出现 bind: address already in use。这表示端口被其他进程占用，内核无法监听。

远端端口拒绝时怎么处理

先更新订阅，再确认节点服务器地址和端口是否变化。若只有一个节点报错，直接切换节点并记录故障项；若同一订阅中的全部节点都被拒绝，应检查订阅是否过期、配置是否仍引用旧服务器，以及网络是否通过透明网关改写了连接。

DNS 解析失败：先区分域名问题与连接问题

常见 DNS 错误包括 no such host、DNS request failed、server misbehaving、context deadline exceeded。DNS 失败发生在把域名转换为 IP 的阶段。若日志已经显示正在连接一个明确 IP，例如 198.51.100.20:443，后面的 timeout 通常不是该次连接的域名解析失败。

三类 DNS 故障要分开处理

mihomo 的 DNS 配置可以区分用于解析节点域名的默认服务器和处理普通查询的 nameserver。下面是一份用于理解结构的精简示例，实际地址应按当前网络环境调整：

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query

default-nameserver 使用 IP 地址，主要用于解析 DoH 服务器或代理节点自身的域名，避免“解析 DNS 服务器之前还需要先解析 DNS 服务器”的依赖循环。listen: 0.0.0.0:1053 是 Clash DNS 监听地址，不代表系统会自动把所有查询发送到该端口；TUN 模式通常还需要 DNS 劫持配置。

Fake-IP 模式下的特殊现象

Fake-IP 会向应用返回映射地址，并在 Clash 内部保留原始域名，以便规则匹配。日志中看到 198.18.0.0/16 范围的地址，通常是映射结果，不应把它当作真实网站服务器。若某个局域网设备、游戏或企业应用不兼容 Fake-IP，可以针对域名设置过滤，或对照测试 redir-host 模式；不要仅因出现映射地址就判定 DNS 损坏。

TLS、EOF 与 context deadline exceeded 怎么看

TLS handshake timeout

TLS handshake timeout 表示 TCP 可能已经建立，但 TLS 握手未在时限内完成。常见原因包括线路丢包、节点过载、中间设备干扰和 MTU 不合适。先切换节点和网络；若只在 TUN 下出现，可把 MTU 从常见的 1500 对照调整到 1400 或 1280，并逐次测试。不要一次同时修改 MTU、DNS 和代理协议，否则无法判断哪一项产生效果。

x509 certificate 错误

x509: certificate has expired 表示证书已过期；x509: certificate is valid for ... 表示证书域名与连接目标不匹配；certificate signed by unknown authority 表示证书链不受当前环境信任。首先确认系统日期、时间和时区准确，再检查节点域名、SNI 或 server name 配置。随意关闭证书验证会掩盖配置错误，不适合作为长期处理方式。

EOF 与 unexpected EOF

EOF 表示连接对端结束了数据流。单次 EOF 可能来自服务正常断开；如果每次请求都在同一阶段出现，通常需要检查协议参数、节点服务状态或中间网络设备。unexpected EOF 更强调连接在预期数据读取完成前中断，切换节点是最快的对照方法。

context deadline exceeded

这是通用的操作超时提示，单独看无法确定发生在 DNS、节点拨号、健康检查还是订阅下载。应查看同一行前面的操作名称，以及前后 5 至 10 行日志。如果它紧跟 proxy provider，问题多半是订阅或 provider 更新超时；如果紧跟 DNS 请求，则检查上游 DNS；如果跟在节点地址后面，则按连接超时处理。

端口占用、配置错误与内核启动失败

如果日志窗口只有几行，客户端随后停止运行，重点通常不是节点质量，而是内核未完成启动。配置语法错误和监听端口冲突是最常见的两类原因。

address already in use

listen tcp 127.0.0.1:7890:
bind: address already in use

这表示已有进程占用 7890。可能是另一个代理客户端、上一次未退出的内核进程，或本机开发服务。先完全退出其他代理程序，再重启客户端；如果仍然冲突，可在「设置」→「端口设置」把 Mixed Port 临时改为 7892，同时把系统代理端口改为相同数字。只修改 Clash 端口而不更新系统代理，会导致浏览器继续访问旧端口并出现 connection refused。

配置解析错误

YAML 对缩进和数据类型敏感。日志可能显示具体行号，例如 yaml: line 42: did not find expected key。先检查该行及其上一行，确认缩进使用空格、冒号后有空格、列表项以 - 开始。策略组引用的节点名也必须与实际名称一致。

mixed-port: 7890
mode: rule

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - HK-01
      - DIRECT

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

如果订阅更新后立即启动失败，先在客户端「配置」→「配置文件」切换回上一份可用配置，再对新配置执行语法检查。不要直接在未知问题的配置上连续改动十几处。每次只改一项，保存、重载并观察第一条 error。

TUN 模式日志的定位重点

TUN 模式接管的流量范围比系统代理更广，因此会暴露 UDP、局域网、系统服务和不遵循代理设置的应用连接。开启 TUN 后日志数量明显增加属于正常现象，真正需要关注的是持续重试、路由回环、接口创建失败和 DNS 劫持异常。

常见 TUN 问题

• operation not permitted：创建接口或修改路由所需权限不足。检查客户端权限和 TUN 服务安装状态。
• network is unreachable：当前路由表中没有到目标的可用路径，常见于失效的 IPv6 或错误接口选择。
• device or resource busy：TUN 设备正被另一个实例或其他 VPN 使用。
• 循环连接：节点服务器流量再次进入 TUN，日志中同一目标高速重复。检查自动路由、接口检测和节点地址排除逻辑。
• UDP timeout：可能只影响游戏、语音或 QUIC，不一定影响普通 TCP 网页。

系统代理与 TUN 的二分测试

1. 记录当前配置，并确认规则模式、节点和 DNS 设置不变。
2. 关闭 TUN，只开启系统代理，测试浏览器和订阅更新。
3. 重新开启 TUN，关闭系统代理，再测试同一目标。
4. 若只有 TUN 失败，查看接口权限、自动路由、MTU、DNS 劫持和其他 VPN。
5. 若两种模式都失败，回到节点、DNS、规则和本地端口继续排查。

Android 上还要确认系统 VPN 权限没有被另一款 VPN 应用占用，并在系统「设置」→「应用」→「Clash 客户端」→「电池」中允许符合使用需求的后台运行策略。Windows 上出现 TUN 接口创建失败时，应检查客户端的服务模式或管理员权限；macOS 上则需确认系统设置中的网络扩展授权状态。

规则命中正确，但网站仍无法访问

日志中出现 match、using 或规则名称，只表示 Clash 已经做出策略选择，不表示后续连接成功。需要继续看同一连接之后是否出现 dial、TLS 或 DNS 错误。

先核对策略结果

• 命中 DIRECT：连接绕过代理。若目标需要通过节点访问，应检查规则顺序和域名匹配方式。
• 命中 REJECT：Clash 按规则主动阻止连接。检查广告过滤或自定义规则是否误匹配。
• 命中策略组：继续确认策略组实际选中的节点，而不是只看组名。
• 命中 MATCH：前面的具体规则都未匹配，连接进入最终兜底策略。

Clash 规则按从上到下的顺序匹配，通常在第一次匹配后停止继续检查。具体域名规则应放在宽泛规则之前，MATCH 应作为末尾兜底。例如：

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

如果 MATCH,DIRECT 被放在列表前部，后面的域名规则不会得到预期执行。修改后应重载配置，并在日志中确认新连接命中了目标规则。已经建立的旧连接可能继续使用原策略，测试时应关闭对应应用或等待旧连接结束。

一套可重复执行的日志排查流程

有效排查依赖对照，而不是同时更换配置、节点、DNS 和网络。下面的流程适用于网页打不开、订阅更新失败、节点测速超时和 TUN 无网络等常见问题。

1. 记录环境：写下客户端版本、内核类型、当前网络、代理模式、是否开启 TUN，以及实际监听端口。
2. 清空日志：进入「日志」或「设置」→「日志」，将级别设为 info；需要更细信息时再临时切换 debug。
3. 只复现一次：执行一个明确操作，并记住准确时间。
4. 找到目标：按域名、IP、端口或策略组名称筛选记录。
5. 定位层级：判断失败发生在本地端口、DNS、规则、节点拨号、TLS、目标服务还是 TUN 路由。
6. 做一次对照：只切换一个变量，例如节点、网络、TUN 状态或 DNS 上游。
7. 验证结果：再次清空日志并复现，确认原错误消失且没有转变成新的错误。

提交日志前需要整理哪些信息

向客户端维护者、订阅提供方或网络管理员反馈时，完整环境信息比一张“连接失败”截图更有价值。建议附上客户端名称与版本、mihomo 内核版本、操作系统版本、代理模式、TUN 状态、故障发生时间、复现步骤和相关日志片段。

日志可能包含访问域名、节点名称、服务器 IP、本机局域网地址和配置路径。分享前应隐藏订阅 URL、认证信息、用户名、密码与访问令牌。不要删除错误前后的全部上下文；保留目标连接前后各 10 至 20 行，通常足以判断规则选择和失败阶段。

适合反馈的简要格式

客户端：名称与版本
内核：mihomo 版本
系统：系统名称与版本
模式：Rule / TUN 已开启
端口：mixed-port 7890
现象：浏览器访问指定域名超时
时间：20:14:08
对照：切换节点后恢复
错误：dial tcp ...: i/o timeout

日志排查的核心是先识别连接阶段，再做单变量对照。timeout 指向未及时完成，refused 指向端口明确拒绝，DNS 错误发生在域名解析，规则日志只说明策略选择，TUN 错误则需要额外检查权限与路由。沿着“本地应用 → Clash 入站 → DNS 与规则 → 节点 → 目标服务”的路径逐段验证，通常可以把问题缩小到一个可操作的配置项或网络环节。