Clash 内核版本区别：原版、Meta 与 mihomo 配置兼容性

在客户端设置、配置仓库和订阅说明中，Clash、Clash.Meta、Meta、mihomo 经常同时出现。它们并非四套彼此独立的配置体系，但也不能简单视为同一个程序的不同拼写。判断一份 YAML 能否加载，除了看文件扩展名，还要确认实际运行的内核、内核版本、客户端提供的配置预处理方式，以及订阅服务输出了哪些扩展字段。

多数基础配置可以在这些内核之间复用，例如监听端口、代理节点、策略组和常见域名规则。不过，TUN、流量嗅探、新协议、规则集合、DNS 扩展和进程匹配等能力存在明显差异。选错内核时，常见结果不是整个文件都无法读取，而是部分字段被拒绝、某个节点无法创建、规则没有按预期命中，或者图形客户端根本不显示对应开关。

Clash、Clash.Meta 与 mihomo 的名称关系

原版 Clash

通常所说的“原版 Clash”，指最初的开源 Clash 内核及其既有配置语法。它建立了目前仍广泛使用的基础结构，包括 proxies、proxy-groups、rules、dns、mixed-port 和 external-controller 等字段。很多订阅转换工具与客户端配置模板，也以这套结构作为共同基础。

原版项目已经停止持续维护。这意味着它仍可能在旧设备或既有客户端中正常运行，但不会继续跟进新协议、平台网络接口变化和后续扩展字段。对仅使用 HTTP、SOCKS5、Shadowsocks、Trojan 等既有能力的旧配置而言，短期内可能感觉不到差异；一旦订阅加入较新的节点类型或配置依赖新规则能力，兼容边界就会显现。

Clash.Meta

Clash.Meta 是在 Clash 配置体系基础上继续发展的分支。它保留大量基础字段，同时扩展了代理协议、TUN、DNS、嗅探、规则类型和平台适配能力。部分客户端曾直接把内核标记为“Meta”，配置文档也经常使用“Meta 专属字段”这一说法，因此该名称至今仍出现在订阅模板和故障日志中。

mihomo

mihomo 是 Clash.Meta 后续采用的项目名称。就演进关系而言，日常语境中的新版 Meta 与 mihomo 通常指向同一条持续维护的内核路线，而不是需要互相转换的两种配置格式。实际判断时仍应查看版本号，因为早期 Clash.Meta 与当前 mihomo 之间经历了字段补充、默认行为调整和协议实现更新。

因此，“支持 Meta”不能自动等同于“支持当前全部 mihomo 配置”。某个较旧客户端即使内置 Meta 内核，也可能无法识别后来加入的节点参数；反过来，新的 mihomo 通常能够读取大部分基础 Clash 配置，但旧字段的行为、默认值或推荐写法可能已经变化。

维护状态、协议与规则能力对比

协议支持是最容易观察到的差别。订阅中的每个节点都会声明 type 及其参数。内核不认识节点类型时，通常会在配置检查或启动日志中报告解析错误；认识协议但不支持某个参数时，也可能出现字段错误。此类问题不能通过修改策略组名称解决，应先核对客户端内置内核的版本与节点协议要求。

规则能力的差异更隐蔽。经典规则如 DOMAIN-SUFFIX、DOMAIN、IP-CIDR、GEOIP 和 MATCH 具有较高通用性。涉及规则集合行为、进程名、网络类型、入站标签或逻辑组合的配置，则更依赖 mihomo 的具体版本。配置能够启动，也不代表扩展规则一定按照作者预期执行，迁移后应通过连接记录检查实际命中项。

哪些 YAML 字段通常可以兼容

以下结构适合作为跨版本配置的基础层。它只展示字段关系，不包含真实服务器凭据：

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

proxies:
  - name: Example-Node
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Example-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mixed-port 用于同时提供 HTTP 与 SOCKS 代理入口；mode: rule 表示按规则决定连接去向；策略组名称必须与规则末尾引用的目标一致。此类错误与内核分支无关，例如规则指向 Proxy，而策略组实际名为 PROXY，任何内核都无法自动推断两者是同一组。

节点字段是兼容检查的第一层。即使 proxies 列表本身属于通用结构，列表内部的协议类型、传输层参数、TLS 指纹、UDP 行为和认证选项仍可能仅被特定版本支持。订阅服务更新节点模板后，旧客户端突然无法启动，往往就是内核版本落后于订阅输出格式。

DNS 是第二层。经典 enhanced-mode: fake-ip、默认解析器和备用解析器具有较广泛的认知度，但 nameserver-policy、代理服务器域名解析、Fake-IP 排除列表以及不同上游的传输格式，会随内核版本出现差异。复制新版 mihomo 示例到旧版 Clash 前，应逐项查询内核文档，而不是只删除报错的第一行。

TUN、嗅探与规则集合为何容易出问题

TUN 不只是一个开关

TUN 模式让内核通过虚拟网络接口接收流量，适合不遵循系统代理设置的应用。mihomo 配置中常见 tun 区块以及 enable、stack、auto-route、auto-detect-interface 等参数。能否正常运行还取决于操作系统权限、路由表、已有 VPN、虚拟机网络和客户端是否正确启动服务组件。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

将这段配置放进原版或较旧 Meta 内核时，可能出现未知字段，也可能因平台实现不同而无法建立接口。即使内核支持，图形客户端也可能在启动时重写 TUN 配置。因此排查顺序应是：确认内核版本、检查配置测试结果、查看启动日志、核对系统权限，最后再检查路由冲突。

嗅探用于恢复域名信息

流量嗅探会尝试从 HTTP、TLS 或其他可识别流量中提取目标域名，使仅表现为 IP 连接的请求仍可参与域名规则匹配。mihomo 对嗅探协议、端口范围、强制域名与跳过域名提供了较细控制。旧内核无法直接承接这些字段，错误配置还可能影响局域网服务、游戏连接或采用特殊握手方式的应用。

规则集合需要同时检查格式与行为

远程规则集合涉及下载地址、缓存更新、规则行为类型和内容格式。不同内核及版本对 Rule Provider 或 Rule Set 的字段命名、载荷格式和更新方式可能不同。仅仅看到规则文件下载成功，还要确认它被目标规则引用，并且集合行为与内容一致。例如域名集合不能直接按 IP 网段集合的方式解释。

规则列表遵循从上到下匹配。无论使用哪种内核，过早出现宽泛规则都会截断后续匹配。MATCH 一般应置于末尾；局域网与私有地址直连规则应放在适当位置；启用 Fake-IP 后，DNS 映射与规则判断也要结合连接日志观察。内核升级不会自动修复规则顺序错误。

客户端名称与实际内核如何核对

图形客户端通常把内核文件封装在应用目录中，并通过控制接口读取代理组、连接、日志和配置状态。有些客户端允许在设置中切换内核，有些固定使用某个分支，还有些在应用升级时一并更新内核。判断实际环境时，可以按以下顺序检查：

1. 查看关于页面或日志首行。启动日志通常会显示内核名称、版本和构建信息，比客户端宣传页更接近当前运行状态。
2. 使用客户端自带的配置检查。先验证 YAML 语法，再观察错误是否指向未知字段、节点类型或无效值。
3. 确认覆写与订阅转换。客户端可能在加载前合并本地设置，磁盘上的订阅原文不一定等于内核最终收到的配置。
4. 核对控制接口兼容性。mihomo 延续了大量 Clash API 结构，但扩展功能未必能被旧界面完整展示。
5. 检查内核切换是否真正生效。更换文件后应彻底停止旧进程并重新启动，避免界面仍连接到后台残留实例。

客户端界面没有某个选项，不一定表示内核缺少该能力；可能只是界面尚未提供表单。反过来，界面保留了旧开关，也不保证当前内核仍采用相同默认值。对高级字段，较稳妥的方法是编辑 YAML 或覆写文件，并在启动后检查最终配置与日志。

移动端和桌面端还存在系统能力差异。桌面客户端常通过系统代理或 TUN 接管流量，移动系统通常依赖系统提供的 VPN 接口。相同 mihomo 配置跨平台复制时，节点和规则可以复用，但入站端口、TUN 路由、局域网访问与 DNS 接管设置应按平台调整。

从原版 Clash 迁移到 mihomo 的检查步骤

从旧内核迁移时，不建议一开始就叠加所有新功能。先让原有配置在新内核上稳定运行，再逐层启用 DNS、TUN、嗅探和规则集合，更容易定位问题。

1. 保留原配置和客户端设置。分别备份订阅原文、本地覆写、策略组选择和 DNS 设置，避免把多个来源混成一份难以回退的文件。
2. 建立最小可运行配置。保留一个可用节点、一个选择策略组和少量规则，确认内核能启动并建立连接。
3. 恢复完整节点与策略组。重点检查组内引用名称、自动测速地址、筛选表达式和协议参数。
4. 恢复规则。先加入经典域名与 IP 规则，再接入远程集合；每次调整后观察规则命中和日志。
5. 配置 DNS。确认基础解析、代理节点域名解析与 Fake-IP 排除项，再检查局域网域名及特殊应用。
6. 最后启用 TUN 与嗅探。这两项会改变系统流量入口和目标识别方式，应单独测试浏览器、终端、游戏与局域网访问。

迁移后出现“浏览器可用但终端不可用”，通常要检查终端是否读取系统代理、环境变量是否设置，以及是否需要 TUN；出现“节点可连接但域名打不开”，应检查 DNS 上游、Fake-IP 模式和节点服务器域名解析；出现“部分网站策略错误”，则应查看实际命中规则，而不是直接更换全部节点。

如果新内核提示弃用字段，应根据当前版本文档替换，而非长期依赖兼容处理。配置文件是持续运行的基础设施，保留已经失去含义的字段会增加后续升级成本。对于订阅生成的字段，应优先调整订阅模板或转换规则，避免每次更新后手工修改。

不同使用场景的内核选型

继续运行已有旧环境

如果设备长期离线、配置固定、节点协议稳定，并且客户端与系统版本都不再变化，原版 Clash 仍可能维持既有用途。但这种选择适合维持现状，不适合作为新的部署基线。订阅一旦引入新协议或新参数，旧内核可能立即暴露兼容限制。

新安装与持续更新的订阅

对新安装、经常更新订阅、需要 TUN 或希望使用现代规则能力的环境，优先选择内置较新 mihomo 的客户端。选客户端时应同时查看内核更新机制、配置目录、日志入口、系统代理控制和 TUN 服务安装方式，而不是只比较界面布局。

多设备共用配置

多设备配置应以兼容性较高的基础层为中心，再为每个平台附加覆写。节点与策略组可以来自同一订阅，桌面端追加 TUN 和进程规则，移动端保留适合系统 VPN 接口的设置，服务器则按命令行服务和环境变量需求处理。这样能够避免某个平台专属字段阻止其他设备加载。

服务端或命令行部署

在 Linux 服务器、软路由或容器中直接运行内核时，mihomo 的持续维护更适合作为部署基础。除了配置语法，还要固定可控的版本更新流程，明确配置目录、工作目录、Geo 数据位置、控制端口和服务权限。升级前应先执行配置测试，再重启服务并检查日志，避免把语法问题误判成网络故障。

常见兼容问题