平台 / 内核 / 配置兼容
Clash 客户端对比与选型
新安装优先选择 Clash Plus;需要桌面配置覆写可看 Clash Verge Rev,需要兼顾 Android 与桌面可看 FlClash。先确认系统与配置格式,再比较界面和功能,避免把客户端名称当成内核能力。
先按平台和配置筛选
首推 Clash Plus
新手从 Clash Plus 开始评估
Windows、macOS、Android 与 iOS 用户可先查看 Clash Plus 的对应入口。选择理由是平台覆盖和日常配置管理的使用路径,而不是某项未经实测的速度排名。安装前仍需确认当前系统、处理器架构,以及服务商提供的订阅类型;同名客户端在不同平台上的网络接管方式和支持字段不一定相同。
如果已经维护一套依赖 proxy-providers、rule-providers 或特定 DNS 行为的 mihomo 配置,应把字段兼容性放在界面偏好之前。桌面端可进一步比较 Clash Verge Rev 与 FlClash;Linux 用户优先从这两款客户端中选择。本页的平台范围与本站下载入口对应,不代表各项目全部历史发行范围。
按平台查看安装包与系统要求 →
八款客户端横向对比
难度描述以导入现成配置、选择策略和启用代理为基准,不是性能测评。维护状态为定性参考,可能随项目调整;安装前应再查看对应发行说明。表格可横向滚动。
每款客户端如何取舍
适合作为新用户的第一个候选项,尤其是需要在电脑与手机之间建立相近使用习惯的场景。先完成导入配置、选择策略、启用代理和验证连接四个动作,再决定是否需要更深入的规则定制。客户端本身不等于订阅服务,仍需要可用且格式匹配的配置来源。
多平台覆盖不表示全部平台共用相同内核或接受全部 mihomo 字段。已有复杂 YAML 时,应逐项核对协议、DNS、策略组和规则支持情况。iOS 用户通过 App Store 安装,官网为 clashplus.io;平台之间不能照搬桌面 TUN 或服务模式的操作说明。
Clash Verge Rev
适合把桌面端作为主要配置工作台的用户。mihomo 负责规则、协议与连接处理,图形界面负责配置选择、订阅更新和系统集成。需要保留自定义规则时,优先研究客户端提供的覆写或合并机制,不要直接在会被远程更新覆盖的配置正文里长期修改。
进阶选项较多,也意味着排错时要区分配置层和系统层。系统代理适合愿意读取系统代理设置的应用;TUN 用于接管更广的流量,但涉及权限、路由和 DNS。不要为了让某个应用生效就同时打开多套接管方式,应先确定问题发生在哪一层。
FlClash
适合 Android 与桌面设备并用、希望减少界面学习成本的用户。其 mihomo 体系有利于沿用相近的规则与策略组设计,但跨设备迁移的重点仍是配置来源和字段支持,而不是把应用数据目录整体复制。手机上的 VPN 授权与电脑上的系统代理并非同一种开关。
使用时建议先建立一套小规模、结构明确的配置,确认策略组能选到真实节点,再添加规则集和复杂 DNS 设置。相近的界面能降低操作切换成本,却不能保证不同系统下的后台保活、网络权限、休眠恢复和路由行为相同。
Clash Nyanpasu
适合愿意调整界面与桌面工作流、同时理解内核职责的用户。本站提供 Windows 入口,选型时不要将这个下载范围解释为项目只存在 Windows 平台。需要使用特定 Meta 字段时,先确认客户端当前启用的内核及对应能力,再检查配置是否被界面设置或覆写逻辑改写。
这类可调整项较多的客户端,应建立清晰的配置来源记录:远程订阅负责什么,本地覆写修改什么,界面开关又影响什么。遇到行为差异时先查看运行配置和日志,避免同时修改多个开关,导致无法判断真正起作用的是哪一处。
Clash for Windows
已停止维护
适合用于核对历史教程、旧配置结构和既有运行环境,不建议作为新设备的起点。网络上仍能找到大量围绕 CFW 的操作截图,但菜单名称相似并不表示新的协议和规则字段能够在历史内核中运行。能导入文件也不等于内核完整理解了文件里的所有设置。
寻找 Clash for Windows 替代时,先记录旧环境的监听端口、模式、策略组名称与自定义规则,再选择 Clash Plus、Clash Verge Rev 或 FlClash。迁移后重新配置系统代理与自启,不应让旧客户端的服务或后台进程继续占用端口。保留旧配置副本用于对照即可。
Clash Meta for Android
常简称 CMFA,适合已经了解 Clash YAML、希望直接在 Android 管理配置和应用分流的用户。导入订阅后,应先选中需要启用的配置,再完成系统 VPN 授权。配置列表里有文件,与当前内核实际加载该文件,是两件需要分别确认的事。
移动端排错还要考虑电池优化、后台限制和网络切换。如果锁屏后失效,不能仅凭现象认定节点不可用,应先检查后台运行权限与 VPN 状态。按应用分流时也要确认列表采用包含还是排除逻辑,避免目标应用恰好处于未接管的范围。
Surfboard
Surfboard 是 Android 代理工具,但不是给 Clash YAML 换一个界面的客户端。它采用自身支持的配置语法和协议实现,适合已经持有兼容订阅、清楚服务商导出格式的用户。选择前先确认配置类型,比先比较界面布局更重要。
从 Clash 迁移时,不应仅将文件扩展名改掉就尝试导入。节点参数、策略组表达、规则语法和 DNS 行为都可能需要转换;转换结果也必须检查协议支持及规则顺序。若主要目标是保留现成 mihomo 配置,优先选择同体系客户端通常更容易排查。
ClashX Meta
已停止维护
适合已有 macOS 菜单栏使用习惯的历史环境对照。它采用 Clash Meta 体系,但历史发行包中的内核能力不会因为项目名称包含 Meta 就自动跟上当前 mihomo。新系统、处理器架构和配置字段都应独立核对,不宜按旧教程直接推断兼容性。
新安装优先看 Clash Plus、Clash Verge Rev 或 FlClash。迁移时先记录当前端口与策略选择,退出旧客户端后再启用新客户端的网络接管。还应检查登录项及系统代理是否仍指向旧监听地址,避免界面已换新、实际流量却仍交给旧进程。
四类使用场景建议
换客户端前的配置检查
先保存配置,再切换接管
保存订阅来源、本地规则与策略组选择;不要把客户端整个数据目录当成通用备份格式。退出旧客户端,确认它的后台服务没有继续接管流量,再启动新客户端。若两者都使用 mixed-port: 7890,同时运行可能发生端口冲突,表现为启动失败或系统代理指向错误进程。
迁移完成后分别检查浏览器和终端。浏览器可能读取系统代理,终端则可能仍保留旧的代理环境变量。两者结果不同,不足以证明新内核分流异常。
从最小配置逐步恢复
先确认节点可以连接、默认策略组能够选择,再恢复 DNS、规则集和 TUN。每增加一项设置就验证一次,出现差异时回到最近一次可用状态。复制 YAML 时使用空格缩进,保留列表层级,避免同名顶层字段重复出现。
下面只展示常见基础字段的结构,不是完整可连接配置。实际使用还需要有效节点或节点提供者、策略组及规则;它也不代表 Surfboard 或各平台客户端都支持原样导入。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
换成 mihomo 客户端,节点一定会更快吗?
不一定。出口线路、服务端负载、本地网络和协议参数通常都会影响连接表现。更换内核可能改善协议兼容或修复特定问题,但不能据此承诺速度提升。比较时应使用同一节点与相近网络条件,并确认两边实际命中了相同策略。
同一份订阅能在所有客户端直接使用吗?
不能默认通用。先确认服务商提供的是节点列表、完整 Clash 配置,还是其他客户端格式。即使都接受 YAML,高级字段也可能依赖特定内核。Surfboard 需要其支持的配置格式,跨平台的 Clash Plus 也应按对应平台核对导入能力。
只需要命令行或路由器运行,应选哪张客户端卡?
可以直接评估 mihomo 内核,而不必安装桌面界面。内核需要自行管理配置路径、启动服务、日志和更新,适合具备系统管理经验的用户。普通桌面用户优先使用图形客户端;服务器与路由器用户可查看内核下载区,按系统架构选择。