先看时间线，再看报错关键词
一次只复现一个请求，先找最早的相关错误。“网页打不开”可能卡在接管、域名解析、规则选择、代理连接或目标站响应。日志中的最后一条超时，经常只是前面故障的结果；直接搜到 timeout 就换节点，容易改错地方。
Clash 是内核与客户端生态的统称。旧 Clash 内核、Clash Meta（现称 mihomo）以及不同桌面界面，日志格式和可用字段并不完全相同。界面里的“日志”页通常显示内核运行输出；客户端自身的服务安装、权限和更新错误，可能另存于应用日志。内核未启动时，连接日志为空并不奇怪。
- 记下故障发生的本地时间，例如
14:32:10，同时记录目标域名与使用的程序。 - 关闭无关网页、下载器和持续联网的软件，减少背景连接。
- 打开日志页，清掉界面已有记录；这通常只清显示，不等于删除磁盘日志。
- 只刷新一次目标页面，保留前后约 10 秒的记录。
- 按照“是否进内核 → 解析 → 规则 → 出站 → 应用响应”的顺序检查。
日志级别：日常用 info，复现时用 debug
先在客户端“日志”页查看现有记录。需要更多细节时，在客户端设置中寻找“日志级别”或 Log Level。部分界面支持直接调整内核运行级别；也有界面筛选器只隐藏某些行，并没有改变内核实际输出量。切换后重新发起请求，确认是否出现新的调试信息。
| 级别 | 适用场景 | 阅读重点 |
|---|---|---|
silent | 不适合排障 | 输出被抑制，不能据此判断是否有连接 |
error | 只收集严重错误 | 启动失败等错误，通常缺少正常连接上下文 |
warning | 观察异常 | 连接失败、超时及相关警告 |
info | 日常检查 | 连接目标、规则匹配与所选策略等常见信息 |
debug | 短时复现 | 更细的解析或内部处理信息，具体内容取决于版本 |
配置修改要落在生效配置上
支持通过配置设置级别的内核，可以使用以下顶层字段。不要缩进到 dns: 或 tun: 下面。客户端管理订阅时，优先使用它提供的覆写或合并配置机制；直接改下载后的订阅文件，下次更新可能被覆盖。
log-level: debug保存后按客户端要求重载配置，并检查运行级别是否真的变化。排查完成改回 info。调试输出可能包含访问域名、内网地址及代理服务器信息，长期保留既增加噪声，也扩大分享日志时的信息暴露范围。
连接记录：先拆出目标、规则和出站
14:32:10 INF [TCP] 127.0.0.1:53124 --> example.com:443
match DomainSuffix(example.com) using DIRECT这条示意记录至少提供四个线索：连接使用 TCP；本地来源端口为 53124；目标是 example.com:443；命中了域名后缀规则并选择直连。来源端口通常是应用临时分配的端口，不是 Clash 的监听端口，不能因为看到它就去修改 mixed-port。
- 目标：确认域名或 IP 是否对应刚才的操作。网页还会请求图片、脚本和登录接口，首页域名不是唯一目标。
- 规则：查看命中的规则类型与内容，而不是只看最后显示的策略组名。
- 出站：
DIRECT是直接连接；REJECT是按策略拒绝；代理组后面可能继续显示实际选择的代理。 - 结果：出现连接记录表示内核处理了该连接，不表示 TLS 握手、网页加载或业务请求已经成功。
完全没有相关日志怎么办
先确认日志没有被筛选，再检查流量入口。系统代理只影响遵循该设置的程序；应用内单独填写代理地址时，要核对当前监听地址与端口，例如 127.0.0.1:7890，不要默认所有客户端都使用 7890。TUN 模式还要确认虚拟网卡、路由接管和所需权限已生效。
浏览器复用旧连接时，刷新页面不一定产生新的建连记录。完全退出浏览器后重新打开，或者用新的测试进程发起请求，更容易得到清晰样本。若普通代理测试能留下日志，而原程序始终没有记录，优先排查原程序的接管方式。
dial 失败：区分拒绝连接、超时和路由不可达
dial 表示尝试建立连接。报错中的地址可能是最终目标，也可能是代理服务器或 DNS 上游。先读完整错误链，找出“连接到哪里”，再决定检查网站、节点还是本机网络。
dial tcp 127.0.0.1:7890: connect: connection refused
dial tcp 192.0.2.10:443: i/o timeout
dial tcp [2001:db8::10]:443: connect: network is unreachable上面的 192.0.2.10 和 2001:db8::10 是文档示例地址，不是可测试的节点。三种错误分别侧重“对端拒绝”“规定时间内未完成”“没有可用网络路径”，处理方向不同。
connection refused：先查地址与监听
若被拒绝的是 127.0.0.1:7890，常见原因是代理内核未启动、端口已经改动，或程序仍使用旧设置。Windows 可在 PowerShell 检查 TCP 监听；macOS、Linux 可在终端查看监听进程。以下命令仅查询，不会终止进程：
# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen
# macOS / Linux，需已安装 lsof
lsof -nP -iTCP:7890 -sTCP:LISTEN没有监听时，回到客户端检查运行状态。有监听时，核对进程是否为预期内核。远端代理地址被拒绝，则检查订阅中的服务器端口和服务状态；修改本地混合端口不能修复远端拒绝。
i/o timeout：确认是哪一段超时
超时不等于节点永久失效。它可能来自网络丢包、防火墙丢弃、代理服务器不可达，或目标站响应缓慢。保持目标不变，只切换同一策略组内另一个代理，再比较错误地址与时间。如果所有代理都失败，继续检查本机网络及代理服务器域名解析；不要同时改 DNS、TUN 和规则。
network is unreachable：检查路由与地址族
错误地址带方括号时通常是 IPv6。网络缺少可用 IPv6 路由、VPN 路由冲突或 TUN 接管异常，都可能导致不可达。先确认系统本身能否访问同一地址族，再检查路由变化。单条 IPv6 错误并不能证明整个请求失败，后续可能还有 IPv4 重试，需要把相邻记录一起看。
DNS 解析超时：区分上游故障与连接故障
lookup example.com: i/o timeout
exchange failed: context deadline exceeded
lookup example.com: no such host这些示意输出分别可能指向查询超时、DNS 交换超过期限、名称不存在等问题。实际日志还可能包含上游地址、查询类型及底层连接错误。no such host 不等同于超时：先核对域名拼写，再检查回答来源与过滤设置。
- 确认谁在解析：系统 DNS、应用自己的 DoH，还是 mihomo 内置 DNS。浏览器的安全 DNS 开关会影响路径，TUN 的 DNS 劫持也可能改变实际去向。
- 确认上游可达：传统 DNS 常用 UDP/TCP 53，DoT 常用 TCP 853，DoH 通常使用 HTTPS 443。端口可连接只说明传输层可达，不代表 DNS 查询必然成功。
- 区分两类域名：目标网站域名和代理服务器域名都可能需要解析。代理服务器解析失败时，之后的代理连接也会失败。
- 检查依赖关系：需要走代理才能访问的 DNS 上游，若又依赖尚未解析出的代理服务器，可能形成启动依赖问题。
系统查询只用于对照
nslookup example.com这个命令可以观察系统默认查询路径的结果，但不能证明 mihomo 内置 DNS 正常。在 TUN 或 DNS 劫持生效时，它也可能被内核接管。要判断是否使用相同路径，需要结合当前配置和日志中的上游信息，不能简单得出“系统能解析，所以 Clash DNS 没问题”。
mihomo 的 proxy-server-nameserver 可用于代理服务器域名解析，default-nameserver 涉及解析 DNS 服务器自身的域名；具体行为和支持项应以当前内核文档为准。旧 Clash 配置不一定支持这些字段，不要整段复制新内核示例。涉及 respect-rules 等选项时，还应检查 DNS 请求是否被规则送到了依赖它自身的代理路径。
规则未命中：检查运行模式、顺序和目标类型
“规则未命中”不一定是一条明确报错。更常见的表现是日志显示 Match 兜底，或者出站与预期不同。先确认客户端处于规则模式：全局模式和直连模式不会按普通规则模式选择每条连接的出站。
# 配置片段：并非完整订阅
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,DIRECT规则按顺序检查，先匹配的规则决定结果。上面的具体域名规则放在兜底前；若把 MATCH 放到前面，后面的普通规则就没有机会处理连接。示例只使用内置目标 DIRECT；换成自定义策略组名时，必须在完整配置的 proxy-groups 中定义该组。
- 域名不一致：
DOMAIN匹配指定域名，DOMAIN-SUFFIX匹配后缀及相应子域名。网页重定向后的登录域名，可能不在原规则范围内。 - 只获得 IP：应用直接连接 IP 或域名信息未被保留时，域名规则可能无法参与匹配。流量嗅探是否可恢复域名，取决于协议、配置与内核支持，不能保证所有连接都可恢复。
- 规则集没有加载：查看启动或配置重载时的 provider 下载、解析错误。规则集的格式与
behavior要匹配；订阅下载成功不代表每个规则集也加载成功。 - 覆写未合并：确认当前激活的是哪份配置。编辑另一个配置文件，或写错合并层级，都可能导致规则没有进入运行配置。
- 策略组选择不同：命中预期规则仍可能走错代理，因为组内手动选择、自动测试结果或嵌套组指向已变化。
验证时只添加一条针对目标域名的临时规则，放在相关宽泛规则之前，重载后建立新连接。看到规则名与出站都符合预期，再判断是否解决了实际访问问题。规则写法与混合端口说明可继续查看配置进阶。
按时间线定位：一次复现只改一个变量
下面是排查记录示例，不代表真实测速结果。假设 14:32:10 刷新页面，14:32:10 命中预期策略组，14:32:15 出现代理服务器连接超时。优先检查代理服务器路径；如果 14:32:10 就出现它的域名解析失败，解析才是更早的故障点。
| 观察结果 | 下一步 | 暂时不要做 |
|---|---|---|
| 没有目标连接记录 | 核对日志筛选、系统代理、应用代理或 TUN 接管 | 批量更换节点 |
| 代理服务器域名解析失败 | 检查解析上游和启动依赖 | 只改目标网站规则 |
| 命中兜底或错误规则 | 检查规则模式、顺序、域名与运行配置 | 凭延迟数字判断规则正确 |
| 预期出站连接被拒绝或超时 | 核对远端地址、端口及另一代理的对照结果 | 同时重置全部网络设置 |
| 连接建立但应用仍失败 | 检查 TLS、HTTP 状态和应用日志 | 把所有失败归为 DNS 问题 |
用明确代理请求验证入口
若当前混合端口确实为 7890，可以用下面的请求验证 HTTP 代理入口。Windows 使用 curl.exe 可避免部分 PowerShell 环境中的命令别名差异；macOS、Linux 通常使用 curl。
# Windows
curl.exe -I --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 https://example.com/
# macOS / Linux
curl -I --proxy http://127.0.0.1:7890 --connect-timeout 5 --max-time 15 https://example.com/这里 5 秒是连接阶段限时，15 秒是整个请求限时，只影响这次 curl 测试，不会修改内核全局超时。-I 请求响应头；即使目标返回 403 或 405，也不能直接当成代理故障，要结合是否已建立连接及响应来源判断。此测试明确走本地 HTTP 代理入口，不能单独证明 TUN 对其他程序的接管正常。
如果日志只显示连接已处理，浏览器仍报告证书或登录错误，继续查看浏览器开发者工具的网络状态与应用错误。Clash 运行日志不是完整 HTTP 抓包，通常不能直接给出业务接口的所有响应内容。内核日志负责定位传输路径，应用日志负责补齐更上层的原因。
分享排障日志：保留上下文，隐藏敏感字段
发给维护者的材料，重点是可复现而不是数量多。保留同一请求前后约 10 秒的文本、当前模式、系统版本、客户端版本和内核版本，并说明是否启用系统代理或 TUN。客户端版本与 mihomo 内核版本分别记录，不要用其中一个代替另一个。
- 写明操作与预期：例如“打开目标页面，预期命中指定域名规则，实际走了 MATCH”。
- 保留完整错误链、规则类型、地址族和端口，否则难以区分远端与本地故障。
- 删除订阅链接、认证信息、控制接口密钥及访问令牌。
- 代理服务器、用户名和内网地址可以使用一致的脱敏代号，同一对象始终使用同一个代号。
- 附上最近一次修改，以及修改前后同一请求的结果；不要只截取一行红色错误。