先看结论：Meta 与 mihomo 是同一项目的名称延续

新配置选型时，先确认客户端实际运行的内核，而不是只看客户端名称。Clash 原版、Clash Premium 与 mihomo 的功能边界不同；Clash Meta 后来更名为 mihomo，并不是需要另外安装的第四种独立内核。旧教程中的“Meta 配置”通常指向这一项目的配置体系，但仍需按具体版本检查字段。

旧配置迁移到 mihomo 时，基础节点、策略组和常见域名规则通常可以沿用；新增协议、Premium 脚本、DNS、TUN 与规则集格式需要单独核对。反向迁移更受限制：能被 mihomo 解析的配置，不代表原版 Clash 也能运行。

项目关系：原版、Premium、Meta 与 mihomo

原版 Clash 与 Clash Premium

原版 Clash 通常指 Dreamacro/clash 的开源内核。Clash Premium 则是原项目提供的闭源增强内核分支，两者不能简单视为同一套功能。历史上，TUN、规则提供器和脚本规则等能力，是辨认 Premium 与原版开源内核差异的重要线索。原项目在 2023 年停止维护后，旧二进制仍可能运行，但不再适合作为持续获取新协议支持的基础。

Clash Meta 与 mihomo

Clash Meta 从 Clash 生态演进而来，扩展了协议与路由能力，随后项目更名为 mihomo。文件夹、订阅说明、旧版界面里保留 Meta 字样，并不必然表示内核过时；应以实际二进制的版本输出及对应发布说明判断。

  • 原版 Clash：理解基础 YAML、HTTP/SOCKS 入站及规则分流的历史起点。
  • Clash Premium：旧配置中高级规则、TUN 和脚本能力的来源之一。
  • Clash Meta / mihomo：同一项目的前后名称，支持更多协议与配置扩展。

客户端能切换内核时，也不意味着可以任意替换可执行文件。内核启动参数、控制接口、服务权限和安装路径都可能由客户端管理。优先使用客户端提供的内核更新方式，并查看其明确支持的内核类型。

功能差异：协议、规则集与 TUN 分开比较

历史功能边界与迁移检查方向
检查项 原版开源 Clash Clash Premium mihomo
常见代理协议 支持 SS、VMess、Trojan 等，受旧版实现限制 以历史版本能力为准，不应假设支持新协议 扩展支持 VLESS、Hysteria2、TUIC 等
基础规则 支持域名、IP 网段、GEOIP 与最终匹配等规则 支持基础规则及增强能力 保留常见规则，并提供更多匹配能力
rule-providers 不能按 Premium 能力套用 支持，需核对规则行为与格式 支持，扩展格式需核对目标版本
TUN 接入 不具备 Premium 的内置 TUN 能力 支持，依赖平台与权限 支持，具体网络栈与字段依版本而定
Premium script 不支持 历史专有能力 不能直接视为兼容，迁移时需改写

协议名称相同，也要核对传输与加密字段

节点写着 VMess，不代表连接参数已经完整。还需核对 UUID、TLS、服务器名称、WebSocket 路径与请求头等配置。对于 VLESS，还要确认服务端所用传输、安全层和相关参数。只修改 type，不会把一种协议转换成另一种协议。

Hysteria2 与 TUIC 依赖 UDP 网络环境。内核能够解析节点，却在当前网络持续超时，应继续检查 UDP 通路、服务端端口和证书参数，而不是直接归因于配置格式。支持某协议只是必要条件，不等于线路一定可达。

配置兼容：先保留基础结构，再处理扩展字段

一份典型配置包含 proxies、proxy-groups、rules，也可能包含 proxy-providers 与 rule-providers。这些名称看起来相近，职责却不同：前者可从外部加载节点，后者加载分流规则，不能互换订阅地址。

规则顺序与策略名称必须一起检查

以下片段用于说明 mihomo 的常见配置结构。示例将手动选择组指向 DIRECT，不会产生代理出口；实际使用时，应在保留直连选项的基础上，加入已有的有效节点或正确的节点提供器引用。

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

proxy-groups:
  - name: 手动选择
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手动选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,手动选择
  • mixed-port: 7890 为 HTTP 与 SOCKS 代理共用的监听端口示例，不代表所有客户端默认都使用它。
  • allow-lan: false 适合先在本机验证；需要局域网接入时再检查监听地址和防火墙范围。
  • 规则按顺序匹配。把 MATCH 放到前面，会使后续规则失去预期作用。
  • 规则中的“手动选择”必须与策略组名称完全一致，包括空格及大小写。
  • no-resolve 表示该 IP 规则不主动触发域名解析，不等于关闭整个内核的 DNS。

Premium 脚本与新规则集格式要单独迁移

旧配置中的 script 不能直接当作 mihomo 兼容项。应把脚本实际做的域名、IP 或进程判断拆出来，改写为目标内核支持的规则；无法等价表达的逻辑，需要重新设计。迁移后既要通过语法检查，也要核对代表性请求的实际命中结果。

规则提供器还需检查 behavior 与文件内容是否一致。domain、ipcidr、classical 对应不同规则内容；YAML、文本以及 mihomo 的 MRS 格式也不能只靠修改文件后缀相互转换。MRS 等扩展格式还受规则行为与内核版本约束，旧内核未必能读取。

DNS 与 TUN：最容易出现“能启动但不能用”的部分

DNS 配置要区分解析入口与上游解析

DNS 的监听地址、上游服务器、Fake-IP 模式和域名例外列表分别解决不同问题。看到 enhanced-mode: fake-ip，只能说明使用了 Fake-IP 机制，不能据此判断系统请求一定进入内核。系统仍可能使用其他 DNS 通路，应用也可能启用自己的加密 DNS。

  • 迁移前保存原来的 nameserver、fallback、fake-ip-filter 及相关策略。
  • 若只有本地设备名或内网域名异常，先核对局域网解析路径和 Fake-IP 例外，不要一次替换全部上游。
  • 若日志提示上游域名解析失败，检查用于解析 DNS 服务器自身域名的引导解析设置。
  • 配置变化后可重启相关应用；系统 DNS 缓存与应用缓存不会总在内核重载时同步清除。

TUN 接管流量，不负责修复节点参数

TUN 通过虚拟网络接口接入流量，通常需要管理员或相应网络权限。Windows 的服务模式、Linux 的路由与权限、macOS 的网络扩展或虚拟接口处理方式，应按客户端实现分别检查。普通系统代理已能工作时，再测试 TUN，定位范围会更小。

tun.auto-route、tun.auto-detect-interface 与 tun.dns-hijack 分别涉及路由、出口识别和 DNS 接入，不是可互相替代的“增强开关”。示例中的 any:53 针对 DNS 端口匹配，也不能概括为拦截所有应用内的加密 DNS。与其他 VPN 同时运行时，还需排查路由优先级和虚拟网卡冲突。

旧配置迁移到 mihomo：按六步验证

  1. 保存原始配置。备份订阅来源、本地覆写、规则集与当前配置文件。图形客户端导出的文件可能已合并覆写，应同时保留可编辑源文件。
  2. 记录内核信息。在客户端的内核信息或日志中确认实际版本；独立部署时可执行 mihomo -v，记录输出与系统架构。
  3. 先做语法检查。独立运行可用 mihomo -t -f config.yaml。相对路径资源应在与正式运行一致的工作环境下检查，避免把路径错误误判为格式不兼容。
  4. 先测试本机代理端口。确认配置实际监听 7890 后，可执行下方命令。若端口不同，应同步修改命令。
  5. 核对规则命中。在客户端连接记录中检查目标域名、命中规则、策略组与最终出口。请求成功只证明这次链路可用，并不证明所有分流都正确。
  6. 逐项恢复扩展能力。依次加入规则提供器、DNS 覆写、TUN 与开机启动。每一步都查看日志，并确认配置重载后仍然有效。
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

上面的 10 秒连接超时与 20 秒总超时是诊断参数，不是速度指标。Windows PowerShell 中可明确使用 curl.exe 调用系统中的 curl 程序。测试前确认已有客户端是否正在占用 7890，避免同时启动第二个内核后出现端口冲突。

常见迁移问题：按报错位置缩小范围

订阅能导入，节点却全部不可用

先确认订阅是完整 Clash 配置、节点提供器内容，还是其他客户端的分享链接集合。图形客户端显示“导入成功”，可能只代表已保存地址。继续检查下载结果、节点解析日志以及节点协议支持情况。不要把含凭据的订阅链接粘贴到公开转换服务或问题帖中。

配置检查通过，实际规则没有生效

检查运行模式是否为 rule，以及生效文件是否就是刚修改的文件。客户端可能在订阅更新后重新生成配置，也可能通过覆写插入更靠前的规则。若希望更改持续保留，应使用客户端支持的覆写或合并机制，而不是仅修改生成文件。

启动提示端口已占用

确认是否同时运行两个客户端，或后台服务仍有旧内核进程。代理入站端口与控制接口端口用途不同：例如 7890 可作为本机代理端口，9090 可作为控制接口端口，但都必须以当前配置为准。更换代理端口后，系统代理、终端环境变量和应用中的手动代理地址也要同步调整。

应该继续使用旧内核，还是切换 mihomo？

需要 Hysteria2、TUIC、VLESS 或较新的规则与 DNS 能力时，应选择明确支持这些能力的 mihomo 客户端，并核对所带内核版本。现有环境若依赖 Premium 脚本或特定旧行为，先在独立配置中完成迁移验证，再替换生产使用环境。客户端安装包可参考选型指南，基础设置步骤见使用文档。

最终判断标准是配置能够解析、节点可以连接、规则按预期命中，以及系统代理或 TUN 的接管范围正确。单凭名称中出现“Meta”或“mihomo”，无法替代这四项检查。