原版 Clash、Clash.Meta 与 mihomo 内核差异梳理:功能支持与配置兼容性

名称关系：原版、Premium 与 Meta 分支

判断 Clash 配置能否迁移，先区分图形客户端与代理内核。客户端负责订阅管理、托盘菜单、权限申请与配置生成；内核负责监听端口、解析 DNS、匹配规则和建立出站连接。同一个客户端名称下，可能搭载不同版本的内核。界面能导入 YAML，并不代表内核能够执行其中全部字段。

“原版 Clash、Clash.Meta、mihomo 三代内核”便于检索，但不是严格的项目谱系。Clash.Meta 是从 Clash 发展而来的分支；mihomo 是这一分支后续采用的项目名称，不是与 Clash.Meta 完全无关的第三套实现。Premium 则是原 Clash 体系中的增强版本，不能直接等同于 Meta。

原版 Clash：以 Dreamacro/clash 为代表的开源内核，建立了常见的 YAML 配置结构、规则模式、策略组与控制接口。
Clash Premium：原作者提供的闭源增强内核，历史上提供 TUN、规则集、脚本等增强能力；不能仅凭开源版的功能表推断 Premium。
Clash.Meta：MetaCubeX 维护的衍生分支，扩展协议、DNS、规则与流量接管能力。
mihomo：Meta 分支延续使用的名称。旧订阅模板、客户端选项和教程中仍可能出现 Meta，兼容判断应落实到实际内核版本。

时间线上，原 Clash 与 Premium 的原有发布渠道在 2023 年末发生重大变化；Meta 分支继续演进，随后在 2024 年转向使用 mihomo 名称。旧安装包即使仍能启动，也不会因此自动获得后续协议和配置字段支持。

功能对照：协议、规则与配置边界

下面比较的是能力方向，不是所有历史版本的逐项承诺。尤其是 mihomo，新协议和新字段随发布逐步加入。订阅中出现某个 type，仍需核对本机内核是否支持该类型及其附属参数。

项目	原版开源 Clash	Clash Premium	Clash.Meta / mihomo
常见基础协议	支持 Shadowsocks、VMess、Trojan 等，具体参数受版本限制	延续原版基础协议能力	保留基础协议，并持续扩展实现
VLESS、REALITY、Hysteria2、TUIC	不作为这些新协议或特性的支持目标	不能视为 Meta 扩展协议的替代实现	相应版本支持；还需核对传输层与认证参数
基础分流	支持域名、IP、GEOIP、MATCH 等常见规则	支持基础规则并提供增强能力	保留基础规则，并扩展逻辑匹配等能力
规则集与脚本	不能按 Premium 的规则集、脚本能力理解	支持规则集及特定脚本机制	支持规则集；不应假定兼容 Premium 脚本运行环境
TUN	不提供 Premium 的内置 TUN 能力	提供 TUN，但受系统与发布版本限制	提供 TUN，具体协议栈及路由选项需查对应版本

协议名称相同，也不代表参数完全一致

例如，VMess 节点可能涉及 WebSocket、TLS、服务名称或请求头；VLESS 还可能使用 REALITY 和特定流控参数。REALITY 是相关连接的安全握手能力，不应当作一个可以随意填入 type 的独立节点协议。迁移时只改节点类型、保留不匹配的传输参数，往往会通过部分解析却在握手阶段失败。

解析失败：优先检查协议类型、字段拼写、YAML 缩进和字段的数据类型。
握手失败：核对服务器地址、端口、凭据、TLS 服务名、传输方式与服务端设置。
连接超时：再检查网络可达性、UDP 支持、上游阻断和本地防火墙，不能只归因于内核名称。

配置兼容性：哪些能保留，哪些要重写

原版配置迁往 mihomo 时，proxies、proxy-groups、rules 等基础结构通常具有较强延续性。但“字段仍然存在”不等于“所有默认值与执行结果相同”。应当把协议参数、规则数据、DNS、TUN 和客户端覆写分别检查。

基础规则：先核对策略名称和执行顺序

proxy-groups:
  - name: 出站选择
    type: select
    proxies:
      - DIRECT

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

这段配置用于检查结构，不包含远端代理节点。“出站选择”当前只有 DIRECT，因此命中它仍然直连。迁移真实配置时，需要把已验证的节点名称加入策略组；规则引用的名称必须与策略组或节点名称完全一致。

规则通常自上而下匹配，MATCH 应放在末尾。示例中的 no-resolve 表示不为了这条 IP 规则主动触发域名解析，并不是关闭全部 DNS，也不是让域名规则失效。如果连接尚无可用目标 IP，这条规则可能无法命中。

规则集：数据格式比文件扩展名更重要

迁移 rule-providers 时，同时核对 type、behavior、format、path 和更新地址。behavior: domain、ipcidr、classical 对内容有不同要求。把包含完整规则的 classical 数据当成纯域名列表使用，不会因为文件名都是 YAML 就自动兼容。

同样，不要把 mihomo 支持的规则集格式直接交给旧内核。例如二进制规则集需要对应实现支持，改后缀不能完成转换。远程规则集即使下载成功，也仍需确认解析日志和实际规则命中。

DNS 与 TUN：字段相似，接管范围不同

系统代理通常只影响遵循系统代理设置的应用。TUN 通过虚拟网络接口和路由规则接管符合条件的 IP 流量，适合处理不读取系统代理设置的程序，但并不意味着所有流量必定经过远端代理。接管之后，流量仍要经过规则匹配，可以得到 DIRECT、拒绝或代理等不同结果。

先确认 DNS，再开启虚拟网卡

迁移时建议先关闭 TUN，用本地代理端口验证节点与分流，然后再引入 DNS 劫持和路由接管。这样可以区分“代理连接失败”和“系统 DNS 没有进入内核”两类问题。以下是 mihomo 的配置片段，应合并到现有配置，不要重复定义顶层 dns 或 tun。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

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

127.0.0.1:1053 是本地 DNS 监听地址；仅开启监听，不会自动让所有应用改用该地址。
198.18.0.1/16 是示例 fake-ip 地址池。它提供映射用的合成地址，不是远端代理服务器地址。
enable: false 用于先验证非 TUN 路径。准备好权限和路由后，再将其改为 true。
dns-hijack 处理的是符合接管条件的 DNS 流量，不能将应用自行建立的所有 DoH 或 DoT 连接都当成普通 53 端口查询。

系统差异：权限与路由要一起检查

Windows 通常需要客户端服务模式或相应提升权限；macOS 可能通过特权辅助程序或具体应用的网络接管机制实现；Linux 需要检查 TUN 设备与网络管理权限。Android 客户端常通过系统 VPN 接口接管流量，其界面配置和桌面端原始 YAML 不一定一一对应。

同时运行另一套 VPN、虚拟机网络或企业安全软件时，默认路由与 DNS 设置可能互相覆盖。关闭 TUN 能恢复连接，只能说明问题集中在接管路径，不能直接证明某个协议不兼容。应记录默认出口、DNS 地址、路由变化和日志时间，再逐项排除。

迁移验证：配置检查、端口测试与回滚

可靠迁移需要一个可复现的顺序。不要同时升级内核、替换订阅、修改 DNS 并开启 TUN，否则出现异常时难以定位变量。保留旧配置副本，在新客户端中使用独立配置进行验证。

记录基线：保存当前可用节点、策略选择、DNS 模式和监听端口，记录是否启用系统代理与 TUN。
核对目标内核：确认是 mihomo 还是旧 Meta 二进制，并查看实际版本；不能只看订阅模板标题。
检查配置：先执行配置测试，再启动监听。测试通过说明能够加载，不代表节点握手和规则更新都已成功。
单连接验证：固定一个节点，以同一个目标地址比较直连和显式代理，不先使用自动测速组。
恢复附加能力：依次恢复规则集、DNS、TUN、开机启动，每一步都观察日志和连接记录。

mihomo -v
mihomo -t -f config.yaml

若客户端使用的混合端口是 7890，可以用以下命令区分显式代理和直连路径。实际端口应以运行配置为准，7890 只是常见示例，并非所有客户端的固定默认值。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://clashgrand.com/
curl --noproxy "*" --connect-timeout 10 --max-time 20 -I https://clashgrand.com/

这两个命令不构成速度实测，也不能仅凭状态码判断出口。需要结合客户端连接记录，确认目标连接命中了哪条规则、使用哪个策略及最终节点。如果策略组仍选择 DIRECT，显式连接本地代理端口后也可能直接访问目标。

常见故障与优先检查项

现象	优先检查	处理方向
未知代理类型或字段错误	实际内核、订阅目标格式、参数数据类型	选择 mihomo 对应配置，或升级到支持该字段的版本
端口绑定失败	旧客户端是否仍占用 7890 或本地 DNS 端口	退出旧进程，或修改端口并同步应用设置
订阅节点可见但无法连接	客户端最终生成的节点参数与握手日志	核对传输参数、凭据和服务端协议，而非反复切换模式
手改配置重启后消失	订阅更新、配置合并、客户端覆写	修改持久化的覆写或合并配置，不只改临时运行文件
开启 TUN 后局域网异常	内网路由、DNS、其他 VPN 与接管范围	先关闭 TUN 验证，再配置适当的路由排除

回滚时，先关闭新客户端的系统代理和 TUN，再退出新进程，然后恢复旧客户端及原配置。不要让两套内核同时抢占监听端口和系统路由。对控制接口，也应优先绑定回环地址；确需远程管理时，单独配置认证与访问范围。

选型结论：按配置依赖选择内核

只有基础节点与常见分流：迁移通常比较直接，重点检查策略名称、DNS 行为与客户端覆写。
使用 VLESS、REALITY、Hysteria2 或 TUIC：选择明确支持对应参数的 mihomo 版本，并与服务端配置逐项对齐。
依赖 Premium 脚本：先做行为改写与验证，不把替换二进制当作完整迁移。
需要 TUN：同时评估客户端权限管理、操作系统支持和路由冲突，不能只比较内核功能名称。

对新部署，优先选择仍有维护、能够明确显示内核信息的客户端，再根据实际订阅协议决定配置格式。对旧环境，先建立可复现的测试和回滚路径。内核选型的核心不是名称更新，而是节点能否握手、规则能否命中、DNS 能否正常解析，以及接管范围是否符合预期。