Clash 内核版本怎么选:原版、Premium、Meta 到 mihomo 的演进梳理

先分清客户端、内核与订阅配置

选择 Clash 时，最容易混淆的是窗口里显示的客户端版本与真正处理连接的内核版本。客户端负责订阅管理、托盘菜单、系统代理开关和配置编辑；内核负责读取 YAML、解析 DNS、匹配规则、建立代理连接。两者可以分别更新，名称也不一定相同。

订阅则是配置来源。它可能只提供节点，也可能同时带有策略组、规则、DNS 和 TUN 设置。同一份订阅在两个客户端中的表现不同，原因可能是内核能力不同，也可能是客户端导入后加入了覆写。只看文件后缀是 .yaml，不能判断它适用于哪个分支。

• 客户端版本：用来核对界面功能、系统兼容性及其发布说明。
• 内核版本：用来核对协议、配置字段、TUN 实现和规则能力。
• 配置格式：决定订阅中实际使用了哪些能力，不能仅凭“Clash 订阅”四个字推断兼容性。

演进时间线：不是四个连续升级版本

原版 Clash：开源规则代理内核

通常所说的原版 Clash，指 Dreamacro/Clash 项目的开源内核。它建立了许多人熟悉的 proxies、proxy-groups、rules 等配置结构。规则按顺序判断，命中后选择相应出站，这套思路也延续到了后来的分支。

2023 年 11 月前后的项目变动后，原版不再沿原来的官方渠道持续维护。现在遇到的原版安装包、镜像仓库或第三方重新编译产物，不应直接视为原作者恢复发布。它仍可用于理解旧配置，但不是评估现代协议支持的默认参照。

Clash Premium：历史上的闭源增强内核

Premium 是原项目提供过的闭源增强版本，不是某个图形客户端的付费会员档位。它在原版之外提供过 TUN、规则提供器和脚本等增强能力。这里的“Premium”描述内核分支，不能据此推断订阅服务是否收费。

Premium 同样已停止原渠道更新。旧教程中出现的 script 或 Premium 专用选项，不能直接当成 mihomo 的通用写法。迁移时应对照目标内核文档逐项替换，而不是只把可执行文件改名。

Clash Meta：从原版分出的社区路线

Clash Meta 是在原版基础上发展的社区分支，早期就与原版、Premium 并行存在，并非原版停更后才出现。它扩展了协议和配置能力，逐渐形成独立的维护路线。旧客户端中的“Meta 内核”选项、旧订阅中的 Meta 格式，通常指向这条路线。

mihomo：Meta 路线后续使用的项目名称

Clash Meta 后续更名为 mihomo，项目维护入口通常以 MetaCubeX/mihomo 标识。它不是原版 Clash 的官方续作，也不是 Premium 的下一代闭源版本。理解这一点，才能正确判断“Meta 配置能否用于 mihomo”：基础结构通常可以沿用，具体字段仍取决于所运行的版本。

名称变化不代表旧二进制文件自动获得了新能力。有的客户端菜单仍写“Meta”，内部却已打包 mihomo；也有旧安装包只包含很早的 Meta 构建。最终应以运行日志或内核版本输出为准。

功能差异：按配置需求比较

协议支持不是只比较名称。例如，节点写了 type: hysteria2，旧内核可能直接在加载阶段报“不支持的代理类型”；即使能够识别协议，认证参数、传输选项或 TLS 设置仍可能与服务端不一致。应先确认配置可以加载，再处理连接阶段的问题。

TUN 也不是开启后就把全部流量发送到代理。它改变的是流量进入内核的方式，进入之后仍可能按规则选择 DIRECT、代理策略或拒绝。系统代理与 TUN 是两种接管入口，不是“普通速度”和“加速速度”两个档位。

不同客户端通常使用哪种内核

下表用于识别常见组合，不代替安装包的发行说明。同名客户端的不同年代版本可能换过内核，发行者也可能调整打包方式。

Windows、macOS 与 Linux

桌面新安装可先选明确说明使用 mihomo、并提供适合系统架构安装包的客户端。macOS 要区分 Apple Silicon 与 Intel；Linux 要区分 x86_64、ARM64 等架构。架构不匹配时，程序可能根本无法启动，与订阅是否正确无关。

Android 与 iOS

Android 的 VPN 授权决定应用能否接管设备流量，但“获得 VPN 权限”不等于内核一定支持订阅里的所有字段。iOS 则不要按桌面 Clash 的方式寻找可替换的同名内核：不同网络工具有各自的配置格式与实现，必须确认应用是否支持导入该类订阅，不能仅凭支持相同节点协议就判断整份 YAML 可用。

确认实际内核：先取版本，再测配置

第一步：找到正在运行的文件

优先检查客户端的内核信息和启动日志。如果使用命令行部署，直接对服务实际调用的文件运行版本命令。不要测试下载目录中的新文件，却让后台服务继续运行旧路径下的文件。

# Linux / macOS：在内核文件所在目录执行
./mihomo -v

# Windows PowerShell：在内核文件所在目录执行
.\mihomo.exe -v

记录输出中的内核名称、版本号、构建信息及文件路径。发起问题反馈时，这些信息比“已经更新到最新版”更有用。客户端与内核使用独立版本体系，不能直接比较两者版本号大小来判断新旧。

第二步：用目标内核检查 YAML

# Linux / macOS
./mihomo -t -f ./config.yaml

# Windows PowerShell
.\mihomo.exe -t -f .\config.yaml

-t 用于配置测试，-f 指定配置文件。使用相对路径引用规则文件或其他资源时，还要注意工作目录；服务部署可通过 -d 指定配置目录。测试通过说明配置通过了相关加载检查，不代表每个远程节点、规则下载地址和 DNS 上游都能连通。

第三步：用最小配置排除外围干扰

下面是仅用于验证配置结构和本地监听的直连示例。它在本机开放混合代理端口 7890，不包含远程节点，也没有开启 TUN。若客户端已占用该端口，先停止原实例，或在测试文件中改用空闲端口。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: 手动选择
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手动选择

如果这份配置能够启动，而完整订阅不能，排查重点应转向订阅字段、外部资源、策略组引用和客户端覆写。不要一开始同时更改 DNS、开启 TUN、替换所有规则；一次只改一类设置，日志才有可比较的依据。

从 Premium 或旧 Meta 迁移到 mihomo

1. 保存原环境：备份原始订阅、本地配置、覆写内容和内核版本记录。备份中可能含节点密码与订阅令牌，不要直接公开上传。
2. 检查节点类型：核对每个 type 及其参数。优先使用订阅服务明确标注的 mihomo 格式；只有旧“Clash 格式”时，先做配置测试。
3. 检查规则与脚本：基础规则通常较容易迁移。Premium 的脚本逻辑需要单独评估，不能假设在 mihomo 中行为相同。
4. 先验证普通代理：暂不启用 TUN，确认本地端口监听、策略组选择及代表性网站访问正常，再检查 DNS 和虚拟网卡接管。
5. 逐项恢复覆写：依次恢复规则提供器、DNS、自定义路由与 TUN，每次修改后重新测试并查看启动日志。

如果普通代理能用、TUN 开启后失败，应继续检查管理员权限、路由、DNS 接管和其他 VPN 的冲突，不要直接归因于“mihomo 不兼容订阅”。如果启动时已经出现未知字段、未知协议或缺失策略组，则应先修复配置，切换系统代理开关不会解决加载错误。

选型清单：按需求保留必要能力

• 新安装、需要新协议：优先选择明确集成 mihomo 且持续发布的客户端，核对协议所需的最低内核版本。
• 需要 TUN：同时检查客户端权限处理、操作系统支持和内核配置，不只看下载页是否写了“TUN”。
• 复现历史配置：保留对应旧内核与配置副本，避免把历史行为当成现行标准。
• 设备性能有限：关注实际规则规模、DNS 缓存和连接数量；不要只凭分支名称推断内存占用。
• 希望减少维护：选择发行说明清楚、能展示内核版本、便于备份和回退的客户端，不必追逐每次测试构建。

最终判断顺序应是：先确认系统与架构，再确认客户端内置内核，接着验证订阅格式，最后开启 TUN 等附加能力。需要比较客户端时可查看选型指南；需要核对 DNS 与虚拟网卡设置，可阅读DNS 配置和TUN 配置。把界面版本、内核版本和配置来源分开记录，后续升级与排错会更直接。