CLIENT SELECTION / 客户端选型
先确认设备系统，再比较订阅格式、流量接管方式和本地覆写。客户端界面相似，不代表运行时配置与系统权限完全一致。
没有现成的复杂配置时，优先从 Clash Plus 开始。它覆盖 Windows、macOS、Android 与 iOS，可减少跨设备寻找客户端的步骤。官网为 clashplus.io；具体安装入口集中在本站下载中心。
需要 Linux 桌面、长期维护 Merge 覆写，或经常按连接与日志定位问题时，Clash Verge Rev 更适合作为重点比较对象。多设备用户也可以选择 FlClash；已有特定配置格式的用户，则应先检查格式兼容性，不必为统一名称强行迁移。
按平台查看客户端与安装选项 →平台列表示本站提供下载入口的范围，不是项目全部历史构建的列表。维护状态为定性选型参考，不代表所有平台构建同时更新；安装前仍需查看项目公告与系统要求。
| 客户端 | 本站下载平台 | 内核与配置路线 | 维护状态 | 上手难度 | 特色功能 | 适合人群 |
|---|---|---|---|---|---|---|
| Clash Plus | Windows、macOS、Android、iOS | Clash 生态；各平台内核与协议支持以应用说明为准 | 活跃维护 | 较低，先完成订阅导入 | 跨桌面与移动平台的客户端入口 | 首次配置、日常使用、多设备用户 |
| Clash Verge Rev | Windows、macOS、Linux | Mihomo，延续 Clash Meta 路线 | 活跃维护 | 基础使用较低，覆写需要 YAML 知识 | Merge 覆写、扩展脚本、TUN、连接与日志 | 桌面进阶配置、规则与 DNS 调整 |
| FlClash | Windows、macOS、Linux、Android | Mihomo | 活跃维护 | 较低，进阶配置需理解内核字段 | 跨平台界面、配置管理、代理组切换 | 桌面与 Android 并用的用户 |
| Clash Nyanpasu | Windows | 多内核管理路线；以所选内核为准 | 活跃维护 | 中等，需区分界面设置与内核设置 | 桌面配置管理、内核选择与界面定制 | 重视桌面交互、愿意检查配置兼容性的用户 |
| Clash for Windows | Windows | 原版 Clash 路线；历史修改环境可能不同 | 已停止维护 | 旧用户熟悉，新用户不建议从此入门 | 历史配置、Parsers 与旧工作流参考 | 旧环境迁移、配置对照 |
| Clash Meta for Android | Android | Clash Meta / Mihomo 生态 | 活跃维护 | 中等，需处理 VPN 授权与后台策略 | 分应用代理、配置导入、移动端流量接管 | 需要细分 Android 应用流量的用户 |
| Surfboard | Android | 独立实现，使用 Surfboard 配置体系 | 活跃维护 | 有兼容配置时较低，跨格式迁移较高 | 面向兼容 Surge 风格的配置工作流 | 已有适配配置、熟悉相关语法的用户 |
| ClashX Meta | macOS | Clash Meta；归档内核不等于当前 Mihomo | 已停止维护 | 基础操作较低，新字段兼容性需检查 | macOS 菜单栏操作、旧 Meta 配置参考 | 既有环境过渡、配置迁移 |
以下点评不按速度排名。实际连接质量取决于网络、服务端、协议与规则，不能仅凭客户端名称判断。
适合尚未形成固定配置习惯的用户。选择它的主要理由是平台覆盖：桌面和手机都有对应入口，不必先研究多个客户端的历史分支。首次使用应从服务方提供的适配订阅开始，确认导入成功、策略组可选、系统授权完整，再调整分流。
跨平台不代表配置文件可以不加检查地通用。尤其从桌面迁到 iOS 时，应确认协议、规则和扩展字段支持情况。需要精细维护本地 DNS、脚本与覆写链时，先核对目标平台能力，再决定是否把所有设备统一到同一客户端。
查看 Clash Plus 平台入口 →Verge Rev 使用 Mihomo 内核，界面与本地配置组织适合桌面长期使用。订阅负责提供基础内容，Merge 覆写与扩展脚本处理本地差异。需要固定 DNS 行为、插入特定域名规则，或避免订阅更新覆盖本地修改时，这种分层方式更容易维护。
代价是需要理解生成过程。订阅原文、覆写文件和最终运行时配置不是同一个文件；写入字段后还要检查合并结果与日志。TUN、系统代理和服务模式也应分别确认。仅做首次订阅导入不必提前开启全部进阶选项。
查看覆写与 TUN 配置 →FlClash 同样基于 Mihomo，覆盖 Windows、macOS、Linux 与 Android。若主要设备是一台电脑和一部 Android 手机，相近的配置与代理组操作习惯可以降低切换成本。它适合以订阅为基础、偶尔检查连接和调整策略的日常工作流。
内核相同仍不能直接复制整个应用数据目录。桌面路径、移动端 VPN 权限、后台运行限制与 TUN 参数存在平台差异。迁移时优先导入订阅或可移植的 YAML，再逐项恢复应用设置；不要把桌面端的监听地址与端口暴露设置直接照搬到手机。
查看 Android 下载选项 →Nyanpasu 适合关注桌面配置管理与交互定制的用户。本站下载中心提供 Windows 入口。选择前应把界面功能和实际运行内核分开检查：某个配置字段能否使用，最终取决于当前内核与其支持范围，不是客户端设置页中出现相关名称就一定生效。
如果经常比较内核或管理多份配置，建议先用一份已知可用的订阅建立基线，再更改内核与本地设置。一次同时更换客户端、内核和 DNS 方案，会让故障来源难以区分。只想尽快导入订阅的新用户，可以先考虑操作路径更直接的选项。
查看 Windows 下载选项 →CFW 留下了大量旧教程和 Parsers 使用习惯，但已停止维护，不适合作为新环境的默认起点。旧客户端能够启动，不代表能够处理之后新增的协议、字段与系统变化。第三方修改过内核的安装环境也不能代表原始发行行为，比较前应先确认实际运行内容。
迁往 Verge Rev 时，先保留订阅地址、策略组选择、端口以及 Parsers 处理逻辑，再把本地修改改写为目标客户端支持的覆写方式。Parsers 代码不能简单更名为 Merge YAML。原有规则的插入顺序与数组处理方式，尤其需要通过运行时配置核对。
查看旧配置迁移顺序 →CMFA 面向 Android，使用 Meta/Mihomo 生态的规则与配置能力。适合需要按应用安排流量接管的用户。开始连接前，系统会请求 VpnService 授权；授权只是允许建立本地 VPN 接口，不代表订阅有效，也不代表规则已经按预期命中。
移动端常见问题是熄屏后被系统停止、与另一个 VPN 应用争用接口，以及分应用名单与规则预期不一致。应先确认后台运行策略，再观察日志。不要把桌面客户端的服务安装方法套用到 Android；分应用选择和域名规则也属于不同层面的控制。
查看 CMFA 与其他 Android 客户端 →Surfboard 是 Android 上的另一条配置路线，不应当作换了界面的 Clash。它使用自身的配置体系，面向兼容 Surge 风格的使用方式，具体支持范围以其文档为准。已有对应格式订阅、并熟悉这种规则组织方式的用户，可以将它纳入比较。
只有 Clash YAML 时，不建议把文件后缀改名后直接导入。协议支持、策略组表达、规则语法和 DNS 设置都可能存在差异，转换工具也不保证完整保留语义。优先向服务方取得适配配置；如需转换，应逐项检查规则顺序与最终默认策略。
查看 Surfboard 下载入口 →ClashX Meta 曾提供以菜单栏为中心的 macOS 操作方式，适合用来理解既有 Meta 配置。但归档程序不会因为名称含 Meta 就自动获得当前 Mihomo 的功能。新系统环境、新协议或新的配置字段，都可能超出归档构建的支持范围。
新安装更适合先比较 Clash Plus、Verge Rev 与 FlClash。迁移旧配置时，应保留订阅来源与本地规则，并核对目标客户端的处理顺序。不要默认原来的系统代理端口、启动项和权限配置会自动转移，也不要同时让两个客户端修改系统代理。
查看 macOS 客户端选项 →先选出能完成任务的一款，再测试现有订阅。重复安装多个客户端通常不能解决同一个 DNS 或服务端问题，反而容易留下相互冲突的代理设置。
迁移是否顺利主要取决于配置语义，而不是界面相似程度。保留旧环境作为回退，但验证时只启动一个负责接管流量的客户端。
确定候选后，前往下载中心核对系统与架构；首次配置可继续阅读快速上手。需要跨订阅保留规则或处理 TUN 与 Fake-IP 的组合，再查阅高级用法。