Clash 开源生态梳理：mihomo 内核与各 Mac 客户端的关系

Clash 生态的三层结构

搜索 Mac 上的 Clash，会同时看到 mihomo、Clash Meta、ClashX Meta、Clash Verge Rev 等名称。它们并不处在同一层：有的负责处理网络流量，有的提供设置窗口，有的只提供域名与 IP 规则。选型前先分层，才能判断应该更换客户端、升级内核，还是调整配置。

层级	主要职责	检查位置
代理内核	建立代理连接，执行 DNS、规则匹配与策略组选择	内核信息、启动日志、运行配置
图形客户端	管理订阅、切换配置、设置系统代理、展示连接	客户端设置、订阅管理、服务管理
规则与配置	提供匹配条件、节点定义和流量出口关系	YAML、规则提供者、订阅内容

实际链路通常是“应用流量 → 系统代理或 TUN → 内核 → 规则与策略组 → 出口”。图形窗口负责控制这条链路，但窗口本身不是代理协议实现。同一个内核放进不同客户端，设置入口、订阅覆写方式和权限管理仍可能不同。

原版 Clash、Clash Meta 与 mihomo

原版内核与衍生项目

原版 Clash 的公开项目在 2023 年停止公开维护。历史资料还会提到 Clash Premium，它与原版开源内核不是完全相同的功能集合。旧教程里标注为 Premium 的能力，不能只凭“Clash”这个名称判断当前内核是否支持。

Clash Meta 是基于 Clash 发展而来的分支，后来采用 mihomo 名称。因此，配置说明中的“Meta 内核”与项目文档中的“mihomo”，经常指向同一条技术演进路线。“Meta”字样也可能保留在旧客户端名称中，不能据此推断其中打包的内核新旧。

名称相近不代表字段通用

mihomo 延续了大量 Clash YAML 配置习惯，例如 proxies、proxy-groups、rules，并扩展了协议与规则能力。这种兼容性有方向：常见基础配置可能继续可用，使用 mihomo 扩展字段的配置却不一定能交给旧内核运行。

订阅导入失败，先看日志是否提示未知代理类型、无效字段或策略组引用不存在。
配置加载成功，只说明通过了当前阶段的解析，仍需确认实际请求匹配的规则与出口。
需要特定协议、规则格式或 TUN 功能时，以所用内核的文档和实际构建为准。

不要把“更换 GUI”当作必然的功能升级。新装客户端如果采用不同内核，或者保留了旧运行配置，仍可能遇到相同问题。诊断时应分别记录客户端名称、内核名称和配置来源。

Mac 图形客户端的职责边界

ClashX Meta、Clash Verge Rev、FlClash 等项目都提供过面向 macOS 的图形使用方式，但交互重点和配置管理模型并不相同。下表用于理解分工，不作为实时维护状态或完整功能清单；安装前仍应检查各项目的发布说明与系统要求。

客户端方向	典型使用方式	选型时核对
ClashX Meta	以 macOS 菜单栏操作管理代理与配置	随包内核、配置入口、权限安装方式
Clash Verge Rev	在独立窗口中管理订阅、连接与运行设置	覆写机制、服务模式、内核设置
FlClash	通过跨平台图形界面管理 mihomo 配置	macOS 构建要求、配置管理与 TUN 入口

系统代理属于客户端与系统的配合

macOS 的系统代理通常把支持该设置的应用引向本地监听端口。以 macOS Ventura 及之后的界面为例，可到「系统设置」→「网络」→当前网络服务→「详细信息」→「代理」检查 HTTP、HTTPS 与 SOCKS 项。端口应与内核实际监听值对应，不能照抄另一台设备的设置。

例如内核设置了 mixed-port: 7890，本机代理地址可以指向 127.0.0.1:7890。这里的 7890 是示例，不代表每个客户端的默认值。终端工具是否使用系统代理还取决于工具自身，不能仅用浏览器访问结果判断终端链路。

TUN 需要内核能力与系统权限

TUN 通过虚拟网络接口接收被路由过来的 IP 流量，覆盖范围与系统代理不同。在 Mac 上，客户端还需完成权限授权、路由配置与 DNS 配合。内核支持 TUN，不等于每个 GUI 都提供相同的开关、服务安装流程或故障恢复入口。

订阅、规则集与策略组的连接方式

订阅链接是配置的分发入口，不是一种固定内容格式。它可能返回完整 YAML、节点提供者内容，或需要转换的其他订阅格式。客户端能识别某条订阅，不代表另一款客户端也能以相同方式导入。

节点提供者proxy-providers: 从文件或远程来源加载节点集合，供策略组引用。节点如何连接由协议参数决定。
规则提供者rule-providers: 加载一组匹配条件。规则负责判断请求特征，本身不提供代理节点。
策略组proxy-groups: 组织节点或其他策略组，提供手动选择、自动测试或故障切换等出口选择方式。

例如，一个域名规则集收录了工作服务的域名，RULE-SET 把命中的请求交给“工作出口”策略组，策略组再决定使用哪个节点。下载规则集不会自动获得代理线路；只有规则、没有对应策略组或节点，链路仍不完整。

规则集格式必须配对

在 mihomo 中，规则提供者常见的 behavior 包括 domain、ipcidr、classical。域名列表、IP 网段列表与带规则类型的列表不能随意混用。format 则描述 YAML、文本或 MRS 等存储格式；MRS 支持的行为类型也有约束，应按所用内核文档核对。

先查看规则仓库的文件内容和使用说明，再填写提供者字段。
规则仓库里的分类名称只是组织方式，不保证符合个人使用场景。
规则按顺序匹配；前面的宽泛规则可能让后面的细分规则没有机会命中。
最后的 MATCH 决定未命中前序规则的请求去向，应明确指定目标。

一份配置看清内核与客户端的分工

下面是一份用于本机验证的最小结构示例。它只使用 DIRECT，不会建立远程代理连接，适合观察监听端口、策略组和规则之间的关系。需要远程出口时，应通过可信配置补充真实节点，避免把示例当作可用订阅。

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

proxy-groups:
  - name: 手动出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手动出口
  - MATCH,DIRECT

mixed-port 由内核监听，用同一端口接收 HTTP 与 SOCKS 代理请求；它不会自行修改 macOS 系统代理。
allow-lan: false 用于限制局域网访问代理入口；若确需共享，还要一起核对监听地址与防火墙。
mode: rule 表示按规则选择出口；客户端切换模式后，实际运行状态可能与原始文件不同。
“手动出口”是策略组名称。规则引用必须与名称一致，否则配置可能无法加载。
MATCH,DIRECT 是兜底规则；这里将其余请求直连，并不是通用的远程代理方案。

客户端可能在启动前合并订阅、本地覆写和界面设置，所以“下载的 YAML”与“内核最终收到的 YAML”可以不同。排错时优先寻找客户端的运行配置预览或导出入口，再对照日志，而不是只检查订阅原文。字段含义可继续查阅YAML 配置手册。

Mac 客户端选型与迁移检查

按实际任务选择

主要使用浏览器：先验证系统代理、配置切换和退出后的代理恢复，未必需要开启 TUN。
命令行与开发工具较多：检查工具的代理参数、环境变量支持，再决定是否需要 TUN 统一接管。
多份订阅与复杂分流：重点检查本地覆写、规则提供者管理、运行配置查看与日志筛选能力。
偏好菜单栏操作：确认常用策略组和配置能否直接切换，同时保留查看内核信息的途径。

迁移按四步验证

备份原配置与本地改动。记录规则顺序、策略组选择、端口和 DNS 设置；分享诊断材料时移除订阅令牌与节点凭据。
核对架构与系统要求。在苹果菜单的「关于本机」查看芯片与 macOS 信息，按项目提供的 Apple Silicon、Intel 或通用构建选择安装包。
避免两个内核争用入口。先退出旧客户端并关闭其系统代理或 TUN，再启动新客户端。若日志显示地址已被占用，检查旧进程是否仍在监听。
先基础后增强。先验证配置加载与系统代理，再启用 TUN、DNS 覆写和自动更新；每次只改一类设置，保留可回退的配置。

订阅更新会替换哪些内容，取决于客户端的配置管理方式。直接修改下载文件，可能在下一次更新时丢失；更适合长期保留的本地规则应放到客户端明确支持的覆写层，并检查合并顺序。

开源项目来源与故障归属

开源仓库、客户端安装包和订阅服务是三种独立来源。能查看内核源码，不代表某个同名安装包就来自该项目；订阅能正常导入，也不代表其提供者与客户端开发者存在关系。下载时应核对项目组织、仓库链接、发布说明及安装包对应的操作系统。

现象	优先检查	提交问题时附带
窗口无法打开或订阅按钮报错	客户端界面与配置管理层	系统信息、操作步骤、脱敏错误信息
未知协议或配置解析失败	内核支持范围与配置格式	内核信息、最小配置、启动日志
特定域名走错出口	规则顺序、DNS 解析与策略组	命中规则、目标地址、所选出口
只有某个节点连接失败	节点参数、远端服务与线路	错误类型、连接时间、脱敏节点类型

最小复现比整份配置更有用。先保留一个策略组和必要规则，去掉无关覆写后重试。公开日志前检查其中是否包含订阅链接、认证信息、局域网地址或访问记录；这些内容通常不需要完整公开。

最终的选择应落在三个问题上：内核能否处理所需协议与规则，客户端能否稳定管理这份配置，macOS 是否已按预期交出流量。把三层分别验证，比只比较客户端名称更容易得到可复用的配置方案。