内核解析 预计阅读 10 分钟

Clash 原版、Meta 与 mihomo 内核版本差异对照

梳理 Clash 原版内核、Clash.Meta 与 mihomo 的演进关系,对比协议支持、规则类型、TUN 实现与配置字段差异,帮助判断现有配置能否直接沿用。

先看结论：Meta 与 mihomo 属于同一条演进路线

迁移时，先确认客户端实际运行的内核，再检查订阅格式。Clash.Meta 后来更名为 mihomo，不是两个互不相关的配置体系。大部分基础 Clash YAML 配置可以作为迁移起点；反过来，把使用 mihomo 扩展字段的配置交给旧版 Clash，并不能保证可用。

内核负责解析配置、匹配规则和建立代理连接；客户端负责界面、订阅管理、系统授权等操作。同一个客户端名称下，不同发行版本也可能打包不同内核。因此，“安装了 Clash”不足以判断某个协议是否受支持。

名称、维护状态与配置兼容范围

名称 定位与状态 迁移时重点检查
Clash 原版开源内核 原始开源实现，原项目已停止维护 基础协议、基础规则；不要预期支持后续新增协议
Clash Premium 历史上的闭源增强发行版本，已停止维护 TUN、规则提供器以及脚本等历史功能的迁移方式
Clash.Meta 基于 Clash 演进的分支，是 mihomo 的旧名称 旧版本是否支持配置里使用的新字段
mihomo 延续 Meta 路线，持续扩展协议、规则与网络能力 具体版本、系统平台以及客户端的覆写行为

怎样确认当前运行的内核

  1. 打开客户端的“关于”“内核”或启动日志页面。菜单名称由客户端决定，并不存在所有手机通用的固定路径。
  2. 记录内核名称、完整版本号、设备系统与客户端版本，不要只记录应用商店显示的版本。
  3. 桌面环境若能直接运行内核，可执行 mihomo -v 查看版本。这个命令查询的是指定可执行文件，不代表手机应用内置的版本。

旧配置备注里的“Meta 专用”通常说明它依赖增强能力，并不表示必须寻找名为 Meta 的旧安装包。判断标准应当是目标 mihomo 版本是否支持所用字段，而不是名称是否一致。

协议差异：节点导入成功不等于能够连接

协议是客户端与代理服务器之间的通信约定。原版 Clash 常见配置包括 Shadowsocks、VMess、Trojan、SOCKS5 和 HTTP 代理。mihomo 在这条基础上扩展了 VLESS、Hysteria2、TUIC、WireGuard 等支持，但具体能力仍与内核版本和平台有关。

新协议还要核对传输参数

遇到“不支持的代理类型”时，先看配置中的 type 和内核版本。遇到握手失败或超时，则继续检查服务器地址、端口、设备时间、认证参数和网络条件。不要把所有连接失败都归为内核不兼容，也不要用关闭证书验证来代替定位问题。

规则差异：基础语法相近，扩展规则要逐项核对

规则按从上往下的顺序匹配，命中后交给对应策略处理。DOMAIN 匹配指定域名，DOMAIN-SUFFIX 匹配域名及其子域，IP-CIDR 匹配地址段，MATCH 用于最后兜底。这些基础思路在不同分支之间相对稳定。

规则提供器不是单纯的规则链接

rule-providers 用来声明外部规则集合，再由 RULE-SET 引用。历史 Premium 与 mihomo 都有相关能力，但不能因此推断所有原版开源构建都能读取。迁移时要同时检查提供器类型、文件格式和内容类型。

从 Premium 迁移时，尤其要单独检查 script。旧版脚本配置不能视为 mihomo 的通用兼容接口；更稳妥的方式是梳理脚本实际完成的条件判断，再按目标版本支持的规则、逻辑规则或子规则改写，并逐条测试。

TUN 与手机 VPN：内核能力和系统接管要分开看

TUN 是把网络数据交给虚拟网络接口处理的一种方式。它可以让不读取系统代理设置的应用流量进入代理内核。历史上，TUN 是 Clash Premium 与 Meta 等增强路线的重要能力，不能据此认为原版开源 Clash 的每个构建都自带相同实现。

Android 客户端通常利用 VpnService，也就是系统提供的 VPN 接口，获得接管流量的权限。是否弹出 VPN 授权、哪些应用进入通道、后台是否持续运行，既受客户端实现影响，也受系统限制影响。换内核并不会自动完成这些授权。

mihomo TUN 配置片段如何理解

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

这是常见桌面场景的字段示意，不是手机端必须照抄的完整配置。auto-route 负责自动配置相关路由，auto-detect-interface 用于自动识别出站接口，stack 选择网络栈实现。权限、路由处理与可用选项仍要以目标系统和内核版本为准。

配置迁移：先跑通基础文件，再恢复 DNS 与覆写

YAML 是一种用缩进表达结构的配置格式。文件能被解析，只说明结构基本可读；部分未知字段可能被忽略，并不意味着预期功能已经生效。迁移验收要同时看启动日志、连接记录和实际规则命中情况。

第一步：准备可回退的配置

  1. 保留原订阅地址、当前配置副本和客户端覆写内容。订阅地址属于敏感信息，截图与日志分享前应隐藏认证信息。
  2. 在新客户端新增一份配置，不直接覆盖旧客户端正在使用的文件。
  3. 确认订阅服务返回的是 Clash 或 mihomo 可识别的 YAML，而不是其他客户端格式或仅包含分享链接的文本。

第二步：用基础片段隔离问题

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

proxies: []

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

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,MANUAL

这份示例只用于检查配置加载、端口与规则链路，全部流量最终直连，不提供代理出口。mixed-port: 7890 表示同一监听端口接受 HTTP 与 SOCKS 代理连接。手机上的其他应用是否经过该端口，仍取决于 VPN 接管或应用自身的代理设置。

配置加载正常后，再通过客户端的配置合并、覆写功能，或在本地测试副本中加入真实节点和策略组。策略组名称要与规则引用完全一致。例如规则写了 PROXY，配置却只有 MANUAL，就需要统一名称，不能靠内核自动猜测。

第三步：恢复 DNS，避免一次改动过多

迁移验收：按报错层级排查

现象 优先检查 下一步
配置无法启动 YAML 缩进、节点类型、策略名称和内核版本 根据日志行号定位，再用最小配置复测
端口监听失败 7890 是否已被另一实例占用 停止重复实例，或同步修改监听端口与应用代理设置
延迟测试成功但应用打不开 测试 URL 与实际目标不同、规则出口、DNS、UDP 查看该应用的连接记录，核对命中的规则与节点
浏览器可用，其他应用失败 是否只配置了浏览器代理、VPN 应用排除列表 检查系统 VPN 状态与客户端应用分流设置

在能直接运行内核的桌面环境，可用 mihomo -t -f config.yaml 检查指定文件。通过检查并不代表服务器可达，也不代表客户端最终运行的就是这个文件。手机端还要核对“当前启用配置”，以及订阅更新后覆写是否仍然生效。

最后至少做三项测试：打开一个应直连的站点、打开一个应走代理的目标、锁屏后重新联网。分别确认规则命中、出口选择和后台连接。需要支持新协议或增强规则时，重点选择内核版本清楚、更新记录明确的客户端；只使用基础配置，也应保留原配置副本，逐步迁移而不是一次替换所有网络设置。

下载Clash