Clash 原版、Meta 与 mihomo 是什么关系?内核版本区别与选择

先分清客户端、内核与配置文件

讨论 Clash 版本时，最容易混在一起的是“客户端”和“内核”。桌面上的窗口、托盘菜单、订阅按钮属于图形客户端；负责建立代理连接、匹配规则、处理 DNS 与接管流量的可执行程序才是内核。Clash Verge Rev、Mihomo Party 等名称通常指客户端，而 Clash、Clash.Meta、mihomo 指的是客户端内部调用的内核。

配置文件则是第三层。常见的 YAML 文件包含监听端口、代理节点、策略组、规则和 DNS 设置。客户端负责下载、编辑并把配置交给内核，内核读取字段后开始工作。因此，同一份订阅放进两个界面相似的客户端，结果仍可能不同：一个使用原版 Clash，另一个使用 mihomo，能够识别的协议与字段并不完全一样。

Clash 原版、Clash.Meta 与 mihomo 的关系

原版 Clash：规则代理体系的起点

通常所说的“原版 Clash”，指 Dreamacro 维护的 Clash 项目。它确立了如今仍在沿用的一套配置结构，包括 proxies、proxy-groups、rules、proxy-providers 和 rule-providers。默认示例里常见的 HTTP 代理端口是 7890，外部控制接口常用 9090，这些约定也被许多后续客户端保留。

原版项目在 2023 年 11 月停止公开维护，相关代码仓库随后进入归档状态。原版最后阶段常见的版本标识是 v1.18.0。停止维护不等于已有安装会立即失效：旧协议、基础域名规则和普通系统代理仍可能继续运行，但它不会继续适配新协议、新规则字段与后续操作系统网络变化。

历史上还存在 Clash Premium。它曾在原版基础上提供更多能力，例如增强规则与 TUN 相关功能，但它并不是今天 mihomo 的旧名称。看到旧教程写“Premium 内核”时，应把它当作特定历史分支理解，不要直接等同于当前 mihomo。

Clash.Meta：兼容 Clash 配置的社区扩展

Clash.Meta 是社区在 Clash 配置体系上持续扩展的内核。它保留大量原版字段，让原有规则与策略组可以低成本迁移，同时加入更多代理协议、规则类型、DNS 控制和 TUN 能力。对用户而言，“Meta 配置”通常表示配置中使用了原版未定义的扩展字段。

这里的兼容更接近“mihomo 能读取大部分原版配置”，而不是双向完全兼容。只使用 DOMAIN-SUFFIX、IP-CIDR、GEOIP、MATCH 等基础规则时，两者差异较小；一旦配置使用 VLESS、Hysteria2、TUIC、GEOSITE 或 mihomo 专属入站字段，原版内核就可能报错或忽略配置。

mihomo：Clash.Meta 改名后的延续名称

mihomo 不是排在 Clash.Meta 之后的另一套陌生内核，而是 Clash.Meta 项目改名后采用的名称。旧版客户端、订阅转换工具和历史文章仍可能显示 Clash.Meta；较新的发行包、日志与配置文档通常使用 mihomo。看到“Meta 内核”和“mihomo 内核”时，首先应理解为同一社区项目不同阶段的称呼，而不是两种需要二选一的产品。

协议、规则、DNS 与 TUN 的功能差异

内核选择不能只看“能否打开网页”。协议支持决定节点能否建立连接，规则能力决定流量能否被准确分配，DNS 与 TUN 则影响应用覆盖范围和域名解析路径。下面是面向实际配置的差异概览。

比较项	原版 Clash	mihomo
维护状态	原项目已归档，常见末期版本为 v1.18.0	社区持续维护，客户端通常可跟随稳定版更新
基础协议	支持 Shadowsocks、VMess、Trojan、HTTP、SOCKS5 等常用类型	兼容多种基础类型，并扩展 VLESS、TUIC、Hysteria2 等配置
规则类型	覆盖域名、IP、端口、进程名、规则集与 MATCH 等基础匹配	增加 GEOSITE、IP-ASN、网络类型、入站类型等更细条件
DNS	具备 nameserver、fallback、fake-ip 等常用机制	扩展 nameserver-policy、规则联动及更细的解析控制
TUN	旧分支之间能力不一致，历史教程常依赖 Premium	提供持续维护的 TUN 实现，并可配合 DNS 劫持与路由自动配置
新配置适配	遇到扩展字段可能无法启动	更适合当前订阅与持续更新的规则模板

协议支持：节点名称相同不代表格式相同

Shadowsocks、VMess、Trojan 这类协议在原版和 mihomo 中都有较广泛的使用基础，但具体加密方式、传输层参数和扩展选项仍要以配置字段为准。VLESS、Reality、Hysteria2、TUIC 等较新的节点格式通常应交给 mihomo 处理。若订阅导入后节点数量明显变少，或日志出现 unsupported proxy type，优先检查内核是否过旧。

订阅转换只能改变文本结构。例如，它可以把节点整理成 YAML 的 proxies 列表，却不能让原版内核突然理解 Hysteria2。节点类型超出内核能力时，正确处理方式是更换支持该协议的内核或客户端，而不是反复修改订阅地址。

规则能力：基础规则通用，扩展规则看内核

原版 Clash 已能完成大多数域名与 IP 分流。下面这些规则属于常见基础写法：域名后缀进入代理组，局域网地址直连，其余请求交给最终策略。

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

mihomo 在此基础上支持更细的匹配条件。例如 GEOSITE 可引用域名分类数据，IP-ASN 可按自治系统号匹配，NETWORK 可区分 TCP 与 UDP，IN-TYPE 可按入站类型处理流量。这些能力适合复杂分流，但配置放回原版内核时并不保证可用。

rules:
  - GEOSITE,category-ads-all,REJECT
  - NETWORK,udp,UDP-Proxy
  - IP-ASN,13335,Proxy,no-resolve
  - MATCH,Final

规则是从上到下匹配的，命中后停止继续判断。无论使用哪个内核，都应把具体规则放在宽泛规则之前，把 MATCH 放在末尾。否则，即使内核支持高级规则，也可能因为前面的宽泛条件已命中而没有执行机会。

DNS：关注解析路径，不只看服务器地址

原版 Clash 已提供 nameserver、fallback、fallback-filter 与 enhanced-mode 等核心配置。mihomo 延续这些字段，并提供更细的域名策略和规则联动。实际迁移时，要特别检查 fake-ip 与 redir-host 模式、监听地址、IPv6 开关以及 TUN 下的 DNS 劫持设置。

常见的混合代理监听端口是 7890，DNS 监听示例则可能使用 0.0.0.0:1053。端口不是固定标准，最终以配置文件和客户端界面为准。若本机已有程序占用 7890、9090 或 1053，内核日志通常会出现 address already in use，此时应修改冲突端口，而不是把问题归因于订阅。

TUN：决定更多应用能否被接管

系统代理主要覆盖主动读取代理设置的应用，部分游戏、命令行程序和 UDP 流量可能绕过它。TUN 模式通过虚拟网络接口接管更广范围的系统流量，因此更依赖内核的网络栈、路由配置和 DNS 协作。mihomo 是当前使用 TUN 时更常见的选择。

开启路径因客户端而异，常见入口是「设置」→「网络设置」→「TUN 模式」，或主界面的「服务模式」与「TUN」开关。Windows 首次启用通常需要管理员权限；macOS 可能要求批准网络扩展；Linux 则需要正确的 CAP_NET_ADMIN 权限或以合适的服务方式运行。开启后应同时检查局域网访问、DNS 解析和休眠恢复，而不是只验证一个浏览器页面。

旧配置迁移到 mihomo 时检查什么

从原版迁移到 mihomo 通常比反向迁移顺利，但“能够启动”只是第一步。订阅提供者、客户端和本地覆写都可能修改配置，最好按照固定顺序排查。

1. 先确认实际内核。 在客户端中打开「设置」→「内核」或「设置」→「关于」，记录名称、版本号和架构。命令行环境可运行 mihomo -v；旧原版可执行文件通常使用 clash -v。
2. 保留原配置副本。 备份 YAML、规则集地址、本地覆写和自建策略组。只保存订阅链接不一定包含本地增加的规则。
3. 先做语法测试。 mihomo 可使用 mihomo -t -f config.yaml 检查配置。测试通过表示结构可读取，不代表每个远程规则集和代理节点都能连接。
4. 核对代理组引用。 每条规则末尾的策略名必须存在于 proxy-groups。例如规则写了 Proxy，配置中却只有“节点选择”，内核会报告找不到策略。
5. 检查外部资源。 proxy-providers、rule-providers、GEOIP 和 GEOSITE 数据需要能够下载并写入缓存目录。更新失败时打开「设置」→「日志」，查看 HTTP 状态码、超时信息和文件权限。
6. 最后再开启 TUN。 先用系统代理验证 7890 监听、节点连接和规则分流，再启用 TUN。这样可以把节点问题与系统路由问题分开。

一份基础配置如何保持较高兼容性

需要在多台设备之间共享配置时，可把通用部分限制在基础字段，把 mihomo 扩展放进单独覆写。下面的骨架使用混合端口 7890、本机控制接口 127.0.0.1:9090 和规则模式，适合作为排查结构的起点。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

这段示例没有真实代理节点，所以 Proxy 组暂时只包含 DIRECT。实际使用时应由订阅或本地配置加入节点。不要直接把网上配置中的控制接口改成 0.0.0.0:9090；若确实需要局域网控制，应同时设置访问密钥并限制防火墙范围。

2026 年安装客户端应该选择哪个内核

对新安装而言，优先选择仍在维护并明确使用 mihomo 的客户端。原因不是名称更新，而是它能继续适配当前节点协议、规则数据、DNS 行为和操作系统网络变化。尤其是订阅包含 VLESS、Reality、Hysteria2、TUIC，或计划使用 TUN、GEOSITE、IP-ASN 时，mihomo 更符合配置预期。

适合直接选择 mihomo 的情况

• 首次安装 Clash 类客户端，希望正常接收后续内核修复与功能更新。
• 订阅中包含 VLESS、Reality、Hysteria2 或 TUIC 节点。
• 需要 TUN 接管游戏、命令行工具、UDP 或不读取系统代理的应用。
• 规则使用 GEOSITE、IP-ASN、NETWORK、IN-TYPE 等扩展条件。
• 需要按域名配置不同 DNS 上游，或使用更细的 fake-ip 排除策略。

仍可能保留原版的情况

• 隔离环境中的既有配置已稳定运行，只使用基础协议和基础规则。
• 某个旧客户端与自动化脚本固定依赖原版命令参数，迁移需要先做兼容测试。
• 短期复现历史问题，需要保持与当时相同的内核和配置行为。

这些情况更适合“暂时保留并安排迁移”，而不是把原版作为新设备的默认选择。旧环境至少应记录客户端版本、内核版本、配置来源和端口占用，避免设备重装后无法还原。

选择客户端时看这六项

1. 内核名称与版本：明确标注 mihomo，并能在「设置」→「内核」查看当前版本。
2. 配置管理：能够区分订阅原文、本地覆写和运行时配置，避免更新订阅覆盖手动修改。
3. 日志入口：至少提供 info、warning、error 等级，能够看到节点、DNS、规则集和端口错误。
4. TUN 管理：能显示服务状态、权限要求和失败原因，而不只是一个开关。
5. 平台架构：Windows 区分 x64 与 ARM64，macOS 区分 Apple Silicon 与 Intel，Linux 则核对 amd64、arm64 及安装方式。
6. 更新边界：客户端更新、内核更新、GEO 数据更新和订阅更新应分别可见，便于定位是哪一层发生变化。

常见误区与排查结论

“配置能导入”不等于“字段全部生效”

YAML 语法正确只说明缩进和结构能够解析。某些客户端还会在导入阶段删除未知字段，或者用本地覆写替换订阅内容。判断功能是否生效，应查看运行时配置和内核日志。例如写入 GEOSITE 后没有任何规则命中记录，需要确认规则数据是否加载、规则顺序是否正确，以及实际内核是否支持该类型。

“Meta”和“mihomo”不是两条并行升级线

在当前语境中，mihomo 是 Clash.Meta 改名后的项目名称。下载时不必寻找所谓“Meta 版与 mihomo 版的性能对比”。真正需要核对的是发行日期、版本号、处理器架构，以及客户端是否仍在调用一个多年未更新的内核文件。

版本越新也需要先测试配置

持续维护的内核会修复问题，也可能调整默认行为、废弃字段或加强配置校验。升级前应导出配置，升级后依次测试订阅更新、策略组、DNS、系统代理与 TUN。企业网络、校园网和带有本地 DNS 的环境尤其要检查内网域名与局域网网段是否继续直连。

最终选择可以压缩成一句话

新设备与新配置优先使用 mihomo；旧原版环境若仍有业务依赖，可以先保留、记录版本并逐项迁移。Clash.Meta 与 mihomo 主要是改名前后的称呼关系，而客户端名称只是外壳，真正决定协议、规则、DNS 和 TUN 能力的是正在运行的内核。