Clash 原版、Meta 与 mihomo 内核区别:版本演进与兼容性对照
梳理 Clash 原版内核、Clash Meta 到 mihomo 的演进脉络,对照协议支持、规则类型与配置字段差异,说明各客户端用的是哪一代内核。
先区分内核、客户端与配置文件
内核是执行代理连接、DNS 处理和规则匹配的程序；客户端是管理这些能力的界面。一个客户端可以在升级后更换内核，也可能允许用户手动选择内核。因此，软件名称里带有 Clash，并不能说明它支持哪一种协议。
配置文件则是内核读取的输入。扩展名同为 .yaml，只代表文件使用 YAML 语法，不代表其中的节点类型、规则类型和扩展字段都能被不同内核识别。
- 客户端版本：用于定位界面、系统代理开关、订阅管理和安装问题。
- 内核名称与版本：用于判断 VLESS、Hysteria2、TUN 和特定配置字段是否可用。
- 配置生成目标：用于确认订阅转换器输出的是原版 Clash 配置，还是面向 Meta／mihomo 的配置。
演进关系：原版、Premium、Meta 与 mihomo
Clash 原版与 Clash Premium 是两条能力范围不同的分支
通常所说的原版 Clash，指 Dreamacro 项目体系下的 Clash。讨论兼容性时，还要进一步区分开源内核与 Premium 内核。Premium 曾提供 TUN、规则集合和脚本等扩展能力，不能把 Premium 的功能直接算作原版开源内核的共同能力。
原项目体系在 2023 年 11 月停止公开维护。已经安装的旧版程序不会因此立即失效，但它们不应被期待继续获得新协议、新字段和后续兼容性修复。
Clash Meta 是扩展分支，mihomo 是其后续名称
Clash Meta 在 Clash 的基础上扩展协议、DNS、路由和连接处理能力，随后项目更名为 mihomo。两者是同一项目的演进关系，不是必须串联运行的两个程序，也不是先安装 Meta 才能使用 mihomo。
旧教程中的“Meta 内核”、配置文件注释中的 Meta，以及新客户端显示的 mihomo，往往指向这条项目谱系。但同一谱系仍存在版本差异：早期 Meta 构建不能自动等同于较新的 mihomo 构建。
| 内核名称 | 定位 | 兼容性重点 |
|---|---|---|
| Clash 开源内核 | 原项目的开源基础实现 | 以传统节点协议和基础规则为主 |
| Clash Premium | 原项目的扩展内核 | 包含 TUN、规则集合、脚本等能力，不能与开源版混为一谈 |
| Clash Meta | 扩展协议与路由能力的分支 | 许多配置和教程仍沿用 Meta 名称 |
| mihomo | Meta 项目的后续名称 | 新协议和扩展字段应以实际构建版本为准 |
协议支持：节点能否解析，比界面能否导入更重要
节点协议由配置中的 type 字段指定。客户端可能成功保存订阅文件，却在启动内核时才报告不支持的代理类型。此时，更换代理模式或修改监听端口并不能解决协议解析问题。
| 协议或特性 | 原版开源 Clash | mihomo |
|---|---|---|
| HTTP、SOCKS5、Trojan、VMess | 属于常见支持范围 | 支持；传输与 TLS 参数仍需逐项核对 |
| Shadowsocks | 支持传统实现范围内的加密方式 | 支持；具体加密方式取决于实现和版本 |
| VLESS 与 REALITY | 不支持该组合 | 支持相应节点配置 |
| Hysteria2 | 不支持 | 支持 type: hysteria2 |
| TUIC | 不支持 | 支持；须匹配服务端协议版本与参数 |
REALITY 不是单独的代理类型
在常见 mihomo 配置中，REALITY 是 VLESS 节点使用的安全握手相关配置，而不是把 type 写成 reality。应检查 type: vless、tls、servername、reality-opts 等字段是否与服务端一致。支持 VLESS，也不意味着任意传输组合和任意新参数都适用。
订阅转换不能为旧内核增加新协议
转换器可以重排 YAML、生成策略组、把 URI 参数映射成字段，却不能让原版内核获得 Hysteria2 实现。如果转换后的列表少了节点，应先检查转换目标是否过滤了不支持的协议，而不是直接认定订阅失效。
订阅地址通常包含访问令牌。排错时只提供脱敏后的单个节点结构、错误信息和内核版本，不要把完整订阅链接粘贴到公开讨论区。
规则与字段：基础语法接近，扩展能力不能反向套用
mixed-port、mode、proxies、proxy-groups 和 rules 是常见的配置入口。DOMAIN、DOMAIN-SUFFIX、IP-CIDR、MATCH 等基础规则也有广泛的继承关系，但这不表示整份配置可以任意跨内核复制。
- 规则集合：
rule-providers与RULE-SET在 Premium 和 mihomo 中都有应用，不能据此推断原版开源构建同样支持。 - 扩展规则：mihomo 的逻辑组合、进程路径、入站相关规则等能力，要核对具体规则名称与版本要求。
- 规则文件格式：文本、YAML 和 mihomo 的 MRS 格式不是可以仅靠修改扩展名互换的文件。
- 脚本：Premium 的
script配置不能视为 mihomo 的通用兼容接口，迁移时通常需要改写为规则或其他受支持的机制。 - DNS 扩展：
fake-ip、DNS 策略和嗅探属于不同层次的配置；旧示例中的字段名及默认行为不能直接当作新版约定。
下面是一份刻意只保留基础字段的测试配置。它监听本机 7890 端口，采用规则模式，最后将流量交给 DIRECT。它用于确认内核能加载并接受本地代理连接，不提供远程代理节点。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups:
- name: 出口选择
type: select
proxies:
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,出口选择
- MATCH,DIRECT基础配置能够启动后，再逐步加入节点、DNS、规则集合与 TUN。若一次导入数百行扩展配置，错误可能同时来自字段、文件路径和外部资源，定位成本会明显增加。
TUN 与 DNS：内核支持只是启用条件之一
TUN 通过虚拟网络接口接收被路由过来的流量，适合接管不遵循系统代理设置的程序。它不是第四种代理模式：启用 TUN 后，流量仍然可以由 rule、global 或 direct 决定后续处理。
原版开源 Clash 与 Premium 在这里存在明显区别；mihomo 也提供 TUN 能力，但还需要操作系统权限、路由设置和客户端集成配合。桌面系统通常涉及管理员权限或服务模式，Android 客户端通常通过系统 VPN 授权接入。
mihomo 的 TUN 字段示例
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
nameserver:
- 1.1.1.1
- 8.8.8.8
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53这段内容是配置片段，不是适用于所有平台的独立配置。1053 是示例中的内核 DNS 监听端口，any:53 指向常规 DNS 流量的劫持目标；二者不要求写成相同端口。示例上游 DNS 必须在当前网络中可达，否则应换成可用的解析器。
stack: mixed是 mihomo 的可选网络栈配置之一，不能把它直接复制到所有旧版内核。auto-route用于自动配置相关路由，不等于一定能绕过其他 VPN、路由器策略或防火墙限制。auto-detect-interface用于自动识别出站接口；多网卡环境仍需检查实际出站选择。- 应用自己发起的 HTTPS DNS 请求不一定会被
any:53捕获，应另查应用的安全 DNS 设置和连接记录。
如果开启 TUN 后完全断网，先关闭 TUN，确认仅使用本地 7890 端口时能否正常访问。基础代理可用而 TUN 不可用，才继续查权限、路由与 DNS，而不是立即更换订阅。
客户端对应关系与内核版本确认
客户端名称只能作为初步线索，最终应以当前安装包实际运行的内核为准。部分客户端提供内核切换、测试版通道或自定义二进制路径，安装包的界面版本与内核版本也不一定同步增长。
| 客户端或系列 | 常见内核关系 | 确认重点 |
|---|---|---|
| Clash for Windows 历史版本 | 官方历史版本常见 Premium 内核 | 不要因界面相似就按 mihomo 配置使用 |
| Clash for Android 历史版本 | 存在不同构建分支 | 记录完整版本、构建来源和内核日志 |
| Clash Verge Rev | 使用 mihomo | 查看当前选中的内核及其版本 |
| FlClash | 基于 mihomo | 区分应用版本与内核版本 |
| 其他名称含 Clash 的客户端 | 不能仅凭名称确定 | 检查关于页面、启动日志或内核文件 |
有命令行访问权限时，直接查询二进制
# Linux 或 macOS：在实际内核所在目录执行
./mihomo -v
./mihomo -t -f ./config.yaml
# Windows PowerShell：在实际内核所在目录执行
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml-v 用于输出版本信息，-t 用于测试配置。文件名可能由客户端重新命名，需要使用实际文件名。测试带有相对路径的规则集合或证书时，还应让工作目录与客户端运行环境一致，必要时使用 -d 指定配置目录。
测试通过只说明这次检查没有发现阻止加载的问题，不说明远程节点可达，也不说明 TLS 参数正确。如果没有命令行入口，可在客户端的“关于”“内核”页面或启动日志中寻找内核名称和版本；不同客户端的菜单路径并不统一。
迁移检查顺序：先加载，再连接，最后核对规则
- 保存现状。备份当前配置、订阅来源、策略组选择以及 DNS 和 TUN 设置，保留可以回退的客户端环境。
- 选择正确的订阅目标。包含 VLESS、REALITY、Hysteria2 等节点时，优先使用服务提供方明确标注的 Meta／mihomo 配置，不要只看“Clash”字样。
- 测试最终配置。客户端可能合并订阅、覆写文件和界面设置，应尽量检查实际交给内核的配置，而不只是下载到的原始 YAML。
- 确认基础连接。暂时关闭 TUN，使用明确的本地端口进行测试。系统代理、应用代理和内核监听端口必须一致。
- 确认规则命中。检查连接记录中的域名、命中规则与出站策略，避免把策略组选错误认为内核不兼容。
- 逐项恢复扩展。依次启用 DNS 策略、规则集合、嗅探和 TUN；每增加一项就重复相同的访问测试。
例如，本地混合端口是 7890 时，可以使用下面的命令显式指定 HTTP 代理，避免测试结果受到系统代理开关影响。命令需要系统已安装 curl。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com示例将连接超时设为 10 秒，仅用于限定等待时间，不代表实测延迟。收到 HTTP 响应说明这一请求经过了本地代理入口；是否通过远程节点，仍需看内核连接记录。若使用前面的基础配置，请求最终走的是 DIRECT。
安装前可查看客户端选型指南；核对字段时可查阅配置参考。判断兼容性的顺序应始终是“实际内核 → 配置字段 → 运行结果”，而不是先根据客户端名称下结论。