先确认日志来源与失败时间

Clash 日志不是一份单纯的报错列表。它同时记录配置加载、端口监听、DNS 请求、规则匹配和出站连接。排查时先回答三个问题：请求有没有进入内核、请求走向哪个策略、连接在哪一步失败。只看到一条红色提示就更换全部节点，容易把端口问题、解析问题和远端服务故障混在一起。

本文适用于使用 Clash 或 Clash Meta（现称 mihomo）内核的客户端。不同客户端、内核版本的日志格式与菜单名称可能不同；先在客户端的「关于」页面记录客户端版本和内核版本，再打开「日志」或「运行日志」。不要把订阅更新日志、客户端界面日志与内核运行日志当成同一来源。

  1. 记下失败发生的本地时间，精确到秒，例如 14:32:10。
  2. 暂停下载、视频与其他持续联网任务，清空界面中的历史日志，再仅触发一次目标请求。
  3. 保留触发前后约 10 秒的记录，并在「连接」页面核对目标域名、目标端口、规则和实际出站。
  4. 记录当前是规则、全局还是直连模式，以及是否开启系统代理、TUN；每轮测试只改变一项。

调整 log-level：先 info，再短时 debug

日常排查先使用 info。它通常足以显示连接的目标、匹配规则和使用的策略。只有在解析过程、策略提供器或连接细节不清楚时，再临时切换到 debug。silent 会关闭日志，不适合排查；error 或 warning 可能省略成功连接与规则信息。

配置与生效核对

在客户端设置中查找「日志级别」；如果界面没有这个选项，则通过客户端支持的配置编辑或覆写入口修改顶层字段。下面使用的是内核配置值，警告级别应写 warning，不要从界面上的缩写推断配置写法。

# 顶层配置；排查结束后恢复 info
log-level: debug
mode: rule
  • 保存后使用客户端提供的配置重载功能；如果提示需要重启内核，按提示操作，并确认启动没有报错。
  • 远程订阅可能在更新时覆盖直接编辑的内容，优先使用客户端支持的持久覆写方式。
  • 复现一次即可导出相关时间段，不必让 debug 连续运行数小时；结束后恢复 info。

调试日志可能包含访问域名、本机地址、节点名称和配置路径。对外提交前，应删除订阅令牌、认证信息、控制接口密钥以及个人目录信息；同时保留错误类型、端口和策略关系，避免脱敏后失去定位线索。

按一条连接读取目标、规则与出站

从目标域名或端口搜索，不要从整屏日志的第一行开始猜。一次网页访问可能同时请求主站、图片、接口和统计域名，出现一条失败记录并不意味着主页面连接失败。以下为简化的 TCP 连接示意：

[TCP] 127.0.0.1:52144 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[Node-A]
字段应核对的内容
TCP / UDP区分传输协议；浏览器可能使用基于 UDP 的 HTTP/3。
127.0.0.1:52144此例是本机来源与临时源端口，不是客户端代理监听端口。
www.example.com:443目标主机与服务端口；确认它确实属于这次失败操作。
DomainSuffix命中的规则类型；继续核对规则中的策略名。
Proxy[Node-A]示意策略组及最终节点；实际可能显示多级策略链。

出现 using DIRECT 时，首先确认它是否符合预期，而不是立刻判断规则失效。连接记录显示的是路由选择，不等于远端请求已经成功；还需要结合后续错误、连接流量和应用结果判断。

dial tcp timeout：区分连接到哪里超时

搜索 dial tcp、i/o timeout 或 context deadline exceeded，通常是在定位连接或操作等待超时。其中 dial tcp 指向 TCP 建连阶段，但其他超时文本可能出现在 DNS 查询、TLS 握手或代理协议交互阶段。必须读取它前后的目标地址和操作描述。

先区分节点地址与网站地址

  • 连接代理节点超时：错误中的地址对应节点服务器与节点端口。先核对节点域名解析、端口、网络可达性及订阅是否过期，再测试同一策略组中的另一个可用节点。
  • 直连网站超时：连接记录使用 DIRECT，目标是网站地址。检查直连网络、目标服务与规则选择，不要只调整节点参数。
  • 经过节点后访问网站失败：节点本身可以建立连接，但目标请求失败。比较同一节点访问其他网站、其他节点访问同一网站的结果，缩小到目标侧或节点出口。

connection refused 与超时不同：它通常表示连接收到了主动拒绝，例如目标端口没有服务监听，也可能来自中间设备的拒绝。connection reset by peer 表示连接被重置，不能仅凭这一句认定是密码错误或某一种网络干预。

DNS 解析失败：拆开两条解析链路

DNS 错误至少要区分“代理节点域名解析失败”和“访问目标域名解析失败”。前者会让代理连接尚未建立就终止；后者与当前 DNS 模式、目标解析路径和上游解析器有关。日志中的 lookup、no such host、DNS resolve failed 与查询超时，应结合其后的域名一起阅读。

  1. 确认域名拼写与用途。如果失败的是节点服务器域名，先检查节点配置与该域名本身是否仍有效。
  2. 区分响应与超时。no such host 常见于不存在或没有可用记录的解析结果；查询超时则应检查上游 DNS 是否可达、传输方式与路由。
  3. 检查解析器启动依赖。使用域名形式的 DoH 上游时，还需要先解析解析器自身的域名。mihomo 的 default-nameserver、proxy-server-nameserver 等字段各有用途，应结合当前版本文档核对，不能把所有地址任意互换。
  4. 重载后发起新连接。修改 DNS 设置后，用客户端支持的方式清理缓存或重启内核，同时关闭应用旧连接，避免旧结果影响判断。

Fake-IP 地址不等于解析异常

启用 Fake-IP 后，客户端可能向应用返回配置地址池中的虚拟地址，例如常见的 198.18.0.0/16 范围。它用于把后续连接映射回域名，不是网站的公网地址。看到该地址不能直接判断 DNS 被污染；应检查该连接是否被内核接管，以及域名映射是否仍有效。

系统终端中的 nslookup 结果也不一定等于内核实际使用的结果。系统 DNS、浏览器安全 DNS、内核 DNS 和远端代理解析可能走不同路径。排查 TUN 时，还要确认 DNS 劫持设置与路由是否实际生效，而不是仅确认配置里写了 enable: true。

规则未命中：先检查模式与首条匹配

规则模式按顺序匹配，通常由首条命中的规则决定出站。全局模式不按常规规则列表为每条连接选择策略；直连模式则直接连接。因此，“明明写了域名规则却走错节点”的第一项检查，是客户端当前是否处于 rule 模式。

# 示意：Proxy 必须是配置中已存在的策略名称
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - MATCH,DIRECT

在此例中，example.com 及其子域名应命中第一条；其他未命中的连接落入 MATCH,DIRECT。如果把覆盖范围更大的规则放在前面，后面的细分规则可能永远没有匹配机会。检查时应查看客户端最终生效的规则，而不只是订阅源文件。

  • 日志只显示 IP：检查应用是否绕过内核解析，以及该连接是否保留域名信息。域名规则无法凭空知道一个裸 IP 属于哪个站点。
  • 命中兜底规则：核对目标是否其实是 API 或 CDN 子域名，并检查规则提供器是否成功加载、更新是否报错。
  • 规则正确但节点不对：查看策略组当前选择；自动测速组、故障转移组可能按各自逻辑选择成员。
  • 改完仍走旧策略：先结束对应旧连接再重试。现有长连接不一定随着规则重载立即重新路由。

mihomo 的域名嗅探可以在支持的协议与设置条件下补充域名信息，但不是所有加密连接都能恢复出域名。不要把开启嗅探当成所有规则问题的通用修复，也不要为了某个网站把全部流量永久切到全局模式。

没有连接日志：检查入口端口与接管方式

应用报错而内核没有对应记录，优先检查请求是否进入客户端。系统代理只影响遵循系统代理设置的应用；某些命令行工具、游戏与自带代理设置的应用需要单独配置，或通过适当的 TUN 接管。开启系统代理并不代表所有 TCP、UDP 流量都已进入内核。

用明确的代理入口做一次对照

假设本机实际生效配置中的混合端口为 7890，可使用下面的显式代理请求。这个端口只是示例，务必换成客户端当前显示的监听端口；端口为 0 或未启用时不能照抄。

curl -v --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://example.com/

Windows PowerShell 中可将命令开头改为 curl.exe，避免某些环境中的命令别名差异。执行时同步观察日志：若该请求进入内核，而浏览器请求没有进入，优先检查浏览器代理设置、扩展与连接复用；若立即提示无法连接到 127.0.0.1:7890，先检查内核是否运行、端口是否正确与监听是否成功。

  • address already in use：监听地址或端口被占用。检查是否同时运行两个代理客户端，停止冲突服务或更换监听端口后同步更新入口设置。
  • permission denied / operation not permitted：结合日志上下文检查 TUN、路由操作或文件访问权限，按客户端提示补齐所需授权。
  • authentication failed：确认错误属于本地入口认证、代理节点认证还是订阅下载认证，不要把三个位置的凭据混用。
  • TUN 启动失败：查看创建虚拟网卡、安装路由或权限检查时的首条错误，避免与其他 VPN 同时修改路由后继续盲测。

这个 curl 测试主要验证显式 HTTP 代理入口与对应请求链路，不能据此证明 TUN、UDP 或所有应用都已正常。若客户端存在 TUN 自动路由等设置，测试结果还应结合实际路由一起判断。

固定复现步骤与排查记录

有效的故障记录应该让另一位维护者能够重复同一操作，而不是只提供一张包含几十条红字的截图。建议按以下顺序完成一轮排查，确认一个环节后再进入下一个环节。

  1. 内核启动：检查配置加载成功、所需端口监听成功，没有持续重启。
  2. 请求进入：通过显式代理测试或应用连接记录，确认内核能看见目标请求。
  3. 解析完成：区分节点域名与目标域名，确认失败不在 DNS 前置环节。
  4. 路由符合预期：记录命中的规则、策略组与最终节点，必要时结束旧连接重测。
  5. 出站对照：同一目标换一个节点、同一节点换一个目标；每次只改变一个条件。
  6. 恢复设置：把 debug 恢复为 info，撤销仅用于诊断的临时规则，并确认常用应用的连接状态。

提交问题时附上这些信息

记录操作系统版本、客户端与内核完整版本、使用的代理入口及端口、出站模式、TUN 状态、失败时间，以及脱敏后的相关日志。描述“浏览器访问某域名失败，显式代理 curl 成功”比“网络突然坏了”更容易定位；描述“仅一个节点失败，同组另一个节点成功”则能进一步缩小到节点配置或节点网络路径。

如果日志已显示连接建立成功，而应用仍提示证书、登录或 HTTP 状态错误，应继续检查应用层。系统时间错误、服务端返回 403、账户状态和证书信任都不是靠调整规则顺序就能解决的。排查的终点是确认故障所属层次，并用一次相同操作验证修复，而不是让日志界面看起来没有任何警告。