为什么先看日志，而不是先改规则

很多「某个网站打不开」的问题，表面上是分流规则不对，实际上却是 DNS 解析走了意外路径、策略组选到了不健康节点，或 应用根本没把流量交给 Clash。若你直接在 YAML 里加几条 DOMAIN-SUFFIX 试探，往往越改越乱，因为真正的原因从未被证实。

Clash 日志（或图形客户端里的「连接 / Connections」视图）的价值在于：把一次访问拆成可核对的步骤——匹配了哪条规则、最终策略是什么、出站协议与目标地址是什么、失败时错误信息是什么。先拿到这份证据，再回去改规则或 DNS，才是可复现、可回滚的调试方式。若你尚未建立整体分流概念，可先阅读 Clash 分流规则配置教程，再对照本文的日志字段，会更容易把「列表上的规则」与「实际命中」对上号。

日志在哪里开：级别与噪声

在 Clash Meta（Mihomo） 系配置中，通常存在 log-level 字段，常见取值为 silent、error、warning、info、debug。日常建议至少 info：能看到连接建立与规则匹配的关键行；需要排查握手、DNS 细节时再临时切到 debug，用完即改回，以免日志量与磁盘占用失控。

图形客户端（如 Clash Verge Rev 等）往往在设置里提供「日志等级」或「调试模式」开关，并带有独立日志面板。请优先使用客户端内置的查看方式，而不是去猜内核原始日志路径；不同操作系统打包路径差异很大，跟文档走最稳。若你同时开启 TUN，请记得日志里会出现更多「被内核接管」的连接，这是正常现象，不必把每一条都当作异常。

一条连接日志里，优先看哪些字段

不同客户端展示格式略有差异，但 Clash 系日志通常包含以下信息（名称可能略有不同）：

• 时间与类型：例如 TCP 连接、UDP 会话、DNS 查询，帮助判断是「还没建连」还是「已建连但传输失败」。
• 目标主机 / IP / 端口：确认你访问的域名是否被解析成预期地址；若出现意料之外的 IP，优先怀疑 DNS 模式或 fake-ip 行为。
• 规则（Rule）或策略（Policy）：显示最终命中的规则类型（如 DOMAIN、DOMAIN-SUFFIX、GEOIP）与指向的策略组或代理名。
• 出站（Proxy / Chain）：实际使用的节点或策略组解析结果；若这里是 DIRECT 而你的网站在海外，往往说明规则顺序或 GEOIP 数据有问题。
• 延迟或错误：超时、连接重置、TLS 握手失败等，是区分「节点问题」与「本地规则问题」的关键。

把这些字段当作「最小证据集」：只要 规则命中 + 出站 + 错误信息 三者一致，就能在多数场景下判断下一步该改 DNS、改策略组还是改节点。

规则命中与 YAML 顺序：第一条匹配即生效

Clash 的规则列表是自上而下匹配，命中即停止。日志里显示的「命中规则」对应的是真正生效的那一条，而不是你心理上认为「最合理」的那一条。因此，当你发现某域名走了 DIRECT 或错误策略组时，第一件事是：在配置文件中从上往下搜索，找到最先覆盖该域名的条目。

常见误判包括：上游订阅自带的规则集里已有更宽泛的 DOMAIN 规则；你在本地追加的规则写在文件末尾，永远轮不到；或 Rule Provider 更新后引入了新的高优先级条目。此时日志里看到的「规则名 / 类型」就是你在 YAML 或规则集里应对照的锚点。若需要系统理解「国内直连、海外代理」的整体写法，可参考 使用文档中心 中的规则与 DNS 章节，再回到日志逐条核对。

如何区分：DNS 问题、规则问题还是节点问题

下面是一套可操作的判别逻辑，可按顺序执行：

1. 看 DNS 解析：若日志中显示解析失败、NXDOMAIN，或解析到的 IP 明显与站点真实归属不符，优先检查 dns 配置、DNS 模式（如 fake-ip、redir-host）与是否启用 respect-rules 等选项，而不是先换节点。
2. 看规则命中：若解析正常，但命中规则指向了 DIRECT 或错误策略组，说明是规则或顺序问题；此时应调整规则或规则集，而不是质疑节点质量。
3. 看出站与错误：若规则已指向代理策略组，且多次尝试仍超时或握手失败，再换同组其他节点或检查机场线路；若仅个别站点失败，也可能是 SNI 或证书问题，需要结合错误信息判断。

把三类问题分开处理，能避免「明明 DNS 错了却一直在换节点」的无效循环。若你同时开启 TUN，还要确认应用流量确实进入 Clash 栈，而不是绕过虚拟网卡；有关 TUN 与系统代理的差异，可补充阅读 Clash TUN 模式详解。

常见失败形态与日志里的线索

长时间无响应或超时

若日志显示已匹配代理规则，但连接建立阶段反复超时，优先怀疑节点到目标网络的连通性、本地防火墙或运营商 QoS。可尝试在策略组中切换节点，或临时用同一策略组访问其他 HTTPS 站点做对比。

TLS 握手失败或证书错误

此类错误有时与代理协议与 TLS 特性相关，也可能与系统时间、中间人检测有关。若仅个别域名失败，记录完整域名与 SNI 信息，再对照规则与节点是否支持该协议。

DNS 查询失败或返回异常

日志中若出现 DNS 相关报错，或解析结果与预期域名不一致，应回到 dns 段与 nameserver、fallback 逻辑，而不是先调整 rules。fake-ip 模式下还要注意「域名与 IP 的映射」在日志中的呈现方式，避免把正常现象误判为劫持。

对照配置调试的推荐流程

建议把排障固定成四步，便于下次复用：

• 冻结变量：同一网络、同一客户端版本、只动一个参数（规则或 DNS 或节点）。
• 抓取一条干净日志：从点击访问到出错，完整复制相关行。
• 在 YAML 中定位：用日志中的域名或规则类型搜索，确认命中顺序与策略组定义。
• 验证：修改后重复短窗口复现，确认日志中「命中规则」与「出站」已符合预期。

长期坚持这一流程，你会逐渐熟悉自己订阅与规则集的习惯写法，排障时间也会明显缩短。

开源信息与安装包入口

Clash 生态依赖开源社区与公开文档，在 GitHub 上查阅内核发行说明、比对版本与提交 Issue，都是长期用户的良好习惯。需要强调的是：GitHub 适合用于核对版本与参与社区讨论；日常安装与升级客户端，仍建议以本站 下载聚合页 为主入口，避免误入仿冒 Release 页面。

小结

网站打不开时，Clash 日志与规则命中信息是把主观猜测变成客观证据的捷径：先确认规则是否按预期命中，再区分 DNS 与节点层问题，最后才动大刀改配置。相比在界面里盲目切换「全局」与「规则」，这种顺序能显著减少误伤国内直连与本地局域网的风险。

若你希望在一套稳定、可维护的客户端上完成上述观察与调试，不妨从本站 Clash 客户端下载页 获取安装包，先以默认配置与清晰日志级别建立基线，再逐步叠加自己的分流规则；相比缺少日志入口的旧工具，能看清「流量怎么走」的现代客户端，长期省心得多。→ 立即免费下载 Clash，开启流畅上网新体验