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

先确认日志来源与请求时间

Clash 日志记录的是内核处理连接的过程，不是浏览器页面的完整诊断报告。网页打不开，可能发生在应用没有使用代理、规则选择、域名解析、节点连接或远端服务响应等不同环节。先定位失败发生在哪一层，再修改对应设置，比看到红色文字就重装客户端更有效。

Clash 是内核与相关客户端的常用名称；Clash Meta 后续以 mihomo 名称继续发展。不同内核、桌面客户端和界面版本，日志字段与菜单名称可能不同。本文的日志行是结构示例，不是某次网络测试的实测结果，也不能用示例端口代替本机设置。

1. 在客户端侧栏打开「日志」或「Logs」。如果客户端没有日志页，查找「设置」中的日志目录或内核日志入口。
2. 记下当前时间、所用配置名称、运行模式、策略组中的实际节点，以及系统代理和 TUN 开关状态。
3. 清空界面的旧日志，然后只打开一个有问题的页面。等待约 10 秒，暂停滚动或导出这一小段记录。
4. 按目标域名、目标端口和时间筛选。自动更新、连通性测试与网页请求会混在同一窗口，不能只看最后一条错误。

日志级别怎么设置：先用 info，短时切换 debug

常见日志级别有 silent、error、warning、info 和 debug。日常排查先用 info，通常可以看到连接与规则匹配信息。只有需要核对解析、拨号或内核细节时，才短时启用 debug。

修改位置与配置覆盖

如果界面提供「设置」→「日志级别」，优先从界面调整。直接管理内核配置时，可以在当前生效的 YAML 顶层设置以下字段；它不是 dns 或 tun 的子项。

log-level: info

保存后按客户端支持的方式重新加载配置，并再次查看日志。部分客户端通过覆写、合并配置或运行时参数控制日志级别；订阅更新也可能覆盖直接编辑的文件。不要仅凭磁盘文件内容判断是否生效，应同时核对界面和实际日志输出。排查结束后恢复到 info，避免长期积累大量请求记录。

一条连接日志怎么看：目标、规则、出口与错误链

阅读顺序建议固定为：先看时间，再看请求目标，然后看规则和实际出口，最后读错误链。下面是简化后的结构示例，真实日志可能使用不同的字段顺序或换行格式。

[warning] [TCP] 127.0.0.1:53124 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[节点A]
error: dial tcp 192.0.2.10:443: i/o timeout

• 127.0.0.1:53124 表示内核看到的连接来源。53124 是临时源端口，不是需要填入系统代理的监听端口。
• www.example.com:443 是请求目标。443 常用于 HTTPS，但仅凭端口不能判断网站证书是否正常。
• match 后的内容用于确认命中了哪条规则。规则模式下，一般按顺序匹配，较前的命中规则会影响后续走向。
• using Proxy[节点A] 表示本次使用的策略与节点。策略组名不是节点服务器地址，还要继续核对实际选中的成员。
• dial tcp 后的地址是本次拨号对象。走直连时可能是网站地址，走代理时可能是节点地址，要结合整条错误链判断。

示例中的 192.0.2.10 是文档示例地址，不应填入配置。若看到 DIRECT，却原本希望经节点访问，应先检查规则和模式；若看到 REJECT，应先检查拦截规则，而不是把它当成节点掉线。

dial timeout 与 i/o timeout：连接在哪一段超时

dial timeout、connect: connection timed out 通常指建立连接未在期限内完成。i/o timeout 的范围更广，也可能出现在已经建立连接之后的读写阶段。它们描述的是等待超时，不直接等于“节点失效”或“DNS 被污染”。

按失败范围缩小排查

1. 只有一个网站失败：在相同节点下打开另一个已知可访问的网站，核对失败域名是否命中不同规则，是否走了直连。
2. 同一节点的多个网站失败：在同一策略组里切换另一个节点，并重复同一个请求。若仅原节点失败，重点核对原节点地址、端口和服务状态。
3. 所有节点都失败：先确认本地网络可用，再检查节点域名解析、防火墙、上游网络限制以及订阅是否过期。
4. 仅 TUN 模式失败：保留同一配置与节点，改用系统代理做对照。若显式代理正常而 TUN 异常，重点查路由、DNS 接管和其他 VPN 冲突。

Windows 可在 PowerShell 中运行 Test-NetConnection -ComputerName 节点域名 -Port 节点端口，但必须把两个中文参数值替换为当前配置中的真实值。此类 TCP 测试只适用于需要 TCP 的端点，不能据此判断基于 UDP 的协议是否正常；端口连通也不代表认证、TLS 或应用请求一定成功。

不要首先放大超时时间。反复等待更久不会修复错误地址、失效服务或不通的网络路径。应先识别日志中超时的端点，再决定是否需要调整超时参数。

connection refused：区分本地端口与远端端口

connection refused 表示连接尝试收到拒绝，常见原因是对应地址和端口没有服务监听，或网络设备主动拒绝。它与静默等待后的超时不同。第一步是看拒绝发生在 127.0.0.1 还是节点服务器地址。

本地 127.0.0.1:7890 被拒绝

7890 只是常见的示例代理端口，不是所有客户端的固定值。应用访问本地 7890 被拒绝时，打开客户端「设置」中的端口或混合端口设置，核对内核是否启动、实际监听端口是否已改动。还要检查内核日志中是否先出现端口绑定失败。

# Windows：查看本地 7890 是否处于监听状态
netstat -ano | findstr ":7890"

# macOS / Linux：查看 TCP 7890 的监听进程
lsof -nP -iTCP:7890 -sTCP:LISTEN

Windows 输出中应结合本地地址列和 LISTENING 状态判断，不能仅凭出现“7890”就认定代理已启动。发现占用进程后，先确认程序身份；不要直接结束不认识的系统进程。

远端节点端口被拒绝

若拒绝来自节点地址，检查订阅里的服务器地址与端口是否仍有效，并刷新订阅后再试。HTTP 代理凭据错误常以 407 Proxy Authentication Required 等响应表现，不应把所有拒绝都归因于密码。节点端口可达之后，协议与认证仍需要单独验证。

DNS 解析失败：先区分目标域名和节点域名

no such host、lookup ... failed、DNS resolve failed 都指向解析环节，但失败的域名可能是访问的网站，也可能是节点服务器。节点域名无法解析时，即使网站 DNS 设置正确，也无法先连接节点。

• 目标网站解析失败：检查当前运行配置的 dns 段、解析器可达性，以及直连与代理路径使用的解析策略。
• 节点域名解析失败：在 mihomo 中检查是否配置了 proxy-server-nameserver，以及对应解析器能否在节点尚未连接时使用。
• DoH 解析器本身无法连接：核对 DoH 地址、其主机名的引导解析及出站路径，避免“连接节点依赖 DNS，DNS 又依赖尚未连接的节点”的循环。
• 只在 TUN 下失败：检查 TUN 的 DNS 接管配置、系统现有 DNS，以及其他 VPN 是否同时修改网络设置。

系统查询正常，不代表内核查询正常

运行 nslookup www.example.com 可以检查系统所用解析器的响应，但它不一定经过 mihomo 内置 DNS。浏览器还可能启用安全 DNS，使用另一条解析路径。因此，“nslookup 有结果”只能作为对照证据，不能证明内核实际采用的解析器正常。

使用 fake-ip 模式时，出现配置的 Fake IP 地址段内的合成地址可能是正常行为，例如常见的 198.18.0.0/16。不要看到该地址就判断遭到劫持。应继续确认该连接是否回到正确的内核路由，以及真实的上游解析或节点连接是否失败。更完整的检查位置可见手册中的 DNS 排查。

证书、端口绑定与 TUN 权限报错

TLS 错误要先识别连接对象。内核报告的证书错误可能发生在节点握手、订阅下载或 DNS over HTTPS 请求中，不一定来自浏览器访问的网站。普通代理转发 HTTPS 时，网站证书的最终验证通常仍由浏览器完成。

TUN 创建或路由权限失败时，打开客户端「设置」中的服务模式、权限或 TUN 相关页面，按该客户端要求安装服务或授予权限。Windows 桌面客户端可能依赖已安装的后台服务；Linux 常涉及 TUN 设备和网络管理权限。具体方式随客户端而异，不建议把长期以管理员身份运行作为所有报错的统一处理。

若修改了监听端口，还要同步系统代理、终端代理环境变量及浏览器扩展中的手动配置。内核成功启动但应用仍指向旧端口，会继续出现本地连接失败。

固定复测顺序与日志脱敏

每次只改一个变量，并用同一个域名、同一种访问方式复测。否则同时更新订阅、切换节点、改 DNS 和开 TUN，即使恢复访问，也无法确认真正原因。

1. 保留原配置备份，记录问题发生时间与实际报错行。
2. 确认请求进入内核，再确认规则是否选中预期出口。
3. 根据日志分别检查解析、拨号、认证或 TLS，不跨层猜测。
4. 修改一项后重新加载，观察同一请求的新日志，确认错误是否消失或发生变化。
5. 恢复日常日志级别，并验证浏览器与常用终端程序，避免只修复其中一条代理路径。

向维护者提交问题时，提供客户端名称、客户端与内核的实际版本、操作系统、运行模式、是否启用 TUN、复现步骤，以及前后约 20 行相关日志。版本应从「关于」或内核启动记录读取，不要把客户端版本当成内核版本。

发送前移除订阅链接、访问令牌、代理密码、控制 API 密钥，以及可能暴露个人信息的域名与 IP。脱敏后仍应保留字段结构、端口、错误类型和规则关系，便于判断。不要公开整份订阅文件，也不要通过关闭证书验证或长期停用防火墙来掩盖原始故障。