Clash 运行日志怎么看：常见报错含义与定位顺序

先确定日志来源与时间范围

Clash 客户端中的“日志”可能来自两个不同层级：图形客户端负责订阅下载、配置切换、内核启动和系统代理设置；Clash Meta（mihomo）等内核负责 DNS、规则匹配、连接建立、策略组选择与 TUN 数据处理。两类日志混在一个窗口时，必须先看报错发生在哪一层。

例如，订阅请求返回 403 通常属于客户端的配置更新流程；而某个域名命中规则后连接超时，则属于内核运行阶段。只截取最后一行容易把结果当成原因。正确做法是从故障发生时间向前查看，找到第一条异常，以及异常之前最后一条正常记录。

日志行通常包含哪些信息

• 时间：用于把用户操作与日志对应起来，例如点击更新订阅、切换节点或启用 TUN 的准确时刻。
• 级别：debug 提供详细过程，info 记录正常状态，warn 表示需要关注但不一定中断，error 表示当前步骤失败。
• 模块：常见模块包括配置加载、DNS、入站监听、代理拨号、规则匹配和 TUN。
• 目标：可能是域名、IP、端口、网络接口、配置文件路径或策略组名称。
• 错误链：一条错误可能由多个短语连接，通常从左到右描述执行过程，最末端是操作系统或网络库返回的直接原因。

排查前先复现一次最小故障：清空或记住当前日志位置，只执行一个动作，再保存这一小段日志。若问题是网页打不开，不要同时更新订阅、切换模式、修改 DNS 和更换节点。一次改变多个条件，会让日志中的因果关系失去参考价值。

启动与配置解析错误：先看文件，再看端口

内核无法启动时，后续 DNS、规则和节点测试都没有意义。此阶段应先确认配置文件能否读取和解析，再检查监听端口、控制端口、文件权限及资源文件。图形界面显示“启动失败”只是汇总状态，真正原因通常位于它前面的数行。

配置语法与字段错误

常见信息包括 yaml、unmarshal、invalid config、field not found 或某一行列的位置。YAML 对缩进敏感，Tab、层级错位、未闭合引号和列表格式错误都会阻止加载。下面的规则必须位于列表层级中：

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

若日志指出未知字段，还要核对配置面向的内核类型和版本。Clash Meta（mihomo）支持的部分字段并不属于旧版 Clash 配置能力，反向情况也可能发生。不要仅因文件扩展名是 .yaml 就判断兼容；应查看字段名称、代理协议、规则集写法和 DNS 配置结构。

端口已被占用

address already in use 表示指定监听地址与端口已被其他进程占用。常见对象是 mixed-port、port、socks-port 或 external-controller。这通常发生在旧内核没有退出、另一款代理工具正在运行，或两个配置同时监听相同端口时。

处理顺序是：先确认是否存在重复的 Clash 或 mihomo 进程，再检查其他代理软件，最后才考虑修改端口。修改后还应同步更新浏览器、终端环境变量或局域网设备中填写的代理端口，否则内核虽然启动，应用仍会连接旧端口。

权限与文件路径问题

permission denied 需要结合目标路径判断。访问配置目录失败，通常与目录权限或文件被占用有关；创建 TUN 接口失败，则可能与管理员权限、系统扩展或网络服务权限有关。no such file or directory 往往指向配置引用的规则集、GeoIP 数据库或证书文件缺失。此时应核对日志中的完整路径，不要只检查当前打开的主配置文件。

订阅更新错误：区分下载失败与解析失败

订阅更新由“发出请求、获得响应、识别内容、生成配置、加载配置”组成。界面最终都可能显示更新失败，但每个阶段的处理方法不同。首先记录 HTTP 状态、响应类型和解析信息，再决定检查网络、订阅权限还是格式兼容性。

浏览器能够打开订阅地址，不等于客户端一定能更新。浏览器和客户端可能使用不同的网络路径、User-Agent、DNS 结果或代理设置。排查时应关注客户端实际记录的状态码与响应，而不是只依据浏览器页面。

还要区分“订阅内容为空”和“配置中没有可用节点”。某些订阅返回的是完整 Clash 配置，包含 proxies、proxy-groups 和 rules；另一些只提供通用节点列表，需要客户端转换。若转换器不认识协议字段，可能只生成部分节点，甚至无法生成策略组。此时应保留原始响应类型的判断信息，并核对订阅是否明确提供 Clash 或 Mihomo 格式。

DNS 错误：判断是解析失败还是连接失败

DNS 日志经常出现在连接错误之前，但域名无法访问不一定都是 DNS 问题。应先判断日志是否取得目标 IP：如果出现明确的解析超时、上游不可达或空响应，问题位于 DNS 阶段；如果已经得到 IP，随后才出现拨号超时或 TLS 错误，则应继续检查代理链路。

常见 DNS 日志含义

• no such host：系统解析器或指定上游未返回可用地址，也可能是域名本身拼写错误。
• i/o timeout：向 DNS 上游发送查询后没有按时收到响应，需要检查上游地址、网络路径和防火墙。
• connection refused：目标 DNS 服务地址可达，但相应端口没有接受连接，或本机转发服务没有运行。
• server misbehaving：上游响应异常，可能涉及协议不兼容、响应格式问题或中间网络干扰。
• fake-ip 相关记录：说明域名进入 Fake-IP 映射流程，本身不代表错误，应继续查看后续规则匹配与真实连接结果。

在 Fake-IP 模式下，应用先得到保留地址范围中的映射 IP，内核再根据映射恢复域名并执行规则。看到目标地址属于 Fake-IP 范围时，不应直接把它当成远端服务器地址。若某些局域网服务、时间同步、游戏或特殊协议工作异常，可以检查 fake-ip-filter 是否需要排除对应域名，但不宜将大量域名无条件加入过滤列表。

开启 TUN 后，DNS 还可能经过劫持与重定向。此时系统设置中显示的 DNS 服务器，不一定等于最终使用的上游。排查要同时确认 Clash 的 dns.enable、监听地址、nameserver、fallback 或策略型 DNS 配置，以及 TUN 的 DNS 劫持设置。若端口 53 已被本地解析服务占用，日志通常会在启动阶段给出监听失败，而不是等到访问网页时才出现。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

上例仅用于展示字段关系，实际配置应依据当前网络和内核文档选择上游。修改 DNS 时一次只改一项，并用同一域名重复测试。若同时切换增强模式、上游协议和 TUN 劫持，日志变化将难以归因。

连接、握手与超时错误：沿代理链逐段检查

当规则已经选出策略和节点，内核会连接代理服务器，再由代理服务器访问目标。日志里的超时可能发生在本机到节点、节点到目标、代理协议握手或 TLS 握手任一阶段。判断关键是找到错误前的出站名称、目标地址与网络类型。

connection refused

拒绝连接表示目标主机明确返回端口不可用。若目标是代理节点地址，应检查节点端口、服务状态与协议配置；若目标是本机控制端口，则检查客户端连接的控制地址是否正确。它与超时不同：超时通常没有及时响应，拒绝则说明网络已到达某个主机，但该端口未接受连接。

i/o timeout 与 context deadline exceeded

这类信息表示操作超过时间限制。先切换到已知可用的节点，再测试同一目标。如果多个节点同时超时，应检查本地网络、DNS、系统防火墙和代理模式；只有单个节点超时，则优先检查该节点线路。若普通网页可用而特定站点超时，再查看规则是否将该域名分配给了不合适的策略。

EOF、连接重置与 TLS 握手失败

EOF 表示连接在预期数据完成前被关闭，单独一条信息不足以确定原因。它可能来自远端主动断开、代理协议参数不匹配、传输层配置差异或中间网络重置。connection reset by peer 则更明确地表示对端或链路设备重置连接。

TLS 错误需要关注系统时间、证书域名、SNI、节点传输配置和目标站点。若日志显示证书名称不匹配，不应通过长期关闭证书验证来掩盖问题，而应核对服务器名称与节点参数。系统时间偏差也会导致证书尚未生效或已经过期的判断异常。

UDP 与 TCP 表现不同

节点能够打开网页，只能证明主要的 TCP 路径可用。语音、游戏、QUIC 或部分 DNS 请求依赖 UDP。如果日志在 UDP 连接处失败，应确认节点协议与服务端是否支持 UDP、策略组是否选择了相应节点，以及系统防火墙是否允许相关流量。排查时可暂时让应用回退到 TCP，用于判断故障是否只存在于 UDP 路径，但最终仍应修正实际配置。

规则匹配、代理模式与 TUN：日志正常也可能路径错误

有些故障没有明显的 error。连接成功，却走了错误节点或意外直连，通常属于规则、模式或流量接管范围问题。此时应把日志级别临时调整为 debug，观察域名、进程、规则类型、策略组和最终出站之间的关系，完成测试后再恢复常用级别，避免日志量持续增长。

先确认当前代理模式

• 规则模式：按规则从上到下匹配，命中后使用指定策略。大多数精细分流问题都应在此模式下排查。
• 全局模式：流量统一交给全局策略，规则列表通常不参与常规分流。测试节点连通性时有用，但不能验证规则是否正确。
• 直连模式：流量直接连接目标。若忘记切回规则模式，节点状态正常也不会产生预期的代理连接。

规则模式下，顺序比规则数量更重要。例如宽泛的 DOMAIN-SUFFIX 放在精确规则之前，可能提前截获目标；GEOIP、GEOSITE、规则集与最终 MATCH 的位置也会改变结果。日志若显示命中了意外规则，应回到配置中搜索该规则，并检查它前面的覆盖范围，而不是只修改最终策略组。

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

以上顺序会让 api.example.com 先直连，其他 example.com 子域名再进入代理。若两条规则对调，精确规则将没有机会命中。

TUN 已开启但应用没有进入日志

如果应用发起请求时日志完全没有对应连接，问题通常位于流量进入内核之前。检查 TUN 接口是否创建成功、默认路由是否安装、自动路由设置是否生效，以及其他 VPN、虚拟网卡或安全软件是否改变了路由优先级。某些应用还可能使用独立代理设置，此设置若指向旧端口，也会绕开当前 TUN 路径。

日志出现 operation not permitted、创建接口失败或路由添加失败时，应检查运行权限和系统网络能力。Linux 环境还需关注 TUN 设备、网络管理器、路由表与服务账户权限；Windows 和 macOS 则应查看虚拟网卡、系统扩展或管理员授权状态。不同客户端封装方式不同，判断应以日志中实际失败的系统操作为准。

可复用的定位顺序：从第一处异常到配置项

稳定的排查流程应从底层状态逐步走向具体请求。跳过启动状态直接更换节点，或看到 DNS 字样就重写整个 DNS 配置，通常会增加变量。下面的顺序适用于“无法启动、订阅更新失败、网页打不开、只有部分应用异常”等常见场景。

1. 记录故障边界。明确是所有网站、单个域名、某个应用、TCP、UDP，还是仅在 TUN 开启后发生。
2. 确认内核已运行。检查配置是否加载成功，代理端口与控制端口是否监听，是否存在权限或文件缺失错误。
3. 确认配置来源。如果刚更新订阅，先判断下载是否成功、响应是否为正确格式，以及新配置能否解析。
4. 确认请求进入内核。执行一次可重复测试，在对应时间查看是否出现连接记录。没有记录时检查系统代理、应用代理与 TUN 路由。
5. 确认 DNS 结果。查看域名是否完成解析，Fake-IP 映射是否符合当前模式，DNS 上游是否超时。
6. 确认规则与策略。核对当前模式、命中规则、策略组和实际节点，避免把错误分流误判为节点故障。
7. 确认连接阶段。区分本机到节点、协议握手、TLS、节点到目标及 UDP 路径，按阶段替换单一条件测试。
8. 回退最近改动。恢复上一个可用配置，再逐项应用 DNS、TUN、规则或节点改动，找出引入故障的最小差异。

一份有效的排查记录至少应包括：客户端与内核名称、操作系统、故障时间、当前模式、是否启用 TUN、复现动作、第一条异常日志、命中的策略以及已经测试的单一变量。版本号也很重要，因为字段支持范围、默认行为和错误文本会随内核与客户端更新而变化。

日志判断的核心不是收集尽可能多的错误行，而是建立执行顺序：配置先被读取，端口随后监听，订阅产生配置，DNS 提供目标，规则选择策略，节点建立连接，TUN 决定更多应用流量是否进入内核。把每条日志放回这一条链路，就能从模糊的“Clash 不能用”收敛到具体字段、端口、上游或网络接口。