· 选型参考 · 预计阅读 9 分钟

Clash 原版、Clash Meta 与 mihomo 内核区别:版本演进与选择建议

梳理原版 Clash、Clash Meta 与 mihomo 的来龙去脉,对比协议支持、规则语法与维护状态,说明不同客户端各自内置哪个内核。

先分清客户端与内核

Clash 客户端是用来导入配置、切换节点、打开系统代理的图形界面；内核负责解析 YAML 配置、匹配规则，并实际处理连接。两者可以由不同项目开发。因此，窗口标题里写着 Clash，并不能说明它运行的是原版 Clash、Clash Meta，还是 mihomo。判断时要看客户端的「内核」或「关于」页面，而不是只看应用名称。

这三个名称也不是三个并列的新旧版本。原版 Clash 是较早的项目；Clash Meta 从其生态中发展出扩展功能；mihomo 则是 Clash Meta 后续使用的项目名称。资料、订阅说明或客户端界面仍可能写「Meta」，而实际下载的内核文件和版本信息显示「mihomo」。遇到这两种叫法，先核对项目与版本信息，不必立刻寻找一份所谓的 Meta 转 mihomo 配置。

名称 与其他名称的关系 选型时要看的重点
Clash 原版 早期独立的 Clash 内核项目 现有配置是否只用基础协议与规则；所用客户端是否仍内置它
Clash Meta 扩展 Clash 功能的项目及沿用至今的常见称呼 配置是否使用 Meta 系列支持的协议、规则与 DNS 选项
mihomo Clash Meta 后续使用的项目名称 当前客户端实际打包的内核版本及其功能说明

版本演进与维护状态怎么看

原版 Clash 的公开开发已停止。它曾建立起常见的 YAML 配置结构，例如 proxies、proxy-groups 和 rules，因此不少教程仍用「Clash 配置」统称这类文件。但配置结构相似，不代表新字段能在旧内核上运行。一个客户端如果多年没有更新，也可能继续使用它发布时附带的内核；只更新订阅，并不会自动更换内核。

Clash Meta 在原有使用习惯上增加了功能，项目后来以 mihomo 名称继续发布。判断当前维护情况时，应查看客户端提供的内核版本和更新记录：有的客户端随应用安装包一起更新内核，有的允许在设置中单独切换或更新内核。不要把客户端版本号当成内核版本号。例如「客户端 2.0」只能说明界面程序的版本，不能据此推断它支持某条 mihomo 规则。

检查当前设备的三个位置

  1. 打开客户端的「设置」或「关于」，找「内核」「Core」「Kernel」及其版本号。不同客户端菜单名称不同，以页面实际标注为准。
  2. 查看运行日志的启动部分。内核名称、配置加载错误和监听端口通常会在启动时显示；日志比安装包文件名更能反映正在运行的程序。
  3. 如果客户端提供「切换内核」，先记录当前选项，再确认目标内核与配置文件兼容。切换后重新加载配置，并检查日志中是否还有未知字段或规则解析错误。

协议支持：看节点字段，也看内核版本

选择内核最直接的依据是订阅中的节点类型。原版 Clash 的常见配置多围绕 Shadowsocks、VMess、Trojan、SOCKS5 和 HTTP 等类型。mihomo 在此基础上覆盖更多协议及扩展写法，常见需求包括 VLESS、Hysteria2 和 TUIC。不过，「mihomo 支持某协议」仍不等于任意年代的 mihomo 构建都支持该协议的每个参数；最终以安装的内核版本及其配置说明为准。

收到订阅后，可以在 YAML 的 proxies 下检查每个节点的 type。如果节点写着 type: vless，而客户端使用较早的原版 Clash 内核，导入失败或节点消失，往往是协议不匹配，不是系统代理开关没有打开。若订阅只有一长串 Base64 文本或单节点分享链接，应先确认客户端是否支持该导入格式；内核支持某个协议，不代表图形界面一定能直接解析所有分享链接。

按报错顺序排查导入失败

  • 配置还没加载：查看 YAML 缩进、字段拼写和客户端显示的出错行号。YAML 用空格缩进；同一层级的列表项应对齐。
  • 节点类型无法识别：核对 type 与正在运行的内核，不要只修改节点显示名称。协议参数需要与节点服务端提供的信息一致。
  • 配置加载成功但连接失败：先检查节点地址、端口与网络连通性，再查认证参数。此时仅更换内核未必能解决问题。

订阅服务提供「Clash」「Clash Meta」「mihomo」等多个配置入口时，优先选择与当前内核对应的格式。切换入口前保存原配置；转换工具可能改写策略组或规则集引用，导入成功后还要检查实际分流结果。

规则、DNS 与 TUN：相似配置不等于相同行为

基础规则的阅读方式相近：DOMAIN-SUFFIX,example.com,DIRECT 表示匹配该域名后直连，MATCH,DIRECT 则处理此前规则均未匹配的连接。规则通常按顺序匹配，先命中的规则决定去向。配置文件里若同时出现规则集引用、GEOSITE 等写法，要核对目标内核是否识别相应规则类型及其数据来源，不能因为文件扩展名同为 .yaml 就直接互用。

下面是只用于观察基础规则与监听端口关系的简化示例。mixed-port: 7890 表示本机的 HTTP/SOCKS 混合代理端口；external-controller 使用本机地址与端口 9090。示例中的规则全部指向 DIRECT，没有代理节点，不能把它当成已经配置好的代理订阅。

mixed-port: 7890
mode: rule
external-controller: 127.0.0.1:9090
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

DNS 和 TUN 更需要分开检查。DNS 配置决定域名如何解析；TUN 模式则通过虚拟网络接口接管符合条件的设备流量。打开 TUN 后，客户端可能需要系统授予网络接口权限，但 TUN 本身不会修复失效的节点，也不会自动补齐缺失的规则集。若出现「网页能打开、某个应用不走代理」，先确认该应用的连接是否进入内核日志，再检查系统代理与 TUN 的启用状态、路由设置和规则命中情况。

按现有客户端与配置选择

已有配置能正常运行

先记录客户端名称、内核名称、内核版本及配置来源。如果订阅只包含当前内核支持的节点类型，规则模式下的站点分流也符合预期，可以继续使用现有组合。准备更换客户端时，先导出或备份 YAML，再在新客户端中导入并检查策略组选择；组名相同不代表新客户端会保留上一次选中的节点。

新订阅使用扩展协议或规则

优先找明确标注使用 mihomo 内核、且版本支持所需字段的客户端。导入后检查三处：节点是否完整出现在列表、策略组是否引用了这些节点、连接日志是否显示预期的规则命中。仅在节点列表看见名称，不能证明协议握手或分流已经成功。需要比较不同客户端时，把「客户端界面是否适合设备」与「内核能否读取配置」作为两项独立条件。

客户端只显示 Clash，没有内核说明

先查「关于」页面和启动日志；仍无法确认时，可查看该客户端的发行说明或项目文档。不要因为界面上有 TUN 开关就推定它采用 mihomo，也不要因为文件名含 Meta 就推定运行时已经切换成功。确认内核后，再按对应文档检查订阅里的协议、rule-providers、DNS 字段及 TUN 配置。

选型的落点是现有配置和使用场景：基础规则与旧订阅要关注迁移成本；VLESS、Hysteria2、TUIC 等节点要核对具体版本；需要整机接管流量时，还要确认客户端对所在系统的 TUN 设置与授权流程。完成选择后，用一个常用网站和一个需要特定规则的网站分别测试，并对照连接日志确认实际出口。

查看客户端安装包