Clash 原版内核、Clash.Meta 与 mihomo 区别:功能与配置兼容性梳理

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

看到客户端支持“Clash 配置”，不能直接推断它支持所有 Clash.Meta 或 mihomo 字段。客户端负责窗口、订阅管理、系统代理开关与服务安装；内核负责监听端口、解析域名、匹配规则和建立代理连接；订阅则提供节点或整份配置。这三层分别更新，出现“订阅导入成功，但节点无法启动”时，问题可能在内核能力，而不在导入按钮。

例如，图形界面仍沿用 Clash 的产品命名，底层却可能已经使用 mihomo。反过来，一个能导入 YAML 的旧客户端，也可能继续携带早期内核。判断兼容性时，应先查看内核名称与版本，再看配置里的协议和功能字段，不要只看应用名称。

客户端版本：通常在「设置」→「关于」查看，用于确认界面与服务组件的版本。
内核版本：在客户端的内核信息、运行日志开头查看；直接运行二进制时，可使用 mihomo -v。
实际生效配置：查看客户端提供的运行配置预览或启动日志中的配置路径。订阅原文不一定等于最终加载文件。

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

原版 Clash 还要区分开源版本与 Premium

历史上的原版 Clash 包含开源内核与 Premium 分支。两者不能按同一张功能清单理解：TUN、规则集提供器等能力曾与 Premium 的功能范围有关。如果旧教程只写“Clash 支持 TUN”，却没有注明具体分支，就容易让使用开源版本的用户找不到对应能力。

原版相关项目在 2023 年停止公开维护后，旧二进制仍可能在既有系统上运行，但这不代表它能识别后来新增的协议与配置选项。新配置能否加载，必须以该二进制实际实现为准。

Clash.Meta 是分支，mihomo 是其后续名称

Clash.Meta 在 Clash 的基础上扩展协议、DNS 与路由能力，后来项目改名为 mihomo。因此，Clash.Meta 与 mihomo 不是两套完全独立、需要逐行互译的配置体系。很多旧教程、订阅按钮和文件名继续使用 Meta 字样，指向的却可能已经是 mihomo 配置。

不过，“属于同一演进路线”不等于所有历史版本功能相同。早期 Meta 二进制仍可能不支持较新的 mihomo 选项。看到字段报错时，应核对所用版本对应的文档与发布说明，而不是简单认为“Meta 都支持”。

对象	主要定位	迁移时的关注点
原版开源 Clash	基础代理、策略组与规则分流	不能默认支持 Premium 或 Meta 扩展
Clash Premium	原版体系的扩展分支	脚本模式等功能不能直接视为 mihomo 等价能力
Clash.Meta	扩展协议与路由能力的分支	名称延续广泛，具体功能仍取决于版本
mihomo	Meta 后续项目名称	核对新字段、客户端接管方式与实际运行配置

协议、规则与 TUN 的实际区别

节点协议支持决定订阅能否真正使用

原版常见配置使用 Shadowsocks、VMess、Trojan、SOCKS5 或 HTTP 等代理类型。mihomo 在此基础上支持 VLESS、Hysteria2、TUIC 等扩展协议，但每种协议的传输方式、认证参数与具体选项仍有版本要求。不要把“支持某协议”理解为“支持该协议所有实现的全部参数”。

旧内核遇到 type: hysteria2 之类不认识的代理类型，通常无法正常加载该节点；部分客户端会在转换或导入阶段提前过滤节点。若订阅更新后数量从 20 个变成 0 个，先看导入日志和协议类型，再检查服务是否到期，不必立即调整 DNS。

基础规则通常可沿用，扩展规则需要核对

DOMAIN、DOMAIN-SUFFIX、IP-CIDR、MATCH 这类基础规则具有较好的延续性。更复杂的逻辑规则、进程匹配与规则集格式，则要同时检查内核支持、操作系统能力及数据文件是否可用。规则仍然遵循从上到下匹配的基本思路；把兜底 MATCH 放在前面，会让后面的规则失去作用。

例如，下面是一段独立的规则片段，不是完整配置。它假设现有配置中已经有名为“代理选择”的策略组；名称必须逐字一致，否则即使 YAML 格式正确，也会出现引用错误。

rules:
  - DOMAIN-SUFFIX,example.com,代理选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,代理选择

这里的 no-resolve 表示该 IP 规则不主动为域名触发解析，并不等于整个内核关闭 DNS。192.168.0.0/16 也只覆盖一个私网网段，这段示例不是完整的局域网绕过清单。

TUN 是接管方式，不是节点协议

系统代理通常只影响遵循系统代理设置的应用；TUN 通过虚拟网络接口接管流量，覆盖范围更广，但需要权限、路由和 DNS 配合。原版 Premium 与 mihomo 都可能涉及 TUN，不能单凭界面出现“TUN”开关就判断内核相同。

迁移时不要把旧客户端的虚拟网卡、后台服务或路由配置当作新客户端的依赖。先退出旧客户端并关闭其接管，再由新客户端安装或启用自己的服务。两套 TUN 同时运行，可能造成默认路由竞争、DNS 回环或局域网访问异常。

旧配置迁到 mihomo：哪些保留，哪些重查

不建议把旧配置全文粘贴后一次打开所有功能。先备份，再建立最小可用基线：节点能连、策略组可选、规则命中正确，最后接入 DNS 增强和 TUN。这样每一步都能对应到明确的故障范围。

字段或内容	处理建议	具体检查
`proxies`、`proxy-groups`	先保留基本结构	协议选项有效，策略组引用名称存在
`rules`	保留顺序后逐项验证	目标策略存在，兜底规则位于末尾
`rule-providers`	核对来源与格式	`behavior` 与实际规则内容一致
`dns`、`tun`	按新环境重查	端口、网段、权限与路由没有冲突
`script`	不要直接照搬	Premium 脚本分流需重写为支持的规则逻辑
`external-controller`、`secret`	检查客户端接管	控制端口没有冲突，访问密钥不随配置公开

端口与本地路径尤其容易被忽略

例如，旧配置使用 mixed-port: 7890，新客户端也监听 7890，旧进程没有退出时就可能出现端口占用。若新客户端改成 7897，终端里的代理环境变量仍指向 127.0.0.1:7890，终端请求又会继续找旧端口。这里的数字只是常见配置示例，不是所有客户端的固定默认值。

规则提供器和代理提供器里的相对 path，通常需要结合内核工作目录理解。把 YAML 移到另一目录，并不保证对应缓存文件也一起迁移。应让新客户端重新更新提供器，并从日志确认文件写入成功，不要只看界面上保留的旧节点名称。

订阅覆盖可能让修改“消失”

有些客户端更新订阅时会重建配置，手工改过的 dns 或 rules 随即被覆盖。应优先使用客户端支持的覆写、合并或扩展配置功能，并查看最终运行配置确认结果。合并规则是否追加、替换或前置由客户端决定，不能仅凭覆写文件内容推断最终顺序。

DNS 与 fake-ip：迁移时重查解析链路

fake-ip 的基本思路是为域名返回虚拟地址，并让内核在后续连接中关联回域名。它不是某个节点协议，也不自动保证所有 DNS 请求都经过指定解析器。系统 DNS、浏览器安全 DNS、应用内置解析，以及 TUN 的 DNS 劫持范围，都会影响最终路径。

下面仅展示 mihomo 的 DNS 配置片段，需要合并到现有配置中。示例监听本机 1053 端口，避免直接占用常见的 53 端口；但“开启监听”本身不会自动让操作系统把查询送到这里。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "+.example.com":
      - https://1.1.1.1/dns-query

虚拟地址范围：198.18.0.1/16 位于测试用途地址空间内；若本地实验网络已经使用该范围，需要先消除冲突。
分域解析：nameserver-policy 为匹配域名指定解析器，不等于把该域名的业务连接固定到某个代理节点。
加密解析：DoH 保护对应解析请求的传输，但端点是否可达、请求如何路由，仍需结合实际网络检查。
地址映射：更改 fake-ip 设置后，系统或浏览器可能仍缓存旧地址；应刷新缓存或重启测试应用，再观察新连接。

若需要 TUN 接管 DNS，可在已有 TUN 配置中核对 dns-hijack。常见写法涉及 any:53 与 tcp://any:53，分别关注普通 DNS 的 UDP 与 TCP 流量；具体接管效果还受平台与路由实现影响。应用直接使用 HTTPS 发出的 DoH 并不是发往 53 端口的普通 DNS，不能期待这类劫持把它自动改写。

配置迁移验证：从语法检查到 TUN 接管

第一步：检查配置能否加载

直接使用内核时，可以先运行下列命令。Windows 可将命令中的程序名替换为本地的 mihomo.exe，并在配置文件所在目录执行。使用图形客户端时，应优先使用其配置检查入口，避免另起进程争抢正在使用的端口。

mihomo -v
mihomo -t -f ./config.yaml

检查通过只说明配置达到该次测试的加载要求，不代表节点服务端可达，也不代表每条规则都符合预期。若错误指向某一行，应同时检查上一行的缩进、冒号与列表符号；YAML 的制表符缩进、重复顶层键，都可能造成难以察觉的问题。

第二步：只用一个节点验证代理出口

退出旧客户端，暂时关闭新客户端的 TUN，使用规则模式并选择一个已知可用节点。
确认实际混合端口。若配置为 7890，可用下方命令显式经过该端口请求测试域名。
在连接记录中核对目标域名、命中的规则与最终节点。显式代理成功后，再开启系统代理验证普通应用。
最后启用 TUN，分别测试浏览器、终端和一个不遵循系统代理的应用，同时确认局域网访问仍正常。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

这里的 10 秒连接超时和 20 秒总超时用于控制测试等待时间，不是网速指标。若提示连接本地端口失败，应先检查监听；若日志已经出现代理握手错误，则应检查节点认证、传输参数或线路，而不是继续更改本地端口。

第三步：验证订阅更新与回退

手动更新一次订阅和规则提供器，再确认自定义规则、DNS 覆写和策略组选择是否保留。完成后保存新客户端的有效配置备份，并保留旧配置的离线副本。需要回退时，先停止新客户端接管，再恢复旧环境，避免两边同时修改系统代理与路由。

内核选择结论：按配置需求与维护状态判断

如果目标是继续使用现有 Clash 风格订阅，并需要较新的协议、规则和 DNS 功能，应选择明确集成 mihomo、且能查看内核版本与运行日志的客户端。若旧配置来自 Premium，迁移重点是脚本逻辑、提供器、TUN 与 DNS，而不是简单更换程序文件名。

只需要基础分流：先让节点、策略组和基础规则稳定工作，不必为了功能名称一次开启所有选项。
需要新协议：核对具体内核版本和协议字段，优先获取服务提供方明确标注适配 Meta 或 mihomo 的配置。
需要全局接管：确认平台权限、TUN 服务与 DNS 链路，按“显式代理 → 系统代理 → TUN”的顺序验证。
需要长期维护：同时关注客户端与内核更新。界面更新和内核更新是两件事，升级后仍要复查关键配置。

Clash.Meta 与 mihomo 的名称关系只是起点。真正决定配置能否迁移的，是运行中的内核版本、有效配置内容，以及本机端口、权限和解析路径。把这几项逐一记录下来，出现问题时就能明确回到对应层排查。