Clash 原版、Meta 与 mihomo 内核差异：功能边界和客户端选型

判断一个 Clash 客户端是否适合当前环境，不能只看软件名称和界面截图。实际承担连接接管、规则匹配、DNS 处理与代理协议解析的是内核。桌面客户端通常只是配置、托盘菜单、系统代理开关和日志查看界面，内核版本才决定配置字段能否识别、TUN 如何工作以及新协议能否建立连接。

“Clash 原版”“Clash.Meta”和“mihomo”经常被并列讨论，但三者并不是三个持续同步开发、功能对等的产品。原版 Clash 是配置模型与规则体系的重要来源；Clash.Meta 是后续扩展分支曾经使用的名称；mihomo 则是该扩展分支更名后的现行项目名称。很多客户端、配置目录和订阅转换模板仍保留 Meta 字样，因此界面名称与实际运行内核可能不一致。

项目关系：原版、Meta 与 mihomo 不是三条平行产品线

Clash 原版建立了通用配置模型

通常所说的 Clash 原版，指 Dreamacro 维护的 Go 语言规则代理内核及其配置体系。它确立了代理节点、策略组、规则、DNS、入站端口和外部控制器等核心概念。大量客户端与订阅服务沿用了这些字段，因此即使当前运行的是其他兼容内核，配置文件仍常被统称为 Clash 配置。

原版开源项目目前已经归档，不再处于持续功能迭代状态。历史上还存在功能边界不同的 Premium 构建，部分旧文档会把开源版、Premium 版和图形客户端混在一起说明。阅读旧教程时，需要先核对它描述的是哪一种构建，尤其不要把旧版 Premium 的行为直接当作所有原版内核都具备的能力。

Clash.Meta 是扩展分支的旧名称

Clash.Meta 沿用 Clash 的主要配置结构，并在代理协议、规则能力、DNS、TUN、流量嗅探和运行控制等方面持续扩展。它的目标之一是让常见 Clash 配置能够低成本迁移，同时允许配置文件使用更多字段。因其兼容基础较广，许多桌面端和移动端曾直接把“Meta”写进产品名、内核切换项或配置目录。

mihomo 是 Meta 分支更名后的现行名称

mihomo 不是在 Clash.Meta 之外重新出现的另一套并行内核。更准确的理解是：Clash.Meta 项目更名为 mihomo，代码与维护关系延续下来。到本文日期，面向新版本、问题修复和新配置能力时，应优先查阅 mihomo 的现行文档。旧界面显示“Meta 内核”时，也应继续检查版本输出，因为它可能实际打包了 mihomo，只是客户端尚未调整显示文字。

功能边界：差异集中在接管方式、协议与规则处理

基础的 HTTP、SOCKS、混合端口、代理组和域名规则并不足以区分内核。多数常规订阅都能生成这些内容。真正影响选择的是系统流量如何进入内核、DNS 请求由谁解析、订阅是否包含新代理协议，以及规则集是否依赖 mihomo 的扩展语法。

TUN 与系统流量接管

系统代理只会影响主动读取代理设置的应用。浏览器和部分桌面软件通常可以使用系统代理，但命令行程序、游戏、虚拟机、部分商店应用以及自行实现网络栈的软件可能绕过该设置。TUN 模式通过虚拟网络接口接收更广范围的 IP 流量，适合需要统一接管的环境，但同时涉及管理员权限、路由表、DNS 劫持、网卡冲突和防火墙规则。

原版开源内核、历史 Premium 构建与现代 mihomo 的 TUN 能力不能按一个版本处理。mihomo 当前提供较完整的 TUN 配置，并包含不同协议栈与自动路由相关选项。客户端是否能成功启用，仍取决于操作系统、服务模式和权限。选择支持 mihomo 的客户端，只代表内核具备相应能力，不代表客户端已自动完成驱动、服务与路由配置。

代理协议与传输参数

较早的 Clash 配置主要覆盖当时常见的 Shadowsocks、VMess、Trojan 与 SOCKS 等类型。mihomo 在后续维护中增加或扩展了多种协议与传输参数。订阅中如果出现新协议、新加密方式或扩展传输字段，旧原版内核可能在载入阶段直接报错，也可能忽略不认识的字段，最终表现为节点不可用。

这里不能只比较节点列表是否显示。图形界面可能先解析订阅并绘制节点，而真正发起连接时才把配置交给内核。节点出现在列表中但测速失败，常见原因之一就是客户端前端接受了字段，内核版本却不支持相应协议。诊断时应查看内核日志中的解析错误、握手错误和未知字段提示。

规则集、子规则与匹配能力

经典 Clash 规则通常由规则类型、匹配内容和目标策略组成，例如域名后缀、IP 网段、进程名及最终匹配。mihomo 在这一基础上提供更丰富的规则与规则集能力，可按配置需要组织远程规则集、组合逻辑和子规则。大型配置可以借此减少主文件长度，并按不同更新时间拆分数据。

扩展能力也会带来迁移约束。配置一旦使用只有 mihomo 支持的规则类型，便不能再假设它可以直接回退到原版。即使 YAML 语法正确，旧内核仍可能因未知规则而拒绝启动。需要兼容多种客户端时，应以目标设备中能力最低的内核为基线，或者为不同内核分别生成配置。

DNS、嗅探与域名还原

Clash 系列内核的规则决策经常依赖域名，但进入 TUN 的连接可能只呈现目标 IP。DNS 映射、Fake IP 与流量嗅探用于补充域名信息，让域名规则可以继续命中。mihomo 对相关流程提供了更多可调字段，包括监听、解析服务器分组、Fake IP 范围、过滤项、回退与嗅探覆盖范围。

这些选项并非越多越好。企业内网域名、局域网设备、游戏反作弊、浏览器加密 DNS和系统自带解析缓存都可能改变实际路径。内核选型只能确定可用工具，最终配置仍要结合网络环境。排障时应分别检查系统 DNS、内核 DNS 日志、规则命中结果和实际出口，避免一次同时修改 TUN、Fake IP 与回退服务器。

配置兼容：基础字段通常向前延续，扩展字段不能反向保证

从原版配置迁移到 mihomo，基础结构通常可以保留。端口、运行模式、日志级别、代理列表、策略组和常见规则仍沿用熟悉的层级。下面是一个刻意保持基础化的示例：

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

proxies:
  - name: example-node
    type: socks5
    server: 127.0.0.1
    port: 1080

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

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,DIRECT

这类配置没有引入特定分支的高级能力，迁移阻力较小。但真实订阅还可能包含远程规则提供者、健康检查、接口绑定、流量嗅探、新协议参数和客户端覆写项。只看文件开头几行，无法判断整份配置是否兼容。

从原版迁移到 mihomo

迁移方向通常较顺。先使用原配置启动 mihomo，观察解析与运行日志，再逐项启用新功能。不要在第一次启动时同时改成 TUN、替换 DNS 模式并重写规则集。稳妥顺序是先确认节点能够建立连接，再验证策略组切换，然后检查规则命中，最后处理 TUN 与 DNS。

如果配置来自订阅，客户端还可能在下载后追加覆写内容。例如更改端口、插入本地规则、替换策略组或开启局域网访问。导出的 YAML 与运行时配置不一定完全一致。遇到行为差异时，应使用客户端提供的运行配置查看功能，或从外部控制接口确认内核实际载入的内容。

从 mihomo 回退到原版

反向迁移需要逐项删除扩展字段，并确认每个节点协议仍受旧内核支持。删除一个顶层字段并不够，因为不兼容内容可能藏在代理节点、规则、DNS、TUN、规则提供者和策略组参数中。远程订阅下次更新还会重新写入这些内容，因此临时手工修复不能替代订阅模板调整。

如果某个服务端只提供旧内核不支持的协议，配置转换也无法把它自动变成另一种协议。订阅转换主要负责字段重组、节点筛选和规则拼接，不能改变服务端实际提供的握手方式。此时应继续使用支持该协议的 mihomo 内核，或者从配置来源取得兼容节点。

客户端选型：先看系统集成，再看内核版本

普通用户通常不会单独运行内核，而是安装带图形界面的客户端。选型时应把“前端是否便于操作”和“内核是否满足配置”分开判断。一个界面成熟但内核长期未更新的客户端，可能无法加载新订阅；一个内核更新及时但缺少系统服务管理的客户端，也可能不适合长期启用 TUN。

Windows 桌面环境

Windows 客户端应重点检查 mihomo 内核版本、服务模式、TUN 权限处理、系统代理恢复和日志入口。只使用浏览器与常规办公软件时，系统代理模式通常更容易维护。需要接管游戏、命令行、商店应用或不读取系统代理的软件时，再评估 TUN。启用前应记录原有 DNS、其他虚拟网卡和安全软件状态，便于出现断网时回退。

部分 Windows 客户端允许切换多个内核。切换后不能只重启界面，应确认运行日志中的内核名称和版本已经变化。旧配置若带有 Premium 专用字段，也要检查客户端是否自动转换。系统代理端口必须与内核监听端口一致，否则界面显示已开启，应用仍会连接到空端口。

macOS 桌面环境

macOS 上应关注客户端是否适配当前处理器架构、系统扩展或网络权限，以及退出时能否恢复代理设置。许多名称较早的客户端仍可能通过更新打包 mihomo，因此产品名不能直接代表内核。Apple Silicon 设备优先使用匹配架构的构建，避免把架构兼容层问题误判为代理内核故障。

使用系统代理时，应核对 HTTP、HTTPS 与 SOCKS 项是否由客户端正确设置。使用 TUN 时，则需检查虚拟接口、默认路由和局域网访问。企业管理设备可能限制网络扩展或管理员授权，这属于系统策略边界，单纯更换配置文件无法解决。

Linux 桌面与服务器

Linux 桌面可以选择带界面的 mihomo 客户端，也可以直接运行内核。服务器更适合使用命令行配置和 systemd 服务，便于固定工作目录、限制权限、自动重启并通过 journal 查看日志。需要注意，设置 shell 中的 HTTP_PROXY 和 HTTPS_PROXY 只影响读取这些环境变量的程序，不等同于全局接管。

TUN 部署还涉及网络命名空间、路由规则、转发开关和容器网络。Docker 容器中的请求是否经过宿主机 mihomo，取决于网络模式和路由设计。服务器上不宜直接复制桌面客户端生成的配置，因为其中可能包含仅供界面使用的相对路径、控制器地址或本地规则文件。

Android 与 iOS

移动系统通常通过系统 VPN 接口接管流量，前端应用对内核生命周期和后台运行的控制比桌面端更重要。应确认应用实际集成的内核、支持的代理协议、按应用分流能力和系统版本要求。移动客户端显示的“VPN”表示本地流量入口，不代表流量一定连接传统企业 VPN；后续仍由规则和代理组决定直连或转发。

iOS 上不能把桌面端内核文件直接放入应用运行。应用能使用哪些内核功能取决于其打包版本和系统审核下的实现方式。Android 也存在厂商后台限制、电池优化和 VPN 常驻策略。节点在桌面端正常但移动端频繁断开时，应同时检查系统后台限制，而不是只替换订阅。

按使用场景形成选择结论

对于新部署，选择持续维护的 mihomo 通常更合理。这里的依据不是名称更新，而是配置生态、协议变化和操作系统网络栈会持续演进。仍在稳定运行的旧环境不必在没有备份与测试的情况下立即替换，但应记录当前内核、客户端版本、配置来源和启动参数，避免故障发生后找不到可复现条件。

如果多个设备由同一订阅管理，最好统一内核大版本，并为桌面与移动端分别保存少量平台覆写。通用部分保留节点、策略组和规则，平台部分处理 TUN、监听地址、接口绑定和局域网访问。这样可以避免为了适配一台设备而把平台专用字段写进所有配置。

迁移执行：按最小变量逐步验证

1. 记录当前状态。保存客户端版本、内核名称、内核版本、配置来源、系统代理端口和是否启用 TUN。截图只能辅助定位，文本日志与配置更适合比较。
2. 备份本地覆写。订阅地址通常只提供远程主体，本地规则、策略组调整和 DNS 例外可能存放在客户端数据库中。升级前应使用客户端的导出功能保留这些内容。
3. 先测试基础代理。关闭 TUN 与复杂 DNS 覆写，以系统代理或显式 SOCKS 连接验证一个节点。确认节点握手成功后，再检查策略组与规则。
4. 检查规则命中。分别访问应直连和应代理的目标，在日志中确认目标域名、规则类型与最终策略。仅凭网页能否打开，无法判断是否走了预期出口。
5. 启用 DNS 设置。确认内核监听端口没有冲突，再检查域名解析是否由预期服务器处理。使用 Fake IP 时，应单独验证局域网设备、内网域名和不兼容应用。
6. 最后启用 TUN。检查管理员权限、虚拟接口、自动路由和 DNS 劫持。若发生断网，先关闭 TUN 并恢复系统代理，再读取日志，不要连续切换多个网络工具。
7. 完成重启验证。重新启动系统或服务，确认客户端能恢复配置、订阅不会覆盖关键设置、系统代理和路由能够按预期建立。

常见误判与定位方法

界面写着 Meta，所以一定是旧内核：不成立。Meta 可能只是客户端历史命名。应读取启动日志或内核版本接口，确认实际二进制。

订阅导入成功，所以配置完全兼容：不成立。前端导入、内核解析、节点握手和规则执行是不同阶段。需要逐层查看日志。

切换 mihomo 后必须开启 TUN：不成立。mihomo 同样支持 HTTP、SOCKS 和混合端口。系统代理能够覆盖需求时，可以继续使用较简单的接管方式。

配置转换能解决所有协议差异：不成立。转换器可以重排配置，不能改变服务端协议，也不能让旧内核获得缺失的实现。

同名策略组在所有设备上行为一致：不一定。健康检查间隔、延迟测试地址、网络权限和内核版本都可能改变自动选择结果。需要比较组类型、候选节点与测试参数。

结论：新部署以 mihomo 为基线，旧环境按兼容性迁移

Clash 原版提供了广泛沿用的配置与规则模型，但其项目已经归档。Clash.Meta 是扩展分支曾经使用的名称，mihomo 是该分支更名后的现行项目。把 Meta 和 mihomo 当作两个同时竞争的新旧内核，会造成版本判断错误；正确做法是结合项目沿革、客户端打包版本和运行日志确认实际内核。

选型时，基础系统代理、简单规则和传统节点协议对内核要求较低；新协议、复杂规则集、精细 DNS、流量嗅探与 TUN 接管更依赖当前 mihomo 能力。新安装应优先选择持续维护并明确集成 mihomo 的客户端。现有旧环境则应先记录状态，使用最小配置完成迁移测试，再逐步恢复 DNS、规则集与 TUN。

最终判断标准不是客户端名称，也不是订阅文件能否导入，而是内核能否完整解析配置、稳定建立节点连接、按预期命中规则，并在系统重启后恢复网络状态。围绕这四项验证，可以把内核升级从一次整体替换拆成可观察、可回退的工程步骤。