mihomo 内核与原版 Clash 核心有何不同：协议支持、规则集与配置兼容
对比 mihomo（原 Clash Meta）与原版 Clash 核心，覆盖新增协议、rule-providers 与 GEOSITE 规则、TUN 实现以及配置字段兼容性，帮助判断现有配置能否直接迁移。
先给结论：基础配置接近，扩展能力不能反向套用
如果配置只有常见节点、select 策略组和域名分流规则，迁移到 mihomo 通常只需少量调整。但“能读取 YAML”不等于“所有字段都按原来的方式生效”。涉及新协议、规则数据文件、DNS 劫持或 TUN 接管时，应分项验证，而不是直接覆盖日常使用的配置。
这里的“原版 Clash”需要先分清两个对象：原版开源核心，以及曾单独发布的 Clash Premium 核心。它们的功能边界不同。尤其是规则提供器、TUN 等能力，不能因为某个旧客户端支持，就推断原版开源核心也支持。mihomo 则是从 Clash Meta 延续而来的项目，不是给旧核心换一个显示名称。
- 旧配置转 mihomo：基础语法有较多交集，仍需检查被移除、改名或由客户端覆盖的项目。
- mihomo 配置转旧核心：VLESS、Hysteria2、GEOSITE 等扩展内容不能假设可用。
- 更换图形客户端：还会改变服务权限、配置目录、覆写规则和系统代理入口，不能只比较核心。
协议支持：节点类型与传输参数要一起检查
原版开源 Clash 常见的出站类型包括 Shadowsocks、VMess、Trojan、SOCKS5 和 HTTP。mihomo 在此基础上扩展了协议与传输支持，例如 VLESS、Hysteria2、TUIC，以及相关的 REALITY 配置能力。具体可用参数仍取决于实际安装的 mihomo 构建，不能拿新文档里的字段直接套到很早的 Clash Meta 二进制上。
| 检查项目 | 原版 Clash 开源核心 | mihomo |
|---|---|---|
| VMess、Trojan 等常见节点 | 有相应支持，参数以旧核心为准 | 支持，但仍需核对传输与 TLS 参数 |
| VLESS、Hysteria2、TUIC | 不能直接使用这些节点类型 | 提供相应实现，配置字段各不相同 |
| rule-providers | 不能当作通用内置能力；旧 Premium 需另行区分 | 支持外部规则提供器 |
| GEOSITE 规则 | 不支持 mihomo 的这套写法 | 支持，依赖相应域名分类数据 |
| TUN 接管 | 不能与旧 Premium 的 TUN 能力混为一谈 | 支持，效果取决于系统、权限与路由 |
同名协议也不代表节点可以原样复制
例如一个使用 WebSocket 的节点，除了 type，还要核对 network、路径、请求头和 TLS 服务器名。REALITY 节点则有自己的公钥、短 ID 等参数。只复制服务器地址和端口，通常不足以建立连接。订阅转换工具如果不认识这些字段，可能直接丢弃信息，最终表现为“节点能显示，连接却失败”。
- 先确认订阅提供的是 mihomo 可读取的配置格式，而不是其他客户端的 JSON 配置。
- 检查节点条目中的
type，再检查该类型对应的完整参数。 - 需要 UDP 的业务还要检查节点、策略与网络是否允许 UDP；“网页能打开”不能证明 UDP 可用。
更多协议并不自动等于更低延迟。服务器线路、拥塞、丢包以及客户端到服务器的网络条件，都会影响结果。选核心看功能需求，选节点则应在相同网络、相同目标和相同测试方法下比较。
规则集差异：rule-providers 不等于 GEOSITE
rule-providers 用来声明外部规则来源，RULE-SET 在规则列表中引用它。GEOSITE 则按域名分类数据库中的类别进行匹配。两者都能减少主配置中的规则数量，但数据来源、文件格式与更新方式并不相同。
先用本地规则文件验证引用关系
下面是 mihomo 的局部配置示例，需要合并进已有配置，不能作为完整节点配置直接使用。它从配置目录下的 rules/local-direct.yaml 读取经典规则，并将命中的连接交给 DIRECT：
rule-providers:
local-direct:
type: file
behavior: classical
path: ./rules/local-direct.yaml
rules:
- RULE-SET,local-direct,DIRECT
- MATCH,DIRECT对应的 rules/local-direct.yaml 内容如下。这里用 example.com 演示域名后缀匹配，实际使用时应换成确实需要直连的业务域名：
payload:
- DOMAIN-SUFFIX,example.combehavior: classical 的条目带规则类型，例如 DOMAIN-SUFFIX。如果改成 behavior: domain，就要使用对应的域名规则格式，不能只改声明、不改文件内容。二进制规则格式也有各自的支持范围，不应把文件改个扩展名就交给另一种解析器。
GEOSITE 要同时检查数据库与类别
例如 GEOSITE,cn,DIRECT 依赖域名分类数据中存在 cn 类别。它不等同于 GEOIP,CN,DIRECT：前者按域名分类，后者按 IP 地理数据匹配。某个网站使用境外 CDN 时，两种规则可能得出不同结果，这属于匹配依据不同，不一定是核心出错。
首次加载远程规则或地理数据可能需要联网。如果这些资源必须通过尚未建立的代理下载，就会形成启动依赖。初次迁移可先保留最小规则，准备好所需本地数据，再逐项恢复远程更新机制。
TUN 差异：核心支持只是接管流量的第一步
系统代理通常依赖应用主动使用代理设置；TUN 则通过虚拟网络接口与路由接收流量。mihomo 支持 TUN，不意味着勾选开关后所有应用就一定进入代理。系统权限、虚拟网卡创建、路由安装，以及与其他 VPN 的冲突，都可能阻止接管。
旧 Clash Premium 也有 TUN 能力，但不能据此把它的整段 TUN 配置直接视为 mihomo 的标准写法。迁移时应核对 stack、auto-route、auto-detect-interface 和 dns-hijack 等字段，并结合当前系统的支持情况处理。
按三层证据确认 TUN 是否正常
- 接口层：启动日志中确认虚拟接口成功创建，没有权限不足或设备占用错误。
- 路由层：确认目标流量进入虚拟接口。多网卡、其他 VPN 和手工静态路由都可能改变出口。
- 连接层：用目标应用发起新连接，在连接面板查看目标地址、命中规则和最终策略。
例如 dns-hijack 中常见的 any:53 是 DNS 接管设置，不是“捕获所有加密 DNS”的开关。应用自己发出的 HTTPS DNS 请求使用的是 HTTPS 连接，不能简单当作普通 53 端口查询处理。IPv6 流量也应单独检查，不能只看 IPv4 查询结果就认定接管完整。
Linux 上可能需要 root 或适当的网络管理能力；Windows 与 macOS 的图形客户端可能通过后台服务完成权限操作。具体服务安装入口随客户端变化，应按客户端说明操作，不要为了排错反复叠加多个虚拟网卡和路由工具。
DNS 与配置兼容：先保留解析路径，再换增强模式
mihomo 延续了 Clash 配置中常见的 dns、nameserver、fallback 等概念，也支持更细的解析策略。但这些字段的组合决定查询实际发往哪里。把所有 DNS 地址都改成同一个服务，并不能保证兼容性更好，反而可能掩盖节点域名解析与业务域名解析之间的区别。
fake-ip 与 redir-host 不宜和核心一起切换
fake-ip 会为域名提供映射用的虚拟地址，常见地址段为 198.18.0.0/16。它用于关联域名与后续连接，不是远端服务器的真实地址。redir-host 通常返回真实解析结果。两种模式可能影响局域网设备、依赖真实 IP 的应用及已有 DNS 缓存。
如果旧环境采用 redir-host，迁移首轮先保留该模式。确认节点和规则可用之后，再单独测试 fake-ip。对于异常应用，应根据现象设置适当的排除项，而不是看到一个应用出错就同时关闭 TUN、改 DNS、换节点。
- 节点域名无法解析：检查节点连接建立前使用的解析路径，必要时核对
proxy-server-nameserver等相关配置。 - 域名规则看似失效：检查连接是否保留了域名信息，以及 DNS 是否确实经过预期路径。
- 改完仍像旧配置：检查客户端是否通过合并、覆写或订阅更新重新写入了 DNS 段。
不要把 fallback 理解为简单的“主 DNS 彻底失败后才启动备用 DNS”。它与过滤条件共同决定结果选用方式。迁移排错时先看当前配置与日志，再判断是否需要改动这一层。
迁移步骤：从语法检查到真实连接验证
建议保留旧核心、旧配置及客户端覆写内容，另建测试目录。下面用独立二进制演示，目录名 mihomo-test 只是本次测试目录。命令中的文件和工作目录都相对于当前终端位置：
mihomo -v
mihomo -t -d ./mihomo-test -f ./mihomo-test/config.yaml-t 用于测试配置，-d 指定工作目录，-f 指定配置文件。语法通过仅说明配置测试阶段没有发现阻断性错误，不代表服务器可达、系统代理已设置或 TUN 路由已经生效。
第一轮只验证本地代理端口
测试配置可使用下列基础入口。7890 是这里明确设置的混合代理端口，不是所有客户端都固定使用的端口。把这些字段合并进含有效节点与策略组的配置后，再启动测试：
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info若原客户端也占用 7890，先停止旧核心，或为测试配置选择一个未占用端口。不要只关闭旧客户端窗口，因为后台服务可能仍在运行。此阶段暂不开 TUN，也不配置局域网共享。
- 解析配置：修复未知节点类型、无效规则、缺失策略组和规则文件路径错误。
- 启动核心：确认端口监听成功，没有“地址已被占用”一类启动错误。
- 指定代理测试：在终端运行下方命令，观察请求是否成功及连接面板是否有记录。
- 恢复分流：逐批加入规则提供器与地理规则，确认实际命中结果。
- 最后接管系统：先测系统代理，再单独开启 TUN，避免同时引入多个变量。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com这条命令验证的是通过本地代理入口发起请求。目标域名如果命中 DIRECT，仍可能直连成功，因此还要检查连接面板的策略链。测试通过不等于所有应用都经过远端节点，也不等于下载速度已达到线路上限。
常见迁移故障与选型结论
| 现象 | 优先检查 | 下一步操作 |
|---|---|---|
| unknown proxy type | 实际运行的核心、节点类型拼写 | 确认客户端没有仍调用旧二进制 |
| 找不到规则提供器 | RULE-SET 引用名、文件路径、下载日志 | 先用本地小规则文件验证解析 |
| 配置测试成功但无法联网 | 监听端口、节点可达性、策略选择 | 先使用显式代理请求隔离系统设置 |
| 开启 TUN 后部分应用异常 | 路由、DNS、IPv6、其他 VPN | 回到系统代理基线，再逐项恢复接管 |
| 订阅更新后设置丢失 | 配置来源、客户端合并与覆写顺序 | 将自定义内容放入客户端支持的持久覆写位置 |
需要 VLESS、Hysteria2、TUIC、GEOSITE 或更完整的现代分流配置时，mihomo 是更合适的比较对象。只有基础代理需求时，则应继续比较图形客户端的维护状态、平台集成和配置管理方式，而不是单靠核心功能表做决定。
Clash评测网提供客户端选型与配置资料，不是客户端开发方。实际迁移以所安装核心的文档、启动日志和连接记录为准。把“配置能加载”“请求能成功”“规则命中正确”“系统接管完整”分成四个验收项，排错会比一次性替换全部设置更清晰。