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

LOG LAYERS

先判断日志来自哪一层

Clash 客户端出现“连接失败”时，界面提示通常只是最终结果，运行日志才会记录失败发生在哪个阶段。开始分析前要先区分三层信息：客户端界面层、代理核心层和操作系统网络层。客户端负责配置管理、托盘菜单和系统代理开关；Clash、Clash Meta 或当前使用的 mihomo 核心负责监听端口、解析规则、建立代理连接和处理 DNS；操作系统则管理网卡、路由、防火墙、权限以及本地端口。三层中的任何一层失败，都可能在界面上表现为“无法连接”。

不同客户端对同一条核心日志的显示形式可能不同。有的保留时间、日志级别和模块名称，有的只展示消息正文。mihomo 版本更新后，字段名称与措辞也可能变化。因此不要只搜索一整句报错，应提取其中稳定的对象，例如配置文件路径、监听地址、端口号、域名、节点名称、网络类型和系统错误。

单独出现 warning 或 error 不一定代表所有代理流量都已中断。例如某个节点连接超时，只影响当次连接或对应策略组；一个备用 DNS 服务器失败，也可能由其他服务器完成查询。判断影响范围时，要同时查看错误对象、发生频率和后续是否出现成功记录。

REPRODUCE FIRST

按时间顺序复现问题

有效的日志分析需要明确的复现过程。不要在客户端连续运行数小时后，从混合了配置更新、延迟测试和后台程序连接的记录中猜测原因。更可靠的方法是清空当前日志或记下起始时间，然后只执行一个触发问题的动作。这样可以把用户操作与日志时间对应起来。

1. 记录当前环境。确认客户端名称、核心类型、操作系统、当前配置文件、代理模式以及是否启用 TUN。刚完成客户端或核心更新时，也要记下更新前后状态。
2. 停止无关测试。暂时关闭自动测速、配置自动更新和会持续产生连接的程序，减少日志噪声。
3. 从较低日志量开始。先使用 info 级别复现；如果只能看到连接失败结果，再临时切换到 debug。问题定位后恢复常用级别，避免日志快速增长。
4. 只执行一个动作。例如更新一次订阅、打开一个确定的网页、切换一次节点，或者单独启用 TUN。
5. 定位第一条异常。从操作发生的时间点向下查看，找到最早的 warning、error 或明显超时，再检查它前面的配置与路由信息。
6. 修改一个变量后重试。每轮只更换节点、端口、DNS 或运行模式中的一项，否则无法确认是哪项修改生效。

日志中的时间顺序比错误数量更有价值。假设先出现配置解析失败，随后出现控制端口连接失败，最后界面提示核心未运行，那么根因通常是第一条配置错误，而不是最后的控制端口错误。又如 TUN 初始化失败之后，应用仍能通过系统代理访问网络，说明代理核心可能正常，只是透明接管路径没有建立。

启动客户端
→ 读取配置
→ 初始化 DNS 与规则
→ 监听本地代理端口
→ 初始化 TUN（如启用）
→ 接收应用连接
→ 匹配规则
→ 选择节点
→ 建立远端连接

可以把这条链路当成检查顺序。错误发生在哪一步，就先处理该步骤以及它依赖的前置步骤，不要直接跳到更换节点或重装客户端。

CONFIG PARSER

配置解析与核心启动错误

配置错误通常发生在核心正式监听端口之前。常见关键词包括 parse、yaml、unmarshal、invalid config、field、duplicate 和 not found。这类错误出现时，继续测试节点或系统代理没有意义，因为核心可能尚未加载出可运行的配置。

YAML 结构无法解析

YAML 依赖缩进表达层级。使用 Tab、列表项层级不一致、冒号后缺少空格、引号没有闭合，都会导致解析停止。日志一般会给出行号和列号，但实际问题也可能位于提示行之前，例如上一行字符串没有结束，解析器到下一行才发现结构不合法。

proxies:
  - name: Example
    type: ss
    server: example.test
    port: 443

proxy-groups:
  - name: SELECT
    type: select
    proxies:
      - Example

检查时先确认缩进全部使用空格，再查看报错行前后数行。节点名称包含冒号、井号或其他具有 YAML 语义的字符时，应由配置提供方正确引用。手动编辑过配置后出现错误，可以先回退修改，验证原始配置能否加载。

字段存在但当前核心不支持

Clash 配置并不是所有核心版本都完全通用。某些字段只由 mihomo 支持，旧核心读取时可能报告未知字段、类型错误或缺少必要参数。反过来，客户端更新核心后，过时字段也可能触发警告。此时要确认客户端实际调用的核心，而不是只看客户端产品名称。配置适用于 mihomo 时，应使用支持相应语法的客户端与核心版本。

引用对象不存在

策略组引用了不存在的节点、规则指向未定义的策略组、规则集合路径无法读取，都会造成加载失败或部分功能不可用。重点对照错误中的对象名称，检查大小写、空格和全角字符。名称必须精确匹配；看起来相同的前后空格也可能造成引用失败。

LISTENER STATUS

端口占用与系统代理错误

端口错误的典型关键词是 address already in use、bind、listen、permission denied 或 connection refused。Clash 核心通常需要监听 HTTP、SOCKS、混合端口或外部控制端口。如果另一个核心实例、旧客户端进程或其他网络工具已经占用相同地址，新进程就无法完成监听。

address already in use 表示指定地址与端口已经被其他进程占用。先退出所有同类客户端，再检查任务管理器或系统进程列表中是否仍有核心进程。不要仅关闭窗口，因为部分客户端会继续在托盘运行。确认没有残留进程后重新启动；如果端口仍被占用，再修改为未使用端口，并同步更新依赖该端口的浏览器或应用设置。

permission denied 要结合监听位置判断。普通本地高位端口通常不需要特殊权限，但系统安全策略、防火墙规则或受限制的运行目录仍可能阻止操作。若日志提到的是 TUN、路由或服务注册，则属于系统权限问题，不应通过反复更换代理节点处理。

connection refused 的方向也很重要。客户端界面连接外部控制端口被拒绝，常表示核心没有启动、控制地址不一致，或核心已经退出；代理核心连接远端服务器被拒绝，则表示目标地址可达，但对应远端端口没有接受连接。两者包含相同措辞，故障位置却完全不同，要看日志中的源地址、目标地址和模块名称。

系统代理开启失败不等于核心端口没有工作。可以先确认日志中本地代理监听成功，再检查操作系统代理设置是否已指向对应端口。如果手动配置的浏览器可以连接，而普通应用不能连接，问题更可能位于系统代理设置、应用是否遵循系统代理，或应用自身的网络配置。

DNS PIPELINE

DNS 查询与解析异常

DNS 问题常表现为网页提示找不到域名、部分站点可用而部分站点失败、TUN 启用后所有域名连接超时，或日志反复出现 lookup、resolve、no such host、timeout、SERVFAIL。分析时先区分“域名没有得到地址”和“已经得到地址但后续连接失败”。如果日志已经显示目标 IP 并进入拨号阶段，根因通常不再是最初的域名解析。

传统 DNS、DNS over HTTPS 与 DNS over TLS 的依赖不同。加密 DNS 服务器本身使用域名时，核心可能需要通过 bootstrap 或默认解析器先得到服务器地址。这个前置解析失败，就会造成后续所有查询无法发送。日志中若反复对 DNS 服务器域名进行查询并超时，应检查默认解析器、网络可达性以及配置中的 nameserver-policy，而不是只更换代理节点。

Fake IP 模式下，应用先收到保留地址，核心再依据内部映射恢复原始域名并执行规则匹配。看到保留地址不代表解析错误。真正需要关注的是映射是否存在、目标域名是否被正确接管，以及某些不适合 Fake IP 的局域网域名或设备发现域名是否需要过滤。Redir Host 模式则直接向应用返回解析结果，故障日志的表现会有所不同。

DNS 超时的定位顺序

1. 确认配置能够正常加载，DNS 模块已经初始化。
2. 查看失败的是所有服务器，还是某一个备用服务器。
3. 确认查询使用直连还是代理路径，相关策略是否形成循环依赖。
4. 检查 DNS 服务器的地址与协议格式是否被当前核心支持。
5. 关闭 TUN 后使用系统代理重试，判断问题是否只存在于接管路径。
6. 查看域名解析成功后是否继续出现 TLS、连接超时或路由失败。

TUN DEVICE

TUN 模式启动失败

TUN 模式通过虚拟网卡和系统路由接管更多应用流量，涉及权限、驱动、网络接口和路由表，因此它的错误范围比普通系统代理更广。常见关键词包括 tun、interface、route、adapter、device、service 和 operation not permitted。

第一步是判断“核心整体失败”还是“只有 TUN 初始化失败”。如果本地 HTTP 或 mixed 端口已经监听成功，并且关闭 TUN 后系统代理可以工作，说明节点、规则和基础核心大概率可用，故障集中在虚拟网卡路径。此时应检查客户端要求的服务组件、运行权限以及系统中其他 VPN、虚拟机或网络过滤工具。

出现接口创建失败时，先彻底退出其他可能创建虚拟网卡的程序，再重启客户端。出现路由添加失败时，检查是否存在同网段冲突、旧路由残留或权限不足。日志若指出找不到指定网络接口，则可能是配置中固定了已经变化的接口名称；笔记本从有线切换到无线、网络设备重装后，接口标识可能发生变化。

macOS、Windows 和 Linux 的 TUN 实现与权限模型不同，不能直接套用另一平台的处理命令。桌面客户端若提供服务模式或辅助服务，应先确认该组件状态正常。Linux 环境还要确认 TUN 设备与网络管理权限。无论在哪个平台，都应先用客户端自身提供的启停入口测试，不要同时叠加多个接管工具。

TUN 开启后断网但日志没有致命错误

这种情况要检查默认路由、DNS 接管和规则结果。若日志显示连接进入 DIRECT，但直连流量无法从正确接口发出，可能是出口接口自动识别失败。若所有域名查询超时，则先处理 DNS 路径。若只有局域网设备不可访问，则检查局域网网段是否被错误接管，以及私有地址规则是否按预期直连。

排查 TUN 时建议保留一个对照组：关闭 TUN，仅开启系统代理并访问同一目标。如果系统代理成功、TUN 失败，继续检查网卡与路由；如果两种模式都失败，再回到 DNS、节点和远端连接层分析。

OUTBOUND CONNECTION

连接失败、超时与 TLS 报错

核心完成规则匹配后，会通过选定的出站节点连接目标。此阶段的日志通常包含目标域名或 IP、端口、网络类型、策略组、节点名称和耗时。最重要的问题是：连接的是节点服务器，还是节点已经建立后继续连接目标站点。日志模块与地址可以帮助区分两段链路。

i/o timeout 或 context deadline exceeded

超时表示操作在限定时间内没有完成，但不能单独说明原因。节点服务器不可达、网络丢包、DNS 查询迟迟没有结果、目标站点不响应，都可能产生超时。先看超时对象：若是节点服务器地址，切换同订阅中的其他节点进行对照；若多个不同地区节点同时超时，优先检查本地网络、DNS 和防火墙；若只有特定目标失败，则查看规则结果和目标可达性。

connection reset by peer

该信息表示连接建立后被对端或链路中的设备重置。偶发一次可能是网络波动或服务端主动结束连接；持续发生则要核对节点协议、端口、传输层参数和服务器状态。不能仅凭 reset 判断是客户端故障。使用另一个节点访问相同目标，或使用同一节点访问不同目标，可以快速缩小范围。

TLS handshake timeout 与证书错误

TLS 握手超时常见于链路质量差、目标不可达或协议参数不匹配。证书错误还要确认系统日期和时区是否正确，因为错误时间会让有效证书被判断为尚未生效或已经过期。节点配置包含服务器名称、传输层安全参数时，应保持订阅下发内容完整，不要在不了解用途时手动删除。

network is unreachable 与 no route to host

这类日志指向路由层。可能是当前网络没有对应的 IPv4 或 IPv6 出口、TUN 路由未建立、指定接口不可用，或目标地址所在网络无法到达。如果日志显示尝试 IPv6 而本地网络没有稳定 IPv6，可以检查 DNS 结果和核心的地址选择；如果 IPv4、IPv6 均失败，则返回检查系统网络与路由。

RULE MATCH

规则匹配与流量去向

有时连接本身没有报错，但流量走向不符合预期，例如应代理的域名被直连，局域网地址被送入节点，或策略组选择了失效节点。这类问题要查看规则匹配日志，而不是只搜索 error。debug 或详细连接日志通常会展示目标、命中的规则和最终策略。

Clash 规则按配置顺序匹配，命中后通常停止继续检查。较宽泛的规则放在前面，可能覆盖后面的精确域名规则。最终的 MATCH 规则负责承接此前未命中的连接。如果日志显示命中了错误策略，应回到配置中查找该规则的位置、规则集合内容以及策略组当前选择。

策略组名称不等于实际节点。日志可能先显示某连接交给名为“自动选择”的策略组，再由该组选择具体节点。排查时既要看规则把连接送到了哪个组，也要看该组当时的实际选项。延迟测试成功只说明测试 URL 在测试时可达，不保证节点能访问所有目标，也不代表长连接始终稳定。

DIRECT 同样是一种明确的出站策略。命中 DIRECT 后失败，应检查本地网络、DNS 和目标站点，而不是期待代理节点解决。REJECT 则表示规则主动终止连接，日志中的拒绝属于配置预期结果。应用反复请求被 REJECT 的域名时，可能产生大量记录，但这并非核心异常。

INCIDENT CHECKLIST

日志收集与故障排查清单

需要向客户端维护者、订阅提供方或其他技术人员反馈时，日志应包含足够上下文，同时移除敏感信息。有效反馈不应只有一张“连接失败”截图，也不需要导出数小时的完整记录。保留复现动作前后几十秒的连续日志，通常更容易定位。

应一并记录的信息

• 操作系统及版本、客户端名称与版本、实际核心类型与版本。
• 当前使用规则模式、全局模式或直连模式，是否启用系统代理与 TUN。
• 问题出现前执行的动作，例如更新配置、切换节点、休眠恢复或升级客户端。
• 可重复的操作步骤，以及问题是持续发生还是偶发。
• 第一条异常前后的连续日志，而不是只截取最后一行。
• 关闭 TUN、切换节点或更换网络后的对照结果。

分享前应处理的内容

日志与配置可能包含订阅地址、认证参数、节点服务器地址、局域网设备地址、访问域名和本地文件路径。公开发布前应逐项检查并遮盖这些内容，但要保留错误类型、端口范围、协议类别和时间顺序。不要把所有地址替换成同一个值，否则会丢失“本地地址还是远端地址”“同一目标还是多个目标”等关键关系。

从现象到根因的固定顺序

1. 确认操作系统本身可以联网。
2. 确认配置解析完成，核心没有在启动阶段退出。
3. 确认本地代理端口与控制端口监听成功。
4. 确认 DNS 查询能够返回结果。
5. 启用 TUN 时，确认虚拟网卡与路由初始化成功。
6. 确认目标连接命中了预期规则与策略组。
7. 确认策略组选择了可用节点，并能连接节点服务器。
8. 最后再检查目标站点、TLS 握手和应用自身代理设置。

这套顺序的核心是先处理上游依赖。配置未加载时不测试端口，端口未监听时不检查应用代理，DNS 未完成时不判断目标连接，TUN 未建立时不把所有超时归因于节点。每次只改变一个条件，并保留修改前后的日志对照，通常比反复切换多项设置更快找到根因。