先区分内核、客户端与订阅格式
判断一份 Clash 配置能否使用，先确认实际运行的内核，而不是只看桌面图标。内核负责解析 YAML、建立代理连接、执行规则和处理 DNS；客户端负责配置导入、系统代理开关、服务管理与界面展示。客户端名称相同，也可能因为发行版本、内核切换或自定义内核路径而运行不同程序。
订阅则是配置来源。它可能返回完整配置，也可能仅包含节点列表。订阅页面写着“Clash”，并不意味着其中每个节点都能被原版 Clash 识别。遇到 vless、hysteria2 或 reality-opts 等内容，应继续核对内核与具体版本。
- 内核身份：查看启动日志、内核信息页面，或执行内核程序的版本命令。
- 实际配置：查看客户端合并、覆写后交给内核的配置，不只查看订阅原文。
- 失败阶段：区分配置解析失败、规则加载失败与节点连接失败，三者处理方式不同。
命名时间线：原版、Premium、Meta 与 mihomo
原版 Clash 与 Clash Premium 是两条能力边界
原版 Clash 通常指 Dreamacro 的开源 Clash 核心。Clash Premium 则是原作者曾经发布的闭源增强内核，历史上加入了 TUN、规则集和脚本等功能。不能把 Premium 当成所有 Clash 客户端都具有的一组默认能力，也不能将原版开源核心与 Premium 的配置清单混为一谈。
2023 年原项目停止公开维护后，仍有旧客户端继续携带这些内核。它们可能正常运行既有配置，但不会因为订阅更新而自动获得新协议实现。旧版安装包能启动，与它能处理当前订阅，是两项独立判断。
Clash Meta 更名为 mihomo
Clash Meta 是从 Clash 体系发展出的扩展分支，后来更名为 mihomo。两者属于同一项目的发展脉络，不是两个互不相关、需要整体改写配置的内核。客户端界面中保留的“Meta”字样，也可能实际指向后续 mihomo 构建。
不过，项目延续不等于任意版本完全兼容。较早的 Meta 构建不一定具备后续 mihomo 的字段和协议能力；某些历史功能也可能调整或移除。迁移时应记录完整版本输出，并以该版本对应的配置文档和启动检查结果为准。
| 名称 | 定位 | 迁移关注点 |
|---|---|---|
| 原版 Clash | 开源基础核心 | 基础协议、规则与 DNS；不要套用 Premium 专属配置 |
| Clash Premium | 历史闭源增强核心 | TUN、规则集、脚本；脚本需单独评估替代方案 |
| Clash Meta | 扩展分支的历史名称 | 必须确认构建版本，不能按名称推定全部新特性 |
| mihomo | Meta 更名后的项目 | 协议参数、规则集格式、DNS 与 TUN 的版本要求 |
配置字段兼容清单：哪些可沿用，哪些要检查
基础字段通常具有较好的延续性，但兼容应分为三层：字段能否解析、取值是否支持、运行效果是否一致。例如 dns 节点能被识别，不代表它下面每个新增选项都能被旧内核理解。部分未知字段可能被忽略，配置检查通过也不是功能生效的充分证明。
| 字段或能力 | 原版开源核心 | Premium | Meta / mihomo |
|---|---|---|---|
mixed-port、mode、log-level | 通常可用 | 通常可用 | 通常可沿用 |
proxies、proxy-groups | 支持基础结构 | 支持基础结构 | 结构延续；新增类型另查 |
DOMAIN-SUFFIX、GEOIP、MATCH | 支持 | 支持 | 支持；数据文件也需可用 |
proxy-providers | 支持；载荷须符合格式 | 支持 | 支持；扩展选项依版本 |
rule-providers、RULE-SET | 不应按 Premium 能力使用 | 支持 | 支持；核对格式与行为类型 |
tun | 不具备 Premium 的内置 TUN 能力 | 支持；依平台与权限 | 支持；栈与路由选项需复核 |
sniffer | 不可直接套用 | 不可按 mihomo 字段套用 | 支持；具体选项依版本 |
Premium script 模式 | 不支持 | 历史特性 | 不能直接沿用 Premium 脚本 |
dns.enhanced-mode: fake-ip | 支持基础能力 | 支持 | 支持；过滤与解析策略仍需检查 |
策略组名称属于配置依赖
规则末尾的策略名称必须对应存在的节点、策略组或内置动作。把策略组“代理选择”改名为“节点选择”之后，所有引用它的规则、规则集入口和其他策略组成员都要同步修改。此类错误与内核代际无关，却常在迁移时被误判为协议不兼容。
Premium 脚本需要重写分流逻辑
如果旧配置使用 mode: script 和 script:，不要只替换内核文件。应先列出脚本实际执行的域名、地址与策略判断，再转写为目标内核支持的规则或规则集。涉及动态判断的部分，需要逐项核实是否有对应能力，不能机械地把模式改为 rule 就结束迁移。
协议支持对照：节点类型比订阅名称更重要
原版与 Premium 常见的协议包括 Shadowsocks、VMess、Trojan，以及 HTTP、SOCKS5 代理。这里的支持指协议类型，并不覆盖其后续出现的所有加密方法、传输组合与扩展字段。mihomo 扩展了协议范围，但同样要与服务端参数逐项对应。
| 配置内容 | 原版 / Premium | mihomo 检查项 |
|---|---|---|
ss、vmess、trojan | 有基础支持；不代表全部扩展可用 | 加密方法、传输方式、TLS 参数 |
vless | 不支持 | UUID、传输方式、flow 与 TLS 组合 |
reality-opts | 不支持 | 公钥、short-id、服务端名称等参数 |
hysteria2 | 不支持 | UDP 可达性、认证与 TLS 参数 |
tuic | 不支持 | 服务端协议版本、认证与拥塞控制选项 |
出现“unsupported proxy type”一类错误时，优先检查内核身份和节点类型，而不是改 DNS。配置能载入但连接失败，则继续检查服务器地址、端口、认证、TLS 和底层网络。Hysteria2、TUIC 依赖 UDP；把客户端切换到全局模式，不能解决出口网络阻断 UDP 的问题。
规则集、DNS 与 TUN：迁移后重点复核
规则集的 behavior 与载荷必须对应
rule-providers 的 behavior 常见值包括 domain、ipcidr 与 classical。域名列表不能直接当作完整规则列表加载；完整规则也不能仅通过改文件后缀变成域名载荷。mihomo 的 MRS 格式不适合直接交给历史 Premium 使用，迁移时要核对 format、实际文件内容和目标版本。
规则按照配置顺序匹配。先放域名规则还是地址规则，可能影响解析行为及最终出口。末尾的 MATCH 是兜底，不应放到需要继续匹配的规则之前。规则集下载成功，也不意味着引用它的 RULE-SET 已放在正确位置。
Fake-IP 保留地址不是节点地址
198.18.0.0/16 是常见 Fake-IP 配置范围。应用取得这种地址时，通常需要由同一内核接管后续连接，才能根据映射恢复域名。只启用 DNS 假地址响应，却没有相应流量接管路径，可能造成连接失败。迁移后应检查 DNS 指向、系统代理、TUN 和应用自身代理设置，而不是直接把假地址当作异常服务器。
TUN 需要操作系统权限与路由配合
tun.enable: true 只声明启用意图。实际运行还涉及服务权限、虚拟网卡、路由、DNS 接管与网络栈实现。Windows 上可能需要客户端服务或管理员权限；Linux 通常需要相应网络管理权限。客户端的“服务模式”与配置里的 TUN 开关不是同一层设置。
- 先关闭旧客户端及其后台服务，避免两个程序同时接管路由。
- 先用系统代理验证基础连接，再单独启用 TUN，缩小故障范围。
- 保留原配置副本，分别验证普通域名、局域网设备和 IPv6 访问。
- 从日志核对实际启用的网络栈，不根据界面开关推断接管已经成功。
旧配置迁移步骤：先验证基础端口，再恢复扩展
以下配置用于检查本机监听和基础规则解析，不包含远程节点，也不是完整订阅替代品。它将混合端口设为 7890，关闭局域网访问，并让所有连接直连。端口只是示例值；如果已被其他程序占用，应更换端口或先停止占用程序。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
- MATCH,DIRECT- 保存现场。备份订阅原文、覆写规则和当前运行配置。记录客户端版本及内核版本，避免只备份导入链接。
- 确认新内核。使用 mihomo 二进制时，可执行
mihomo -v查看版本；实际程序路径和文件名以安装位置为准。 - 检查语法。执行
mihomo -t -f config.yaml。配置若依赖相对路径资源，应确保工作目录、数据目录与客户端实际环境一致。 - 恢复节点与策略组。先加入一个已知可用节点，验证认证和 TLS，再恢复自动选择、故障转移等策略组。
- 恢复规则集与 DNS。检查资源加载、策略名称和规则命中，再添加 Fake-IP 或特殊解析策略。
- 最后启用 TUN。验证权限、默认路由与局域网访问，确认退出客户端后网络能按预期恢复。
基础端口可以用 curl -x http://127.0.0.1:7890 -I https://clash-dl.com/ 检查。它用于验证 HTTP 代理入口是否能处理请求，不证明 SOCKS5、UDP、TUN 或所有节点都可用。命令失败时，应结合日志判断是监听未启动、目标访问失败，还是出口链路问题。
客户端选型与常见兼容问题
选择客户端时，先确认操作系统与处理器架构，再看其内核来源和维护状态。Clash Verge Rev、FlClash 等客户端采用 mihomo 体系，但具体支持范围仍取决于所安装版本及内核构建。旧版 Clash for Windows 或 Clash for Android 的历史发行包，不能仅因名称包含 Clash 就推定支持 mihomo 扩展协议。
客户端内核信息、订阅覆写功能和服务管理能力也应纳入检查。即使替换二进制后能够启动，旧界面仍可能无法展示新增字段，或在保存配置时覆盖手工修改。平台与客户端关系可结合客户端对比查看；基础字段含义可参考协议参考。
Clash Meta 配置可以直接给 mihomo 使用吗？
多数基础配置具有延续性，但不能保证所有历史选项原样可用。先执行配置检查，再核对日志中的废弃提示、资源加载与实际连接。旧 Meta 构建和后续 mihomo 之间的差异，应按具体版本判断。
mihomo 配置能降级给原版 Clash 吗？
只有在协议与配置能力都落在原版支持范围内时才可能。VLESS、Hysteria2、嗅探和扩展规则等内容不能直接沿用。涉及服务端协议时，仅做 YAML 字段删减无法完成降级。
配置检查通过，为什么访问仍然失败？
配置检查主要验证结构和可识别的配置内容，不保证远端服务可达。还要检查节点认证、DNS 返回、证书、系统代理生效范围、UDP 路径以及规则最终选择的出口。
旧订阅是否必须重新购买或更换？
不由内核名称决定。先检查订阅实际返回的协议和配置格式。如果现有服务提供适用于 mihomo 的配置入口，可按其说明切换；如果只是基础协议配置，可能可以直接迁移。不要把客户端格式问题与服务端可用性混为一谈。
最终判断依据应是“内核版本、配置字段、服务端协议、操作系统接管能力”四项同时匹配。基础规则可优先沿用，Premium 脚本需要单独处理，新协议必须确认实现范围，TUN 与 DNS 则需要在目标设备上验证。完成这些检查后，再决定保留旧配置、调整订阅格式，或更换客户端。