Clash 报错对照表：订阅导入失败、连不上节点、DNS 出错的日志怎么读

屏幕上那行红字，先别急着换服务

这篇是一张对照表：按你实际看到的那句报错去查，每一条都标了它出自哪个客户端、哪个源文件，以及在你自己机器上能做的检查。

有意这样写，是因为搜索这些报错时最常见的答案是「换一家」。**但这些报错里的绝大多数，根源在本机——配置写法、权限、规则引用、DNS 设置。**换一份订阅不会让一个写错的 default-nameserver 变对。

安装、订阅导入的基本流程不在这里重复，那部分见《Clash 使用教程 2026》。本文只处理「已经装好了，但它在报错」。

先说结论

1. 先把日志级别调到 debug，再谈排错。 mihomo 的 log-level 有五档，官方文档对每一档的定义写得很死：silent 静默不输出、error 只输出到无法使用的错误、warning 输出不影响运行的错误、info 输出一般运行内容、debug 尽可能输出所有信息。默认的 info 看不到 DNS 解析细节。
2. 「订阅导入失败，尝试使用 Clash 代理导入」不是故障码，是一句流程提示。 它出自 Clash Verge Rev 的简体中文语言文件，意思是「直连取订阅失败了，换用代理再试一次」。真正的原因要去日志里找下一行。
3. 订阅取不回来时，你看到的错误文本往往就是 HTTP 状态行本身（403 Forbidden、404 Not Found）。原因在 mihomo 的源码里：状态码不在 2xx 时，它把 resp.Status 原样当作错误返回。
4. 连接失败的那一行有四段信息，多数人只读了最后一段。 [TCP] dial 节点 (match 规则/内容) 来源 --> 目标 error: 原因 —— match 那一段经常才是真凶。
5. 配置类报错和网络无关，特征是一保存就出现：名字重复、规则引用了不存在的名字、DNS 字段自相矛盾。本文第四、第六节逐条列了原文。
6. TUN 打不开基本是权限或防火墙，不是配置。各系统的具体表现见第五节。
7. 确实有一类报错不是你的问题——判断方法在最后一节，以及《机场突然全挂了：30 分钟自救清单》。

一句话原则：报错分三类——取不到配置、配置本身不合法、配置合法但连不通。先判断是哪一类，再往下查。这三类的检查方法完全不同，混着试是最浪费时间的做法。

一、先把日志打开：三行就够

把级别调对

配置里的 log-level 决定你能看到什么。mihomo 官方文档（虚空终端 Docs）对五个取值的说明是：

排错时调到 debug，排完调回 info——debug 会把你访问过的每一个域名都写进日志。

要读的三行

mihomo 的连接日志格式写死在 tunnel/tunnel.go 里，认得出这三种就够用了：

第一行，成功的连接：

[TCP] 192.168.1.10:54321 --> www.example.com:443 match DomainSuffix(example.com) using 香港01

读法：match 后面是命中的规则类型和规则内容，using 后面是最终走的节点或策略链。

第二行，没有命中任何规则：

[TCP] 192.168.1.10:54321 --> www.example.com:443 doesn't match any rule using 香港01

这说明走的是兜底（MATCH）。如果某个网站行为奇怪，先看它是不是落到了这一行。

第三行，失败的连接：

[TCP] dial 香港01 (match DomainSuffix/example.com) 192.168.1.10:54321 --> www.example.com:443 error: ...

这一行来自源码里的 logMetadataErr 函数，四段信息缺一不可：协议（TCP／UDP）、选中的节点、命中的规则、以及最后的原因。

为什么强调 match 那一段：一个「连不上 GitHub」的问题，日志里如果显示 using DIRECT，那节点再好也没用——流量压根没进代理。这类问题见第六节。

二、订阅类报错：取不回来，还是取回来了不能用

这一类的共同特征是：发生在导入或更新订阅的瞬间，和你日常上网通不通没关系。

Clash Verge Rev 弹出的原文

下面的中文都是从 Clash Verge Rev 仓库的简体中文语言文件里原样抄来的（src/locales/zh/ 目录），你在界面上看到的就是这些字：

注意第二条和第三条是一组。第一次失败只说明「直连取不到」，这是一条关于你到订阅地址这段网络的信息，不是关于节点质量的信息。

日志里那串英文状态

当订阅地址回了一个非 2xx 的 HTTP 状态，mihomo 的处理方式很直白：component/resource/vehicle.go 里，状态码不在 200–299 之间时执行 errors.New(resp.Status)——把 HTTP 状态行原样当成错误文本。所以你在日志里看到的会是：

源码里还有一个细节值得知道：304 Not Modified 不算错误——它会被当作「内容没变」正常返回。所以看到 304 不用管。

内容取回来了，但解析不了

这一组来自 mihomo 的 adapter/provider/provider.go 和 common/convert/converter.go，原文如下：

第一条最值得单独说：file must have a 'proxies' field 通常意味着你把一个网页存成了配置。手动检查方法是把取回的文件开头看一眼——如果第一个字符是 <，那它是 HTML。

关于「先有节点才能用节点取订阅」这个循环：当直连取不到、手上又没有任何可用节点时，两条路都断了。此时能做的是换一个网络环境（例如换到手机热点）完成一次导入，把配置文件落到本地。这属于已经没有可用出口的情形，处理顺序见《机场突然全挂了：30 分钟自救清单》。

三、连接类报错：节点连不上的那一行

先明确一件事：mihomo 不会在日志里写一句「节点已失效」。它写的是 dial ... error: 加上底层网络库给出的原因。按原因分类：

一个诊断技巧，不用改任何配置：把客户端切到全局模式再试同一个网址。

• 全局模式下通了 → 问题在规则，看第六节。
• 全局模式下也不通，但换一个节点就通了 → 问题在那个节点。
• 全局模式下换哪个节点都不通 → 问题在你到所有出口的这条链路上，这时候才轮到怀疑外部因素。

这三步的判断只需要两分钟，却能把后面所有排查的方向定下来。如果结论是「能连上但很慢」，那是另一篇的范围：《翻墙慢，到底是节点问题还是本地问题？》。

各客户端的中文提示

「无法从内核获取代理信息」这一条特别值得认识：它说的是图形界面和内核之间的通道断了，不是节点的问题。内核可能已经崩了，也可能外部控制端口被占用。它的提示自己就给了正确的下一步——去日志目录看内核日志。

四、DNS 与 fake-ip：最容易被误读的一类

DNS 出问题的表现往往不像 DNS 问题：某些网站打不开、某些 App 转圈、浏览器能开但客户端不行。

配置校验阶段的 DNS 报错

这一组出现在启动或保存配置的瞬间，全部来自 mihomo 的 config/config.go 与 hub/executor/executor.go：

default nameserver should be pure IP 是这里最值得记住的一条，因为它的成因很反直觉：default-nameserver 的职责就是解析「节点服务器的域名」，如果它自己也是个域名，就没有起点了。填 IP 是硬性要求，不是风格偏好。

fake-ip 造成的困惑

enhanced-mode: fake-ip 的做法是：给每个域名发一个假的内网地址（官方示例默认段是 198.18.0.1/16），真正的解析推迟到连接建立时再做。好处是快，副作用是——

• 你用 ping 某个域名，得到的是 198.18.x.x 这种地址，这是正常的，不是被劫持；
• 任何拿 IP 去做判断的软件都可能困惑（某些游戏、某些依赖 IP 白名单的客户端）；
• 需要例外的域名要写进 fake-ip-filter。

相关的校验报错也很具体：dns.fake-ip-filter[n] [规则] error: invalid action 'xxx', must be 'fake-ip' or 'real-ip'、... rule-set 'xxx' not found、... rule type 'xxx' not supported, only domain-based rules allowed。最后一条的意思是：fake-ip-filter 里只能写基于域名的规则，写 IP 类规则会被拒绝。

怎么确认 DNS 到底有没有走对

把 log-level 调到 debug，你会看到 [DNS] resolve 域名 error: 原因 这类行（定义在 tunnel/tunnel.go）。内核启动时 DNS 服务本身起不来，则会有 Start DNS server error: 或 Start DNS server(UDP) error:（定义在 dns/server.go）。

但日志只说明内核内部发生了什么，不能说明你的系统最终用了谁。那要在外面测：用 DNS 泄漏检测 看最终出去的解析服务器是谁，用 IP 地址查询 确认出口本身有没有变。如果你怀疑的是「解析结果被改了」而不是「泄漏」，那是另一套判断方法：《DNS 污染自测：三条命令分清污染、劫持和节点故障》。

五、TUN 模式与权限：各系统坑不一样

TUN 要做两件高权限的事——创建虚拟网卡、改写系统路由表。因此 TUN 打不开，九成是权限或防火墙，不是配置写错。

你会看到的原文

FlClash 那条提示自己就写明了原因和解法，这类提示不要略读——它比任何第三方教程都准。

mihomo 官方文档写明的限制

这几条来自虚空终端 Docs 的 Tun 页面，是设计上的限制，不是 bug：

• 协议栈可选 system / gvisor / mixed / mips，默认 gvisor，文档建议无问题时用 mixed。
• 防火墙开启时无法使用 system 和 mixed 协议栈。Windows 的放行路径文档写的是：设置 → Windows 安全中心 → 允许应用通过防火墙 → 选中内核。
• macOS 上 TUN 网卡名只能用 utun 开头。文档说 macOS 一般无需配置，防火墙默认放行签名软件。
• dns-hijack 有平台限制：文档原文是「在 MacOS / Windows 无法自动劫持发往局域网的 dns 请求」「在 Android 如开启 私人dns 则无法自动劫持 dns 请求」。安卓用户如果开了系统的「私人 DNS」，这是一个已知会互相打架的组合。
• strict-route 在 Windows 上的作用是「添加防火墙规则以阻止 Windows 的普通多宿主 DNS 解析行为造成的 DNS 泄露」，文档同时提醒「它可能会使某些应用程序（如 VirtualBox）在某些情况下无法正常工作」。在 Linux 上它「让不支持的网络无法到达」「将所有连接路由到 tun」。
• auto-redirect 仅支持 Linux，且需要 auto-route 已启用；配置校验会直接报 'auto-route' is required by 'auto-redirect'。

其他与 TUN 相关的启动校验报错：when tun is enabled, iptables cannot be set automatically、not allowed two tun listener using auto-detect-interface。

一个常被忽略的后果：TUN 异常退出后虚拟网卡和路由表可能没清干净，表现为「关掉代理也上不了网」。遇到这种情况，先完全退出客户端（不是关窗口），必要时重启系统——路由表恢复后再谈别的。

六、规则与分流：看起来像断网，其实是走错了路

这一类最会骗人：某个网站打不开，你以为节点坏了，其实是它被规则送去了直连。

配置校验会拦下的名字问题

来自 config/config.go，原文模板如下（方括号里会填进实际内容）：

这些全部发生在加载阶段，你的网络状况对它们没有任何影响。最高频的成因是：订阅更新后节点被改名或下线，而你手写的自定义规则、策略组还指着旧名字。

FlClash 把同类问题翻成了中文：「某某 是一个无效的代理」「某某 是一个无效的代理集」「某某 是一个无效的策略」「某某 是一个无效的 SUB_RULE」。含义和上表一一对应。

没有报错，但走错了路

更麻烦的是这一类：**配置完全合法，没有任何红字，但某个站点就是不通。**判断只要一步——在日志里搜那个域名，然后看它那一行：

• 出现 using DIRECT → 规则把它判成了国内直连。常见于 GeoIP 库把某些地址归错，或者自定义规则顺序不对（Clash 的规则是从上往下第一条命中生效，一条过于宽泛的规则写在前面会吃掉后面所有规则）。
• 出现 doesn't match any rule using ... → 走了兜底。兜底指向哪里，它就去哪里。
• 出现 match ... using 某节点 但仍然失败 → 规则没问题，回到第三节按连接类排查。

顺序问题是自定义规则最常见的错误，而它不会报错——因为它语法完全正确。

七、什么时候这不是你的问题

前六节都是本机可查的。但确实存在一类情况，你怎么改都没用。特征是同时满足下面几条：

1. 全局模式下，所有节点都连不上（不是某几个）；
2. 换一个完全不同的网络环境（例如手机热点）后，同一份配置仍然全部失败；
3. 订阅地址本身返回的是明确的 HTTP 错误（如 403），而不是超时；
4. 你的配置文件没有任何改动——加载阶段零报错。

四条都对上，那问题不在你的客户端。这时该做的不是继续改配置，而是按顺序处理：《机场突然全挂了：30 分钟自救清单》。

反过来说，只要还有一个节点能通，或者换个网络就好了，那问题就在本机侧，本文前六节覆盖得到。

本文的边界：这里不会出现「换一家试试」这种建议，也不提供任何节点或订阅来源。报错对照表的价值在于让你知道那行红字在说什么——知道了，多数情况你自己就能修。

参考资料

以下源码与文档均于 2026 年 9 月 20 日核对；版本号于 2026 年 9 月 21 日通过 GitHub 发布接口复核。

mihomo 内核（错误文本的来源）

• tunnel/tunnel.go — 连接日志格式 logMetadataErr / logMetadata，以及 [DNS] resolve %s error: %s
• component/resource/vehicle.go — 订阅抓取；HTTP 状态码非 2xx 时 errors.New(resp.Status)，304 Not Modified 单独放行
• adapter/provider/provider.go — file must have a 'proxies' field、doesn't match any proxy, please check your filter 等
• adapter/parser.go — missing type、unsupport proxy type: %s
• common/convert/converter.go — convert v2ray subscribe error: format invalid
• config/config.go — 规则、重名、DNS、fake-ip 的全部校验报错原文
• hub/executor/executor.go — configuration file %s is empty、DNS server must be enable、when tun is enabled, iptables cannot be set automatically
• listener/sing_tun/server.go — 'auto-route' is required by 'auto-redirect'、not allowed two tun listener using auto-detect-interface
• dns/server.go — Start DNS server error: %s

mihomo 官方文档（虚空终端 Docs）

• 全局配置 — 日志级别 — 五档 log-level 的定义原文
• DNS 配置 — enhanced-mode、fake-ip-range 默认值 198.18.0.1/16
• 入站 Tun — 协议栈取值与差异、防火墙放行路径、dns-hijack 的平台限制、strict-route 在 Windows / Linux 上的行为（页面标注更新于 2026 年 9 月 14 日）

各客户端的界面文案（原文出处）

• Clash Verge Rev 简体中文语言文件 — src/locales/zh/profiles.json、shared.json、settings.json、proxies.json、home.json
• FlClash 简体中文词条 — arb/intl_zh_CN.arb
• Clash Meta for Android 简体中文字符串 — design/.../values-zh/strings.xml、service/.../values-zh/strings.xml

版本（2026-09-21 通过 GitHub Releases 接口复核）：mihomo v1.19.31（2026-09-14）、Clash Verge Rev v2.5.4（2026-09-20）、FlClash v0.8.98（2026-09-14）、Clash Meta for Android v2.11.34（2026-09-14）、ClashX Meta v1.4.45（2026-09-14）。