Clash 原版、Clash Meta 与 mihomo 有何区别:内核功能、协议支持与配置语法对照

先区分：客户端、内核与订阅配置

“Clash 支不支持某个协议”不能只看软件窗口的名字。图形客户端负责订阅管理、配置切换、系统代理开关和日志展示；内核负责解析 YAML、建立代理连接、执行分流规则与处理 DNS。客户端界面相似，不代表内部运行的是同一套内核。

订阅则是配置来源。它可能返回含有 proxies、proxy-groups、rules 的完整配置，也可能只返回可供 proxy-providers 加载的代理条目。链接能成功下载，只证明取回了数据，不代表当前内核能解析其中每种节点和规则。

选客户端：检查操作系统、安装方式、权限管理和配置覆写入口。
选内核：检查实际需要的节点协议、规则语法、DNS 与 TUN 功能。
选订阅格式：确认提供方返回的是完整 Clash 配置，还是面向某个内核的扩展配置。

时间线：原版、Premium、Meta 与 mihomo

Clash 原版与 Clash Premium

通常所说的 Clash 原版，是 Dreamacro/clash 开源项目。Clash Premium 则是同一历史生态中的闭源增强内核，提供过 TUN、规则提供者和脚本等增强能力。Premium 的功能不能直接算到开源原版头上，也不能因为名字带 Premium 就推断它是某个图形客户端的付费版。

2023 年 11 月，原版 Clash 项目及 Premium 的常规公开维护中止。旧二进制仍可能启动，但后续协议演进、系统适配和问题修复不能按持续维护中的项目来预期。保留旧环境做对照测试，与继续把它作为日常联网入口，是两个不同的决定。

Clash Meta 与 mihomo

Clash Meta 起源于 Clash 的开源分支，在原有配置模型上增加协议与规则能力。项目在 2023 年末更名为 mihomo。旧教程中的 Meta、Clash.Meta，以及现在的 mihomo，通常指向这条项目演进线，而不是三个互不相关的内核。

更名不意味着所有历史版本的功能完全一致。订阅说明写着“适用于 Meta”，只能说明目标大致属于这一配置生态；某个较新的协议字段能否使用，仍要核对实际运行版本。客户端下载页显示的版本号，也未必就是内核版本号。

在客户端的“关于”、内核管理或启动日志中查找内核名称与版本。
使用独立二进制时执行 mihomo -v，记录输出。
将这个结果与订阅要求、功能文档对应，而不是只记录客户端安装包名称。

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

下表用于判断迁移方向，不是逐版本的完整功能清单。尤其是协议的传输方式、加密方法和认证字段，需要继续核对具体版本；同属一种协议，也可能因为参数不匹配而连接失败。

能力	Clash 开源原版	Clash Premium	mihomo／Meta 系列
常见代理类型	支持 SS、VMess、Trojan、SOCKS5、HTTP 等	支持传统 Clash 常见代理类型	保留常见类型，并扩展 VLESS、Hysteria2、TUIC 等
VLESS 与 REALITY	不支持	不支持	支持对应配置；REALITY 是相关 TLS 握手配置，不是独立节点类型
基础规则	DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP、MATCH 等	支持基础规则，并提供增强能力	支持基础规则，并扩展 GEOSITE、逻辑规则等
rule-providers 与 RULE-SET	不应按 Premium 的能力使用	支持，需匹配规则集格式	支持，并有更多格式与行为选项
TUN	不提供 Premium 式的内置 TUN 能力	支持，受平台和历史构建限制	支持，仍依赖平台权限与网络环境
Premium script	不支持	提供过脚本分流能力	不能把 Premium 脚本直接当作兼容配置加载

协议支持不等于任意节点都能导入

例如，VLESS 节点可能还需要 uuid、network、TLS 参数及 REALITY 的公钥等信息。只把节点的 type 改成 vless，不会补齐这些参数。Hysteria2 与旧 Hysteria 也不能仅凭名称相近就互换配置。

遇到未知代理类型时，先确认订阅是否为 mihomo 输出，再检查内核版本。不要通过删除认证字段或关闭证书验证来绕过报错。配置能被解析、远端握手成功和业务请求成功，是三个需要分别确认的阶段。

旧 YAML 迁移：保留什么，检查什么

大多数基础配置的骨架可以沿用：本地监听端口、代理条目、代理组和顺序规则依然存在。迁移重点不是把整份文件重新命名，而是清理内核专属字段，并确认客户端最终交给内核的运行配置。

常见字段处理表

旧配置项目	迁移处理	验证点
`mixed-port`、`mode`	通常可以保留；检查是否被客户端覆盖	实际监听地址与端口，当前模式是否为 rule
`proxies`、`proxy-groups`	核对协议字段及组内引用名称	大小写、空格、提供者名称是否完全一致
`rule-providers`	核对 behavior、format 和载荷结构	文本规则集与 YAML payload 不能混用解析方式
Premium 的 `script` 与 script 模式	改写为目标内核支持的规则、规则集或逻辑规则	不能只删除脚本后就认定分流行为保持不变
`tun`、`dns`	按目标内核和系统重新核对	路由、DNS 劫持、局域网解析是否符合预期

规则顺序比字段名称更容易被忽略

规则通常按从上到下的顺序匹配，命中后按对应策略处理。把 MATCH 放在前面，会让后续常规规则失去机会。RULE-SET 引用的名称必须存在于 rule-providers；规则指向的策略名称，也必须是有效代理、代理组或内置策略。

proxy-providers 提供代理节点，rule-providers 提供匹配规则，两者不能互换。迁移后出现“找不到提供者”，应先核对引用关系，而不是把两类订阅地址随意交换。

最小配置与迁移验证命令

先用一份容易回退的配置验证内核，再加入真实订阅。下面是 mihomo 的基础结构示例：监听本机 7890 混合端口，使用规则模式，关闭 TUN。代理组只含 DIRECT，因此它用于验证结构与规则加载，不会建立远程代理连接。

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

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

tun:
  enable: false

把文件保存为 config.yaml 后，可在独立终端中检查。下列命令适用于已将 mihomo 放入 PATH 的环境；Windows 本地可执行文件通常需要用 .\mihomo.exe 替换命令名。

mihomo -v
mkdir clash-test
mihomo -t -d ./clash-test -f ./config.yaml

-t 检查配置能否被当前内核加载，不负责证明远端节点可连接。测试目录应与日常客户端的数据目录分开，避免缓存与资源文件相互影响。若配置引用外部规则或地理数据，还要确认相关文件或下载来源可用。

保存原配置副本，记录旧内核版本、端口与已启用的覆写项。
将真实订阅导入目标客户端，先关闭 TUN，仅验证普通代理入口。
检查启动日志中的未知类型、缺失文件、无效引用与端口占用错误。
用目标客户端的连接记录确认命中的规则和实际出口，再逐项恢复 DNS、规则集与 TUN。

需要验证本机 HTTP 代理入口时，可执行 curl -x http://127.0.0.1:7890 https://example.com/。这条命令显式指定代理端口，不能证明系统代理开关已生效；若仍使用上面的示例配置，它最终走的是直连。

TUN 与 DNS：不能直接复制旧开关

系统代理通常只影响读取系统代理设置的应用。TUN 通过虚拟网络接口与路由接管流量，适合需要处理更多应用流量的场景，但不等于开启后所有流量都一定进入代理。内核仍按规则决定直连、代理或拒绝，路由排除项与其他 VPN 也会影响结果。

先解决权限与路由

Windows：检查客户端要求的服务模式或管理员权限；具体入口以该客户端版本为准。
Linux：检查 TUN 设备、进程能力或 root 权限，以及现有路由表。
macOS：检查客户端辅助服务与系统授权，避免同时启用多个争用路由的 VPN。

mihomo 的 TUN 配置常涉及 auto-route、auto-detect-interface、stack 与 dns-hijack。这些字段需要结合平台设置，不能把某个平台的成功配置视为所有系统的默认答案。改动前记录原值，每次只调整一组功能，才能区分权限问题和 DNS 问题。

DNS 能解析，不代表分流就正确

fake-ip 模式通过映射地址协助还原域名，redir-host 则侧重返回真实解析结果；两者对域名识别与应用兼容性的影响不同。迁移时应一起核对 enhanced-mode、fake-ip-filter、上游解析器和局域网域名处理。

常见的 DNS 劫持目标是普通 DNS 的 53 端口。应用自带的 DoH 通常经 HTTPS 的 443 端口发送，不能假定针对 53 端口的规则会自动覆盖它。遇到浏览器与其他应用结果不同，应检查浏览器安全 DNS、缓存和内核连接日志，而不是反复更换节点。

选型结论与验收清单

新建配置需要 VLESS、REALITY、Hysteria2、TUIC 或扩展规则能力时，应选择明确支持所需功能的 mihomo 版本，并确认客户端确实使用该内核。若只是迁移旧的 SS、VMess 或 Trojan 配置，基础结构通常可以保留，但 DNS、脚本分流与 TUN 仍需单独验证。

原版与 Premium 更适合用于理解历史配置和复现旧行为。迁移到 mihomo 的实际收益是获得对应的协议与规则能力，以及持续演进的内核实现；它不会自动修复失效订阅、错误凭据或服务端不可达的问题。

版本：已经记录实际内核名称与版本，而不只是客户端版本。
配置：语法检查通过，节点、代理组和规则提供者的引用完整。
端口：本地入口与应用设置一致，未与旧客户端同时占用 7890 等端口。
分流：至少检查一项直连请求与一项代理请求，日志中的策略符合预期。
TUN：确认权限、路由和 DNS 后再长期启用，退出客户端后网络可以恢复。
更新：手动更新一次订阅，确认自定义覆写仍然存在，再启用自动更新。

需要查字段含义时，可继续查看协议参考；遇到导入失败、端口冲突或系统代理异常，可从帮助中心按现象排查。选型完成后，先完成普通代理链路的验证，再增加 TUN 和复杂规则，问题范围会更清楚。