内核选型 预计阅读 13 分钟

Clash 内核版本对比：原版 Premium、Clash Meta 与 mihomo 有什么区别

梳理三代内核的来龙去脉与分叉关系，对比协议支持范围、规则字段扩展、GEOSITE 与 TUN 能力差异，并给出不同平台客户端应选哪一内核的实用建议。

先理清名称：它们不是三个并行更新的版本

Clash 客户端通常由图形界面、内核和配置文件三部分组成。图形界面负责订阅导入、节点切换和日志展示；内核负责建立代理连接、解析规则、执行 DNS 策略和接管流量。客户端名字相同，不代表使用的内核相同。判断功能范围时，应先查看内核名称与版本，而不是只看应用名称。

原版 Clash 指 Dreamacro 发布的开源核心，提供 HTTP、SOCKS、混合代理端口、代理组和基础规则匹配等能力。Clash Premium 是原作者在这一基础上发布的增强构建，曾加入 TUN、规则集、脚本以及更完整的流量接管功能。原项目仓库在 2023 年停止维护后，原版与 Premium 都不再适合作为持续更新的功能基线。

Clash Meta 是社区从 Clash 分叉出的增强内核。它延续 Clash 配置结构，同时扩展协议、规则、DNS、TUN 和代理组能力。项目随后将正式名称调整为 mihomo，因此 Clash Meta 与 mihomo 主要是前后名称关系，并不是两套完全独立的新内核。旧客户端界面可能仍显示 Meta，新版本、文档和进程名则更多使用 mihomo。

名称与维护关系

名称 定位 当前选型意义
原版 Clash 早期开放源代码的基础内核 适合阅读旧配置和理解基础语法，不建议作为新部署首选
Clash Premium 原作者发布的增强构建 常见于旧桌面客户端，重点是兼容既有配置
Clash Meta 社区增强分支的旧称 多数能力已延续到 mihomo
mihomo Clash Meta 更名后的持续维护项目 适合需要新协议、扩展规则和完整 TUN 能力的设备

协议支持差异：先看订阅节点使用什么传输方式

内核能否读取订阅，不等于能否连接订阅中的全部节点。订阅转换后通常是一组 proxies，每个节点都带有 type、服务器地址、端口和认证字段。遇到不受支持的类型时，内核可能在加载阶段直接报错，也可能跳过对应节点，最终表现为订阅已更新但节点数量减少。

原版与 Premium 的基础范围

原版 Clash 主要覆盖 Shadowsocks、VMess、Trojan、Snell、SOCKS5 和 HTTP 等当时常用类型。Premium 的核心优势更偏向 TUN、规则集和运行能力，不应简单理解为支持所有后来出现的代理协议。含有新字段的订阅放入旧 Premium 客户端，仍可能出现 unsupported proxy type 或字段解析失败。

mihomo 的扩展范围

mihomo 在兼容常见 Clash 节点结构的基础上，持续增加 VLESS、Reality、Hysteria 2、TUIC、WireGuard、ShadowTLS 等类型或传输组合。具体字段会随内核版本变化，例如 VLESS Reality 通常涉及 servername、reality-opts、公钥和短标识；Hysteria 2 通常需要服务端口、认证信息与 TLS 服务器名称。旧内核不认识这些字段时，仅修改节点名称不能解决问题。

  • 订阅以 Shadowsocks、VMess、Trojan 为主时，三类内核的基础连接能力重叠较多。
  • 订阅含 VLESS Reality、Hysteria 2 或 TUIC 时，应直接确认客户端是否内置 mihomo。
  • 使用 WireGuard 节点时，要区分“代理节点类型”与系统中独立运行的 WireGuard 应用，两者配置入口不同。
  • 节点支持还受客户端封装影响。内核具备功能，但图形界面未提供字段编辑入口时，需要通过 YAML 配置使用。

规则能力差异：基础语法兼容，扩展字段不能反向通用

三者都沿用 Clash 自上而下匹配、首条命中即停止的规则模型。常用的 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP 和末尾兜底规则具有较高兼容性。真正拉开差距的是规则集合、进程匹配、入站条件和地理数据加载方式。

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN-KEYWORD,video,Media
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Final

这段配置体现了通用原则：域名规则放在需要解析 IP 的规则之前；局域网地址直接连接；no-resolve 用于避免 IP-CIDR 规则主动触发 DNS 解析；最后使用 MATCH 承接未命中的连接。部分旧配置使用 FINAL，迁移时应根据目标内核文档统一为其支持的写法。

RULE-SET 与规则提供器

Premium 曾通过规则集能力解决超长规则列表的维护问题。Meta 与 mihomo 进一步普及 rule-providers，可以从本地文件或远程地址加载 domain、ipcidr、classical 等行为类型。配置时不仅要看规则文件内容，还要让 behavior 与内容格式一致。把域名列表声明成 ipcidr，内核不会自动猜测并修正。

rule-providers:
  private-domain:
    type: file
    behavior: domain
    path: ./rules/private-domain.yaml

rules:
  - RULE-SET,private-domain,DIRECT
  - MATCH,Final

远程规则提供器还可能包含 url、interval 和缓存路径。更新间隔通常以秒计，例如 86400 表示 24 小时。规则文件并非更新越频繁越好；公共地理列表每天拉取一次通常足够，频繁更新只会增加启动和网络请求负担。

进程与入站匹配

mihomo 支持更丰富的规则条件，例如 PROCESS-NAME、PROCESS-PATH、NETWORK、IN-PORT、SRC-IP-CIDR 和逻辑组合规则。进程匹配依赖操作系统权限与实现方式，在 Android、Windows、macOS 上的可用范围并不完全一致。移动系统限制较多时，使用域名和 IP 规则通常更稳定。

GEOSITE 与 GEOIP：名称接近，匹配对象不同

GEOIP 按目标 IP 所属地区匹配。连接只有域名时，内核可能需要先解析出 IP，才能判断地区。GEOSITE 则基于预先整理的域名分类数据匹配，例如搜索服务、流媒体或特定地区域名集合。它不等同于实时查询网站归属，也不会分析网页内容。

原版 Clash 对 GEOIP 等基础地理匹配支持较早。Premium 和后续分支扩展了可用的数据与规则形式。mihomo 可结合 GeoIP、GeoSite 及不同格式的数据文件工作，但文件格式、下载路径和配置项必须与具体版本对应。只有规则行而缺少数据文件时，启动日志通常会提示资源读取失败。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Final

上例先按域名分类处理广告集合，再让中国大陆常见域名直连，之后用 GEOIP 补充处理已得到 IP 的连接。顺序不能随意颠倒。如果把宽泛的 GEOSITE,cn,DIRECT 放在某个需要代理的具体域名规则之前，具体规则可能永远没有机会命中。

地理数据常见排查点

  1. 在客户端「设置」→「内核」或「关于」中确认实际运行的是 Premium、Meta 还是 mihomo。
  2. 打开配置目录，检查 GeoIP 与 GeoSite 数据文件是否存在，并观察修改时间是否合理。
  3. 在「设置」→「日志」中搜索 geo、rule 或 provider，确认文件已加载。
  4. 将目标域名放在更具体的 DOMAIN 或 DOMAIN-SUFFIX 规则中测试，排除地理分类本身的偏差。
  5. 确认客户端更新内核后是否同时更新了地理数据。两者常由不同入口管理。

TUN 模式差异：接管范围取决于内核、权限与系统路由

系统代理只影响遵循 HTTP 或 SOCKS 代理设置的应用。游戏、命令行程序、部分商店应用和自带网络栈的软件可能绕过系统代理。TUN 模式通过虚拟网络接口接管更多 TCP 与 UDP 流量，因此常用于需要统一分流的桌面与移动设备。

原版基础核心主要围绕代理端口工作。Premium 将 TUN 作为重要增强能力。mihomo 延续并扩展了 TUN 配置，常见字段包括 enable、stack、auto-route、auto-detect-interface、strict-route 和 dns-hijack。不同版本支持的取值可能变化，迁移旧配置时应以当前内核输出的错误信息为准。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53

auto-route 用于自动写入必要路由；auto-detect-interface 尝试识别当前出口网卡；strict-route 用于减少流量绕过；dns-hijack 将指定的 DNS 请求交给内核处理。示例中的 any:53 表示接管目标端口为 53 的 DNS 流量，但是否适合当前系统，还要结合本地 DNS、局域网设备和其他 VPN 软件判断。

常见 TUN 栈怎么选

  • system：更多依赖操作系统网络栈，通常性能较直接，适合先作为桌面系统的测试选项。
  • gVisor：使用用户态网络栈处理部分连接，兼容表现可能不同，遇到特定 UDP 或应用问题时可用于对照测试。
  • mixed：按流量类型组合处理。是否存在及具体行为取决于 mihomo 版本，旧配置迁移后应检查启动日志。

打开 TUN 后无法联网，不代表内核本身无法使用。先关闭 TUN，确认普通系统代理能够连接；再检查管理员权限、虚拟网卡、默认路由和 DNS。Windows 可重点观察是否与其他 VPN 虚拟网卡冲突，macOS 要确认系统扩展或 VPN 权限，Android 则要确认系统只保留一个活动 VPN 服务。

DNS 行为差异：Fake-IP 配置要与规则和 TUN 一起看

Clash 系内核常见 DNS 增强模式包括 fake-ip 与 redir-host。Fake-IP 会先向应用返回保留地址，再在连接阶段恢复原始域名，以便域名规则尽早参与匹配。它能减少部分场景下的重复解析，但也可能影响依赖真实局域网地址的设备发现、打印机、游戏平台或公司内网域名。

mihomo 对 Fake-IP 过滤、DNS 分流、回退解析和 nameserver-policy 等能力提供了更多组合方式。配置越复杂，越需要明确每组 DNS 的用途。把所有域名同时交给多个上游并不一定更快，还可能造成结果不一致。家庭网络可以先从一组主要解析器、一组直连规则和必要的 Fake-IP 过滤项开始。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

示例把内核 DNS 监听在 1053 端口，并使用 198.18.0.1/16 作为 Fake-IP 地址段。该地址段不应当被当作节点服务器的真实地址。日志里看到连接到 198.18.x.x 时，要结合域名映射判断，不要直接认定为错误目标。

配置兼容性：能启动只是第一步

Clash Meta 与 mihomo 尽量延续 Clash YAML 结构，但兼容不是双向的。基础 Clash 配置通常更容易被 mihomo 读取；使用 mihomo 新协议、新规则类型或扩展 DNS 字段的配置，则无法直接交给原版或 Premium。客户端还可能在保存时重写配置，因此手工修改前应区分“订阅生成配置”和“本地覆写配置”。

从 Premium 迁移到 mihomo 的检查清单

  1. 记录原客户端的混合端口、局域网访问设置、工作模式和当前代理组选择。
  2. 保留原始 YAML 副本，再将订阅导入新客户端，不要直接覆盖唯一配置。
  3. 先关闭 TUN，只测试 7890 等本地代理端口是否能正常连接。
  4. 检查日志中是否存在弃用字段、重复键、规则集加载失败和代理类型错误。
  5. 逐个测试 DIRECT、REJECT、节点选择组和自动测速组，确认规则动作符合预期。
  6. 最后打开 TUN 与 DNS 劫持，分别测试浏览器、命令行、游戏和局域网设备。

自动测速组也可能产生体验差异。常见 url-test 会定期访问指定 URL，根据连接耗时选择节点。测试间隔设为 300 表示每 5 分钟检测一次。延迟最低不等于下载速度最高，因为测试通常只覆盖 DNS、TCP、TLS 或一次小型 HTTP 请求，无法代表长连接带宽与晚高峰拥塞。

proxy-groups:
  - name: Auto
    type: url-test
    proxies:
      - Node-A
      - Node-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

tolerance: 50 表示候选节点延迟差距较小时减少频繁切换。对于会议、下载和持续播放，稳定连接通常比每次测试后追逐几毫秒更重要。迁移内核后如果节点切换明显增多，应检查测试 URL、间隔和容差，而不是只调整规则。

不同平台怎么选内核

Windows 与 macOS

新安装优先选择明确标注使用 mihomo、能够展示内核版本并提供日志入口的客户端。桌面系统常需要 TUN、进程规则和规则提供器，mihomo 的覆盖更完整。安装后可依次检查「设置」→「内核版本」、「配置」→「订阅」和「日志」，确认界面版本与实际内核不是两套独立更新状态。

如果旧客户端仍使用 Premium 且现有订阅只有基础协议，短期内可能继续工作。但遇到系统升级、地理数据失效或订阅增加新节点类型时，排查成本会逐渐增加。迁移前保留规则和端口设置，再用 mihomo 客户端逐项恢复，通常比在旧内核中补新协议更直接。

Android

Android 客户端通过系统 VPN 接口接管流量，应用本身是否集成 mihomo比桌面上的系统代理设置更关键。选择时应查看内核说明、分应用代理、IPv6、UDP 和后台运行策略。系统只允许一个主要 VPN 服务同时运行，因此 Clash 类客户端与其他 VPN、DNS 过滤应用往往不能同时接管。

iPhone 与 iPad

iOS 上通常不是直接安装一个名为 mihomo 的独立内核程序，而是使用支持 Clash 配置或相近规则体系的网络工具。不同应用可能采用不同实现，不能根据配置文件扩展名推断其完整兼容性。导入前应核对应用说明支持的协议、规则类型与 TUN 行为，尤其是 VLESS Reality、Hysteria 2 和复杂 rule-providers。

路由器、NAS 与命令行环境

路由器与 NAS 更看重 CPU 架构、内存占用、启动方式和防火墙整合。下载内核时要匹配 amd64、arm64 或其他实际架构。命令行运行后可通过版本命令或控制接口确认内核身份，并检查 7890、9090、1053 等端口是否与现有服务冲突。低内存设备应控制规则提供器数量和更新频率。

使用场景 建议选择 优先检查
新装桌面客户端 mihomo TUN 权限、内核版本、订阅协议
继续维护旧配置 先确认 Premium 兼容，再安排迁移 规则集、脚本、旧字段
Android 分应用代理 集成 mihomo 的客户端 VPN 权限、后台限制、UDP
iOS 配置导入 按应用实际兼容范围选择 协议、规则提供器、系统 VPN 限制
路由器与 NAS 匹配架构的 mihomo 架构、内存、路由与端口冲突

最终判断：按功能需求选，不按名称新旧猜

原版 Clash 奠定了配置、代理组和规则体系；Premium 补充了当时重要的 TUN 与高级规则能力；Clash Meta 延续社区开发，并以 mihomo 名称继续维护。对普通用户而言，Meta 与 mihomo 不需要当成两套互斥技术，重点是客户端内置的实际版本与配置兼容范围。

只使用基础 Shadowsocks、VMess 或 Trojan 节点，并依赖系统代理时，旧内核与 mihomo 的表面体验可能接近。需要 VLESS Reality、Hysteria 2、TUIC、完整规则提供器、GEOSITE、进程规则或更细的 TUN 与 DNS 控制时，mihomo 更适合作为当前基线。

选定内核后，按“普通代理连接 → 基础规则 → DNS → TUN → 扩展规则”的顺序验证。每增加一层能力就查看一次日志，并记录端口、模式与测试结果。这样即使客户端更新或订阅结构变化，也能快速确定问题位于节点、规则、DNS 还是系统路由。

下载 Clash 客户端 查看 Windows、macOS 与移动端版本