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

先看失败发生在哪一层，再改配置。看到红色日志就换节点，往往会绕远路：本地端口没启动、域名没解析出来、规则选错出口、远端握手失败，表面上都可能是“网页打不开”，处理方法却完全不同。

本文面向 Clash 及 Clash Meta（现名 mihomo）内核。不同客户端会重新排版日志，同一个错误的前缀也可能不同。下面的日志是结构示例，不是某台设备的实测记录；排查时应以自己的时间、目标地址和实际出口为准。

一、先取到一次完整的失败记录

打开客户端的“日志”或“Logs”页面，先把界面搜索词清空。若界面同时提供级别筛选和内核日志级别设置，要分清两者：筛选只隐藏已有记录，不能让内核补回此前没有输出的调试信息。平时用 info，问题难以复现时再短暂切到 debug。

记录客户端名称、客户端版本、内核名称与内核版本。界面版本不等于内核版本。
确认当前配置名称、运行模式、系统代理与 TUN 的开关状态，再记录本机时间。
保留已有日志，清空界面显示或记下开始位置，只访问一次出问题的网址。
复制失败行及前后约 10 行。若同时有多条连接，用目标域名、端口和源端口区分，别只按相邻位置推断关联。

二、日志级别和连接字段怎么读

级别	常见内容	排查用途
`debug`	解析、连接等较细的过程信息	短时间复现问题，完成后恢复
`info`	启动状态、规则匹配与出口选择	确认请求是否进入内核、走了哪个策略
`warning`	连接失败或可恢复异常	结合目标地址判断是否影响正在访问的服务
`error`	较严重的运行或加载问题	优先查看配置加载、监听和资源初始化
`silent`	抑制常规日志输出	不适合故障复现阶段使用

这些名称是常见的内核日志级别。客户端可能把 warning 显示为 WARN，或使用中文标签。级别反映记录的重要程度，不代表故障一定发生在本地；一条网站后台请求的超时，也可能被记为警告。

time="2026-09-11T10:20:30+08:00" level=info msg="[TCP] 127.0.0.1:53124 --> example.com:443 match DomainSuffix(example.com) using PROXY[节点A]"

time：记录时间。对照系统时区，避免把旧错误当作本次请求。
[TCP]：连接使用的传输协议；UDP 请求会有相应标识。
127.0.0.1:53124：本次连接的来源，不是内核的代理监听端口。
example.com:443：请求目标。443 通常用于 HTTPS，但端口本身不能证明应用协议。
match：实际命中的规则，而不是配置里希望命中的规则。
using：策略组及选中出口。组名叫 PROXY，并不保证组内当前选项一定是代理节点。

这行记录说明内核已经为连接匹配规则并选择出口，不等于网页已下载成功。后续连接、TLS 握手或应用响应仍可能失败。需要把同一次访问产生的失败记录一起看。

三、dial tcp 超时：先确认连的是谁

dial tcp 203.0.113.10:443: i/o timeout
dial tcp 127.0.0.1:7890: connect: connection refused

第一行表示一次 TCP 拨号在期限内未完成。示例中的 203.0.113.10 是文档示例地址，不可拿来测试。真实日志里，这个位置可能是网站 IP，也可能是代理服务器 IP；必须结合错误前缀和出口判断。走代理时，“拨号失败”并不总是网站服务器出了问题。

按地址类型逐项检查

地址是代理服务器：保持同一个测试网址，只切换一个节点。如果只有某个节点持续超时，优先检查该节点地址、端口及服务状态，不要先改整套 DNS。
地址是目标网站：检查是否实际走了 DIRECT。如果国内外规则写反，原本应该经代理访问的目标可能被直连。
地址是本机回环地址：核对本地代理是否监听该端口。7890 只是常见配置值，实际值以当前配置和客户端界面为准。

connection refused 通常表示连接被明确拒绝，常见于没有进程监听或防火墙主动拒绝；i/o timeout 则表示等待超时。两者不能混为一谈，也不能仅凭一次超时就断言节点永久失效。

用一次显式代理请求缩小范围

确认混合代理端口确实是 7890 后，可以运行以下命令。Windows 建议使用 curl.exe，避免旧版 PowerShell 中 curl 别名的影响。

curl --noproxy "" -v --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

这里的 10 秒是连接阶段上限，20 秒是整次请求上限，不是网络速度成绩。命令明确指定本地代理，便于与浏览器结果对比。如果命令能通而浏览器失败，接着查浏览器代理扩展、系统代理和应用自己的网络设置；若日志完全没有对应连接，先确认命令端口和日志筛选。

四、DNS 解析失败：区分三种域名

DNS 报错前先问：失败的是目标网站域名、代理服务器域名，还是 DNS 上游自身的域名？这三类失败出现在不同阶段。代理服务器域名无法解析时，换网站通常没有意义，因为连接出口本身还没准备好。

lookup example.com: no such host
lookup example.com: i/o timeout

no such host 通常与域名不存在或解析器返回的否定结果有关；i/o timeout 更偏向查询没有及时得到响应。具体还要看错误里指出的解析服务器和上下文。若出现 all DNS requests failed，说明此次查询尝试的上游均未成功，并不能直接推导出“所有节点都坏了”。

先核对域名拼写，再检查当前配置中 dns.enable、nameserver 等字段。
检查 DNS 上游是否可达。使用加密 DNS 时，还涉及到上游地址解析、连接与证书验证，不只是 UDP 53 端口。
mihomo 配置若使用 proxy-server-nameserver，还要确认它负责的代理节点域名解析能正常完成，避免依赖尚未建立的代理出口。
只替换一个上游进行对比，记录修改前后的同一域名结果。不要一次同时修改 DNS、节点和规则。

使用 fake-ip 模式时，看到 198.18.0.0/16 范围内的合成地址不应立即判定为解析污染。应继续检查 fake-ip 映射、流量是否回到内核，以及域名信息是否能参与规则匹配。

五、规则未命中：从实际出口反查顺序

“规则未命中”很多时候不是一条明确的报错，而是连接日志显示命中了意料之外的规则。先确认当前处于 Rule／规则模式。Global／全局模式和 Direct／直连模式不会按同样方式使用分流规则，修改规则文件可能看不到预期变化。

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

这段只用于说明顺序，假定配置里已定义名为 PROXY 的策略组。规则通常自上而下匹配，先命中就使用对应策略；MATCH 应放在末尾作为兜底。把 MATCH 写在域名规则之前，后面的规则就没有机会处理连接。

命中 MATCH 不一定是错误

没有更具体规则匹配时，进入兜底是正常行为。如果某个域名本来应该命中专用规则，则检查实际加载的配置、规则拼写、远程规则集加载状态，以及日志里是否保留了域名信息。只有目标 IP 时，域名类规则可能无法按预期参与匹配；嗅探也不是所有连接都能可靠还原域名。

DOMAIN 用于精确域名；DOMAIN-SUFFIX 用于域名及其子域，别把完整 URL 或路径写进去。
RULE-SET 需要对应的 rule-providers 名称，并与规则集的类型、内容格式相容。
GEOSITE 等能力应核对内核支持情况，不能把 mihomo 配置直接当作所有旧版 Clash 内核都支持的配置。
修改订阅生成的配置前，确认客户端的覆写机制。直接编辑临时文件，下一次订阅更新可能覆盖改动。

最后打开策略组，确认组内实际选项。日志即使命中了 PROXY，如果该组当前选的是 DIRECT，最终仍然是直连。规则名称、策略组名称和真实出口要分开看。

六、监听、TLS 与 TUN 的常见误判

日志或现象	先检查什么
`address already in use`	具体冲突的监听地址和端口，是否运行了第二个内核
`certificate has expired or is not yet valid`	系统日期、时区及被验证服务的证书有效期
`TLS handshake timeout`	TCP 建连后的握手链路、节点参数及网络中间设备
`permission denied`	错误对应的文件、监听操作或虚拟网卡权限
启用 TUN 后无对应连接记录	TUN 是否成功创建、路由是否生效、应用是否绕过接管

遇到端口占用，Windows 可运行 netstat -ano | findstr :7890 查看相关监听及 PID，macOS 或 Linux 可使用 lsof -nP -iTCP:7890 -sTCP:LISTEN。确认进程身份后再退出重复实例，不要直接结束不认识的系统进程。若修改端口，系统代理和测试命令也要同步修改。

遇到证书错误，不要把关闭证书验证当作通用修复。先校准系统时间，再确认报错来自订阅下载、DNS 上游、代理服务器还是目标网站。不同环节的证书互不替代，改错位置既无效，也会削弱连接验证。

TUN 是流量接管方式，不会自动修复节点不可达或证书过期。可以先关闭 TUN，用显式 HTTP 代理命令验证内核出口；若显式代理成功、TUN 失败，再集中检查服务权限、虚拟网卡、路由和 DNS 接管。这样的对比比同时重装客户端和修改全部规则更容易保留证据。

七、从日志回溯到配置的固定流程

确认内核在运行。检查配置是否加载成功、代理端口是否监听；启动错误没解决前，先不研究网站规则。
确认请求进入内核。固定一个网址和一次访问，查看是否出现对应目标，排除日志筛选造成的“空白”。
确认模式与匹配规则。记录 Rule、Global 或 Direct，以及日志中的命中项。
确认实际出口。把策略组展开到最终节点或 DIRECT，不只看组名。
确认失败阶段。区分域名解析、TCP 拨号、TLS 握手和应用响应，再定位相应配置字段。
一次只改一处。保留原配置，重新加载后发起新连接，用相同请求比较结果；旧连接可能继续使用原来的出口。
复测并恢复日志级别。连续重复几次同一请求，确认修复稳定，再把 debug 改回 info，避免长期积累过细的访问记录。

需要对照字段时，可以查看配置字段说明。提交社区问题时，附上内核版本、脱敏后的配置片段、复现步骤和对应时间段日志。比起一句“代理不能用”，这些材料能更快把问题缩小到某个端口、某条规则或某个解析上游。