先看失败阶段，再看日志级别
Clash 日志应按“连接是否进入内核 → 命中了哪条规则 → 使用哪个策略 → 在哪一步失败”的顺序阅读。warning 表示事件级别，不等于整个客户端不可用；一条 i/o timeout 也不足以证明节点失效。先把同一次请求的时间、目标地址、策略和错误放在一起，才能决定该检查本地端口、DNS，还是代理服务器。
# 合并到当前生效配置的顶层，不要重复添加同名字段
log-level: info本文以 Clash 常见配置及 Clash Meta（mihomo）内核为讨论范围。不同内核和客户端会调整日志格式、字段名称及中文提示，下文示例用于解释字段关系，不是所有版本都会逐字输出的固定文本。排查前记录客户端版本、内核名称与内核版本，不要只记录桌面应用的版本号。
log-level 各级别如何选择
log-level 是 YAML 顶层字段，不能放进 dns 或 proxy-groups。常见取值为 silent、error、warning、info、debug，其中是 warning，不是 warn。日志中显示的 WARN 是输出标签，不代表配置也接受同样拼写。
| 配置取值 | 输出范围 | 适用情况 |
|---|---|---|
silent | 关闭常规内核日志输出 | 不适合连接故障定位；客户端自身仍可能输出消息 |
error | 错误事件 | 输出较少，可能漏掉有用的连接警告 |
warning | 警告及错误事件 | 关注连接异常，但不适合追踪正常分流 |
info | 常规运行信息及更严重事件 | 核对规则命中、策略选择与基本连接情况 |
debug | 增加调试信息 | 短时追踪解析、连接与内部处理细节 |
修改后为什么没有更多日志？
- 确认修改的是当前启用的 Profile，而不是尚未切换的另一份配置。
- 检查客户端是否通过运行设置或覆写功能把
log-level改回其他值。最终生效配置比订阅原文更有判断价值。 - 按客户端提供的方式重新加载配置；客户端支持运行时修改时，可通过其设置调整，不必反复重启系统。
- 清除日志查看器的关键词与级别筛选，再发起一条新请求。旧记录不会因为切换到
debug自动增加细节。
如果配置无法加载，应查看启动日志或客户端的内核输出。此时“日志列表为空”可能是内核尚未启动，不应继续从代理规则入手。
一条连接日志应读哪些字段
先读连接路径，再读尾部错误。下面是结构化的说明示例：源地址是本机临时端口，目标是网站的 HTTPS 端口，Proxy 为示例策略组名。
[TCP] 127.0.0.1:53124 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[节点A]
[TCP] dial Proxy (match DomainSuffix/example.com)
127.0.0.1:53124 --> www.example.com:443
error: dial tcp 192.0.2.10:443: i/o timeout这里的 192.0.2.10 是文档示例地址，不是可用节点。真实日志中的拨号地址可能是代理服务器，也可能是直连目标或解析器；不能只看最后一个 IP 就断言网站宕机。需要结合当前出站策略与完整错误上下文，确定内核正在连接谁。
- 时间：是否与手动测试一致，还是后台应用早先留下的连接。
- 网络类型：
TCP与UDP不能混为一谈。网页成功不代表游戏或其他 UDP 应用正常。 - 目标：是域名还是 IP，端口是否符合预期，例如 HTTPS 常见为
443。 - 规则与出站：命中了哪条规则，进入哪个组，组内最终选中了节点、
DIRECT还是REJECT。 - 错误阶段：发生在解析、TCP 建连、代理握手，还是后续读写阶段。
dial tcp 与 i/o timeout 分别说明什么
dial tcp 描述正在发起 TCP 连接，本身不是错误原因。后面的 i/o timeout、connection refused 或 network is unreachable 才提供失败方向。代理协议握手、TLS 协商及应用请求发生在不同阶段，不能用一次 TCP 建连成功替代全链路判断。
| 错误片段 | 可得出的结论 | 下一步检查 |
|---|---|---|
dial tcp … i/o timeout | 向指定地址建立 TCP 连接未在期限内完成 | 核对地址与端口；检查网络路径、服务可达性及防火墙 |
i/o timeout | 某次网络读写超时，单独看不能确定阶段 | 保留前后文，确认是否已经建立连接或开始握手 |
connection refused | 收到了拒绝连接的响应，或被网络设备主动拒绝 | 核对监听端口和服务状态，不要首先调整 DNS 模式 |
network is unreachable | 当前网络栈无法找到可用路径 | 检查路由、网卡及 IPv4/IPv6 可达性 |
connection reset by peer | 连接被对端或链路中的设备重置 | 核对协议、服务端日志与触发时间，不能仅凭此定位责任方 |
EOF | 读取时连接结束 | 结合是否处于握手阶段检查协议参数，也可能只是正常关闭 |
全部节点超时与单个目标超时要分开
多个不同服务器同时出现拨号超时，优先检查本地网络、路由、防火墙以及订阅地址是否仍有效；只有一个节点失败，则优先核对该节点的服务器地址、端口和服务状态。同一节点能访问其他网站、只有一个域名失败时，再检查目标网站、目标解析与分流结果。延迟测试通常只访问特定测试地址，它的成功不能保证每个网站都能访问。
DNS、TLS 与端口错误如何区分
解析失败：先区分节点域名与目标域名
lookup … no such host 指向域名解析失败；DNS … timeout 则表示解析请求未及时完成。先确认失败域名是节点服务器、订阅服务器，还是待访问网站。节点域名解析失败时，代理连接可能根本尚未建立，盲目更换网站规则没有帮助。
系统的 nslookup 结果不一定等于 mihomo 内部 DNS 的结果，尤其在启用 Fake-IP、DNS 劫持或分流解析时。可将系统解析作为对照，但要同时查看当前生效的 dns 配置。mihomo 的 proxy-server-nameserver 用于代理节点域名解析，排查时应核对其适用版本和实际设置，不要直接套用到不支持该字段的旧内核。
TLS 错误：检查证书、时间和协议参数
x509 相关错误常涉及证书信任、有效期或名称不匹配。先检查系统日期，再核对节点的 TLS 开关、服务器名称及服务端要求。tls handshake timeout 表示 TLS 握手未及时完成，不等于必然存在证书错误；如果请求仍在握手阶段，就还不能归类为网站返回了 HTTP 错误。
监听失败：先恢复本地入口
bind: address already in use 通常表示本机监听地址与端口被占用。例如将 HTTP 与 SOCKS 合并监听在 7890，但另一个客户端也占用了该端口，内核入口就可能无法正常建立。应停止冲突进程，或修改端口并同步更新系统代理、浏览器和终端设置。
# 本地入口示例；7890 是示例端口，不是所有客户端的默认值
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info这段只是字段片段，不含节点或完整规则。修改前先确认原配置是否已有 mixed-port，避免重复键。只需要本机访问时保留 allow-lan: false，没有必要为了修复本机端口冲突而开放局域网监听。
规则未命中：检查顺序、模式与最终策略
“规则未命中”通常是排查描述，不是跨版本统一的报错文本。连接命中兜底规则、进入非预期策略，或者没有进入内核，都可能被用户归为这一类。规则模式按 rules 从上到下匹配；较前的宽泛规则可能提前接走连接。
# 示例片段：域名规则在前，兜底规则在后
# Proxy 必须是完整配置中已经存在的策略组或代理名称
mode: rule
rules:
- DOMAIN-SUFFIX,example.com,Proxy
- MATCH,DIRECT- 先确认模式：
global使用全局策略，direct使用直连，不能用它们验证rule模式下的规则顺序。 - 再确认目标信息：应用可能直接连接 IP。能否恢复域名取决于 DNS 映射、嗅探及实际流量，不能假定每条 IP 连接都会命中域名规则。
- 核对兜底：命中
MATCH,DIRECT是规则正常执行的结果，只是可能不符合预期；应修正前面的具体规则。 - 核对组内选择：日志显示进入
Proxy，不代表一定代理。如果该组当前选择了DIRECT，最终仍然直连。 - 核对更新覆盖：订阅更新可能替换手工编辑内容。需要长期保留的规则，应使用客户端支持的合并或覆写机制，并检查生成结果。
如果当前流量完全没有对应日志，应先查入口。系统代理只影响遵循该设置的应用，终端、游戏或自带代理设置的浏览器可能走其他路径。TUN 可承接更多 IP 流量，但仍受权限、路由、排除项及 DNS 配置影响；开启 TUN 不是证明所有流量已进入内核的充分条件。字段含义可继续查阅配置字段说明。
一次可复现的日志定位流程
有效排查应让每次修改都能对应一条新证据。以下流程以本机 HTTP 代理入口 127.0.0.1:7890 为例；如果当前配置使用其他端口，命令也要同步修改。
- 记录当前 Profile、内核版本、代理模式、选中节点与本地监听端口；把日志级别设为
info。 - 关闭无关下载与测速任务，记下当前时间。只请求一个目标，避免把后台连接当作测试结果。
- 用下面的显式代理命令测试，使请求不依赖系统代理设置。Windows PowerShell 可使用
curl.exe，避免旧环境中同名别名的差异。 - 在同一时间段找到对应连接，核对规则和出站，再读错误结尾。若没有日志，先查监听入口和查看器筛选。
- 信息不足时改为
debug，重复同一请求。每轮只改变一个条件，例如只切换节点，不同时修改 DNS、规则和 TUN。 - 确认恢复后改回
info，保存故障原因与最终生效字段，而不是长期保留大量调试输出。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 15 --verbose https://example.com/ --output /dev/nullWindows 使用 curl.exe 时，可把输出目标 /dev/null 换成 NUL。这里的 10 秒是 curl 的连接阶段上限，15 秒是整个请求的上限，不会直接修改内核内部超时。命令中的 --verbose 会显示代理连接与 TLS 过程；HTTPS 经过 HTTP 代理时，出现 CONNECT 成功也只代表隧道已建立，仍需继续看后续握手与响应。
分享日志前保留什么、隐藏什么
求助时提供故障发生时间、客户端与内核版本、相关模式、目标端口、规则结果，以及一次请求前后的连续日志。通常保留同一次复现前后约 10～30 行，比只截图最后一句 timeout 更容易定位。配置片段保留层级与字段名，但应移除可用于访问服务的凭据。
- 隐藏订阅完整链接及其查询参数、节点密码、UUID、访问令牌与控制接口的
secret。 - 按需要隐藏真实域名、局域网地址及节点地址，但为同一对象使用一致的替代名称，避免丢失关联关系。
- 保留错误类型、目标端口、TCP/UDP 类型和规则顺序；这些内容直接影响结论。
- 不要上传完整订阅文件作为默认求助材料。节点数量多并不能弥补缺少复现步骤。
最终判断应能落到具体层级：请求没有进入本地入口、规则选择不符、节点拨号失败、协议握手失败，或目标返回异常。先归类再修改，比反复重装客户端或同时重置所有配置更能保留有效线索。