先保留现场：日志时间、请求目标与实际内核

Clash 显示“已连接”，通常只表示内核运行或本地代理入口已启用，不代表每个网站都能建立连接。判断故障要沿着请求路径看：应用是否进入代理、域名是否解析、规则选择了什么策略、节点连接是否成功、远端是否返回响应。

Clash、Clash Meta（现通常以 mihomo 内核维护）以及不同图形客户端的日志格式并不完全相同。下面展示的是字段与报错片段示意，不是某个版本逐字固定的输出。先在客户端“关于”或内核信息页面记录内核名称和版本，再按对应内核的配置说明排查，不能只记录外层客户端的版本。

  1. 记录复现时间：精确到秒，例如 14:32:10。清空日志视图前，先保存当前关键报错。
  2. 缩小请求范围：暂停下载和后台更新，只打开一个出问题的网址，避免几十条并发连接混在一起。
  3. 记录环境：系统、客户端与内核版本、规则或全局模式、系统代理与 TUN 开关、当前策略组及节点。
  4. 只改一项：每次修改后发起新请求，比较相同目标的结果，不同时更换 DNS、节点和规则。

日志级别设置：日常用 info，复现时短暂用 debug

在客户端侧栏的“日志”或“运行日志”页面查看输出；日志级别的入口名称因客户端而异，可能位于设置或内核设置中。界面的日志筛选不一定等于修改内核输出级别：只筛选“调试”无法找回内核没有生成的记录。

Clash 与 mihomo 常用配置字段是顶层 log-level，支持 silent、error、warning、info、debug。以下是配置片段，需要合并到当前配置，不是独立可用的订阅：

# 顶层字段，与 mode、rules 同级
log-level: debug

保存后按客户端要求重载配置或重启内核，确认新设置已生效。订阅更新可能覆盖直接编辑的内容；客户端支持覆写或合并配置时，优先使用该机制。完成复现后改回 info，不要长期依赖大量调试输出。

读懂一条连接记录：先看目标，再看规则与出站

一条记录里可能同时出现源地址、目标域名、命中规则、策略组、最终节点和错误原因。阅读顺序很重要：报错前的 DIRECT 与代理节点名称，会决定下一步应该检查哪一段链路。

# 字段示意，不代表固定日志格式
[TCP] 127.0.0.1:53124 --> example.com:443
match DomainSuffix(example.com)
using Proxy[节点 A]
error: dial tcp 203.0.113.10:443: i/o timeout

这里的 53124 是应用本次连接的临时源端口，不是要填进系统代理的监听端口。example.com:443 是请求目标，Proxy 是策略名称。示例中的文档保留地址 203.0.113.10 仅用于说明，不能用于连通性测试。

记录线索先确认的事实对应配置或入口
完全没有新连接请求是否进入本地代理系统代理、mixed-port、TUN、应用设置
目标域名解析失败哪个解析环节失败dns、节点域名解析、系统解析器
命中 DIRECT是否符合预期分流mode、rules、规则集
经过代理后超时节点入口还是最终目标不可达proxies、proxy-groups、节点服务状态
监听端口启动失败端口是否已被占用mixed-port、port、socks-port、控制端口

dial timeout：区分节点入口超时与目标连接超时

dial timeout、i/o timeout 或 context deadline exceeded 都表示某个操作未在期限内完成，但不能只凭“超时”断定 DNS 出错。先读同一行的地址和前后日志：如果失败地址是节点服务器，优先检查本机到节点的路径；如果是直连目标，则检查直连路径与分流是否正确。

按四步缩小范围

  1. 在策略组中手动选择另一个节点，重新发起同一个请求。另一个节点成功，说明问题更集中在原节点或其线路，但还不足以证明协议本身有问题。
  2. 换一个目标网站。如果只有一个目标失败，检查目标站点状态、出口地区限制及节点到目标的路径。
  3. 保持节点不变，切换一次网络，例如从 Wi-Fi 改为手机热点。结果改变时，重点检查本地网络、防火墙或运营商路径。
  4. 对照节点配置中的服务器地址、端口和协议参数。订阅过期、服务端端口调整也会造成连接失败，修改前先更新订阅并确认账户状态。

延迟测试成功只说明测试目标在当时可以完成相应探测，不代表流媒体、文件下载和 UDP 都可用。不要把测试结果的 80 ms 直接解释为网页一定能在 80 ms 内加载。

connection refused 与 timeout 不同

connection refused 通常表示收到了主动拒绝，例如目标端口没有服务监听，或防火墙返回了拒绝响应。若地址为 127.0.0.1:7890，先确认本机代理是否监听该端口；若地址属于节点服务器，则核对节点端口与服务状态。盲目增加超时时间不能解决端口被拒绝的问题。

DNS 解析失败：分清请求域名、节点域名与上游解析器

no such host、lookup ... failed、DNS query timeout 等信息指向解析环节，但需要继续判断失败对象。访问目标域名需要解析，代理服务器使用域名时也需要解析；配置为域名形式的加密 DNS 上游，还涉及如何先解析上游自身地址。

Windows 可先运行 nslookup example.com，macOS 或 Linux 在安装对应工具后可运行 dig example.com。这些命令通常检查系统使用的解析路径，不一定经过 Clash 内置 DNS；系统解析成功与内核解析成功必须分别验证。

Fake-IP 地址不是解析错误的直接证据

在 Fake-IP 模式下，应用获得合成地址可能是正常行为。常见配置使用 198.18.0.0/16 范围，这与真实网站的公网地址不同。要确认后续连接是否进入内核并恢复域名映射，而不是看到这个地址就切换节点。

若问题出现在切换 DNS 模式之后，先重新建立应用连接，必要时刷新系统 DNS 缓存。不要立即把所有域名加入 fake-ip-filter；先用一个确实不兼容的域名验证，再做最小范围调整。字段说明可查阅 DNS 配置参考与 Fake-IP 说明。

规则未命中：从模式、顺序和域名可见性检查

“没有走预期节点”不一定会产生错误日志。请求可能正常命中了较前面的直连规则，也可能处于全局模式，根本没有按预期的规则列表分流。先核对运行模式，再检查连接记录中的实际规则和策略。

# 分流片段；Proxy 必须是已有的策略名称
mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

规则按从上到下的顺序匹配，命中后停止。若把 MATCH,DIRECT 放到第一行，下面的域名规则就没有机会生效。示例中的 Proxy 不是内置保留名称，必须与配置中已有代理或策略组的名称完全一致。

  1. 确认规则模式：全局模式通常由全局策略决定出站，直连模式则绕过预期代理策略。模式说明见 代理模式设置。
  2. 确认当前配置：检查编辑的是否为正在使用的配置；订阅刷新后，自定义规则是否仍保留。
  3. 确认规则集状态：使用 RULE-SET 时，查看对应提供者是否加载成功，名称和内容格式是否与声明一致。
  4. 确认域名信息：应用若直接连接 IP，域名规则可能无法命中。嗅探能在部分场景补充域名信息，但不能保证恢复所有连接的域名。
  5. 重新建立连接：既有长连接可能沿用原来的出站。关闭相关页面或应用连接后再测试，避免把旧连接当成新规则的结果。

启动与权限报错：端口占用、配置错误和 TUN

address already in use：先确认是谁占用了端口

如果内核启动时报 bind: address already in use，先看被占用的是代理端口、DNS 监听端口还是控制接口端口。以下命令以 7890 为示例；实际端口以当前配置为准，不同客户端默认值可能不同。

# Windows：查看监听端口及进程编号
netstat -ano | findstr :7890

# macOS：查看 TCP 监听进程
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：查看 TCP 监听套接字
ss -ltnp 'sport = :7890'

确认进程身份后，退出重复运行的客户端，或修改本地监听端口。若把 mixed-port 从 7890 改为 7891，系统代理和应用内代理也要同步更新。不要看到进程编号就直接终止未知系统服务。

YAML 与策略引用错误：先让配置通过加载

yaml: line ... 往往提示语法或结构问题。使用空格缩进，不用 Tab；含有特殊字符的值应按 YAML 规则加引号。报错行可能只是解析器无法继续的位置，实际错误也可能在上一行。策略不存在、规则集名称写错则属于配置引用问题，不能靠重启网络解决。

TUN permission denied：检查系统授权与接管范围

TUN 创建失败可能涉及管理员权限、客户端服务模式或操作系统 VPN 授权。Windows 通常要检查服务及提权状态，Android 要确认已批准 VPN 请求；具体操作应以客户端说明为准。启用 TUN 不等于所有流量都会自动进入代理，路由、排除项和已有 VPN 都会影响接管结果。

若普通显式代理可用而 TUN 不可用，保留同一节点和配置，只切换接管方式做对照。这样可以把问题集中到虚拟接口、路由或 DNS 接管，而不是同时怀疑订阅和节点。

验证修复：用同一请求比较前后结果

日志变少不等于故障消失。修复后应使用同一目标、同一网络和同一节点复测，确认请求确实到达预期策略，并获得应用层响应。浏览器可能缓存页面，因此最好重新发起请求；终端可以显式指定本地代理，避免环境变量带来干扰。

# 本地 mixed-port 为 7890 时的 HTTP 代理测试
# Windows 可将 curl 写为 curl.exe
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

# mixed-port 或 SOCKS 入口为 7890 时的 SOCKS 测试
curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

socks5h 表示把域名交给 SOCKS 代理端解析，适合与本地解析路径做区分。测试返回 HTTP 403 等响应，说明已经获得某个 HTTP 端点的响应，但访问仍可能受到目标站点策略限制；它与建立连接前就超时不是同一类问题。

若仍需提交问题，整理一份最小记录：系统与内核版本、复现步骤、时间点、脱敏日志、相关配置片段，以及已经做过的单项对照。相比整屏截图，这些信息更容易把问题定位到 DNS、规则、监听入口或节点连接中的具体一段。