一、先分清客户端、内核与订阅
Clash for Windows，简称 CFW，停止维护后，已有配置可能仍能连接，但客户端适配、依赖更新与故障修复不会因此继续。迁移的目标不是把旧目录完整覆盖到新程序，而是把订阅来源、个人规则和系统接管方式分别恢复。旧版客户端的数据库、服务组件与新客户端并不通用。
Clash Verge Rev 是桌面图形客户端，Mihomo 是负责解析配置、匹配规则和建立连接的内核。Mihomo 延续了 Clash Meta 的技术路线，支持的配置字段不能简单等同于早期 Clash 内核。订阅则是远程配置来源，可能包含节点、策略组、规则和 DNS 设置。三者需要分别检查，不能用“订阅导入成功”代替全部验收。
二、替代客户端怎么选：先看配置工作流
Windows 上可优先评估 Clash Verge Rev、Clash Nyanpasu 和 FlClash 这类使用 Mihomo 的客户端。项目是否仍在维护，应以迁移当天的发布记录、问题处理和内核更新记录为准；不要仅凭下载页标注“最新版”判断。也不要把名称接近的分支当作同一个项目。
| 候选客户端 | 适合的迁移重点 | 安装前核对 |
|---|---|---|
| Clash Verge Rev | 订阅管理、本地 Merge 或脚本处理、桌面系统代理与 TUN | 当前版本的覆写关联方式、服务安装状态和内核版本 |
| Clash Nyanpasu | 桌面配置管理与配置处理流程 | 当前版本选用的内核，以及本地配置处理能力 |
| FlClash | 希望在桌面与移动设备使用接近的操作习惯 | 平台支持范围、配置导入方式及本地规则编辑方式 |
如果旧 CFW 里主要维护订阅和少量 YAML 参数，Verge Rev 的 Merge 工作流通常更容易对照。如果依赖复杂 Parsers 脚本，选型重点应转为脚本接口、执行顺序与更新行为，而不是界面相似度。更多平台入口可在客户端对比中核对。
三、旧 CFW 需要备份哪些内容
在旧客户端还能启动时完成备份。通过 CFW「Settings」中的配置目录入口打开用户数据目录；不同安装形式和历史版本的目录位置可能不同，不要只搜索安装目录。先复制整个用户配置目录到离线备份位置，再单独整理下面的迁移清单。
- 原始订阅地址：记录每个订阅的名称、地址、更新间隔。带令牌的订阅地址相当于访问凭据，不要发到公开工单。
- Parsers 内容：保留匹配条件、YAML 修改项和脚本原文，注明分别作用于哪个订阅。
- 本地规则：记录规则顺序、引用的策略组名称、规则集地址与本地文件依赖。
- 端口与系统接管：记录 HTTP、SOCKS、混合端口、是否允许局域网，以及系统代理和 TUN 状态。
- 个人选择：记录规则模式、常用策略组的选中节点，以及 DNS 的自定义项。
不要把订阅中临时生成的节点列表当成唯一备份。订阅更新可能改变节点名称、凭据或策略组；只复制当前 YAML，容易失去后续更新能力。如果已找不到原始地址，可以先把现有 YAML 作为本地配置导入验证，再向订阅提供方找回更新入口。
备份完成后，关闭 CFW 的系统代理、TUN 和开机启动，再退出程序。旧服务如果仍在接管网络，应先停止。保留旧程序用于回退即可，不要让两个客户端同时争用系统代理或虚拟网卡路由。
四、导入订阅：先验证未覆写的基线
- 启动 Clash Verge Rev，进入「订阅」页，通过新建或导入入口添加原始订阅地址。具体按钮名称可能随版本变化。
- 更新订阅并将其设为当前配置。确认代理组和节点已经出现；只有订阅名称、没有节点，不算导入完成。
- 在「代理」页选择规则模式，再检查主要策略组的选项。自动选择组和手动选择组的行为不同，旧客户端的选中状态通常不会自动迁移。
- 暂时关闭 TUN，仅开启系统代理，用浏览器访问一个直连站点和一个需要代理的站点，再到「连接」页观察规则与出站。
导入失败时按错误类型处理
HTTP 401 或 403 通常需要检查令牌、账户权限和订阅地址；超时则需要区分 DNS、网络可达性和下载链路。YAML 解析错误应检查返回内容是否其实是网页或错误提示。缺少策略组、引用不存在的节点等错误，需要查看内核日志，而不是反复切换系统代理。
不要把原有订阅随意提交给在线转换站。需要转换时，先确认提供方是否直接支持 Mihomo 配置；第三方转换意味着额外传递订阅凭据。基线未通过之前，先不要叠加 DNS、规则和 TUN 修改。
五、Parsers 改成 Merge：按修改结果迁移
CFW Parsers 是客户端侧的配置处理机制，不是内核通用字段。旧文件中的 parsers:、匹配条件或 JavaScript 函数不能直接粘贴进 Mihomo 主配置。迁移时应先读出“修改了什么”，再选择 Verge Rev 的 Merge 或脚本处理方式。
| 旧 Parsers 行为 | 迁移方式 | 重点核对 |
|---|---|---|
| 覆盖一个标量或对象字段 | 优先使用 Merge，写成目标配置的 YAML 结构 | 字段层级、值类型、运行时最终值 |
| 前置或后置规则 | 使用当前版本明确支持的列表操作；否则使用脚本 | 是否保留订阅原规则、规则插入位置 |
| 重命名节点、按条件修改策略组 | 重新编写适配新客户端接口的脚本 | 名称引用同步更新、脚本返回完整配置 |
| 按订阅地址匹配不同处理 | 将相应覆写关联到对应订阅 | 切换订阅后是否错误应用到其他配置 |
Merge 示例：迁移日志级别与 DNS 缓存策略
下面的 YAML 适用于当前内核支持 cache-algorithm 的情况。它只演示两个明确的字段修改，不重写订阅的上游 DNS、代理组或规则。若旧 Parsers 的目的正是设定这两个参数，可在「订阅」页创建 Merge 类型的本地处理项，并按当前版本提供的管理入口关联到目标订阅。
log-level: info
dns:
cache-algorithm: arc保存后重新应用配置，检查运行时配置中 log-level 是否为 info，以及 dns.cache-algorithm 是否为 arc。如果内核提示未知字段，先核对实际内核版本和配置文档；不要通过忽略错误来完成迁移。原订阅若未开启 DNS，这段示例也不会替你启用 DNS。
规则数组不能按普通字段机械搬运
YAML 中的 rules 是有顺序的列表，通常按从上到下首次匹配生效。把只有两条规则的 rules: 放进 Merge，并不能保证得到“前置两条规则”的结果；具体列表处理语义取决于客户端实现与版本，可能覆盖原列表。旧 Parsers 的 prepend-rules 也不是可直接交给 Mihomo 的字段。
- 先用一条范围很窄的测试规则验证，例如
DOMAIN,example.com,DIRECT，不要一开始就改全局兜底。 - 检查最终规则列表：测试规则应位于预期位置，订阅原有规则仍然存在，
MATCH仍位于末尾。 - 引用订阅策略组时，组名必须完全一致；空格、大小写或符号不同都可能导致引用失效。
- 旧脚本包含条件判断时，按新客户端的脚本签名重写。不要假定 CFW 的参数、辅助函数和返回方式可以原样复用。
六、端口迁移：保留调用方式，不盲抄默认值
旧 CFW 常见 HTTP 端口为 7890、SOCKS 端口为 7891，但实际值可能被修改。Verge Rev 的默认端口也可能随版本或已有用户数据不同而变化。以「设置」中的端口项和运行时配置为准；迁移要么保持原端口，要么同步更新所有调用方。
例如，决定统一使用 127.0.0.1:7890 的混合端口时，可在客户端对应端口设置中配置，再核对最终字段。混合端口同时接受 HTTP 与 SOCKS 请求，不代表旧的独立端口会自动转发到这里。
mixed-port: 7890
allow-lan: false这段配置只表达本机混合入口；GUI 管理的字段可能覆盖 Merge 中的同名项，优先在客户端对应设置里调整。普通本机使用不需要开启局域网访问。若确实需要给其他设备提供代理，还应单独配置监听地址、认证和防火墙范围。
Windows 上的两项检查
netstat -ano | findstr :7890
curl.exe --proxy http://127.0.0.1:7890 https://example.com/ -I第一条用于检查端口占用及进程编号；若被旧客户端占用，先停止旧进程。第二条显式经过 HTTP 代理发出请求，可以区分“代理入口可用”和“应用是否使用系统代理”。HTTP 响应状态仍需结合目标站点判断，不能只凭命令结束就认定代理链路正常。
终端环境变量、Git 的代理配置、浏览器扩展和下载工具都可能保留旧端口。系统代理通常不会替这些应用改写独立设置。外部控制接口 external-controller 则是管理 API，不是上网代理端口，不应填进浏览器代理地址，更不应为了迁移而开放到所有网卡。
七、最后恢复 TUN 与 DNS，避免双重接管
系统代理依赖应用遵守系统代理设置；TUN 通过虚拟网卡和路由接管更多流量。两者不是同一个开关。基线与覆写都稳定后，再按客户端提示安装或启动所需服务，开启 TUN，并观察虚拟网卡、路由和日志。Windows 上的服务权限问题应通过服务状态处理，不要直接搬用旧 CFW 的服务文件。
- 确认旧 CFW 的 TUN 已关闭，退出其他可能接管默认路由的 VPN 工具；企业 VPN 场景先遵守组织网络要求。
- 启用 Verge Rev 的 TUN，先测试普通网站，再测试原先不遵守系统代理的应用。
- 检查连接页是否出现相应进程、目标和规则。如果请求没有进入内核，应先排查接管范围，而不是修改节点。
- 若出现域名失败、IP 可达，检查 DNS 上游、DNS 劫持配置与日志；不要同时改解析模式和全部服务器。
使用 Fake-IP 时，应用可能得到合成地址，常见地址池为 198.18.0.1/16，实际以配置为准。这不等于真实目标地址，也不能据此判断 DNS 受到污染。从旧 DNS 模式切换后，若 Windows 仍缓存旧结果，可执行 ipconfig /flushdns，再重启受影响的应用。
局域网打印机、NAS 或公司内部域名异常时，应分别检查 DNS 是否能解析内部名称、规则是否直连、TUN 路由是否包含相关网段。单独添加一条 DIRECT 规则并不保证内部 DNS 立即可用。详细字段可继续查阅高级用法。
八、迁移完成前的验收与回退清单
至少完成一次订阅更新和一次客户端重启，再决定移除旧环境。更新可以验证覆写是否独立保留，重启可以发现服务未自动启动、端口未保存或系统代理没有恢复等问题。以下项目全部通过，才算完成迁移。
- 订阅能够更新，节点和策略组完整，选中的订阅符合预期。
- 规则模式下，直连与代理请求分别匹配到正确规则和出站。
- 本地 Merge 或脚本在订阅更新后仍生效，没有丢失原规则列表。
- 浏览器、终端及常用下载工具使用的是新端口，旧进程不再监听。
- 需要 TUN 时，重启后服务与虚拟网卡状态正常；不需要时，保持关闭。
- 临时调试日志恢复到日常级别，分享日志前移除订阅令牌、节点凭据与敏感域名。
如果仍无法稳定工作，先关闭新客户端的系统代理和 TUN，再退出；确认路由与代理设置已恢复后，才启动旧客户端进行对照。回退时保持同一时间只有一套接管机制。不要把“两个客户端同时运行时偶尔能上网”视为可用结果，这往往会掩盖真正的端口或路由冲突。