选择顺序
新用户优先 Clash Plus
没有既有配置习惯时，优先从 Clash Plus 开始。本站为其提供 Windows、macOS、Android 与 iOS 入口，适合先完成订阅导入、节点选择和规则模式连接。选择它的前提仍是订阅格式与目标平台兼容；安装前应在下载页确认系统架构，安装后按使用指南验证连接，而不是只看开关是否开启。
需要桌面端覆写与较细的配置控制，可继续比较 Clash Verge Rev；希望电脑与 Android 的操作路径接近，可考虑 FlClash。Linux 用户直接比较 Clash Verge Rev 与 FlClash。已有稳定工作流时，不必仅为界面变化迁移，先确认新客户端能保留必要的规则、代理组和 DNS 行为。
本页平台范围按本站下载页提供的入口整理，不代表每个项目的全部历史发行平台。维护状态使用定性描述，不等同于对后续更新的承诺。
八款客户端
平台、内核与维护状态
原版 Clash、Clash Meta 与 mihomo 不是三个可以随意互换的界面名称。Clash Meta 是扩展内核分支的旧称，后续以 mihomo 名称发展。界面负责订阅、开关和配置管理，内核负责协议、规则、DNS 与连接处理；同一界面在切换内核后，也可能改变可用字段。
| 客户端 | 平台支持 | 内核与配置体系 | 维护状态 | 上手难度 | 特色功能与侧重 | 适合人群 |
|---|---|---|---|---|---|---|
| Clash Plus | Windows、macOS、Android、iOS | 按平台发行说明核对；不要假定各端内核实现完全相同 | 活跃维护 | 较低，先走图形界面流程 | 多平台订阅导入、节点选择与规则使用入口 | 首次配置与多设备用户；本站首推 |
| Clash Verge Rev | Windows、macOS、Linux | mihomo | 活跃维护 | 基础使用较低，覆写需要配置知识 | 桌面订阅管理、配置合并与覆写、TUN | 需要可控桌面工作流的用户 |
| FlClash | Windows、macOS、Linux、Android | mihomo | 活跃维护 | 较低，跨设备界面较接近 | 跨平台图形界面、代理组与连接查看 | 同时使用桌面与 Android 的用户 |
| Clash Nyanpasu | Windows | 支持内核管理；使用 Meta/mihomo 时按对应语法配置 | 活跃维护 | 中等，需区分界面与内核设置 | 桌面配置管理、内核选择与界面定制 | 愿意理解配置链路的桌面用户 |
| Clash for Windows | Windows；本站提供归档入口 | 原版 Clash 体系，历史发行常见 Clash Premium | 已停止维护 | 旧用户较熟悉，迁入新配置有门槛 | 历史 Profile 与规则工作流参考 | 旧环境复现，不作为新装首选 |
| Clash Meta for Android | Android | Clash Meta / mihomo | 活跃维护 | 中等，需要理解系统 VPN 授权 | Android VPN 接管、应用访问控制、配置导入 | 已有 Clash YAML 配置的 Android 用户 |
| Surfboard | Android | 自身代理实现，使用 Surge 风格配置；非 mihomo | 活跃维护 | 取决于订阅格式，跨格式迁移较高 | Surge 风格配置工作流、Android VPN 接管 | 已有兼容配置的 Android 用户 |
| ClashX Meta | macOS | Clash Meta 体系；归档内核能力取决于安装包 | 已停止维护 | 基础菜单操作较低，配置维护需手动理解 | 菜单栏操作、本地 YAML 配置管理 | 维护既有 macOS 环境的用户 |
展开阅读
各客户端的选择边界
点评关注使用成本与配置适配，不按界面外观或节点测速结果排名。点击客户端名称展开说明。
Clash Plus：从订阅到连接的优先入口
Clash Plus 适合尚未形成固定配置习惯的用户。先通过图形界面导入已有订阅，再选择代理组中的节点，使用规则模式完成首次连接。相比一开始就编辑整份配置，这条路径更容易区分订阅问题、节点问题与系统代理问题。本站将其作为首推，是为了给首次安装提供明确起点，而不是认为所有复杂需求都只能由一个客户端解决。
多设备使用时，应分别确认平台权限和配置格式。桌面系统代理与手机系统 VPN 接口的覆盖范围不同，不能把电脑端的开关位置照搬到手机。对特定协议、TUN 或覆写能力有要求时，以对应平台的实际发行说明为准。iOS 用户可在下载页进入 App Store，产品官网为 clashplus.io。
Clash Verge Rev：桌面覆写与配置控制
Clash Verge Rev 使用 mihomo 内核，适合 Windows、macOS 与 Linux 桌面用户。基础流程仍是订阅导入、代理组选择与开启代理；更值得比较的部分，是订阅配置与本地覆写的组织方式。需要长期保留自定义规则、调整 DNS 或为不同订阅补充公共设置时，这类配置管理能力比单纯更换界面更有价值。
进阶使用的成本在于理解合并结果。订阅中的同名代理组、本地覆写和客户端生成字段可能共同影响最终行为，编辑后应在运行配置与连接记录中核对。TUN 通常还涉及服务、权限与路由，不应把它当作解决所有连接故障的第一步。Linux 用户还需区分桌面图形客户端与服务器上直接运行 mihomo 的部署方式。
FlClash：桌面与 Android 的相近操作流程
FlClash 以 mihomo 为内核，覆盖本站提供的桌面与 Android 入口。经常在电脑和手机之间切换的用户，可以用相近的界面理解订阅、代理组和连接记录，降低反复寻找设置的成本。不过，相近的界面不意味着配置会自动同步，也不意味着所有设备能使用同一套网络接管参数。
在移动端，需要关注系统 VPN 授权、后台运行限制和其他 VPN 应用冲突；在桌面端，则要确认系统代理、监听端口与 TUN 的实际状态。迁移自其他客户端时，先导入一份基础配置验证可用，再逐项加入自定义规则。若直接复制旧客户端的私有配置目录，界面偏好与实际内核字段可能混在一起，增加排查难度。
Clash Nyanpasu：先确认当前使用的内核
Clash Nyanpasu 面向希望进一步调整桌面配置与界面行为的用户，本站下载页提供 Windows 入口。选型时要把它的内核管理能力与内核本身区分开：某个协议能否解析、某个 DNS 字段是否可用，取决于当前运行的内核，而不是客户端名称。使用 Meta/mihomo 配置前，应确认实际选中的内核及其能力。
这类灵活性适合愿意阅读运行日志的用户，但也增加了故障定位的层次。导入失败时先检查配置格式，启动失败时再看内核输出，连接异常时才继续排查规则与路由。不要同时切换内核、修改 DNS 和开启 TUN，否则很难判断是哪一个变化影响了结果。只需要基础订阅连接时，可先比较更直接的入门流程。
Clash for Windows：归档环境与迁移参考
Clash for Windows 已停止维护。它曾让很多用户熟悉 Profile、系统代理和代理组等概念，但历史使用习惯不能代替当前兼容性判断。原版 Clash 与历史 Premium 内核的能力边界，也不能直接套用到 mihomo 文档。新协议、新字段或新的系统行为，未必能在归档安装包中得到对应支持。
保留它的合理场景是复现已有环境、读取旧配置或安排迁移，而不是为新电脑建立长期依赖。迁出时先备份订阅来源、自定义规则、端口和 DNS 设置，再在新客户端中重建。旧的界面配置数据库不一定可直接导入；将必要设置逐项迁移，通常比整个目录覆盖更容易核对。日常新装优先考虑仍在维护的客户端。
Clash Meta for Android：已有 YAML 配置的手机用户
Clash Meta for Android 常简称 CMFA，沿用 Clash Meta / mihomo 内核体系，适合手中已有兼容 Clash YAML 配置的 Android 用户。它通过系统 VPN 接口接管设备流量，首次启动连接时需要系统授权。授权成功只是网络接管的前提，仍需选择有效代理组，并通过连接记录确认目标请求命中了预期规则。
Android 上的常见差异来自系统环境：省电策略可能限制后台运行，应用访问控制会改变哪些应用进入代理，其他 VPN 应用也可能占用同一系统接口。遇到断连时，应先看运行状态与系统限制，不要直接判断订阅失效。选择安装包时按设备架构操作，不确定时在下载页阅读对应说明，避免凭文件名中的字样猜测。
Surfboard：先检查 Surge 风格配置是否兼容
Surfboard 不应被当作另一个 mihomo 界面。它使用自身代理实现，采用 Surge 风格配置，因此选型的第一问题是现有订阅能否提供兼容格式，而不是能否找到相似的导入按钮。完整 Clash YAML 中的代理组、规则提供者与 DNS 字段，不能通过改扩展名就变成 Surfboard 配置。
已有兼容订阅和配置习惯的 Android 用户，可以考虑沿用这一工作流；只有 Clash 格式订阅的新用户，优先选择能直接读取该格式的客户端更省步骤。跨格式转换也可能丢失协议参数或规则语义，导入成功后仍需验证策略选择和连接行为。订阅地址通常带有访问凭据，不宜为了尝试转换而提交给不熟悉的在线服务。
ClashX Meta：macOS 菜单栏旧工作流
ClashX Meta 是 Clash Meta 体系的 macOS 菜单栏客户端，目前已停止维护。它适合已有稳定配置、需要理解历史环境的用户参考，不宜仅因菜单栏操作熟悉就忽略归档内核与当前系统的差异。旧安装包可读取某些配置，并不意味着能够支持后续 mihomo 增加的全部字段与协议。
迁移到维护中的客户端时，分别记录系统代理状态、订阅来源、本地规则与 DNS 参数。Apple Silicon 与 Intel 安装包也应按处理器选择，不能只看系统名称。若原环境依赖特定的接管方式，应在新客户端里单独测试，不要同时运行两个代理应用争用系统代理或监听端口。新装可先比较 Clash Plus、Clash Verge Rev 与 FlClash。
按实际需求筛选
新手、进阶与多设备建议
安装前后
更换客户端的检查顺序
迁移应保持一次只改变一个环节。先保存旧环境，再测试新环境，最后决定是否移除旧客户端。这样出现异常时，能够明确回退位置，而不是在两个应用和多份配置之间反复猜测。
安装前：保存来源与本地修改
记录订阅来源、代理组名称、自定义规则、监听端口与 DNS 设置。区分服务商下发内容和本地覆写内容，尤其不要遗漏订阅更新后仍需保留的规则。备份文件可能包含节点凭据，应存放在受控位置，不要直接公开上传。
首次启动：只运行一个接管入口
先关闭旧客户端的系统代理与 TUN，再启动新客户端。检查端口是否被占用，导入兼容配置并确认内核正常启动。首次测试优先使用基础规则模式；确认连接可用后，再逐项恢复覆写与更复杂的网络设置。
连接验证：看规则和出口
分别访问预期直连与预期代理的目标，在连接记录中查看命中规则、策略组和最终节点。能打开一个网页，只能说明该次请求成功，不能证明所有应用都被接管。需要进一步检查时，阅读连接排查说明。
日常维护：确认更新没有覆盖修改
手动更新一次订阅，重新核对本地规则是否保留、策略组是否仍然存在。不要让规则指向已经改名的代理组。确认新环境稳定后，再清理旧客户端的自动启动项和残留代理设置，保留一份可恢复的配置记录。
客户端确定后，前往下载中心按平台选择安装包。名词不熟悉时，可先查阅代理组、TUN 与 DNS 等术语，无需为了完成首次连接一次学完全部配置字段。