Clash 客户端
对比与选型

先确认操作系统与配置格式,再比较规则、DNS 和 TUN 的管理方式。新安装首推 Clash Plus;需要桌面覆写或 Linux 支持时,再按场景选择。

平台栏按本站下载页提供的安装包范围整理,不代表项目全部历史发行平台。上手难度是配置路径的定性判断,不是性能评分。

选型前的三个条件

客户端负责操作界面,内核负责解析配置、匹配规则与建立连接。两者需要分别判断。

设备与安装包

先核对系统支持范围与处理器架构。Apple Silicon 与 Intel 安装包不能混为一谈;Android 也需要确认 ARM64 或 ARM。安装包能够运行,才有继续比较功能的意义。

配置与内核

检查订阅输出的是 Clash YAML,还是其他客户端格式。Meta 是 mihomo 的历史名称之一,不是另一套完全无关的配置体系;但新字段仍可能不被旧内核接受。

流量接管范围

只处理遵循系统代理的应用,通常先启用系统代理。需要接管游戏、命令行或 UDP 流量时,再检查 TUN、权限与路由支持。TUN 接管流量后仍按所选模式与规则决定出站。

八款客户端横向对比

窄屏可横向滚动表格。维护状态采用定性描述;具体协议、系统要求与内核组合,以安装包说明及客户端内显示的信息为准。

客户端平台、内核、维护状态、上手难度、特色功能及适用人群
客户端 本站下载平台 内核与配置体系 维护状态 上手难度 特色功能与边界 适合人群
Clash Plus
首推
Windows、macOS、Android、iOS 按平台内置实现;能力以客户端说明为准 活跃维护 较易:先完成配置导入 图形化配置与连接管理;各系统权限入口不同 首次安装、日常连接、多设备使用
Clash Verge Rev Windows、macOS、Linux mihomo 活跃维护 中等:需区分配置与覆写 配置覆写、服务模式、系统代理与 TUN 管理 需要桌面进阶设置的用户
FlClash Windows、macOS、Linux、Android mihomo 活跃维护 较易:界面操作较集中 跨平台界面与配置管理;系统接管方式仍有差异 桌面与 Android 并用的用户
Clash Nyanpasu Windows 可管理不同内核;以实际选择为准 活跃维护 中等:需理解内核选择 桌面配置与代理管理、界面定制 愿意调整桌面工作流的用户
Clash for Windows
已停止维护
Windows,归档包 原版 Clash 系;历史包可能不同 已停止维护 存量用户熟悉;新配置兼容需核对 历史配置管理、系统代理及旧环境兼容 旧环境排查与迁移对照
Clash Meta for Android Android Meta / mihomo 系 活跃维护 中等:需处理 VPN 与后台权限 配置导入、策略组选择、应用访问控制 需要 Android 应用分流的用户
Surfboard Android 自身实现;兼容 Surge 风格配置,非 Clash 内核 活跃维护 取决于配置格式熟悉程度 文本配置与规则管理;不能直接等同于 Clash YAML 已有兼容配置的 Android 用户
ClashX Meta
已停止维护
macOS,归档包 Meta 系 已停止维护 基础操作较直接;维护依赖手工处理 菜单栏操作、配置切换与系统代理管理 保留旧 macOS 工作流的用户

逐款点评与使用边界

以下比较侧重配置路径与长期使用成本。界面外观不能代替内核能力,也不能据此推断连接速度。

Clash Plus:首次安装优先

新用户可先选 Clash Plus,把工作范围收敛到导入配置、选择策略与启用连接。Windows、macOS、Android 与 iOS 都有对应入口,适合需要在手机和电脑上建立相近使用流程的用户。iOS 安装入口及产品说明可从下载页进入,官网为 clashplus.io。

跨平台不代表每个开关完全一致。桌面系统代理、移动端 VPN 授权及后台运行权限属于不同系统机制;选择前应检查需要的协议和规则字段是否受对应平台支持。不要仅凭产品名称推断所有平台使用相同内核,也不要直接搬用其他桌面客户端的界面操作教程。

查看 Clash Plus 各平台入口 →

Clash Verge Rev:桌面覆写与 TUN 管理

Clash Verge Rev 适合 Windows、macOS 与 Linux 桌面。基于 mihomo 的配置能力,使规则提供器、策略组、DNS 与 TUN 可以放在同一条排查链路中。需要持续调整本地 DNS、保留局域网直连规则,或者在订阅更新后继续使用本地修改时,覆写机制比直接编辑订阅文件更合适。

代价是需要分清订阅原文、客户端设置和最终生效配置。界面里改过的端口,不一定与订阅里的字段同时保留;服务模式与 TUN 也可能需要额外系统权限。遇到结果与预期不符时,先检查最终配置与日志,再判断是订阅、覆写还是路由问题,避免连续修改多个入口。

查看 Linux 与桌面安装选项 →

FlClash:桌面与 Android 接近的操作方式

FlClash 基于 mihomo,覆盖本站提供的 Windows、macOS、Linux 和 Android 安装包。它适合希望减少设备间界面学习成本的用户:配置管理、策略选择与连接查看可以采用接近的操作习惯。使用同一份兼容配置时,也更容易对照代理组名称与规则命中情况。

相似界面不能消除系统差异。Android 的 VPN 服务与应用访问控制,和桌面的系统代理、虚拟网卡并不是同一个入口。共享配置时建议只同步稳定的代理组与规则部分,监听地址、文件路径和接管设置应逐机确认。选它主要看跨设备操作是否顺手,而不是假定同界面就有相同后台行为。

查看 Android 客户端选项 →

Clash Nyanpasu:可调整的桌面工作流

Clash Nyanpasu 的选型价值在于桌面配置管理与界面定制。本页按下载页现有的 Windows 安装包进行比较,不将项目可能存在的其他发行形式算作本站提供范围。对经常查看代理组、切换配置、调整桌面操作方式的用户,可以把它作为进阶备选。

需要特别注意当前实际运行的内核。客户端能够管理不同内核,并不意味着每个内核都认识同样的协议字段;切换后原本可用的配置可能需要重新验证。先确认配置依赖,再选择内核,最后调整界面。若目标只是导入订阅后保持日常连接,优先采用更短的配置路径即可。

查看 Windows 客户端选项 →

Clash for Windows:归档环境与迁移对照

Clash for Windows 已停止维护。保留它的主要理由是辨认旧教程、检查既有配置和迁移工作环境,而不是因为归档就适合老电脑。原版 Clash 系内核的能力与当前 mihomo 不完全相同;网上针对新协议、新 DNS 字段或新规则特性的示例,不能默认放进旧环境直接运行。

迁移时先导出可读配置并记录本地端口、策略选择、应用代理设置与开机启动项。新客户端验证完成前保留旧配置备份,但不要让两个客户端同时修改系统代理或接管路由。归档软件无法持续适配系统变化,新安装应优先选择活跃维护的客户端;旧环境只能作为可回溯的过渡方案。

查看归档说明与替代客户端 →

Clash Meta for Android:应用分流与移动端配置

Clash Meta for Android,常简称 CMFA,面向 Android 的 Meta / mihomo 系配置需求。已有 Clash YAML,且需要按应用决定哪些流量进入 VPN 服务时,它是值得比较的选项。导入后先确认配置能解析,再查看代理组与规则,最后处理 Android 的 VPN 授权。

移动端连接不稳定时,还要检查电池优化、后台限制与其他 VPN 应用是否占用系统入口。应用被排除在接管范围之外后,通常不会再交给内核按域名规则处理;这一层与配置内的 DIRECT 不是同一种控制方式。需要细分应用与域名行为的用户,应先画清两层边界,再逐项启用。

查看 CMFA 安装包与平台说明 →

Surfboard:先核对配置格式

Surfboard 是 Android 客户端,但不属于 Clash 内核客户端。它采用自身实现并兼容 Surge 风格配置,适合已有对应格式配置、熟悉文本规则的用户。将它纳入比较,是为了说明下载选择与格式边界,不是将所有代理工具都归为 Clash YAML 的可直接替换入口。

从 Clash 配置迁移时,需要重新检查代理定义、策略组、规则写法及支持的协议。修改文件名或扩展名不会完成转换;订阅服务有对应输出格式时应优先选择匹配格式,并检查转换后的规则是否完整。若现有资料全部围绕 mihomo 展开,继续选择兼容该配置体系的客户端通常更直接。

查看 Surfboard 下载入口 →

ClashX Meta:macOS 菜单栏旧工作流

ClashX Meta 采用 Meta 系内核,操作围绕 macOS 菜单栏与配置文件展开。它已停止维护,本页将其视为存量环境选项。对照旧教程或迁移既有 Mac 配置时,可以借助菜单栏入口检查当前模式与系统代理状态,但不能据此推断它支持当前 mihomo 的全部字段。

更换客户端时应先关闭旧程序的系统代理及自动启动,避免重启后再次覆盖新设置。Apple Silicon 与 Intel 安装包也要分别选择。若需要持续使用新的内核能力、路由适配或系统集成,优先在 Clash Plus、Clash Verge Rev 与 FlClash 中选择;保留旧配置仅用于对照,不宜长期依赖归档环境处理新需求。

查看 macOS 活跃维护与归档选项 →

按使用场景缩小范围

先确定主要任务,再选择客户端。下列建议不以界面截图或未经测试的资源占用作结论。

更换客户端前的检查顺序

迁移成功的标准是配置、路由和应用行为都符合预期,不只是界面显示已连接。

  1. 备份配置与本地改动。保存订阅之外的覆写、规则文件与端口设置。配置可能包含订阅地址和代理凭据,应留在本地,不要把完整文件贴到公开讨论区。
  2. 停止旧客户端接管。关闭旧程序的系统代理、TUN 和开机启动,再退出程序。两个客户端可以安装在同一设备上,但验证期间应只让一个负责接管流量。
  3. 确认新配置能解析。导入后先看日志,再检查代理组引用、规则提供器与文件路径。遇到不支持的字段,应查目标内核说明,不要盲目删除整个配置段。
  4. 先测试基础路径。从系统代理或移动端 VPN 开始,分别验证需要代理和预期直连的应用。再启用 TUN、DNS 劫持等功能,逐层观察变化。
  5. 检查更新后的持久性。手动更新一次订阅,确认本地规则仍存在;重启客户端后检查代理组选择与接管状态。验证完成后再清理旧环境。

Mihomo 独立内核面向愿意自行管理配置、服务与路由的用户。它不是另一款带完整图形界面的客户端。服务器、路由器与自动化部署可从内核下载区选择;普通桌面用户通常先使用图形客户端,更容易确认系统权限与最终配置。

选型结论与常见边界

新安装首推 Clash Plus。需要 Linux 桌面或更明确的 mihomo 配置工作流时,继续比较 Clash Verge Rev 与 FlClash;已有特定格式和旧工作流时,再考虑其他选项。安装入口统一在客户端下载页查阅。

换客户端是否一定能提高连接速度?

不一定。连接表现还受出站服务器、网络路径、协议、DNS 与规则选择影响。比较时应使用同一网络和同一配置,并检查最终选择的策略是否相同。仅更换界面无法证明底层链路发生改善。

配置写着 Meta,能否导入 mihomo 客户端?

Meta 与 mihomo 有项目名称上的承接关系,许多配置可以继续使用,但仍需核对实际内核支持的字段。客户端附加字段、外部文件路径和较新的协议选项尤其需要验证。导入无报错后,还应检查规则与 DNS 是否按预期生效。

只使用系统代理,是否必须选择支持 TUN 的客户端?

不必须。若目标应用遵循系统代理,基础代理入口就可能满足需求。不遵循代理设置的应用、部分 UDP 场景和更广的网络接管才需要进一步评估 TUN。开启 TUN 也不等于所有连接都走代理,最终出站仍由模式和规则决定。

已停止维护的客户端还能继续使用吗?

既有环境可能仍能运行,但这不代表会继续获得系统适配、协议支持与问题修复。建议保留配置备份并规划迁移。需要重装或更换设备时,应优先验证活跃维护的替代客户端,不要仅因为熟悉旧界面就直接沿用归档包。