搜索 Clash 下载或配置教程时，经常会同时遇到 Clash、Clash Meta、Mihomo、Clash Verge Rev、FlClash 等名称。它们并不是同一个程序的不同版本，也不能简单理解为“新版”和“旧版”。这些项目分布在内核、图形客户端、配置文件、规则数据和订阅服务等不同层次，名称相近只是因为它们沿用了相同的配置与代理分流体系。
判断一个项目是否适合当前设备，不能只看名称里有没有 Clash。更可靠的方法是确认它使用什么内核、支持哪些配置字段、项目是否持续发布版本，以及图形界面是否能管理系统代理、TUN、DNS 和配置更新。把这些层次分开后，客户端迁移、订阅导入和配置排错会清晰很多。
先区分内核、客户端与配置数据
Clash 生态可以拆成三个主要层次：负责处理网络连接的内核、负责操作和展示的客户端，以及描述节点和分流逻辑的配置数据。多数使用问题都来自这三层之间的混淆。
内核负责实际代理与规则匹配
内核是代理程序的执行主体。它会打开本地监听端口，建立到代理服务器的连接，解析 DNS 设置，并按照规则列表选择策略组。系统代理、浏览器或其他应用把流量交给本地端口后，真正决定连接走向的是内核，而不是客户端界面的按钮样式。
原始 Clash 内核由 Go 编写，建立了后来广泛使用的 YAML 配置结构，包括代理节点、代理集合、策略组和规则等概念。原始项目停止活跃维护后，生态中的维护重点逐渐转向兼容分支。现在常见的 Mihomo 源自 Clash.Meta 分支，延续了大量 Clash 配置语法，并加入了更多 DNS、TUN、流量嗅探、规则数据和协议相关能力。
客户端提供图形界面和系统集成
客户端通常是桌面或移动端图形程序。它负责下载和切换配置、显示节点延迟、控制系统代理、申请 TUN 所需权限、启动内核并展示日志。客户端自身可以使用不同技术开发，例如原生界面、Web 技术桌面壳或跨平台工具包，这与它内部调用哪一种代理内核是两个问题。
部分客户端会把内核直接放在安装包中，升级客户端时同时更新内核；另一些客户端允许单独下载、切换或指定内核文件。因此，同名客户端的不同发行版也可能带有不同内核版本。排查配置字段不生效时，应先在“关于”“内核设置”或启动日志中查看实际内核名称和版本，而不是只看客户端名称。
配置、订阅和规则库不属于客户端本体
YAML 配置描述端口、节点、策略组、DNS 与规则。订阅链接则是配置数据的获取入口，返回内容可能是完整 Clash 配置，也可能只是节点列表，再由客户端或订阅转换服务生成策略组。GeoIP、GeoSite、MMDB 和规则集文件属于分流数据，它们可以被内核读取和更新，但不是内核程序本身。
这意味着更换图形客户端时，原订阅不一定失效；更换内核时，原配置也不一定能原样使用。能否迁移取决于订阅输出格式、配置中使用的扩展字段，以及目标内核对这些字段的支持情况。
Clash、Clash Meta 与 Mihomo 的维护关系
原始 Clash 奠定了配置模型和规则路由方式。随着原始项目不再持续发布，社区分支开始承担新协议适配、操作系统兼容和功能扩展。Clash.Meta 是其中影响较大的分支，之后以 Mihomo 名称继续维护。因而在当前生态里，“Clash 配置”常常指一种兼容格式，而不一定表示程序正在运行原始 Clash 内核。
分支并不只是改了项目名称。Mihomo 在经典配置基础上扩展了若干能力，而且不同时间发布的版本之间也可能调整字段、默认值和资源格式。某份配置能在 Mihomo 中加载，不代表较早的 Clash 内核也能识别全部内容。尤其是复杂 TUN 参数、增强 DNS 行为、流量嗅探、GeoSite 规则及特定代理协议，更容易遇到版本边界。
下面是一份只用于说明层级关系的简化配置。客户端读取文件后启动内核，内核监听本地端口，并把连接交给策略组和最终规则处理：
mixed-port: 7890
mode: rule
proxies: []
proxy-groups:
- name: 节点选择
type: select
proxies:
- DIRECT
rules:
- MATCH,节点选择实际订阅通常会增加节点定义、代理提供器、DNS、规则提供器和更完整的策略组。若出现“配置解析失败”，应根据日志定位具体字段，而不是直接删除整个配置段。YAML 对缩进敏感，字段支持情况还取决于内核类型与版本，两类问题需要分别判断。
如何确认项目仍在维护
项目名称中带有 Rev、Next、Meta 或 Community，并不能单独证明维护状态。确认维护情况时，建议查看最近正式版本、发布说明、代码提交、问题处理记录和支持的操作系统版本。对于只提供客户端安装包的项目，还应确认它打包的内核版本是否同步更新。
- 内核版本：在运行日志或客户端关于页面确认是 Mihomo、原始 Clash，还是其他兼容实现。
- 客户端版本：客户端版本与内核版本通常是两套编号，不能相互替代。
- 发布时间：连续的正式发布比项目名称中的“新版”字样更有参考价值。
- 平台支持：检查当前 Windows、macOS、Linux 或 Android 版本是否仍在支持范围内。
- 升级方式：确认内核随客户端升级，还是需要在设置中单独更新。
常见图形客户端处在生态的哪一层
Clash Verge Rev、Clash Nyanpasu、FlClash 等项目首先是图形客户端，它们通常围绕 Mihomo 或兼容内核提供配置管理和系统集成。它们之间的主要差别不是代理规则原理，而是支持平台、界面实现、内核管理方式、TUN 权限流程、配置覆写能力和更新节奏。
桌面客户端一般会提供系统代理开关、节点选择、连接记录、配置订阅更新和延迟测试。在 Windows 与 macOS 上，客户端还需要处理开机启动、系统代理恢复、管理员权限以及系统托盘行为。Linux 桌面环境较多，系统代理写入方式和托盘兼容性可能因发行版而异，因此同一客户端在不同桌面环境下的体验并不完全相同。
Android 客户端通常通过系统 VPN 接口接管流量，这种工作方式和桌面端勾选“系统代理”并不相同。移动端是否支持按应用分流、后台持续运行、IPv6 与私人 DNS，也取决于客户端实现和系统限制。不能因为桌面与移动客户端都使用 Mihomo，就推断所有界面功能和网络行为完全一致。
历史上常见的 Clash for Windows 属于桌面图形客户端，不等同于开源 Clash 内核；它已经停止维护。旧教程中围绕其界面编写的操作步骤，例如特定菜单名称、配置覆写入口或服务模式安装方式，不应直接套用到当前客户端。配置中的节点和规则可能仍可迁移，但界面设置需要在新客户端中重新确认。
选择客户端时应检查哪些边界
选择客户端的第一步是确定平台，而不是先比较界面。桌面端需要确认操作系统版本和处理器架构，例如 Windows x64、Windows ARM64、macOS Apple 芯片或 Intel 处理器。安装包架构不匹配时，程序可能无法启动，或者只能通过兼容层运行。
内核和配置兼容性
如果现有配置包含 Mihomo 扩展字段，应优先选择明确采用 Mihomo 且内核更新较及时的客户端。导入后先查看启动日志，确认配置解析成功，再测试策略组切换和 DNS。仅看到节点列表并不代表整份配置已经正确生效，因为客户端可能忽略了无法识别的覆写项，或者继续使用之前缓存的配置。
订阅兼容还要区分“完整配置订阅”和“节点订阅”。完整配置通常已经包含策略组与规则，导入后可以直接使用；节点订阅只提供服务器信息，需要客户端模板或本地配置补充分组与规则。两种链接即使都能导入，最终路由结果也可能明显不同。
系统代理与 TUN 模式
系统代理主要影响遵循操作系统代理设置的程序，例如多数浏览器和桌面应用。终端工具、游戏、虚拟机或自行实现网络栈的程序可能绕过系统代理。TUN 模式会创建虚拟网络接口并接管更广泛的流量，但通常需要管理员权限或系统 VPN 授权，还涉及路由、DNS 和防火墙兼容问题。
因此，支持 TUN 不应只理解为界面里有一个开关。还要检查客户端是否能正确安装服务、是否能在退出时恢复网络设置，以及当前操作系统是否允许相应权限。遇到开启 TUN 后断网，应先关闭 TUN 恢复基础连接，再检查内核日志、DNS 监听冲突、路由回环和其他 VPN 软件，而不是反复切换节点。
配置管理与更新机制
长期使用时，配置管理方式比一次导入是否成功更重要。需要观察客户端能否设置订阅更新间隔、保留本地覆写、切换多份配置，并在更新失败时继续使用上一份有效配置。部分客户端会在订阅更新后重新生成配置，本地直接修改的内容可能被覆盖，因此规则调整应放在客户端支持的覆写、合并或脚本机制中。
客户端自动更新和内核自动更新也应分开理解。界面程序更新成功，不一定表示内核已经更新；反之，单独替换内核后，客户端也可能因管理接口变化而出现兼容问题。稳定做法是使用客户端支持的更新渠道，并在升级前记录当前客户端版本、内核版本和有效配置。
从旧 Clash 客户端迁移到 Mihomo 客户端
迁移前应先保留原始订阅地址、当前使用的 YAML 文件、手工规则和策略组选择。只复制客户端安装目录并不可靠，因为不同程序存储配置的位置、文件名和数据库格式各不相同。更通用的迁移对象是订阅 URL 与可读的 YAML 配置。
- 记录现状：保存旧客户端和内核版本，记录本地监听端口、系统代理状态、TUN 状态及当前策略组选择。
- 导出配置：保存完整 YAML，并单独整理手工添加的规则、DNS 设置和配置覆写。
- 安装目标客户端：按操作系统和处理器架构选择安装包，首次启动时暂不启用 TUN。
- 导入订阅或文件：先验证配置能否加载，再检查节点、策略组和规则是否完整出现。
- 测试基础代理：开启系统代理，确认浏览器访问、DNS 解析和策略切换正常。
- 按需启用 TUN：基础代理稳定后再申请权限并测试终端、游戏或其他不遵循系统代理的程序。
- 清理旧设置：确认新客户端可用后，关闭旧客户端的开机启动和后台服务，避免两个程序同时占用端口。
迁移后最常见的冲突是本地端口重复。若旧程序仍在后台监听 7890、7891 或其他配置端口，新内核会启动失败。另一类问题是系统代理仍指向旧端口，即使新客户端已经运行，浏览器也无法连接。此时应以新客户端日志显示的监听地址为准，重新写入系统代理设置。
如果旧配置使用的是经典 Clash 字段，而目标客户端采用 Mihomo，通常可以先直接导入，再根据日志处理差异。反方向迁移则需要更谨慎：Mihomo 扩展字段可能无法被旧内核识别。遇到未知字段时，应查明该字段控制的功能，再决定采用目标内核支持的等价写法，而不是机械删除。
通过日志确认正在运行的项目
客户端名称可能沿用 Clash，但启动日志通常会给出更直接的信息。排查时应关注内核名称、版本号、配置文件路径、本地监听端口、外部控制端口、TUN 初始化结果和配置解析错误。日志中的客户端版本只能说明界面程序版本，真正决定规则与协议能力的是内核版本。
还可以通过进程列表观察实际启动的可执行文件。常见客户端会启动一个界面进程和一个内核进程；启用服务模式后，内核也可能由系统服务管理。不要在客户端运行期间手动启动第二个相同内核，否则容易出现监听端口冲突、配置文件竞争或系统代理状态不一致。
当节点能连接但规则不符合预期时，应查看连接记录中的目标域名、命中规则和最终策略组。若连接记录中只出现 IP，可能与 DNS 解析方式或流量嗅探设置有关；若始终命中 MATCH，则应检查规则顺序和规则集加载状态。规则按照从上到下的顺序匹配，先命中的结果会被采用，客户端界面中的组名只是配置关系的展示。
项目选型结论
Clash 是生态起点和配置体系名称，Mihomo 是由 Clash.Meta 延续而来的活跃兼容内核，Clash Verge Rev、Clash Nyanpasu、FlClash 等则属于调用内核并完成系统集成的图形客户端。订阅、YAML 配置、GeoIP、GeoSite 和规则集是数据层，它们可以跨客户端使用，但兼容范围受内核版本与配置扩展影响。
实际选型时，应依次确认平台与架构、客户端维护状态、内核类型、配置兼容性、系统代理与 TUN 需求。迁移旧客户端时，重点保留订阅和可读配置，并通过日志核对真实运行的内核。只要把界面、内核和数据分开判断，就能避免因相似名称造成错误下载、配置不兼容或排障方向偏差。