Clash 原版内核、Clash Meta 与 mihomo 有什么区别：版本演进与功能对照

名称关系：原版 Clash、Premium 与 Meta 分支

先给出选型结论：Clash Meta 与 mihomo 属于同一分支的前后名称，不能简单理解为两个互不相关的内核；原版 Clash 则是这条技术路线的上游来源。选择客户端时，应查看实际运行的内核名称与版本，而不是只看应用名称里是否带有 Clash。

还需要单独区分 Clash Premium。许多旧教程把原版开源内核和 Premium 内核统称为“Clash”，容易造成“原版一定支持 TUN”“旧配置都能直接迁移”等误解。判断功能时，至少要分清以下四个名称。

原版 Clash 开源内核：通常指 Dreamacro/clash 项目的开源版本，提供本地代理入口、策略组、规则匹配和 DNS 等基础能力。
Clash Premium：原项目另行发布的闭源增强内核，曾提供 TUN、规则集和脚本等扩展能力，不能把它的全部功能归入原版开源内核。
Clash Meta：由社区基于 Clash 发展出的分支，扩展了协议、规则与网络接管能力。
mihomo：Clash Meta 后续使用的项目名称，现行文档、程序文件和日志中常见这一名称；部分客户端或订阅服务仍沿用 Meta 标签。

客户端与内核：界面版本不等于功能版本

客户端负责订阅管理、配置切换、系统代理开关和日志展示；内核负责解析配置、建立连接、执行规则与处理 DNS。同一个客户端可能内置某个内核，也可能允许切换内核，因此“客户端已经更新”并不能证明底层网络能力也已更新。

确认实际运行内核的三条线索

打开客户端的“关于”或“内核”页面，分别记录客户端版本和内核版本。各客户端菜单命名不同，不要把应用版本号直接当作内核版本号。
查看启动日志中的内核名称、版本与加载配置结果。切换内核后应重新确认日志，避免只更换了文件而没有重启进程。
若启用了本地控制接口，可请求 /version。返回内容因内核版本而异，重点核对版本字段与分支标识。

例如，控制接口配置为 external-controller: 127.0.0.1:9090 时，可在本机执行下面的命令。如果配置了接口密钥，需要另外使用正确的认证请求；出现 401 只说明认证未通过，不表示内核不支持版本查询。

curl http://127.0.0.1:9090/version

9090 在这里是控制接口端口，并非浏览器代理端口。控制接口能修改运行状态，应保留本机监听；不要为了让面板连接而直接改为公网可访问的地址。

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

下面对照的是能力方向，不是每个历史版本的完整清单。原版项目与其 Premium 发布线已经停止原项目维护；mihomo 的具体字段仍应以所用版本文档为准，尤其是新协议参数、DNS 选项和平台相关功能。

比较项	原版开源 Clash	Clash Premium	Meta / mihomo
常见代理协议	支持 Shadowsocks、VMess、Trojan 等，具体参数受版本限制。	沿用原版协议体系，不能按 mihomo 扩展协议理解。	扩展 VLESS、Hysteria2、TUIC 等支持，需核对版本与参数。
基础规则	支持域名、IP 段、GEOIP、MATCH 等常见规则。	支持基础规则，并提供规则集等增强能力。	支持基础规则、规则集及更多逻辑与匹配条件。
TUN 接管	不提供 Premium 式内置 TUN 功能。	提供 TUN，具体支持受系统与发布版本限制。	提供 TUN，多种协议栈与路由选项依版本、平台而定。
DNS 与 Fake-IP	具有 DNS 与 Fake-IP 基础能力。	具有 DNS 与 Fake-IP 能力。	继续扩展 DNS 策略、上游选择及解析控制能力。
迁移注意点	不能识别分支新增的协议与字段。	Premium 脚本不能假定可直接在 mihomo 运行。	可复用不少基础配置，但仍需逐项验证扩展字段。

协议名称相同，也要检查传输与 TLS 参数

支持某种协议，不代表支持它的所有组合。例如 VLESS 是代理协议，REALITY 属于相关 TLS 安全配置能力，WebSocket 和 gRPC 则属于传输方式。服务端需要哪种组合，客户端内核就必须支持对应字段；只看到“支持 VLESS”不足以确认连接条件完整。

同样，Hysteria 与 Hysteria2 不是只改显示名称就能互通的配置。订阅中出现 type: hysteria2 时，旧内核不能通过把类型改成 hysteria 获得兼容。应选择匹配的内核和订阅输出，而不是逐个删除报错字段。

规则兼容：基础语法可复用，扩展能力需复核

多数基础分流仍遵循“从上到下匹配，命中后决定策略”的思路。DOMAIN-SUFFIX、IP-CIDR、MATCH 等规则具有较强的共通性，但规则引用的策略组必须存在，组内代理名称也必须对应实际资源。

以下是用于说明顺序的规则片段，不是完整订阅配置。DIRECT 为内置直连策略；实际使用时，应将需要代理的规则指向已有策略组，而不是照抄为全部直连。

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,DIRECT

末尾兜底：MATCH 通常放在最后，提前放置会让后续规则失去匹配机会。
规则集声明：使用 RULE-SET 时，应检查对应的 rule-providers 名称、格式和行为类型，不能只复制规则引用行。
解析副作用：no-resolve 用于避免该条 IP 规则主动触发域名解析，不等于整个连接过程都不需要 DNS。
Premium 脚本：迁移包含 script 的旧配置时，要确认目标内核是否支持相应机制，必要时改写为规则与策略组。

如果配置加载成功但分流不符合预期，先检查当前是否为 rule 模式。全局模式不会按通常的规则列表执行分流，直连模式也不能用于验证代理规则是否正确。

TUN 与 DNS：功能存在不代表接管已完成

系统代理与 TUN 解决不同入口问题

系统代理通常让遵循系统设置的应用连接本地 HTTP 或 SOCKS 入口，例如 127.0.0.1:7890。它不保证接管所有程序，更不表示任意 UDP 流量都会进入内核。TUN 则通过虚拟网络接口和路由接管更多 IP 流量，适用范围与实现路径不同。

mihomo 支持 TUN，并不意味着在配置中写下 enable: true 就一定生效。还需确认客户端是否具备服务权限、系统是否允许创建接口、路由是否正确，以及是否与另一个 VPN 或透明代理发生冲突。排查时只保留一套网络接管方案，减少路由回环和 DNS 重复劫持。

Fake-IP 是 DNS 工作方式，不是代理协议

Fake-IP 会为域名分配映射地址，让内核在连接阶段找回原始域名并进行分流；常见配置示例使用 198.18.0.1/16 地址池。它不表示目标网站真的位于该地址，也不能据此判断节点地区。

下面的片段仅展示相关字段。1053 是自定义本地 DNS 监听端口，不会自动替代系统通常使用的 53 端口；系统 DNS 如何送入内核，需要客户端接管、TUN DNS 劫持或其他明确配置配合。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

DNS 配置字段和接管顺序可继续查阅完整手册的 DNS 说明；Fake-IP 的概念边界见术语手册。

迁移检查：从旧 Clash 配置切换到 mihomo

迁移重点不是把配置文件中的 Clash 字样替换为 mihomo，而是验证协议、规则与系统接管是否同时成立。建议按以下顺序操作，每一步确认后再增加下一层功能。

保留原配置：备份订阅地址、当前 YAML、本地覆写和策略组选择。订阅 URL 可能包含访问凭据，不应放入公开日志或截图。
核对订阅目标：服务提供方若区分 Clash 与 Meta 输出，先确认所选输出包含目标内核可识别的协议和字段。Base64 节点列表不能仅改扩展名就变成完整 YAML 配置。
执行语法检查：使用目标内核测试配置；常见命令为 mihomo -t -f config.yaml。Windows 可使用 mihomo.exe -t -f config.yaml，实际程序路径以安装位置为准。
先验证本地代理：暂时关闭 TUN，确认本地入口端口、策略组和代理连接正常，再验证规则模式。
再启用接管：根据权限要求开启 TUN，检查日志中的接口、路由与 DNS 状态，分别测试浏览器和不遵循系统代理的应用。
最后恢复自动更新：确认一次订阅更新后，本地覆写仍然生效。直接修改远程配置文件的内容，可能被后续更新替换。

例如配置使用 mixed-port: 7890 时，可以通过下面的命令验证 HTTPS 请求是否经过这个本地 HTTP 代理入口。命令成功只能证明这一入口和目标请求可用，不能证明所有应用、UDP 或 TUN 都已正常。

curl -I -x http://127.0.0.1:7890 https://example.com

若提示端口占用，应检查是否仍有旧内核或其他客户端运行；若提示未知代理类型，优先检查内核与订阅格式；若语法通过但连接超时，再检查服务端参数、网络可达性和 DNS。把这三类问题分开，通常比连续更换配置更容易定位原因。

选型结论：按订阅协议与运行平台决定

需要新协议或扩展规则：优先选择明确集成并维护 mihomo 的客户端，同时确认内置内核版本满足配置要求。
只使用基础协议与域名分流：基础功能不一定需要复杂配置，但新部署仍应优先考虑维护状态与系统兼容性，而不是只因旧教程熟悉就固定使用旧内核。
需要 TUN：除内核支持外，检查客户端权限管理、系统架构和路由处理能力；手机端尤其要以应用实际采用的内核与系统 VPN 接口实现为准。
迁移 Premium 配置：优先复核脚本、规则集与 TUN 字段，不把“能够导入”当作“全部行为一致”。

最后把三个更新入口分开管理：订阅更新改变代理资源与规则内容，内核更新改变协议和网络能力，客户端更新改变界面与集成方式。遇到不支持的字段，单纯刷新订阅不一定有效；遇到失效的服务端地址，单纯更换内核也不能解决。先确认问题属于哪一层，再选择相应操作。