先确认看的是什么日志

Clash 客户端通常同时包含图形界面与代理核心。界面负责导入配置、切换节点和修改设置，Clash Meta（mihomo）等核心负责监听端口、解析 DNS、匹配规则并建立连接。排查网络问题时，真正有价值的通常是核心运行日志，而不是安装记录或界面的崩溃报告。

一条典型日志会给出时间、级别、连接来源、目标地址、命中的规则和最终出口。不同客户端的排版略有区别，但信息含义基本一致。例如：

2026-06-02 14:32:18 INFO [TCP] 127.0.0.1:51842
--> api.example.com:443
match DomainSuffix(example.com) using Proxy[Node-A]

这条记录表示：本机端口 51842 发起了 TCP 连接，目标是 api.example.com:443，配置中的 DOMAIN-SUFFIX,example.com 规则命中，连接最终交给名为 Proxy 的策略组，组内实际使用 Node-A。它能证明流量已进入 Clash，也能说明规则和出口选择结果，但不能单独证明目标网站已经返回正常内容。

界面日志与核心日志的区别

  • 核心日志：包含 TCP、UDP、DNS、规则匹配、代理握手和 TUN 入站信息，是连接排查的主要依据。
  • 界面日志：记录配置保存、托盘操作、窗口加载、更新检查等事件，适合排查客户端无法启动或按钮无响应。
  • 服务日志：部分 Windows 客户端会安装系统服务，用于接管 TUN 或提升权限。服务启动失败时，应同时查看服务日志。
  • 订阅更新记录：用于判断远程配置请求是否返回 200、401、403、404 或超时，不等同于日常代理连接日志。

日志级别怎么选

Clash 配置中的 log-level 控制核心输出量。mihomo 1.19.x 常用级别包括 silent、error、warning、info 和 debug。部分图形客户端会将 warning 简写为 Warn，或把级别放在「内核设置」中。

级别 主要内容 适用场景
silent 停止常规输出 长期运行且不需要观察时使用，不适合排障
error 明确失败的操作 确认核心是否持续出现严重错误
warning 警告与错误 观察配置兼容性、DNS 异常和资源加载问题
info 连接、规则命中与常规状态 首次排查连接失败或规则不生效，优先使用
debug 更细的解析、拨号和内部处理信息 Info 无法定位时短时开启

多数问题先用 Info 即可。Debug 的记录量可能在几分钟内增长到数千行，浏览器后台连接还会掩盖真正的失败请求。建议只在复现前开启，完成一次测试后立即恢复 Info。

直接编辑 YAML 时，可在顶层设置：

log-level: info

以 Clash Verge Rev 2.3.x 为例，可先打开「设置」→「Clash 设置」→「日志等级」，选择 Info；查看记录时进入「日志」。不同小版本可能把入口写成「内核日志」或「运行日志」。如果界面修改后没有生效，检查当前配置是否由订阅托管，以及客户端是否在切换配置后覆盖了本地参数。

从一行记录拆解连接路径

读日志时不要只搜索红色 Error。很多网页打不开的问题会以普通 Info 记录出现，因为核心成功接收了请求，只是在后续拨号阶段超时。更有效的方法是按「入站、目标、规则、策略、结果」五项依次阅读。

  1. 入站来源：确认请求来自 HTTP、SOCKS、Mixed 或 TUN。常见本地监听地址是 127.0.0.1，Mixed 端口常设为 7890。
  2. 目标地址：查看目标是域名还是 IP，以及端口是否为 80、443、53 或应用自定义端口。
  3. 规则命中：识别 Domain、DomainSuffix、GeoIP、IPCIDR、RuleSet 或最终 Match。
  4. 策略出口：确认流量走 DIRECT、REJECT，还是进入某个代理组及具体节点。
  5. 连接结果：继续查看同一时间附近是否出现 timeout、refused、TLS、DNS 或 EOF。

如何判断系统代理没有接管流量

清空日志后访问一个此前未打开的网站，如果日志完全没有新增 TCP 或 UDP 连接，问题通常发生在请求进入核心之前。先检查系统代理是否开启，再核对应用是否绕过系统代理。Windows 可在「设置」→「网络和 Internet」→「代理」中查看手动代理状态；常见 HTTP 代理地址为 127.0.0.1:7890，实际端口以客户端显示为准。

如果浏览器有独立代理扩展，扩展中的端口也必须与 Clash 当前监听端口一致。日志为空时反复换节点通常没有意义，因为节点根本没有收到请求。使用 TUN 模式时，还应确认日志中能看到 TUN 入站启动记录，并检查虚拟网卡是否已经建立。

如何判断规则命中错误

目标能出现在日志里，但出口与预期不同，应把注意力放在 match 后面的规则上。例如目标本应代理，却显示：

INFO [TCP] 198.18.0.1:42116 --> service.example.com:443
match GeoIP(CN) using DIRECT

198.18.0.1 可能是 Fake-IP 映射地址，并不代表真实服务器位于该地址。重点是最终命中了 GeoIP 并走 DIRECT。若域名规则应当优先命中，应检查规则顺序、规则集是否成功加载，以及域名是否被过早解析为 IP。Clash 规则按从上到下的顺序匹配，第一条命中后不会继续检查后面的规则。

高频报错分别表示什么

i/o timeout 与 context deadline exceeded

这两类文字都指向超时，但超时位置可能不同。连接节点地址超时，常见原因是节点离线、端口不可达、网络阻断或 UDP 不通；连接目标站点超时，则可能是节点到目标的链路异常。先查看报错中的地址：如果是节点服务器 IP 和节点端口，应切换到另一个已通过延迟测试的节点；如果是目标域名的 443 端口，应比较 DIRECT 与代理出口。

延迟测试显示 80 ms 不等于节点一定可用。部分测试只访问固定 URL，真实网站还涉及 DNS、TLS 和目标服务器策略。可连续测试三次，若结果在 80 ms、450 ms、超时之间剧烈变化，节点链路本身就不稳定。

connection refused

connect: connection refused 表示目标主机明确拒绝了连接，通常比超时更快返回。若被拒绝的是 127.0.0.1:7890，说明应用正在连接本地代理端口，但该端口没有进程监听，可能是核心未启动或端口已修改。若被拒绝的是远程节点端口，常见情况是服务端进程停止、端口变更或订阅中的节点信息过期。

Windows 可执行 netstat -ano | findstr 7890 查看端口；macOS 或 Linux 可执行 lsof -i :7890。如果没有 LISTEN 记录，先恢复核心运行，不必继续检查规则。

no such host、server misbehaving 与 DNS 超时

no such host 通常表示域名没有获得可用解析结果。原因可能是域名拼写错误、上游 DNS 返回 NXDOMAIN，或 Clash 无法访问配置中的 nameserver。server misbehaving 多见于 DNS 上游返回异常或请求流程中断。日志若同时出现 lookup、exchange failed、deadline exceeded，应优先排查 DNS，而不是节点规则。

可先确认配置中的 DNS 开关和监听地址，例如：

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

这里的 1053 是 Clash DNS 监听端口，不是浏览器代理端口。若系统或其他程序需要向该端口发送 DNS 请求，还要确保端口未被占用。使用 DoH 时，应同时考虑 DoH 域名自身的首次解析问题；必要时通过 default-nameserver 提供可直接访问的 IP 型 DNS。

TLS handshake timeout 与证书相关文字

TLS handshake timeout 表示 TCP 连接可能已经建立，但 TLS 握手未在限定时间内完成。它可能由节点质量、目标网站响应慢、中间网络丢包或系统时间异常引起。先核对系统日期、时区和自动校时，再换节点复测。如果只有一个域名失败，问题更可能集中在目标站点或该域名的路由。

x509、certificate signed by unknown authority 或域名不匹配则属于证书校验失败。不要直接关闭证书验证作为长期处理方式。应检查系统时间、本地抓包软件、企业网络证书和节点返回内容，确认连接是否被重定向到了错误服务器。

EOF、connection reset by peer 与 broken pipe

EOF 表示数据流提前结束，单独出现一次不一定构成故障，浏览器取消请求也可能产生 EOF。connection reset by peer 表示远端主动重置连接；broken pipe 表示本地继续写入时，对端连接已经关闭。若这些记录只在关闭页面时出现，可以忽略；若每次访问都在 1 至 2 秒内重复出现，应切换节点、关闭 QUIC 后重试，并检查目标是否限制当前出口 IP。

按现象定位节点、规则与 DNS

节点延迟正常，但网页打不开

  1. 将日志等级设为 Info，清空现有记录。
  2. 只访问一个 HTTPS 网站，记录目标域名和操作时间。
  3. 确认日志出现目标域名，并查看实际使用的策略组和节点。
  4. 搜索同一分钟内的 timeout、TLS、reset 和 EOF。
  5. 固定同一规则，换另一个节点复测，避免同时修改多个变量。
  6. 若所有节点都失败，再切换 DIRECT 对比，并检查 DNS 解析结果。

如果换节点后立即恢复，问题集中在原节点或其上游线路。如果所有节点都在解析阶段失败，优先看 DNS。如果日志显示 DIRECT，而预期是代理，则处理规则顺序或策略组选择。

只有某个应用无法连接

浏览器正常而某个应用完全不产生日志，通常说明该应用没有使用系统代理。部分游戏、命令行工具和商店应用会直接建立连接，此时可启用 TUN 模式接管更多流量。启用后应检查 TUN 设备是否启动、路由是否写入，以及是否出现权限错误。

如果应用能产生日志但 UDP 持续失败，确认所选节点是否支持 UDP，并查看策略组是否允许 UDP。TUN 的 MTU 也可能影响特定网络；默认值出现分片问题时，可按客户端支持范围从 1500 调整到 1400 进行一次对比测试，但不应在没有现象依据时频繁修改。

规则模式不生效，切全局模式却正常

这类情况通常与规则命中有关。全局模式会绕过大部分规则判断，直接使用选定代理组，因此能证明节点至少具备基础连接能力。切回规则模式后，搜索目标域名并查看命中项。如果落到 MATCH,DIRECT，应检查末尾规则；如果命中过期规则集，查看规则提供器是否下载失败。

规则集加载问题常伴随 HTTP 404、403、超时或 YAML 解析错误。修正远程地址后，在客户端执行「配置」→「更新」或对应的规则集更新操作，再确认日志出现加载成功记录。只修改策略组名称而不更新规则引用，会造成规则指向不存在的策略。

TUN 模式日志要额外看什么

TUN 模式在系统网络层接收流量，日志中可能出现虚拟网卡、路由、DNS 劫持和接口选择信息。核心启动后若没有创建 TUN 设备，常见原因包括权限不足、系统服务未运行、虚拟网卡冲突或其他 VPN 正在占用路由。

  • 启动即报权限错误：检查客户端服务状态，并按操作系统要求授予管理员权限。
  • 启动成功但全网断开：检查默认接口识别、DNS 劫持目标和路由写入是否正常。
  • 局域网设备无法访问：查看私有网段是否被错误送入代理，常见网段包括 192.168.0.0/16、10.0.0.0/8 和 172.16.0.0/12。
  • 部分 UDP 应用异常：确认节点协议支持 UDP，并观察是否出现超时或网络不可达。
  • 退出后网络未恢复：先完全关闭核心，再检查系统代理、DNS 和默认路由是否仍保留旧值。

整理一份可用的故障记录

向配置提供方或客户端项目反馈时，完整屏幕截图往往不如一段经过整理的文本有效。建议保留核心版本、客户端版本、操作系统、发生时间、代理模式、目标域名、命中策略和连续错误行。mihomo 核心版本可在客户端「关于」或「内核」页面查看，例如 mihomo v1.19.x；客户端版本也应精确到小版本。

提交前应删除订阅地址、认证参数、节点服务器凭据和局域网设备名称。公网目标域名、错误类型和规则名称通常需要保留，否则无法判断请求在哪一步失败。可按下面的格式整理：

系统：Windows 11 24H2
客户端：Clash Verge Rev 2.3.x
核心：mihomo 1.19.x
模式：Rule + TUN
发生时间：2026-06-02 14:32
现象：浏览器访问目标域名持续超时
命中：DomainSuffix → Proxy → Node-A
错误：dial tcp 203.0.113.10:443: i/o timeout
对比：切换 Node-B 后连接恢复

这份记录已经能把范围缩小到 Node-A 或其链路，不需要附上数分钟的全部后台连接。若问题与 DNS 有关，再补充 nameserver 类型、Fake-IP 或 Redir-Host 模式、查询失败文字即可。

日志排查顺序总结

稳定的排查顺序是：先确认流量有没有进入 Clash，再确认目标和端口，然后查看命中的规则、策略组与实际节点，最后读取紧随其后的错误。日志为空时检查系统代理或 TUN 接管；出口错误时检查规则；出现 lookup 或 no such host 时检查 DNS；出现 timeout、refused、TLS 和 reset 时再判断节点或远端链路。

Info 级别适合大多数场景，Debug 只在缺少关键细节时短时开启。完成复现后恢复原设置，并保留一份精简、带时间和版本信息的日志。这样可以避免凭感觉反复换配置，也能更快判断问题位于客户端、规则、DNS、节点还是目标网站。