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

网页打不开时，先别连续更换端口、DNS 和代理节点。Clash 日志更适合用来回答三个具体问题：请求有没有进入内核、规则把请求交给了谁、连接在哪一步失败。沿着这条顺序检查，通常比搜一整行报错更容易缩小范围。

本文适用于 Clash 系列客户端及 Clash Meta（现名 mihomo）的常见排查流程。不同内核、版本和图形界面的日志格式会有差异；下文日志均为脱敏说明示例，域名和地址不代表可用服务。不能仅凭某个英文关键词就断定节点失效。

1. 打开内核日志，先保留一次完整失败记录

客户端里可能同时存在“应用日志”“内核日志”和“连接”页面。应用日志主要记录界面启动、配置下载和服务管理；内核日志才会涉及规则匹配、DNS 查询以及代理连接。连接页面则用于查看仍在活动的连接及其代理链。这三处信息相互补充，不是同一份记录。

用最少操作复现一次

进入客户端的“日志”或“内核日志”页面，记下当前时间、启用的配置文件和代理模式。菜单名称以当前客户端为准。
确认内核日志级别为 info。如果关键细节不足，临时调整为 debug，应用配置后再复现。
关闭其他持续联网的应用，只打开一个失败页面。记录点击时间，例如 14:32:08，观察随后约 10 秒的日志。
保留失败行及其前后各 5～10 行。排查结束后恢复 info，避免调试信息长期大量累积。

# 合并到当前配置的顶层，不要重复添加同名字段
log-level: info

通过订阅管理配置时，直接修改下载后的文件可能在下次更新时被覆盖。优先使用客户端提供的覆写或合并功能；如果只能编辑文件，先备份，再确认重载是否成功。配置解析失败时，新设置未必已经生效。

2. 日志级别与单行字段怎么读

日志级别表示记录的重要程度，不是网络质量评分。一个后台应用重试产生的 warning，不一定对应当前网页的故障；反过来，只有 info 也不能证明页面内容已成功加载。

级别	常见内容	排查用途
`debug`	更细的 DNS、连接和内部处理信息	短时间复现复杂故障，注意脱敏
`info`	常规运行状态、连接与规则记录	日常排查的起点
`warning`	连接失败、查询异常等警告	结合时间和目标判断是否相关
`error`	较严重的运行或配置问题	先检查是否影响内核启动或监听
`silent`	抑制日志输出	不适合收集故障线索

把一条记录拆成五个部分

time="2026-09-15T14:32:08+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> www.example.com:443 match DomainSuffix(example.com) using 网页代理[节点A]"

时间：14:32:08+08:00 用来对应刚才的操作，跨设备对照时还要注意时区。
协议：[TCP] 表示这条连接使用 TCP，不能据此推断 UDP 也正常。
来源：127.0.0.1:53124 是本机来源地址和临时端口，53124 不是需要填进代理设置的监听端口。
目标：www.example.com:443 是访问目标及目标端口，不一定是报错中最终拨号的节点地址。
匹配与出口：DomainSuffix(example.com) 是命中的规则，网页代理[节点A] 表示策略组与选中的节点。

这类信息行主要说明内核如何处理连接，不代表 TLS 握手、登录和页面资源都已完成。后面如果紧跟超时或握手错误，应继续读取，不能停在“已经命中代理”这一行。

3. dial tcp timeout：先识别超时发生在哪一段

level=warning msg="[TCP] dial 网页代理 (match DomainSuffix/example.com) 127.0.0.1:53124 --> www.example.com:443 error: dial tcp 203.0.113.20:443: i/o timeout"

dial tcp 表示建立 TCP 连接；i/o timeout 表示某一步等待超过了期限。有些记录会显示 connect: connection timed out，或者在上层包装成 context deadline exceeded。这些信息指向等待失败，但不能单独证明是 DNS、远端服务还是本地防火墙造成的。

重点看最后一个 IP 和端口

示例里目标是 www.example.com:443，实际拨号地址却是 203.0.113.20:443。如果后者对应节点的 server 和 port，先检查电脑到节点这一段；如果当前走 DIRECT，则应检查到目标站点的直连路径。使用链式代理时，还需要结合实际代理链判断中间跳。

核对节点配置：检查订阅是否过期，节点域名、端口和协议是否与服务端一致。不要把网页的 443 直接当成节点端口。
只换一个变量：保持规则和 DNS 不变，切换到另一个已知可用的节点，再访问同一目标。
比较网络：在允许的情况下切换手机热点。如果同一节点只在某个 Wi-Fi 下超时，优先排查该网络的出口限制。
检查本机路径：关注防火墙、其他 VPN、虚拟网卡和 TUN 路由冲突，不要一开始就关闭全部安全防护。

Windows 可在 PowerShell 中使用 Test-NetConnection 检查 TCP 可达性。下面的地址属于文档示例地址，实际测试应改用节点配置中的真实主机和端口，不要测试示例本身。

Test-NetConnection -ComputerName 203.0.113.20 -Port 443

TcpTestSucceeded 为真，只说明这次 TCP 连接建立成功；它不能验证代理协议、凭据或 UDP 转发。节点延迟测试也类似：某个测试网址成功，不代表所有业务域名都能访问。

4. connection refused：检查被拒绝的是本地端口还是远端端口

dial tcp 127.0.0.1:7890: connect: connection refused

connection refused 通常表示连接收到明确拒绝，常见原因是目标端口没有服务监听，也可能是防火墙主动拒绝。它与超时不同：超时是迟迟没有得到预期结果，拒绝则往往更快返回。

地址是 127.0.0.1：检查代理监听

如果报错来自浏览器、命令行或其他应用，且地址是 127.0.0.1:7890，先确认内核已运行，以及实际监听端口确实为 7890。客户端可能改用了 7897，而系统代理仍保留旧值。不要用来源临时端口去替换这里的端口。

# 当前配置的相关字段示例；端口需与应用里的设置一致
mixed-port: 7890
allow-lan: false

mixed-port 同时接收 HTTP 与 SOCKS5 代理连接。填写应用代理时仍要选对协议，不能因为端口混合就任意填写。Windows 可查看监听状态；macOS 和 Linux 可使用对应的端口检查命令：

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen

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

# Linux
ss -lntp 'sport = :7890'

地址是远端节点：核对服务端监听与订阅

若被拒绝的是节点 IP 与节点端口，重点检查服务端是否仍在监听、端口是否变更、订阅是否更新。反复修改本机 mixed-port 不会修复远端端口拒绝。若启动日志出现 address already in use，则是本机端口被占用：应先找出占用进程，再决定停用冲突服务还是统一更换端口。

5. DNS 解析失败：分清目标域名与节点域名

lookup www.example.com: no such host
dns resolve failed: all DNS requests failed
read udp 192.168.1.8:53012->192.168.1.1:53: i/o timeout

no such host 常见于系统解析器报告名称不存在，但仍需核对域名拼写、DNS 上游及返回结果。all DNS requests failed 是汇总错误，要继续找前面的具体失败原因；UDP 53 超时则指向到相应 DNS 服务的查询未及时得到响应。

按三层检查解析路径

失败的是谁：如果是网页域名，影响该网站访问；如果是节点的 server 域名，代理隧道可能根本无法建立。两者处理顺序不同。
谁在解析：查看是否启用了内核 dns、应用是否使用自己的安全 DNS，以及系统 DNS 请求是否被 TUN 接管。
上游能否访问：传统 DNS、DoH 和 DoT 的网络路径不同。DoH 使用 HTTPS，并不意味着它在当前网络中一定可达。

系统命令 nslookup www.example.com 通常查询系统指定的 DNS。它成功，只能说明那条解析路径可用，不能直接证明 Clash 内核 DNS 或浏览器自带 DoH 正常。对照测试时，必须记录查询使用的服务器，而不是只看有没有返回 IP。

Fake-IP 模式下，应用拿到 198.18.0.0/16 范围内的映射地址可能是正常现象，具体范围取决于 fake-ip-range。不能仅因地址看起来不像公网 IP 就判断解析错误，也不应拿这个映射地址直接做公网连通性结论。

修改 DNS 后，应用、系统和内核可能保留各自的缓存。按客户端支持的方式清理相关缓存，并关闭旧连接后重新测试；不要把一次旧缓存命中的结果当成新配置已经生效。

6. 从规则命中反查：为什么请求走错了出口

规则模式通常按 rules 从上往下匹配，命中后采用相应策略。若运行在全局模式，主要应检查全局策略选择；若为直连模式，则不要期待普通代理规则按规则模式的方式接管请求。排查前先确认当前模式，避免在未参与决策的配置上反复修改。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,网页代理
  - GEOIP,LAN,DIRECT
  - MATCH,网页代理

这段示例要求现有 proxy-groups 中确实存在名为“网页代理”的策略组，并且内核支持所用规则。它只是规则片段，不是完整配置。MATCH 是兜底规则，应放在需要优先判断的规则之后。

依次核对规则、策略组、最终节点

规则是否命中：预期访问 example.com 却显示 MATCH，要检查实际域名、子域名、规则顺序以及重载结果。
命中是否合理：显示 DIRECT 时，先看是否被更靠前的直连规则截走，而不是直接断言节点故障。
策略组是否选对：同一个组可能选择 DIRECT、另一个组或某个节点。自动测速与故障转移组还可能动态改变出口。
是否只有部分资源失败：主页面、图片、登录接口可能使用不同域名。只检查地址栏里的域名，会漏掉真正报错的资源。

例如，主页面走“网页代理”，但登录接口命中了直连规则，表现可能是“页面能开，登录一直转圈”。应按登录操作的时间找对应目标域名，必要时结合浏览器开发者工具的“网络”面板，确定失败请求后再查日志。

临时切换全局模式可以用于对照，但不是最终修复。如果全局可用、规则模式失败，应回到规则和 DNS 路径继续定位。修改后关闭旧连接再重试：既有连接可能继续沿用原出口，不会因为改了规则就自动重新建立。

7. TLS、UDP 与配置错误的补充判断

日志关键词	优先检查	需要避免的误判
`x509: certificate`	系统时间、证书有效期、节点服务器名称与 TLS 配置	不要把跳过证书验证当成常规修复
`TLS handshake timeout`	TCP 建立后的链路、服务端响应及 TLS 参数	不等同于域名一定解析失败
`EOF` / `connection reset by peer`	哪一端提前关闭、协议参数、服务端日志	单凭一行无法确定是凭据还是网络干扰
`[UDP]` 相关超时	节点 UDP 支持、TUN 路由、出口网络限制	TCP 测速通过不代表 UDP 正常
`yaml: unmarshal errors`	报错行附近的缩进、字段类型、重复键与内核兼容性	配置未加载时，切换节点通常没有帮助

配置里的 udp: true 不能让不支持 UDP 的服务端凭空具备该能力。游戏或语音异常时，需要核对客户端入口、节点协议及服务端、出口网络整条链路。类似地，浏览器使用 QUIC 时可能出现 UDP 相关记录，不能只拿 TCP 连接成功来解释所有现象。

若证书报错发生在节点握手，重点检查节点的服务器名称与协议参数；若发生在订阅更新，则应检查订阅站点及系统信任链。两类错误看起来都包含 x509，却不属于同一个连接阶段。

8. 提交排查信息：保留上下文，隐藏敏感内容

一份有用的排查记录不必很长，但必须能把操作和连接对应起来。优先提供下列信息，比只发“超时了”更容易得到准确判断：

环境：操作系统版本、客户端版本、内核名称与完整版本号，从“关于”或启动日志复制，不要只写“最新版”。
入口：系统代理或 TUN、当前模式、本地监听端口，以及只有一个应用失败还是全部应用失败。
复现：操作时间、失败功能、当时策略组及节点选择，并说明是否刚更新订阅或配置。
证据：相关日志前后文、规则命中记录，以及换节点或换网络后的对照结果。

最终复测仍按同一顺序进行：确认请求进入内核，确认规则与出口符合预期，再确认 DNS、连接建立和应用层请求完成。每次只改一项，并记录结果。这样才能区分真正修复与偶然恢复，也能在订阅更新后更快找回有效配置。