Clash 运行日志怎么看：dial tcp、i/o timeout 等常见报错逐条解读
运行日志是定位问题的第一手资料。本文讲解日志级别的切换方法，逐条解读 dial tcp、i/o timeout、connection refused 等报错的含义，并示范如何从一条日志定位到节点、规则或 DNS 环节。
1. 先复现一次故障，再找同一时间的日志
网页打不开时，不要先把 DNS、节点、TUN 和规则一起改掉。打开客户端的「日志」页面，记下当前时间，只刷新一次出问题的网页。优先检查这一时刻前后数秒的记录，而不是从整屏红字里挑一条看起来最严重的报错。
日志颜色只表示记录级别，不等于故障范围。一次后台测速失败可以产生警告，但浏览器当前连接仍可能正常；反过来，命中错误的直连规则也可能只有普通连接记录，没有醒目的错误提示。
- 记录客户端名称、版本、内核名称，以及当前使用「规则」「全局」还是「直连」模式。
- 记下失败的域名、操作时间和症状，例如首页能开但图片加载失败。
- 清空日志视图或用时间筛选，再执行一次相同操作。清空视图不一定会删除磁盘日志文件。
- 保留失败请求前后的记录，尤其是目标地址、命中规则、出站策略与错误原因。
2. 日志级别怎么改：先用 info，必要时短时开启 debug
Clash 系列客户端通常把运行日志放在侧栏「日志」。如果该页提供级别筛选，先确认它只是过滤已显示的记录，还是会修改内核日志级别。仅把筛选器切到 Debug，未必能让内核开始输出调试信息。
内核配置中控制日志详细程度的字段是 log-level。原版 Clash 与 mihomo 都使用这一字段。客户端若提供「日志级别」设置，应优先从界面修改；若界面没有入口，再使用客户端支持的配置覆写或合并功能。不要直接改订阅生成文件后就认为设置会永久保留，订阅更新可能覆盖它。
# 放在配置顶层，不要缩进到 dns 或 rules 下面
log-level: info| 级别 | 适用场景 | 注意事项 |
|---|---|---|
silent | 抑制常规日志输出 | 排障时先退出这个级别 |
error | 只关注错误 | 可能缺少规则匹配和连接上下文 |
warning | 查看警告及更严重的问题 | 适合快速发现重复连接失败 |
info | 日常排障的起点 | 结合目标地址与出站策略阅读 |
debug | 补充解析、连接等细节 | 短时复现后恢复，避免日志过多 |
需要调试时，把该字段暂改为 debug，按客户端要求重载配置或重启内核，复现一次后恢复为 info。配置字段使用 warning，但日志行里的级别标签可能显示为 WARN 或 warning，不要混淆。
分享记录前先检查是否含订阅链接、访问令牌、节点密码、服务器地址和本地路径。保留错误原文与端口结构即可，公开求助不需要提供整份订阅配置。
3. 一条连接日志先看四处：目标、规则、出站、错误
[info] [TCP] 127.0.0.1:53142 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[节点-A]这条简化记录表示：本机某个程序从临时端口 53142 发起 TCP 请求，目标是 www.example.com:443，匹配了域名后缀规则，最终通过策略组 Proxy 选中的节点-A 出站。左边的临时端口不是客户端的代理监听端口，不需要照着它修改设置。
- 目标：确认是失败网页的域名，还是更新检查、测速地址、广告资源等后台请求。
- 规则：查看实际命中的规则。规则模式下通常按从上到下的顺序匹配，命中即使用对应策略。
- 出站：
DIRECT表示直连，REJECT表示拒绝；策略组名后还可能出现最终选中的节点。 - 错误：继续看相同时间、相同目标的失败原因，不能只看到
using Proxy就认定代理链路成功。
看到 MATCH 通常表示落到兜底规则，不代表规则引擎失效。如果本该走指定策略的网站落到兜底，需要检查前面的规则是否覆盖该域名、规则集是否加载，以及当前是否确实使用了预期配置。
4. dial tcp：正在建立 TCP 连接，原因要看后半句
dial tcp 是连接动作的描述，不是独立的故障结论。它后面通常跟着地址与底层错误。下面两条都含这个词组，但处理方向不同：
dial tcp 203.0.113.10:443: i/o timeout
dial tcp 127.0.0.1:7897: connect: connection refused远端地址失败：先确认它属于谁
第一条中的远端地址可能是代理服务器，也可能是直连目标网站，必须结合出站字段与配置判断。如果它等于当前节点的服务器地址，应先检查本机到节点这一段；如果是 DIRECT 访问的网站地址，就应检查本地网络、路由及该网站本身。
本机地址失败：先检查监听端口
第二条指向本机 127.0.0.1:7897。如果这是浏览器或命令行使用的代理入口，拒绝连接通常意味着该地址没有对应服务监听，或服务未成功启动。7897 这里只是示例，不能当成所有客户端的默认值。
在客户端查看实际的「混合端口」或 HTTP/SOCKS 端口。若启用了混合端口，对应配置字段是 mixed-port。Windows 可以先用以下命令检查示例端口是否有监听：
netstat -ano | findstr :7897检查输出中的本地地址与 LISTENING 状态，再核对进程 PID。只有包含这个数字的远端连接行，不能证明本机正在监听。若客户端根本未启动成功，先处理启动错误，不要急着更换节点。
5. i/o timeout：等待超时，不能直接等同于节点失效
i/o timeout 表示某次网络读写在期限内没有完成。它可能出现在 TCP 建连、DNS 查询、代理握手或连接建立后的读取阶段。单看这两个词，无法区分运营商路径、远端服务、UDP 丢包还是本机防火墙问题。
- 先看失败对象。节点服务器超时与 DNS 服务器超时属于不同环节。保留
read udp、dial tcp等前缀。 - 同网络换一个节点。只切换策略组选择，保持规则、DNS、TUN 设置不变，然后访问同一目标。
- 同节点换一个网络。例如从 Wi-Fi 切到手机热点，观察同类超时是否消失。
- 区分所有网站与单一网站。只有一个域名失败时，还要检查目标站状态及其规则走向。
如果多个目标都只在同一节点下失败，节点或到该节点的路径更值得优先检查。如果仅一次后台测速超时，而网页请求正常，不必据此重置整套配置。测速检查的 URL、协议和实际业务并不一定相同。
6. connection refused：连接被拒绝，与超时分开处理
connection refused 通常表示连接请求收到了明确的拒绝响应，而不是一直没有回应。常见情况是目标端口没有服务监听，或者设备上的策略主动拒绝了该连接。它不等于密码错误；密码或协议不匹配往往发生在建立连接后的认证、握手阶段。
- 拒绝来自本机端口：核对系统代理、浏览器代理扩展和终端环境变量是否还指向旧端口；确认内核运行中。
- 拒绝来自节点端口：核对订阅里的服务器与端口，更新订阅后再试；不要自行把所有节点端口改成 443。
- 拒绝来自局域网地址：检查服务是否只绑定在回环地址，以及局域网访问权限和防火墙设置。
如果日志显示 address already in use，含义又不同：这是客户端尝试监听端口时发现端口已被占用。先查占用进程，再决定关闭旧实例或修改端口。更改端口后，手工配置代理的应用也需要同步修改。
7. DNS 报错：区分节点域名与网站域名
no such host 常表示域名查询没有得到可用结果，可能涉及名称不存在、拼写错误或解析链路；server misbehaving 通常指解析器返回了异常状态。遇到这些文本，先找出正在解析的具体名称，而不是直接替换整段 DNS 配置。
lookup www.example.com: no such host
read udp 192.168.1.20:53000->192.168.1.1:53: i/o timeout第二条表示一次到 192.168.1.1:53 的 UDP 读取超时，关注点是 DNS 查询路径。如果配置使用 DoH，则还可能看到到解析服务 443 端口的连接或 TLS 错误，不能只按传统 UDP 53 端口排查。
节点服务器域名解析失败
节点自身的域名解析不出来时，后续代理握手根本无法开始。mihomo 的 proxy-server-nameserver 可用于指定代理服务器域名的解析器，但它是有版本与配置语义要求的字段，不能直接复制到不支持它的旧内核。先确认实际内核，再检查当前解析器能否在代理尚未建立时访问。
只有目标网站解析失败
检查该域名是否受 nameserver-policy 等配置影响，以及客户端是否真正接管了应用 DNS。浏览器自带的安全 DNS、应用内置解析、系统缓存和 TUN 的 DNS 劫持设置，都可能让查询走不同路径。
使用 Fake-IP 时，在日志里看到 198.18.0.0/16 等配置范围内的映射地址并不自动代表解析污染。应继续观察域名映射和出站结果。系统里的 nslookup 只能说明那次查询经过的解析路径，不能单独证明浏览器或内核使用了同一个解析器。
8. 其他常见提示：TLS、EOF 与启动失败
| 日志文本 | 含义与优先检查项 |
|---|---|
TLS handshake timeout | TLS 握手未及时完成。先确认握手对象是节点、目标网站还是 DoH 服务，再检查路径与协议配置。 |
x509: certificate has expired or is not yet valid | 检查系统日期、时间、时区及对端证书有效期。不要通过跳过证书验证掩盖原因。 |
EOF / unexpected EOF | 连接结束或读取提前结束。结合是否稳定复现、协议和上下文判断，不能据此直接认定被封锁。 |
connection reset by peer | 连接被复位。可能涉及远端、链路设备或协议不匹配，需比较其他节点与网络。 |
network is unreachable | 检查本地路由、接口与 IPv6 可达性，尤其是休眠恢复、网络切换或 TUN 启停后。 |
Parse config error | 先处理配置解析问题。按后续提示检查 YAML 缩进、字段类型与当前内核的协议支持。 |
原版 Clash、Clash Meta 与后续 mihomo 的配置能力并不完全相同。如果订阅包含当前内核不支持的协议或字段，问题会在配置加载阶段出现，换节点通常不能修复。应确认配置是否成功加载、代理组是否生成，再讨论连接超时。
TUN 启动失败还可能涉及权限、虚拟网卡或路由创建。此时系统代理路径与 TUN 路径可以表现不同。不要因为浏览器通过系统代理能访问，就认为 TUN 已经工作；也不要一遇到 TUN 报错就删除系统网络组件。
9. 完整示范：从一条 timeout 缩小到节点链路
假设浏览器访问 www.example.com 失败，日志在同一时刻出现以下简化记录：
[warning] [TCP] dial Proxy (match DomainSuffix/example.com)
127.0.0.1:53142 --> www.example.com:443
error: dial tcp 203.0.113.10:443: i/o timeout- 确认是这次请求。目标域名与操作时间一致，排除后台测速记录。
- 确认规则符合预期。日志显示走 Proxy。如果本来就希望代理访问，先不动规则。
- 核对失败地址。假设当前节点的服务器地址确实是
203.0.113.10:443，则现有证据指向到节点的连接超时，不是网页返回了 HTTP 错误。 - 只切换节点。选择节点-B，保持模式与目标不变。若请求恢复，优先检查节点-A 或到它的路径。
- 必要时换网络复查。若节点-A 在热点下可用、在原网络下持续超时，说明问题更可能与原网络路径有关，但还不能确定具体是哪台设备阻断。
反过来，如果原记录显示 using DIRECT，就不能沿用上面的节点结论。先检查为什么直连，再用客户端「连接」页核对当前请求的规则与出站。临时切到全局模式可以用于对照，但对照结束后应恢复原模式，并修正规则，而不是把全局模式当成所有故障的长期解法。
10. 没有日志时先检查入口，求助时保留最小证据
刷新网页后完全没有对应记录，优先怀疑流量没有进入这个内核，或日志视图过滤掉了记录。检查应用是否使用系统代理、浏览器扩展是否覆盖了代理设置、是否连接了另一个 VPN，以及 TUN 是否确实启动。单纯开启系统代理，并不能保证所有应用或 UDP 流量都会进入 Clash。
本地混合端口也可以用来做一次明确的入口测试。下面命令中的 7897 必须换成客户端实际显示的端口；Windows PowerShell 中使用 curl.exe 可避免旧环境里的同名别名差异。
curl.exe -I --proxy http://127.0.0.1:7897 https://example.com执行后立即查看日志。若命令提示本机端口连接失败，先查监听与内核状态；若已出现目标连接记录，再按规则、出站、错误逐层分析。命令返回 HTTP 状态只能说明这次请求的结果，不能替代对其他应用的检查。
提交故障信息时带上这些内容
- 客户端与内核版本、操作系统版本，以及系统代理或 TUN 的启用情况。
- 故障时间、目标域名、当前模式和最终出站，注明是所有网站还是单一站点失败。
- 脱敏后的完整错误行及相邻上下文，不要只截取
i/o timeout两个词。 - 同网络换节点、同节点换网络的结果，以及最近一次修改的配置项。
排查顺序保持固定：先确认流量进入内核，再确认规则和出站，最后定位 DNS、连接或握手阶段。每次只改一个变量，记录结果；恢复访问后把调试级别调回去。这样下一次遇到相同错误，就能从已有证据继续，而不是重新试遍所有开关。