先区分内核、客户端与配置体系
讨论 mihomo 与原版 Clash 时，最容易出现的误区，是把内核、图形客户端和订阅配置视为同一个产品。Clash 原版通常指 Dreamacro 维护的 Clash 开源内核；它负责监听本地端口、建立代理连接、执行规则、处理 DNS，并通过外部控制接口向图形界面提供运行状态。原项目停止持续维护后，原版内核仍能运行既有配置，但不会继续跟进新的协议、规则能力和平台网络变化。
mihomo 是从 Clash.Meta 延续而来的内核项目。它保留了 Clash 配置体系、策略组和规则匹配方式，同时扩展协议、DNS、TUN、规则集合与流量控制能力。名称变化不代表配置体系重新设计：很多仍在使用 Clash.Meta 标识的客户端、配置目录或文档，实际已经接入 mihomo，判断时应查看客户端设置里的内核名称和版本，而不是只看应用标题。
图形客户端则是内核外部的管理层，通常负责下载订阅、切换配置、编辑策略组、控制系统代理和展示连接记录。一个客户端可以更换不同内核，同一份配置也可能被多个客户端读取。因此，“客户端支持某字段”实际包含两层含义：所带内核能否解析该字段，以及界面能否正确展示和修改它。内核可以正常执行但界面没有对应开关的情况并不少见。
协议支持差异：mihomo 覆盖更广，但仍受配置与网络约束
原版 Clash 已覆盖 Shadowsocks、VMess、Trojan、Snell、HTTP 和 SOCKS 等常见代理类型，能够满足传统 Clash 配置的基本需要。mihomo 在此基础上继续加入和维护 VLESS、Reality 相关传输、Hysteria、Hysteria2、TUIC、WireGuard 等能力，并持续适配协议参数变化。具体可用范围仍取决于所安装的 mihomo 版本，较旧客户端内置的内核可能无法识别新字段。
支持一种协议并不等于导入后一定可连接。VLESS 节点可能同时依赖 TLS、Reality、WebSocket、gRPC 或其他传输参数；Hysteria2 与 TUIC 主要基于 UDP，在限制 UDP 的网络中可能出现握手超时；WireGuard 配置还涉及地址、私钥、公钥、路由与 MTU。订阅转换过程中若丢失字段，内核即使支持协议，也无法恢复缺失参数。
从原版 Clash 迁移到 mihomo 时，原有 Shadowsocks、VMess 和 Trojan 节点通常最容易保持兼容。反向迁移则不能按同样逻辑理解：含有 VLESS、Hysteria2、TUIC 或 mihomo 专属选项的配置，交给原版内核时可能直接报告未知代理类型，也可能在解析到不支持的字段时终止加载。配置兼容更接近“mihomo 对传统 Clash 语法保持较高兼容度”，而不是两个内核之间完全双向等价。
协议切换前应检查的内容
- 客户端内置的实际内核版本，以及是否允许独立更新内核。
- 节点协议、传输层、TLS、服务器名称和证书校验等字段是否完整。
- 当前网络是否允许 UDP，以及路由器、防火墙或企业网络是否限制相关流量。
- 订阅更新后是否经过转换服务，转换过程是否保留新协议参数。
- 同名策略组是否仍然引用有效节点，避免节点存在但未被任何策略组选中。
规则与策略组：基本模型一致，扩展能力不同
两者的核心分流模型相近：流量依次匹配规则，命中后交给代理节点或策略组；未命中的连接通常由末尾的 MATCH 规则接管。DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、PROCESS-NAME 等常见规则便于迁移，select、url-test、fallback、load-balance 等策略组也延续了 Clash 用户熟悉的组织方式。
mihomo 对规则表达进行了扩展，包括更丰富的规则类型、逻辑组合、入站条件、网络类型及规则集合能力。AND、OR、NOT 等逻辑规则适合表达“特定域名并且来自某个入站”一类复合条件，但括号、逗号和子规则结构必须符合当前内核语法。复杂规则并不会自动提高准确率；条件越多，排查命中结果时越需要结合连接日志与规则追踪信息。
规则集合也要区分数据格式。传统域名列表、IP CIDR 集合、经典规则文本以及二进制规则集在 behavior、format 和加载方式上并不相同。若 rule-provider 声明为 domain，内容中却放入完整的逗号分隔规则，更新成功后仍可能无法按预期匹配。mihomo 还可使用 GEOSITE 与 GEOIP 数据进行分类，但分类名称受所用地理数据文件影响，并非所有数据源都包含相同标签。
mode: rule
proxy-groups:
- name: 手动选择
type: select
proxies:
- DIRECT
rule-providers:
local-direct:
type: file
behavior: domain
format: text
path: ./rules/direct.txt
rules:
- RULE-SET,local-direct,DIRECT
- MATCH,手动选择上例只展示规则集合与策略组之间的引用关系。迁移真实配置时，还要保留现有代理节点、代理提供者和完整策略组，不能把片段单独覆盖到正在使用的文件。若配置来自订阅，优先在客户端提供的覆写或合并功能中增加自定义规则，避免下次更新订阅时丢失修改。
DNS 与 TUN：能力更完整，也更依赖系统环境
Clash 系内核的 DNS 模块不仅负责把域名解析为 IP，还会影响规则匹配、代理服务器地址解析和防止系统 DNS 绕过。原版 Clash 已提供 fake-ip、redir-host、nameserver、fallback 和 fallback-filter 等机制。mihomo 继续扩展 nameserver-policy、proxy-server-nameserver、direct-nameserver、fake-ip-filter 等配置，使代理节点域名、直连域名和普通查询可以使用不同解析路径。
这些字段之间存在明确分工。nameserver 负责常规查询；proxy-server-nameserver 可用于解析代理服务器自身的域名，避免建立代理前出现依赖循环；nameserver-policy 可以按域名指定解析器；fake-ip-filter 用于排除不适合返回虚拟地址的域名。启用 respect-rules 一类依赖规则选择解析路径的选项时，还要保证代理节点域名有可用的独立解析器，否则 DNS 查询可能需要代理，而代理连接又等待 DNS 结果。
fake-ip 模式会给域名分配虚拟地址，再由内核在接管连接时还原域名，因此通常具有较稳定的规则匹配效果。局域网设备发现、某些游戏、打印服务和依赖真实地址的应用可能需要加入过滤列表。redir-host 返回真实解析结果，行为更接近传统 DNS，但在复杂分流和污染环境下需要更谨慎地规划上游解析器。迁移时不应只复制 enhanced-mode 一行，还要一起检查监听地址、IPv6、过滤范围和上游协议。
TUN 模式用于接管不遵循系统代理设置的流量，包括部分命令行程序、游戏和使用自定义网络栈的应用。mihomo 提供较完整的 TUN 路由、DNS 劫持、自动路由与接口识别能力，但是否可用仍由操作系统权限、虚拟网卡驱动、防火墙和其他网络软件共同决定。system、gVisor 等网络栈在性能、兼容性和平台支持上有所差异，应先使用客户端默认推荐项，再针对具体故障调整。
配置兼容并非只看 YAML 能否加载
一份配置被 mihomo 成功解析，只代表字段语法通过检查，不代表节点可用、规则正确命中或外部控制界面完全兼容。迁移评估至少要分为四层：YAML 结构、内核字段、运行资源和客户端控制。缩进错误、重复键和错误数据类型属于 YAML 层；未知代理类型、策略组参数不匹配属于内核层；规则文件缺失、地理数据库未下载属于资源层；外部控制地址、认证密钥和接口差异则影响图形客户端。
mihomo 通常能够读取传统的 proxies、proxy-groups、rules、proxy-providers 和 rule-providers 结构，也保留 mixed-port、socks-port、redir-port、allow-lan、mode、log-level 等常用字段。不过，一些历史配置依赖特定 Clash Premium 行为，另一些配置又加入了客户端私有覆写。看到同样的字段名时，还要核对字段值的格式和当前版本说明，不能只根据文件扩展名判断兼容性。
外部控制接口总体延续 Clash API 的使用方式，因此很多控制面板可以继续查看流量、连接、策略组和日志。但界面若没有适配 mihomo 新增的代理类型或配置字段，可能只展示基础信息，甚至在保存配置时移除未知内容。重要扩展项应放在独立配置或覆写文件中，并确认客户端的保存动作不会重写原始订阅。
常见不兼容表现与定位方向
- 启动时立即报错：优先查看错误行号，检查 YAML 缩进、字段类型和当前内核是否支持对应代理类型。
- 配置加载成功但节点全部超时：检查节点参数、代理服务器 DNS、系统时间、UDP 条件和订阅字段是否完整。
- 策略组为空：检查 proxies、use、filter 与 exclude-filter，确认提供者名称和筛选表达式能匹配节点。
- 规则未按预期命中：检查规则顺序、规则集合 behavior、解析结果以及连接是否被 TUN 或系统代理实际接管。
- 界面可以连接但不能编辑：可能是客户端尚未提供对应表单，应通过受支持的覆写方式维护扩展字段。
从原版 Clash 迁移到 mihomo 的执行顺序
稳定迁移的重点是缩小变量范围。不要在更换内核的同时重写 DNS、替换所有规则集并开启 TUN，否则故障出现后很难判断来源。先让原配置在新内核中完成解析和基本连接，再逐项启用 mihomo 扩展功能。
- 保留当前配置与客户端设置。记录监听端口、系统代理状态、当前策略组选择、DNS 模式和外部控制地址。订阅地址与本地覆写应分别保存。
- 确认配置来源。区分本地 YAML、远程订阅、代理提供者和客户端生成配置。直接修改缓存文件通常会在刷新订阅后被覆盖。
- 使用 mihomo 做语法检查。命令行环境可运行
mihomo -t -f config.yaml检查配置。图形客户端则应查看内核日志中的具体文件和行号。 - 先测试基础代理。保持原有规则模式，选择一个已知可用节点，确认网页访问、DNS 查询和策略切换正常。此阶段暂不增加新协议节点。
- 验证规则与提供者。检查远程规则集能否下载、策略组是否有成员、MATCH 最终规则是否存在，并通过连接日志确认常用域名的实际命中项。
- 单独启用 DNS 扩展。根据需求配置代理服务器解析、域名策略与 fake-ip 过滤。每次只调整一组字段，并观察是否出现解析超时或循环依赖。
- 最后测试 TUN。关闭其他代理客户端，确认虚拟网卡权限与路由恢复机制，再测试不使用系统代理的程序。出现断网时应先退出 TUN，而不是连续修改节点参数。
mihomo -t -f config.yaml语法检查通过后，还应进行运行验证。建议依次检查内核日志、代理组选择、DNS 查询、连接详情和系统路由。若旧配置包含大量自定义字段，可以先复制出最小配置，只保留一个本地端口、一个节点、一个策略组和末尾规则；最小配置能够连接后，再逐段恢复规则提供者、DNS 与 TUN 设置。
如何选择：按配置需求与维护状态判断
仍在运行固定传统节点、简单域名规则且网络环境长期不变的设备，原版 Clash 配置可能继续工作。但原版内核已经停止持续维护，遇到新协议、操作系统网络变化和长期兼容问题时，可用的修复路径有限。对新安装环境、需要更新协议、复杂规则集合、精细 DNS 或 TUN 接管的用户，mihomo 通常是更合适的内核方向。
选择图形客户端时，应确认其内置 mihomo 版本、内核更新方式、配置覆写机制和日志入口。仅标注“支持 Clash 配置”不足以说明它能完整管理 mihomo 扩展功能。需要长期维护的配置还应减少对客户端私有字段的依赖，把节点来源、策略组、规则集合和本地覆写分层管理。
最终判断标准不是功能数量，而是当前配置是否可验证、可更新和可回退。mihomo 扩展了 Clash 配置体系的边界，但每项扩展都会增加相应的参数和环境条件。按“先兼容旧配置，再增加新能力”的顺序迁移，可以把协议、DNS、规则和系统接管问题分开处理，也更容易在更新内核后定位变化。