停更意味着什么,不意味着什么
Clash for Windows(社区常简称 CFW)在开发者宣布归档后,不再有新版本发布、不再修复漏洞、不再适配新内核特性。这是一个明确的事实,但它常被过度解读成"现在立刻不能用了"或"配置文件全部作废",这两点都不准确。
先说清楚风险边界。停更带来的实际影响主要有三条:一是客户端内置的内核版本被锁定在归档时的那个版本,后续内核新增的协议类型(例如更新的传输层混淆方式)或规则语法扩展,CFW 都不会再支持;二是客户端本身若存在未修复的界面或连接稳定性问题,不会再有补丁;三是操作系统升级后(尤其是 Windows 的网络栈调整),旧客户端与系统组件的兼容性问题只能靠用户自行绕过,没有官方响应渠道。
不需要恐慌的部分同样值得说清楚。首先,已经写好的订阅链接、规则集、DNS 配置这些内容都保存在你自己的配置文件里,不依赖客户端本身,换客户端不等于重新配置一切。其次,mihomo(Clash Meta)内核仍在活跃维护,只要新客户端内置的是较新的 mihomo 内核,你此前遇到的协议不支持、规则不生效等问题反而可能被顺带解决。第三,配置文件语法(YAML 结构、代理组写法、规则匹配逻辑)在主流客户端之间高度兼容,迁移的核心工作量不是重写配置,而是把现有文件正确导入到新客户端并核对少数字段差异。
如果你的配置文件里手写了大量自定义规则或覆写脚本,且这些内容依赖 CFW 特有的字段写法,迁移前建议先备份原始文件再逐项核对,不要直接删除旧客户端。
迁移前的准备:备份与清点
动手换客户端之前,先把现有资产完整备份,这一步能避免绝大多数"迁移完发现规则丢了"的问题。
-
定位配置文件目录
CFW 的配置文件一般存放在用户目录下的
.config\clash或客户端安装目录内的profiles文件夹,文件名通常是订阅生成的一串字符加.yaml或.yml后缀。找到全部订阅对应的配置文件并复制到一个新建的临时文件夹。 -
记录订阅原始链接
配置文件是订阅拉取后生成的结果,更可靠的迁移方式是重新用订阅链接生成配置,而不是直接搬运旧文件。打开 CFW 的订阅管理界面,把每一条订阅的原始 URL 完整复制出来,单独存成一个文本文件。
-
检查是否使用了覆写(Override)脚本
如果你在 CFW 里为某条订阅添加过覆写规则或 JavaScript 覆写脚本(用于强制修改端口、追加规则、屏蔽广告分组等),这部分内容不会自动跟随订阅链接迁移,需要单独复制脚本正文,新客户端里重新粘贴配置。
-
确认系统代理与 TUN 设置
记下当前使用的是系统代理模式还是 TUN 模式,以及混合端口(mixed-port)、允许局域网连接(allow-lan)等字段的取值,这些是迁移后最容易被忽略、但直接影响能否正常上网的开关项。
配置文件迁移的具体步骤
备份清点完成后,正式的迁移操作分为三种情况,按你的实际使用习惯选择即可。
方式一:重新导入订阅链接(推荐)
在新客户端的订阅管理界面粘贴原始订阅 URL,让新客户端自己拉取并生成配置文件。这种方式的好处是配置内容始终由订阅方维护,如果订阅方后续更新了节点列表或规则集,你不需要手动同步。缺点是如果你在旧客户端里做过手动修改(比如调整过某个代理组的策略),这部分修改不会带过来,需要重新设置。
方式二:直接导入本地配置文件
把备份出来的 .yaml 文件通过新客户端的"从文件导入"功能加载。这种方式保留了你手动改过的全部内容,但订阅方后续更新时,你需要自己判断是否要用新版本覆盖当前文件。
# 典型的 Clash / mihomo 配置文件顶层结构,迁移时核对字段是否被新客户端识别
mixed-port: 7890
allow-lan: true
mode: rule
log-level: info
dns:
enable: true
nameserver:
- 223.5.5.5
- 119.29.29.29
proxies:
- name: "示例节点"
type: vmess
server: example.com
port: 443
proxy-groups:
- name: "自动选择"
type: url-test
proxies: ["示例节点"]
rules:
- DOMAIN-SUFFIX,example.com,自动选择
- MATCH,DIRECT导入后重点核对三处:一是 proxy-groups 里引用的节点名称是否和 proxies 列表完全一致(大小写、空格都会导致匹配失败);二是 rules 里的策略组名称是否存在,新客户端如果对未定义的分组报错,通常就是这个原因;三是 DNS 配置块的写法,新版内核对 nameserver-policy、fake-ip-filter 等字段的解析可能比旧内核更严格。
方式三:混合迁移
先用订阅链接生成基础配置,再把旧配置里的覆写脚本正文单独粘贴到新客户端的覆写功能里。这是多数长期用户实际采用的方式,既能享受订阅方的持续维护,又不丢失自己的定制内容。
切换完成后,依次确认:节点列表能正常测速、代理组的自动选择策略生效、指定域名走对了分组(用规则里配置过的域名做一次实测)、DNS 解析没有异常(用命令行工具查一次域名解析结果)。四项都正常再卸载旧客户端。
三款接手客户端横向对比
CFW 停更后,社区里逐渐形成了几个公认的接手方向,思路各有侧重,选择时可以按下面的维度对照自己的实际需求。
| 客户端 | 技术路线 | 界面风格 | 适合人群 |
|---|---|---|---|
| Clash Plus | 基于 mihomo 内核,官方持续维护 | 贴近 CFW 原有交互习惯,上手成本低 | 希望迁移后操作逻辑变化最小的用户 |
| Clash Verge Rev | Rust 编写外壳 + mihomo 内核,社区活跃维护 | 轻量,提供图形化规则编辑与订阅管理 | 喜欢自定义细节、愿意折腾配置的用户 |
| FlClash | 跨平台外壳,支持桌面与移动端统一体验 | 简洁,强调多设备配置同步的一致性 | 同时在多台设备之间切换使用的用户 |
三者的共同基础都是 mihomo 内核,这意味着协议支持范围和规则语法的核心能力是一致的,真正的差异体现在界面交互深度、订阅管理便利性、以及是否提供额外的图形化配置能力。如果你此前在 CFW 里习惯用最基础的订阅+规则模式,几款客户端切换后都不会有明显的功能缺失感;如果你依赖过 CFW 的某些细节功能(比如特定的流量统计展示方式),建议先用小范围测试确认新客户端是否提供等价能力,再做正式切换。
选择时的几个实际判断点
- 是否需要频繁手动改规则:如果经常手动增删规则,优先选择提供图形化规则编辑界面的客户端,能减少直接改 YAML 文件出错的概率。
- 是否多设备使用:如果同一套配置要在电脑和手机之间切换,优先考虑配置同步能力更完善的方案,减少重复维护订阅的工作量。
- 是否追求内核更新速度:三者都跟随 mihomo 上游更新,但发版节奏存在差异,对新协议特性有紧迫需求的用户可以关注各自的更新日志频率。
迁移完成后如何避免"二次踩坑"
换了客户端不代表万事大吉,以下几点是实际迁移中最常被忽略、事后又最容易返工的细节。
订阅更新周期要重新确认。不同客户端对订阅的自动更新间隔设置位置不同,迁移后建议重新打开订阅详情,确认自动更新周期(通常以小时为单位)是否符合预期,避免节点信息长期未刷新导致连接失败却找不到原因。
开机自启与静默模式要重新勾选。这是最容易被忘记的一项——旧客户端设置的开机自启不会带到新客户端,重装后系统重启时会发现代理没有自动启动,需要在新客户端的系统设置里重新勾选。
本地覆写脚本要逐条测试。如果覆写脚本里有依赖 CFW 特定 API 或字段名的写法,新客户端解析时可能静默忽略而不报错,建议逐条注释掉部分规则再逐步恢复,定位到底哪一段生效、哪一段没生效。
确认内核版本号。迁移后在新客户端里查看当前使用的 mihomo 内核版本号,和你此前遇到的问题对照的话,能确认是否是因为内核升级顺带修复了旧问题,还是需要额外配置才能解决。
不建议为了"省事"继续长期使用已停更的 CFW 且完全不关注后续风险。协议兼容性问题会随时间推移逐渐累积,越晚迁移,届时需要核对的配置差异往往越多。
总体上,从 CFW 迁移到接手客户端是一次性的、可控的工作量,核心步骤是备份订阅链接与覆写脚本、选定一款基于 mihomo 内核的新客户端、逐项核对规则与 DNS 字段、完成后走一遍验证清单。只要按顺序做完,原有的使用习惯和配置逻辑基本能够无损保留。