Clash 原版内核、Clash Meta 与 mihomo 的功能差异与配置兼容对照

内核沿革：原版 Clash、Premium 与 Meta 分支

选择 Clash 客户端时，界面名称与内核名称需要分开核对。客户端负责订阅管理、系统代理开关、配置合并与日志展示；内核负责建立代理连接、匹配规则和处理 DNS。同一个客户端可能更新内置内核，也可能允许切换内核。仅凭软件名称，无法判断某条 VLESS 节点或某段 TUN 配置能否使用。

原版 Clash 还要区分开源内核与 Clash Premium。Premium 是原项目的另一条发行线，曾提供 TUN、规则集等扩展能力，不能把它的功能全部归到原版开源内核。原项目在 2023 年停止维护后，旧客户端与旧二进制仍可能运行，但不再适合作为新配置功能的参照。

Clash Meta 是从 Clash 发展而来的分支，后来更名为 mihomo。因此，Meta 与 mihomo 主要是同一技术路线在不同阶段的名称，并不是两个互不兼容的独立产品。旧教程中的“Meta 内核”、订阅中的“Clash Meta 格式”，通常指向这条扩展路线；具体能力仍取决于实际运行的发行版本。

功能对照：协议、规则、TUN 与 DNS

下表比较的是功能边界，不是每一个历史版本的完整清单。“支持”还需要服务器参数、客户端打包方式与操作系统权限共同满足。尤其不能把当前 mihomo 的功能反推到任意早期 Meta 版本。

能力	原版开源 Clash	Clash Premium	Meta / mihomo 路线
常见代理协议	支持 SS、VMess、Trojan、SOCKS、HTTP 等；参数受版本限制	以原项目支持范围为基础	扩展 VLESS、Hysteria2、TUIC 等；需核对版本与参数
基础分流	支持域名、IP 段、GEOIP 等常用规则	支持基础规则及扩展功能	保留常用规则，并扩展 GEOSITE、逻辑规则等能力
规则集	不能假定支持 Premium 的 RULE-SET 配置	支持 rule-providers 与 RULE-SET	支持规则集；格式和行为需与配置匹配
TUN 接管	不提供 Premium 同等的内置 TUN 能力	提供 TUN，平台与版本存在差异	提供 TUN，栈、路由与权限需单独核对
DNS	支持内置 DNS 与 Fake-IP 等基础机制	在原项目 DNS 能力上配合扩展功能	扩展解析策略与连接解析控制，字段随版本演进
维护状态	历史项目，已停止维护	历史发行线，已停止维护	以 mihomo 项目当前发行记录为准

协议支持不是订阅文件能否打开

YAML 能被读取，只代表基本格式成立。假如订阅包含 type: vless，却交给不支持 VLESS 的旧内核处理，结果可能是节点解析失败或整个配置加载失败。Reality 是相关协议的传输安全配置，不是与 VLESS、Trojan 并列的一种节点类型。迁移时应同时核对 type、network、TLS 与对应传输选项。

订阅服务标注“Clash”也不能证明兼容原版 Clash。一些服务用这个名称泛指 YAML 输出，实际已经包含 mihomo 扩展字段。若服务提供明确的 Meta 或 mihomo 输出，应按目标内核选择；转换工具只能转换受支持的数据结构，无法让旧内核获得缺失的协议实现。

配置兼容：可以保留的结构与需要检查的字段

常见的 proxies、proxy-groups、rules 结构通常可以沿用。基础的 DOMAIN-SUFFIX、IP-CIDR、MATCH 规则也不需要因为更名就全部改写。迁移的重点是确认扩展字段是否受支持，以及客户端最终生成了什么配置。

逐项检查清单

本地端口：检查 port、socks-port 与 mixed-port。例如统一使用 mixed-port: 7890 时，系统代理和需要手动设置的应用都应指向实际监听端口，不能继续沿用旧环境的 7897。
控制接口：external-controller 是管理 API，不是应用代理入口。若使用 127.0.0.1:9090，不要把浏览器代理填成 9090。仅本机管理时保持回环地址，并设置访问密钥。
规则引用：RULE-SET 引用的名称必须与 rule-providers 中的键一致；GEOSITE 还依赖相应数据文件。数据下载失败与规则语法错误应分别处理。
规则目标：每条规则引用的策略组名称必须存在。把“自动选择”重命名为“延迟优选”后，规则与其他组内的引用也要同步更新。
脚本配置：不要直接搬用 Premium 的 script 分流实现。客户端提供的 JavaScript 覆写是在生成配置时执行，和内核处理连接时运行的脚本不是同一机制。
界面专用配置：旧客户端的配置混入、配置文件扩展与启动设置，不等于 mihomo 原生 YAML。迁移的是这些设置产生的有效结果，不是把所有旧文件整包复制。

先用独立配置确认端口与规则

下面是本机诊断骨架，不含可用代理节点。它仅用于确认内核能启动、7890 端口可监听，以及基础规则能够加载。MATCH,DIRECT 会让未匹配流量直连，不能把它当作已经配置好的代理方案。

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

proxies: []
proxy-groups: []

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

先测试这个骨架，再分批加入真实节点、策略组和规则集。这样可以把启动错误定位到新增内容，而不是在包含数千条规则的订阅文件里同时排查多个变量。

TUN 迁移：权限、路由与 DNS 接管分别检查

系统代理主要服务于遵循系统代理设置的应用；TUN 通过虚拟网卡接管流量。切换内核后，TUN 开关处于开启状态，不代表虚拟网卡、路由和 DNS 劫持都已经成功。Windows 通常涉及服务模式或管理员权限，Linux 涉及网络管理权限，macOS 也需要相应授权，具体入口由客户端实现决定。

不要照搬旧教程里的 TUN 默认值。stack、自动路由与接口检测的适用性受到平台、内核版本和其他网络软件影响。以下 mihomo 配置仅展示常用字段，首次测试仍保持 enable: false，等系统代理路径验证完成后再启用。

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

先验证权限：日志出现创建网卡或添加路由失败时，先检查服务和权限，而不是更换节点。
再确认出口：同时运行其他 VPN、虚拟机网络或容器网络时，自动接口检测可能选错出口。临时停用另一套接管工具，再比较结果。
最后看 DNS：any:53 针对常规 53 端口 DNS 流量，不会自动解密浏览器自带的 HTTPS DNS。后者可能成为普通 HTTPS 连接，再由规则决定其出口。

TUN 也不会补齐节点缺少的 UDP 能力。游戏或语音应用仍然异常时，应分别核对节点协议、服务端 UDP 支持、策略组选路和本机防火墙，而不是只反复切换 TUN 栈。

DNS 与 Fake-IP：兼容字段不等于相同解析路径

原版 Clash 已有 Fake-IP 机制，不能把 Fake-IP 本身当作 mihomo 独有功能。它的工作方式是先返回虚拟地址，再由内核根据映射恢复域名并处理连接。迁移后若 DNS 没有送到内核，或应用仍缓存旧结果，即使 YAML 里的 enhanced-mode 没变，实际行为也可能不同。

DNS 字段按职责保留

nameserver 定义常规上游解析器。使用域名形式的加密 DNS 上游时，还要考虑上游地址本身如何完成引导解析。
nameserver-policy 根据域名条件选择解析器；它不是代理分流规则，不能直接替代 rules。
fake-ip-filter 决定哪些域名不返回 Fake-IP。应为有兼容问题的域名精确添加例外，避免用大范围通配把整个方案退回真实地址解析。
fallback 与 fallback-filter 是另一组解析选择机制，并非所有配置都必须启用。旧配置里存在这些字段，不代表迁移时需要照抄所有地域过滤条件。

下面展示 Fake-IP 与域名解析策略的最小组合。example.com 是文档示例域名；替换时应填入确有独立解析需求的业务域名。1053 是本地 DNS 监听端口，不是系统默认的 53 端口；单独启动监听器不会自动修改系统 DNS。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
  nameserver-policy:
    '+.example.com':
      - 1.1.1.1
  fake-ip-filter:
    - '*.lan'

测试时可执行 nslookup example.com 127.0.0.1 -port=1053 的平台等价命令；不同系统的参数顺序与实现存在差别，使用支持 dig 的环境时可直接执行下面的查询。命中 Fake-IP 的结果应位于所配置的虚拟地址范围，但返回真实地址也可能来自过滤项，不能仅凭单个地址判定泄漏。

dig @127.0.0.1 -p 1053 example.com A

还应观察内核日志中是否收到查询，并对照系统 DNS、浏览器安全 DNS与连接出口。在线检测页面列出的解析器归属只是观察结果之一：解析器所在地不同于代理出口所在地，并不能单独证明请求绕过了预期路径。

迁移顺序：离线测试、分层恢复与回滚

迁移时不必同时更换客户端、订阅格式、DNS 方案和规则来源。保持同一条节点与同一个测试目标，先完成最小切换，再恢复扩展功能，比较结果才有意义。

备份运行事实。保存订阅原文件、客户端覆写内容、当前有效配置及内核版本输出。记录本地代理端口，例如 7890，以及是否开启系统代理、TUN 和局域网访问。含节点密码和订阅凭据的文件只保存在可信位置。
确认目标二进制。执行版本命令，记录实际输出，而不是根据安装包名称推断。桌面客户端可能打包了与独立下载版本不同的内核。
执行配置测试。先做语法与引用检查。测试通过后再启动；如果报错指出策略组不存在，应先修复名称引用，不要同时改 DNS。
验证系统代理路径。关闭 TUN，加载一条确定可用的真实节点。用显式代理请求检查监听端口、握手和出口，再测试系统代理开关。
恢复规则与 DNS。逐个加入规则集，确认日志中的匹配规则与目标组。随后检查 DNS 查询路径，最后启用 TUN。
保留可回退状态。新配置出现问题时，先关闭新客户端的 TUN 与系统代理，再恢复旧环境。不要让两套客户端同时争用同一端口或虚拟网卡路由。

命令行验证示例

以下以二进制名为 mihomo、配置文件为当前目录的 config.yaml 为例。Windows PowerShell 中，本地可执行文件通常需要写为 .\mihomo.exe；使用桌面客户端时，应针对它实际加载的配置测试，而不是仅测试订阅下载文件。

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

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

-t 检查通过不代表远端节点可达。上面的请求设置 10 秒连接超时和 20 秒总超时，是为了避免故障时无限等待，并不是速度基准。若当前使用前面的直连诊断骨架，这条请求也只验证本地代理入口，不能证明流量经过了远端节点。

内核选型结论与故障定位边界

需要 VLESS、Hysteria2、TUIC 或更新规则能力时，应优先核对 mihomo 的对应版本支持，而不是在原版内核中反复尝试新增字段。维护历史环境时，则应把配置限制在原内核已实现的范围内，避免订阅更新后突然出现无法解析的节点。

Clash Meta 与 mihomo 之间的迁移，通常以版本差异和客户端配置生成方式为主要检查对象；原版或 Premium 转到 mihomo，则还要核对脚本、规则集、DNS 与 TUN 的实现差异。没有一条通用的“全部替换字段”规则，最可靠的路径仍是版本确认、有效配置检查和逐层连接测试。

选择客户端时，可继续查看客户端平台与内核对照；需要理解规则语法与配置结构时，可查看协议手册。保留一份能解释每个字段用途的配置，比叠加多份来源不明的覆写更便于后续维护。