先分清三层：内核、客户端与配置
搜索 Clash 时，结果里常同时出现内核仓库、桌面安装包、手机应用和订阅教程。它们不是同一种东西。理解这套生态，先看每个项目负责哪一层，比只看名称里的 Clash 更有用。
| 层级 | 负责什么 | 常见内容 |
|---|---|---|
| 代理内核 | 接收连接、解析 DNS、匹配规则、建立出站连接 | Clash、mihomo |
| 图形客户端 | 导入订阅、选择策略、管理内核与系统接入 | Clash Verge Rev、FlClash |
| 配置与订阅 | 描述节点、策略组、规则和运行参数 | YAML 配置、远程配置地址、代理集合 |
内核像处理网络请求的执行层；客户端提供按钮、列表和设置页；配置则告诉内核如何处理连接。安装一个客户端，通常会同时获得它配套的内核，但这不代表客户端名称就是内核名称。
Clash、Clash Meta 与 mihomo 的传承关系
Clash：原始项目与通用称呼
狭义的 Clash 指 Dreamacro 发起的规则代理内核。它通过 YAML 配置组织代理节点、策略组、DNS 与分流规则，图形界面可以通过控制接口读取连接和切换策略。日常交流里，“Clash”也常被用作这一类客户端和配置格式的统称，因此教程中的“安装 Clash”未必是在要求直接运行原始内核。
原版开源 Clash 与历史上的 Clash Premium 也需要区分。Premium 是不同的历史发行分支，功能集合并不等同于原版开源内核。旧教程涉及 TUN、脚本或规则提供器时，必须同时核对教程所用的分支与版本，不能把其中一项功能推广到所有叫 Clash 的程序。
Clash Meta：从 Clash 衍生的内核项目
Clash Meta 是从 Clash 发展而来的社区分支。它保留了大量已有配置结构，并继续扩展协议支持、DNS、路由和 TUN 等能力。这里的 Meta 是内核项目名称，不是一个必须另行购买的客户端版本，也不代表所有带 Meta 字样的应用都由同一团队开发。
mihomo：Clash Meta 后续使用的名称
Clash Meta 后续更名为 mihomo，相关开发延续于 mihomo 项目。旧文档、配置注释和部分客户端界面仍可能使用“Meta 内核”这个称呼。看到“支持 Clash Meta”和“使用 mihomo”时，应先检查实际内核版本；它们通常指向同一条项目发展脉络，而不是两个必须同时安装的服务。
- 项目传承：原版 Clash → 社区分支 Clash Meta → 后续名称 mihomo。
- 客户端关系：不同界面项目可以集成同一种内核，各自维护自己的安装包和交互。
- 兼容判断：名称只能帮助定位项目，具体字段支持情况仍由运行中的内核版本决定。
2023 年原版项目及部分客户端的公开维护发生变化后，新的社区分支继续发展。由此不能推导出“所有 Clash 客户端都停止更新”，也不能把一个新客户端视为原项目自动改名后的官方续作。判断维护归属，应查看项目仓库、发布记录与维护者说明。
Verge、Verge Rev 与 FlClash 分别处在哪一层
Clash Verge、Clash Verge Rev 和 FlClash 都属于图形客户端这一层。它们让用户通过界面导入配置、切换策略并查看日志，而真正的代理处理由其启动的内核完成。
| 项目或名称 | 生态定位 | 选择时核对 |
|---|---|---|
| Clash Verge | 历史桌面客户端项目 | 不要与 Rev 的发布记录混用 |
| Clash Verge Rev | 延续 Verge 路线的社区桌面客户端，使用 mihomo | 系统要求、内核版本、服务模式说明 |
| FlClash | 基于 Flutter 构建、使用 mihomo 的多平台客户端 | 目标平台安装包与平台权限 |
| Clash for Windows | 历史桌面客户端，已停止维护 | 旧教程与当前系统的适配差异 |
| Clash for Android | 历史 Android 客户端，原项目已停止维护 | 不要将其与后续社区项目混为一谈 |
客户端名中的平台词也不能代替发行信息。例如 Clash for Windows 的历史发行不只涉及 Windows，而一个桌面客户端也不一定提供 Android 安装包。下载时应以具体项目当次发布的系统和架构列表为准。
同样使用 mihomo，为什么设置页不同？
因为订阅存储、托盘菜单、开机启动、服务安装和配置覆写由客户端实现。两款客户端即使内核版本相同，也可能使用不同的配置目录和订阅更新机制。某个界面里的“设置”→“订阅更新”路径不能直接套用到另一款应用；找不到同名菜单时，应寻找“配置”“Profiles”或该客户端文档中对应的入口。
配置能否通用：先看字段，再看加载方式
mihomo 延续了 Clash 生态中常见的 YAML 结构，但“能导入”不等于“全部字段都生效”。基础代理组和域名规则通常较容易迁移；新协议、DNS 扩展和 TUN 参数则更依赖版本。旧内核可能拒绝加载新配置，也可能忽略不认识的内容，具体要结合日志判断。
用基础字段识别配置结构
下面只展示通用设置和规则片段，不包含可连接的节点。这里明确把本地混合代理端口设为 7890，并限定为本机使用；它不是所有客户端都采用的默认值。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,DIRECTmixed-port 提供 HTTP 与 SOCKS 混合代理入口；mode: rule 表示按规则选择策略。示例最后一条规则是直连兜底，所以不会凭空产生代理连接。正式配置若要引用名为 Proxy 的策略组，还必须在配置中实际定义它，名称和大小写都要对应。
整份订阅与代理集合不是同一种输入
- 完整配置订阅：可能同时包含
proxies、proxy-groups、rules和 DNS 设置，通常导入客户端的配置列表。 - 代理集合：通常由
proxy-providers引用，供已有策略组使用，本身未必是一份完整运行配置。 - 单个节点链接：需要客户端支持解析或转换，不能直接把任意分享链接粘进 YAML 顶层。
遇到“同一订阅在 A 能用、在 B 不能用”，先检查 B 是否接受相同输入格式，再比较内核版本。不要只因链接能在浏览器下载，就断定它一定是客户端可直接加载的完整配置。
系统代理与 TUN：接入流量，不是另一种内核
系统代理和 TUN 解决的是“应用流量如何进入内核”，规则模式解决的是“进入后交给谁处理”。它们不是同一组开关。开启 TUN 后仍然可以使用规则模式，也仍然需要有效的节点、DNS 和路由设置。
系统代理：让遵循系统设置的应用连接本地端口
以 Windows 11 为例，可在“设置”→“网络和 Internet”→“代理”检查代理状态。如果客户端的有效混合端口是 7890，系统代理应指向对应的本地地址和端口，而不是继续使用另一款旧客户端的 7897 或其他值。这些数字只是不同配置中可能采用的端口，不能凭教程截图推定当前值。
并非每个程序都遵循系统代理。浏览器可用而某个终端工具不可用时，先检查该工具自身的代理参数或环境变量，不应立即认定内核失效。
TUN：通过虚拟网络接口与路由接入流量
TUN 可以接入更多不遵循系统代理的流量，但能否正常工作取决于系统权限、路由设置、DNS 处理和现有网络环境。桌面客户端可能要求先安装服务或提升权限；Android 通常通过系统 VPN 接口接入，并需要用户确认授权。不同平台的权限步骤不能照搬。
- 切换到 TUN 前，先确认普通代理入口与节点连接正常，避免同时排查两套问题。
- 保留其他 VPN、虚拟网卡和安全软件的状态记录，便于发现路由冲突。
- UDP 是否可用还取决于节点协议、服务端与出站链路，不是打开 TUN 就自动获得支持。
实际选型与迁移：按这五步核对
- 确定平台与架构。先确认 Windows、macOS、Linux 或 Android，再核对 x64、ARM64 等安装包标记。macOS 可从苹果菜单→“关于本机”查看芯片信息。
- 确认项目身份。对照完整项目名、仓库归属与发布记录，尤其区分 Clash Verge 和 Clash Verge Rev，以及原始移动端项目与社区分支。
- 记录客户端与内核两个版本。在“关于”、内核管理页或启动日志中查找；界面位置以具体版本为准。客户端升级不一定同时升级内核。
- 先导入配置，再测试单个节点。确认配置加载成功，查看日志中是否有未知字段、策略组不存在或端口占用提示，然后测试实际网页访问。
- 最后迁移自动化设置。基本连接稳定后，再设置自动更新、开机启动、覆写和 TUN，避免一次改变太多变量。
如果是独立运行内核，可以在终端执行以下命令查看版本。命令要求当前目录已有相应二进制文件；图形客户端用户不需要为了查版本额外安装另一份内核。
# Linux / macOS：在内核文件所在目录执行
./mihomo -v
# Windows PowerShell：在内核文件所在目录执行
.\mihomo.exe -v排错时记录实际输出，而不是只写“最新版”。还应同时记录系统版本、配置来源类型、接入方式和具体报错。对外分享日志前，移除订阅地址中的令牌、节点密码以及控制接口密钥。
常见问题：名称相近时怎么判断
安装了 mihomo，还需要客户端吗？
不一定。熟悉命令行和配置文件的用户可以直接运行内核，并自行管理启动与系统接入。希望通过界面导入订阅、切换策略和查看连接时，图形客户端更方便。二者是不同使用方式，不是必须叠加安装的两道步骤。
把内核换成 mihomo，旧配置就一定能用吗？
不能只凭继承关系保证。除了字段兼容，还要核对相对文件路径、规则文件格式、客户端覆写和权限。迁移后应检查实际加载日志与规则命中情况，不要仅以配置列表出现名称作为成功标志。
看到“Meta”旧名称，需要重新找一份订阅吗？
名称变化本身不要求更换订阅。只有现有订阅输出格式、协议或字段与当前内核不兼容时，才需要调整订阅输出或配置。应先核对具体错误，避免在不必要的转换过程中泄露订阅凭据。
怎样避免客户端与内核混淆？
保留一份简短记录：客户端完整名称与版本、内核名称与版本、配置类型、本地代理端口、系统代理或 TUN 状态。下次换软件或查日志时，这五项信息就能把“界面问题”“配置问题”和“网络接入问题”分开。
继续阅读时，可以用术语表核对代理组、Fake-IP 等概念，或在配置字段说明中查找具体参数。选客户端看平台与维护状态，排兼容问题看内核与实际配置，这两条线分开后，生态中的大多数名称就不容易混淆。