Clash for Windows 停更后怎么办：迁移到 Clash Verge Rev 的方案对比

停更后的迁移重点：配置来源、内核和接管方式

Clash for Windows（下文简称 CFW）停止维护后，原有安装并不会立即失效，但客户端界面、依赖组件和内核不再随当前网络环境持续更新。常见的 CFW 0.20.39 安装仍可能处理原有订阅，能连接并不等于适合继续作为长期运行环境。迁移的目标是保留可复用配置，并重新确认新客户端实际加载了什么。

需要分清三个层次：客户端负责订阅管理、托盘菜单和系统集成；内核负责解析配置、匹配规则与建立连接；订阅提供节点、策略组以及可能附带的规则。换客户端不一定要换订阅，但换内核后，旧字段、脚本和 DNS 行为都需要重新检查。

配置来源：记录订阅地址、当前本地 YAML，以及哪些设置来自订阅、哪些来自本地覆写。
内核差异：Clash Verge Rev 使用 mihomo，即原 Clash.Meta 项目后续采用的名称；它不是把旧版 CFW 界面换成另一个外壳。
流量入口：系统代理、TUN、应用自行填写的 HTTP/SOCKS 代理是三种不同入口，不能只凭一个开关判断迁移成功。

替代方案对比：Clash Verge Rev 与其他路径

如果主要需求是 Windows 桌面上的订阅导入、策略选择、日志查看与 TUN，Clash Verge Rev 是较直接的迁移路径。跨桌面系统继续使用同类配置，也可以考虑它的 macOS、Linux 版本；手机端则需要另外选择适合移动系统的客户端，不能把桌面安装包直接使用在 Android 或 iOS 上。

方案	内核与平台	配置迁移重点	适用情况
Clash Verge Rev	mihomo；Windows、macOS、Linux	重新导入订阅，重建本地覆写和系统接管设置	需要桌面界面、订阅管理与 TUN
ClashX Meta	Meta/mihomo 系；macOS	检查发行包内核版本，重新配置菜单栏与系统代理选项	主要使用 macOS 菜单栏操作
mihomo 命令行	mihomo；提供多种桌面与服务器平台构建	自行维护 YAML、服务启动、日志和控制接口	需要脚本部署或固定服务运行
暂时保留 CFW	取决于原安装携带的内核	仅作短期回退，不能据客户端名称推断协议支持	迁移窗口内复核旧配置行为

兼容的是配置语义，不是整个配置目录

常见的 proxies、proxy-groups、rules 可以作为迁移基础，但客户端保存的界面状态、订阅数据库、服务安装信息并不通用。不要将 CFW 数据目录整体覆盖到 Clash Verge Rev 目录，也不要把旧的内核可执行文件复制进新客户端目录。

CFW 的 Parsers、客户端侧脚本与 Clash Premium 的脚本规则也需要区分。前者属于客户端处理流程，后者涉及内核能力；二者都不能假设在 mihomo 中原样运行。简单的域名分流可以改成标准规则，复杂脚本则应逐项确认等价实现，而不是只修改文件扩展名。

迁移前备份：订阅之外还有哪些内容

先在 CFW 的 General 页面通过 Home Directory 打开实际数据目录。许多旧安装使用用户目录下的 .config/clash，但便携模式或自定义路径可能不同，应以当前安装显示的位置为准。备份时先退出程序，避免配置仍在写入。

保存订阅入口：记录 Profiles 中每个订阅的名称与原始 URL。订阅 URL 通常带有访问凭据，只保存在自己的备份中，不粘贴到公开工单、截图或在线转换页面。
保存本地配置：复制正在使用的 YAML，以及自己维护的规则文件、规则提供器和脚本。单独标记曾直接修改过的订阅缓存文件，这类修改可能在更新时被覆盖。
记录运行参数：包括代理模式、HTTP/SOCKS 或混合端口、是否允许局域网连接、DNS、TUN，以及控制接口地址。不要将控制接口密钥当作节点密码迁移。
记录选择状态：记下主要策略组当前选中的节点或下级组。组名相同不代表新客户端一定会继承选择结果。
记录外部依赖：检查浏览器扩展、终端环境变量、Git 和开发工具是否写死了 127.0.0.1:7890 一类地址。

订阅只能恢复服务商提供的内容，无法恢复所有本地习惯。例如旧客户端把某个工作域名设置为直连，而订阅本身没有这条规则，重新导入后这项行为就会消失。把这些差异另存为清单，比只保留一份看似完整的运行配置更容易核对。

迁移到 Clash Verge Rev：先验证订阅，再启用系统代理

第一步：安装后先确认内核可以启动

按操作系统和处理器架构选择安装包，入口见客户端下载页。退出 CFW，并关闭旧系统代理和旧 TUN 后再启动 Clash Verge Rev。先观察内核状态与日志；若内核尚未运行，优先处理配置解析、端口占用或服务启动错误，不要直接反复切换节点。

第二步：导入原始订阅或本地 YAML

在「订阅」页面使用导入入口添加原始订阅 URL；如果原来使用本地 YAML，就使用本地文件导入入口。不同版本按钮措辞可能略有差异，应确认导入结果是可供内核读取的 Clash/mihomo 配置。一个返回 Base64 节点列表或其他客户端专用内容的链接，不一定能直接当作完整 YAML 使用。

导入后选中配置，检查节点列表、策略组和规则是否出现。遇到解析错误，先根据日志给出的字段或行号定位问题；遇到 HTTP 401、403，则先检查订阅授权与服务商状态。若订阅地址本身只能经代理访问，可以利用仍可用的旧环境下载配置备份，但切换新客户端时仍应退出旧内核。

第三步：确定端口，然后开启系统代理

在「设置」中的端口设置入口查看实际混合端口，部分版本将其放在「Clash 设置」下。下文以 7897 为例，它不是对所有安装的固定要求。如果继续使用旧端口 7890，必须先确认没有旧进程占用；如果采用新端口，就同步修改应用中写死的代理地址。

把运行模式设为「规则」，并选择一个明确可用的策略或节点。
开启「系统代理」，暂时保持 TUN 关闭，先用浏览器访问常用站点。
查看「连接」或日志中的命中规则、策略链与连接结果，确认请求进入了新内核。
基础代理通过后，再逐项恢复开机启动、服务模式和 TUN，避免一次改动多个变量。

保留自定义规则：覆写位置和策略组名称要一起迁移

订阅更新通常会重新获取远程内容。需要长期保留的本地规则，应放进客户端支持的扩展配置、合并配置或脚本机制，而不是直接编辑下载后的订阅缓存。具体入口随版本变化，关键是检查最终配置：本地规则是否真的进入 rules，以及是否排在兜底规则之前。

下面是规则顺序示意，不是完整订阅。示例保留域名 example.com 用于测试；PROXY 是示例策略组名，实际使用时必须与自己的配置逐字一致。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

顺序：规则从上往下匹配，放在 MATCH 后面的普通规则无法发挥预期作用。
目标：DIRECT 是内置策略，PROXY 则必须是存在的节点或策略组；订阅改名后需要同步调整引用。
合并：确认所用扩展机制是前置、追加还是替换整个数组。错误替换 rules 可能让原订阅分流规则全部丢失。
规则集：检查 rule-providers 的 URL、格式、行为类型与本地路径；旧电脑上的绝对路径不能直接用于另一台电脑。

不要把旧 YAML 的所有顶层字段都当作必须保留的设置。新客户端可能管理监听端口、控制接口和 TUN 参数；本地覆写与界面设置同时修改这些字段时，需要确认最终优先级。字段解释可结合配置参考核对。

DNS 与 TUN：从能连接到应用行为一致

先检查 DNS，再处理特殊域名

从旧内核迁移后，DNS 的 fake-ip、真实地址解析、解析请求出口和规则匹配方式都可能影响访问结果。先使用新客户端生成的基础设置，确认公共网站能访问，再逐步恢复原来的 DNS 自定义内容。不要为了让一个站点工作，直接叠加多个来源不明的 DNS 片段。

如果浏览器正常但公司内网域名失败，应先确认系统原本是否依赖 VPN 下发的内部 DNS，以及该域名是否需要专用解析策略。fake-ip 模式下显示合成地址本身不等于解析错误；应用必须拿到真实 IP 才能工作的场景，才需要结合实际配置评估过滤或域名解析策略。

TUN 需要单独验收

系统代理主要服务于遵循系统代理设置的应用；TUN 通过虚拟网卡与路由接管更多流量，但并不保证所有应用、协议和网络环境都自动兼容。Windows 上应先按客户端提示安装或启用所需服务，并确认权限满足要求，再打开 TUN。

关闭旧客户端 TUN，避免两套自动路由同时修改出口。
分别测试浏览器、一个不遵循系统代理的应用，以及局域网地址。
检查公司 VPN、虚拟机网络和安全软件是否与新路由冲突。
若开启 TUN 后内网异常，先关闭 TUN 对照，再分析路由和 DNS，不要同时删除多项配置。

验收与回退：用端口、请求和规则记录定位问题

下面的 PowerShell 命令假设已经确认新混合端口为 7897。第一条只检查监听是否可达，第二条显式通过 HTTP 代理发送请求。示例站点的响应只能用于基础连通性观察，不能代替对实际业务网站的测试。

Test-NetConnection 127.0.0.1 -Port 7897
curl.exe --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com

TcpTestSucceeded : True 仅说明本地端口可连接，不代表节点或远端网站正常。显式代理请求成功，而浏览器失败时，优先检查系统代理和浏览器自己的代理配置；请求也失败时，结合客户端日志检查策略选择、节点连接和 DNS。

现象	优先检查	下一步
内核启动失败	YAML 解析错误、监听端口冲突	退出旧进程，按日志定位字段
浏览器正常，终端失败	终端代理环境变量仍指向旧端口	更新地址后重开终端再测试
规则与旧客户端不同	模式、规则顺序、策略组名称	查看连接记录中的实际命中规则
重启后不能接管	服务启动状态、系统代理、TUN 权限	分别验证内核运行和接管开关
更新订阅后自定义规则消失	修改的是缓存还是持久扩展配置	重建本地覆写并再次执行更新测试

结束迁移前，至少完成一次订阅更新、一次客户端退出重开和一次系统重启，并复核直连网站、代理网站、内网资源三类目标。需要回退时，先关闭新客户端的系统代理与 TUN，退出新内核，再恢复旧客户端；不要通过同时启动两套客户端来“补上”缺失流量。

确认新环境稳定后再清理旧程序，并保留必要的订阅与规则备份。后续维护重点也随之明确：客户端版本、内核版本、订阅内容和本地覆写分别管理，出现问题时一次只变更其中一项。首次配置操作可继续查看使用指南，常见连接问题可查阅疑难解答。