Clash for Windows 停更后怎么迁移:Verge Rev、FlClash 等替代客户端与配置搬家步骤

停更后的迁移边界：客户端、内核与配置分开处理

Clash for Windows，通常简称 CFW，于 2023 年 11 月停止维护。旧安装仍可能启动，但后续操作系统变化、依赖组件问题和协议兼容性不会由原项目继续修复。迁移的目标不是让新客户端复刻旧界面，而是保留订阅来源、节点、代理组和分流意图，再重新建立系统代理与网络接管设置。

先区分三个层次：CFW 是图形客户端；Clash、Clash Premium、Clash Meta 与 mihomo 属于内核相关项目；YAML 是承载代理、规则和运行参数的配置格式。Clash Meta 后续以 mihomo 名称继续发展。安装一个基于 mihomo 的客户端，不代表旧 CFW 的每项界面设置都会自动转换。

迁移前先记录这六项

当前启用的 Profile 名称，以及它来自订阅地址还是本地 YAML。
HTTP、SOCKS 或混合端口的实际数值，例如 7890；不要只凭默认值判断。
运行模式是 Rule、Global 还是 Direct，代理组当前选中了哪个节点。
是否开启 System Proxy、TUN、开机启动和后台服务。
是否使用 Parsers、自定义规则、DNS 修改或其他配置加工逻辑。
浏览器、终端、开发工具中是否单独指定了代理地址。

替代客户端对比：Verge Rev、FlClash 与 Nyanpasu

选型先看操作系统和配置能力，再看界面。下面的平台范围指项目通常提供的客户端平台；具体系统最低版本、CPU 架构和内核版本，以下载入口对应发行说明为准。不要把“支持 Windows”理解为所有历史 Windows 版本均能运行。

客户端	主要平台	内核关系	迁移关注点
Clash Verge Rev	Windows、macOS、Linux	基于 mihomo	适合桌面订阅管理；需重建覆写、服务与系统代理设置
FlClash	Windows、macOS、Linux、Android	基于 mihomo	适合跨桌面与 Android 使用；各平台的网络接管方式不同
Clash Nyanpasu	Windows、macOS、Linux	提供 Clash 系内核管理，具体选项随版本变化	确认实际启用的内核，不能只凭客户端名称判断语法支持

按使用方式做选择

以桌面配置管理为主：可以先评估 Clash Verge Rev，重点查看订阅更新、覆写和日志入口是否满足现有流程。
同时使用电脑与 Android：可以评估 FlClash，但不要把 Windows 的服务模式步骤照搬到 Android；后者通常通过系统 VPN 授权接管流量。
需要检查或切换内核：可以评估 Clash Nyanpasu，导入前先确认内核选择和版本，再判断订阅字段是否可用。

CFW 的名称虽然带有 Windows，历史发行也包含其他桌面平台。迁移不必局限于名称相近的产品。真正影响配置能否加载的是目标内核、订阅输出格式和客户端对覆写的实现，而不是界面是否像 CFW。

备份订阅与本地 YAML：保留来源，也保留可用副本

订阅地址与当前配置快照承担不同作用。地址用于以后更新；YAML 快照用于保留当前可用节点和自定义内容。只保存地址，无法找回曾经手改但已被覆盖的规则；只保存 YAML，则可能失去自动更新能力。

在 CFW 的 Profiles 页面确认当前配置。对远程配置记录原始订阅地址；对本地配置保存原文件。不要根据显示名称猜测来源。
通过客户端提供的配置目录入口定位实际数据目录。若使用过便携方式，目录可能随安装位置变化，不要只查用户主目录。
将配置目录复制到独立备份文件夹，同时单独保存订阅地址、配置名称和对应关系。
保存 Parsers 内容、手写规则和本地资源文件。若 YAML 引用了相对路径，把被引用的文件一起备份。
记录备份时的端口、模式与代理组选择。可截取相关设置页，但截图不能代替 YAML 和订阅地址。

检查 provider 引用与相对路径

配置中的 proxy-providers 和 rule-providers 可能依赖远程地址，也可能依赖本地 path。复制主 YAML 不等于复制所有依赖。新客户端的数据目录改变后，相同相对路径指向的位置也可能改变，应按照目标客户端的工作目录重新确认。

导入与切换步骤：先规则模式，再系统代理

第一次迁移建议只接管普通应用流量，暂时关闭 TUN。这样可以把“配置是否正确”和“系统路由是否正确”分开验证。整个过程中只让一个客户端负责系统代理，避免两个后台程序反复修改同一组设置。

结束旧客户端接管。在 CFW 的 General → System Proxy 关闭系统代理；如开启 TUN，也先关闭。随后退出 CFW，并确认它没有因开机启动再次运行。
安装目标客户端。从客户端安装入口选择操作系统和架构。首次启动先确认内核可用，再处理服务模式等附加功能。
导入一份配置。远程配置使用原始订阅地址，本地配置使用保存的 YAML。不同客户端可能将入口命名为“配置”或“订阅”，以安装版本界面为准。
启用刚导入的配置。仅出现在列表中还不代表内核正在使用它。检查当前配置标记和加载日志，确认没有 YAML 解析错误或不支持的字段。
选择 Rule 模式。打开对应代理组，先手动选择一个可用节点。代理组名称相同不代表之前的选择状态会被保留。
核对监听端口。确认新客户端实际使用的端口，再开启系统代理。浏览器若有代理扩展，应先关闭扩展接管或设置为跟随系统。

端口迁移示例：7890 改为 17890

如果旧客户端使用 127.0.0.1:7890，新客户端使用 127.0.0.1:17890，所有写死旧地址的终端变量和工具设置都需要更新。下面是 mihomo 的局部参数示例，不是一份包含节点与规则的完整订阅。实际应通过客户端支持的设置或覆写机制应用。

mixed-port: 17890
allow-lan: false
mode: rule
log-level: info
tun:
  enable: false

mixed-port 同时接受 HTTP 与 SOCKS 代理连接。它与内核控制接口端口不是一回事；控制接口用于管理，不应填写到浏览器的 HTTP 代理栏。已有应用若明确使用单独的 SOCKS 监听端口，也要按照新配置重新核对。

规则、覆写与 TUN：不能直接照搬的设置

CFW Parsers 需要重新实现

Parsers 是 CFW 的配置加工机制，不是 mihomo YAML 的通用顶层字段。把 Parsers 原文粘进订阅文件，不能自动得到相同效果。应先列出它实际做了什么，例如添加局域网直连规则、修改 DNS、增加代理组，再用目标客户端支持的合并配置或脚本覆写逐项实现。

先保存原始订阅，再保存自定义修改。直接编辑下载后的远程 YAML，下一次更新可能覆盖修改。验证方法很具体：记录一条自定义规则，执行一次订阅更新，再查看运行配置中该规则是否仍然存在、位置是否正确。

规则顺序与组名必须一起检查

规则通常按顺序匹配，首次命中的规则决定后续策略。需要优先的例外规则应放在兜底规则之前。
MATCH 是常见兜底规则，应检查它实际指向的策略组，不能只看文件里存在节点。
规则引用的代理组名称必须与定义一致，包括大小写、空格和符号。重命名代理组后也要修改引用。
订阅若提供 Clash 与 Clash Meta 两种输出，使用 mihomo 时优先确认服务方推荐的兼容格式，不要把其他格式的内容仅改成 .yaml 后导入。

TUN 与 DNS 最后单独开启

TUN 会创建虚拟网络接口，并可能调整路由与 DNS 处理方式。它不是“更强的全局模式”：规则模式仍可在 TUN 接管后执行。先确认普通系统代理能工作，再按目标客户端要求启用服务或授予权限，最后开启 TUN。

若启用后内网域名、公司 VPN 或本地设备访问异常，应核对路由排除、DNS 策略和其他 VPN 的占用情况。fake-ip 是 DNS 处理模式，不能只迁移一个开关而忽略相关过滤与规则。不要同时启用两个客户端的 TUN 来判断哪一个更快，这会让故障来源更难定位。

迁移验收：配置加载、代理连接与更新分开测试

看到节点延迟数字，只说明某个测试目标在指定条件下得到响应，不足以证明浏览器、终端和规则全部正常。下面的命令以 Windows PowerShell 为例，假定新客户端混合端口为 17890；使用其他端口时同步修改命令。

1. 确认本地端口与显式代理

Get-NetTCPConnection -State Listen -LocalPort 17890
curl.exe --proxy http://127.0.0.1:17890 --connect-timeout 10 --max-time 20 -I https://example.com/

第一条命令检查是否有进程监听该端口，可根据输出中的 OwningProcess 进一步确认所属程序。第二条命令明确指定 HTTP 代理，连接超时为 10 秒，总时限为 20 秒；使用 curl.exe 是为了避免部分 PowerShell 环境中的命令别名差异。

收到 HTTP 响应说明这次请求完成，但不代表一定使用了代理节点：Rule 模式也可能命中 DIRECT。应同时查看客户端连接记录，确认匹配规则、策略组与最终出口符合预期。若显式代理可用而浏览器不可用，优先检查系统代理、浏览器扩展和代理例外列表。

2. 检查终端变量与系统设置

Get-ChildItem Env:*proxy*
netsh winhttp show proxy

第一条命令可发现仍指向旧端口的代理环境变量。第二条只显示 WinHTTP 代理设置，不代表 Windows 用户级系统代理的全部状态。在 Windows 11 中还应查看“设置 → 网络和 Internet → 代理”，核对当前手动代理地址与端口。终端工具是否读取系统代理取决于工具自身，不能仅靠打开客户端开关来推断。

3. 完成更新与重启验收

手动更新一次订阅，确认节点列表仍能加载，自定义规则没有消失。
分别访问一个应直连的目标和一个应走代理的目标，在连接记录中核对策略。
关闭并重新启动新客户端，确认当前配置、模式和代理组选择符合预期。
如需 TUN，单独开启后再测试本地网络、DNS 与日常应用。
重启系统，确认只有新客户端自启，旧客户端不再修改端口或系统代理。

常见迁移问题与回退方法

订阅能导入，但节点列表为空，应该先检查什么？

先看订阅请求与配置加载日志。地址可能返回登录页、错误提示或不兼容格式，而不是有效 YAML。也可能使用了 proxy-provider，但提供者下载失败或未被代理组的 use 引用。先核对原始订阅是否仍有效，再检查目标内核支持情况，不要反复切换系统代理掩盖配置问题。

新客户端提示端口占用，可以直接改端口吗？

可以，但先确认占用进程。如果是旧 CFW 或残留后台服务，应先正常退出或停止对应服务。确实需要改为 17890 等其他端口时，浏览器手动代理、终端变量和开发工具配置必须一起更新。不要结束用途不明的系统进程。

迁移失败后怎样回到旧配置？

先关闭新客户端的系统代理与 TUN，再退出新客户端，随后启用旧客户端和备份配置。回退是短期恢复手段，不会改变旧项目停止维护的事实。如果暂时不再使用代理，应同时清理仍指向已关闭端口的手动代理和环境变量，避免应用持续连接失败。

迁移完成的标准是：原订阅可更新，本地修改可保留，规则命中可解释，系统重启后仍能按预期接管流量。确认这些项目之后，再移除旧客户端的自启动项与服务，并保留一份受控备份。需要核对配置字段时，可继续查阅协议参考；系统代理异常则可从帮助中心按现象排查。