先确认日志来源与连接阶段
Clash 日志不是一张“节点好坏清单”。同一次网页访问可能触发域名解析、规则匹配、代理服务器连接、协议握手和目标站点访问。报错出现在不同阶段，处理方向也不同。看到一条红色记录就更换订阅，往往会丢失最有用的现场。
先区分客户端日志与内核日志。客户端日志通常记录界面、配置下载、更新和权限问题；Clash 或 mihomo 内核日志主要记录配置加载、监听端口、DNS 与连接处理。客户端使用 mihomo，并不意味着所有错误都来自 mihomo。排查时同时记下客户端版本和内核版本，不能只写“最新版”。
- 启动即失败：先看配置解析、策略引用、端口占用和权限提示，不必先检查目标网站。
- 启动正常但网页打不开：先找该域名的连接记录，再确认规则与出站路径。
- 只有订阅更新失败：检查配置下载所走的网络、订阅地址状态与 HTTP 响应，不直接等同于代理连接故障。
- 浏览器失败但没有相关日志：先检查流量是否进入客户端，再讨论节点。系统代理不能覆盖所有应用；TUN 也可能存在路由排除。
日志级别怎么调：先用 info，再短时启用 debug
在客户端中打开“日志”页面，查找级别下拉框或过滤选项。注意：界面的过滤器可能只是隐藏部分记录，并没有改变内核生成日志的级别。如果需要详细记录，应确认运行配置中的 log-level 已改变。
Clash 常见内核与 mihomo 使用 silent、error、warning、info、debug 等级别。日常使用以 info 为起点；需要排查时改为 debug，重现一次问题后恢复。详细日志会增加输出量，也可能暴露访问的域名。
通过配置调整的步骤
- 备份当前配置，确认客户端支持持久化覆写、配置合并或本地配置编辑中的哪一种方式。
- 在顶层设置
log-level: debug。若已经存在同名字段，修改原字段，不要重复追加。 - 通过客户端的配置重载功能应用改动；若客户端要求重启内核，按其提示操作。
- 打开日志面板，确认不是仍在只显示 warning 或 error。只执行一次失败操作，保留前后约 30 秒记录。
- 收集完成后恢复
log-level: info，避免长期输出大量访问记录。
# 顶层字段片段，合并到现有配置中
log-level: debug以上不是完整配置。直接编辑订阅生成的文件，可能在下次更新时被覆盖。若客户端提供覆写功能，优先使用持久化覆写。菜单位置随客户端版本变化，因此不要把某一款客户端的“设置”路径当作所有 Clash 客户端的统一入口。
一条连接日志要看哪些字段
先看时间，再看目标、规则和错误。连接日志常带 [TCP] 或 [UDP] 标记；match、using 等文字通常用于说明命中的规则与使用的出站。具体输出取决于内核，不能要求每条记录都包含完整字段。
| 字段或内容 | 需要确认的问题 |
|---|---|
| 时间与协议 | 是否对应刚才的失败操作？TCP 与 UDP 是否表现不同？ |
| 来源地址 | 请求是否来自当前设备或预期应用，而不是后台更新、局域网其他设备？ |
| 目标域名与端口 | 是目标网站的 443 端口、DNS 的 53 端口，还是代理服务器自己的服务端口？ |
| 规则与策略 | 预期走代理却命中 DIRECT，还是被 REJECT 拒绝？策略组实际选择了哪个成员？ |
| 错误链末尾 | 连接失败的直接原因是解析、超时、拒绝连接，还是协议与证书错误？ |
DIRECT 表示使用直连出站，不表示请求成功。REJECT 表示按策略拒绝，可能正是预期的拦截结果。即使日志显示使用某个代理组，也要在连接详情或策略页面核对实际选中的节点；自动策略组的成员可能在两次测试之间变化。
dial tcp、timeout 与连接中断的区别
dial tcp：先看后面的地址与原因
dial tcp 192.0.2.10:443: connect: connection refused
dial tcp 192.0.2.10:443: i/o timeout
dial tcp: lookup proxy.example on 127.0.0.1:53: no such hostdial tcp 只说明正在建立 TCP 连接，本身不是故障结论。示例中的 192.0.2.10 是文档示例地址。真实记录中需要判断该地址属于代理服务器，还是直连访问的目标。若连代理服务器都没有成功，修改目标网站的分流规则通常不能解决问题。
- connection refused：连接被明确拒绝，常见于端口没有服务监听、端口填写错误，或防火墙主动拒绝。它不等于账号密码错误；认证通常发生在建立连接之后。
- i/o timeout：某个网络读写操作在期限内未完成。可能是线路丢包、目标没有响应、出口限制或协议阶段卡住，需要结合外层错误判断发生位置。
- network is unreachable：本机或当前网络没有可用路由。优先看网络接口、默认路由与 IPv6 可达性，不先改认证信息。
context deadline exceeded：整体操作超时
这个错误表示带截止时间的操作没有按时完成，可能出现在 DNS 请求、健康检查或连接建立过程中。单看这几个词不能定位节点。应保留外层上下文，例如记录来自 DNS 模块还是代理拨号模块，并对照同一时间的其他连接。
EOF、connection reset by peer：连接建立后被关闭
EOF 表示读取时遇到连接结束；connection reset by peer 表示收到了重置。可能涉及服务端关闭、协议不匹配或中间网络设备干预。若每次都在握手阶段出现，核对节点类型、端口、TLS 设置和传输参数；若仅偶尔出现在空闲连接结束时，且实际访问正常，不必单凭这一条记录判定故障。
DNS 解析失败：区分节点域名、目标域名与解析器
看到 lookup、no such host 或 DNS request failed，先抄下正在解析的域名。节点服务器域名解析失败，会影响通过该节点的全部请求；只有一个目标域名失败，则应先查该域名的记录和解析路径。
| 日志线索 | 含义与下一步 |
|---|---|
| no such host | 解析未得到可用结果，常见于域名不存在或上游返回否定答案。核对拼写、域名状态与实际解析器。 |
| DNS 请求超时 | 先确认 DNS 上游可达、协议配置正确；使用 DoH 时还要考虑其服务器域名如何完成初始解析。 |
| 127.0.0.1:53 连接失败 | 确认本机 53 端口确有 DNS 服务监听。回环地址指当前设备，不能代表路由器或其他设备。 |
| server misbehaving | 通常与 DNS 服务器失败响应有关，应结合具体响应和其他解析器对照，不能直接断言是域名不存在。 |
系统查询结果不一定代表客户端 DNS
例如执行 nslookup example.com，通常查询系统所选解析器。如果客户端使用内置 DNS、fake-ip 或单独的 DNS 上游，这个结果不一定等于应用实际走的解析路径。要先查明运行配置中的监听地址、端口，以及应用请求是否被接管。
fake-ip 模式下出现 198.18.0.0/16 一类地址，可能是配置分配的映射地址，不应仅凭该地址判定解析错误。若应用保留了旧映射，而内核重启后映射状态变化，可能需要关闭相关应用连接并按客户端提供的方式清理缓存，再重新测试。
mihomo 的 proxy-server-nameserver 可用于代理节点域名解析。是否需要该字段，应结合内核版本和现有 DNS 设计判断。不要把用于 mihomo 的字段直接塞入不支持它的旧内核，也不要一次替换所有 DNS 配置；先验证到底是哪一个域名、哪一个上游失败。
端口、TLS 与配置错误的定位入口
address already in use：本地监听端口被占用
如果启动日志提示无法监听 127.0.0.1:7890，先检查是否同时运行了两个客户端，或旧内核尚未退出。7890 只是常见配置示例，应以当前 mixed-port、port 或 socks-port 的实际值为准。
# Windows PowerShell：查看示例端口的监听进程
Get-NetTCPConnection -LocalPort 7890 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
# macOS：查看示例端口的 TCP 监听
lsof -nP -iTCP:7890 -sTCP:LISTEN
# Linux：查看示例端口的 TCP 监听
ss -ltnp 'sport = :7890'确认进程身份后，再通过正常退出应用释放端口，或调整当前监听端口。不要看到 PID 就强制结束未知进程。更改端口后，还要同步更新系统代理或应用中的代理地址，否则会出现“内核正常、应用仍连旧端口”的情况。
x509 与 TLS handshake：检查时间、证书和服务名
x509: certificate has expired or is not yet valid 应先检查设备日期、时区和自动校时，再确认服务端证书有效期。证书名称不匹配时，核对服务端地址、TLS 服务名及提供方要求的配置。TLS handshake timeout 也可能是网络阻断或端口协议不匹配，不能只解释成证书过期。
配置加载失败：先恢复可运行状态
出现 YAML 解析错误、未知策略或缺少代理组时，先回退最近一次修改。YAML 缩进使用空格，避免混入制表符；规则引用的策略名必须与实际定义一致。若内核没有成功加载配置，后续网页访问失败就不是单纯的线路问题。先让配置加载和端口监听成功，再进入连接排查。
按时间线复现：一次只改变一个变量
日志容易被后台同步、自动健康检查和应用重试淹没。有效复现不靠收集越多越好，而是把一个操作与一小段记录对应起来。下面是一套可重复的检查流程，时间仅为操作示例。
- 14:20:00，记录基线。写下客户端版本、内核版本、系统版本、网络类型、当前模式、是否启用 TUN，以及策略组所选节点。
- 14:20:10，开始短时收集。将内核日志调到 debug，在面板中清空旧显示或记下起始时间，保留启动与配置加载的原始错误。
- 14:20:20，访问一个目标。关闭无关标签页，只打开一个此前失败的网址。记下浏览器提示与日志里的目标端口、规则和出站。
- 14:20:40，做一次对照。保持目标、模式与网络不变，只切换一个节点。若节点域名都无法解析，先查 DNS，而不是继续随机切换。
- 14:21:00，归纳差异。是没有流量进入、命中错误规则、节点连接失败，还是连接建立后目标响应异常？把结论写成具体阶段。
没有日志时，检查接管而不是提高日志级别
可以用本机代理请求做对照。下面命令仅适用于当前配置确实在 127.0.0.1:7890 提供 HTTP 或 mixed 代理的情况。Windows PowerShell 可使用 curl.exe，避免与其他命令别名混淆。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/这里的 10 秒是建立连接阶段的超时上限，20 秒是整个请求的时间上限，不是速度指标。该命令使用 HEAD 请求；部分网站对 HEAD 的处理与普通网页不同。它适合检查显式代理路径，不能替代浏览器访问，也不能据此确认 TUN 已接管所有流量。
如果命令能产生连接记录，而浏览器没有记录，应检查浏览器代理扩展、系统代理与应用独立设置。如果 TUN 开启后出现问题，先记录路由与 DNS 状态，再做单次开关对照。不要同时切换 TUN、DNS 模式、节点和规则，否则无法知道哪个改动起作用。
提交故障记录：保留上下文，删除敏感字段
向维护者或服务提供方反馈时，提供失败前后约 30 秒的必要日志，比一张只截最后一行的图片更有用。文字日志便于搜索和比对，但必须先检查内容是否包含凭据和个人信息。
- 保留：准确时间与时区、客户端及内核版本、错误全文、目标端口、命中规则、所用协议和已做过的单变量对照。
- 删除：订阅完整地址、认证令牌、密码、UUID、控制接口密钥，以及不需要公开的访问域名和设备路径。
- 一致脱敏：同一个节点在不同日志中使用同一个代称，避免无法关联；不要把所有域名和地址都替换成同一个词。
- 区分原始与整理：注明哪些是实际日志，哪些是复现步骤。不要把重新编写的示例当作客户端原始输出。
最终结论尽量写成“连接代理服务器的 TCP 阶段超时”“规则将目标送往 DIRECT”或“节点域名解析失败”，而不是只写“Clash 不能用”。先确定失败阶段，再选择对应的网络、规则或配置检查，后续修改才有明确依据。