迁移替代 预计阅读 12 分钟

Clash for Windows 停更后迁移到 Clash Verge Rev:订阅、规则与快捷设置搬家步骤

梳理停更客户端的替代选择,按导出订阅、核对配置字段、迁移覆写脚本、重设系统代理的顺序,把旧环境平稳搬到 Verge Rev。

迁移范围：客户端设置与内核配置分开处理

Clash for Windows（下文简称 CFW）已停止维护。迁移到 Clash Verge Rev，不只是换一个窗口：界面、配置管理方式和后台服务都会改变，负责解析订阅、匹配规则与建立连接的内核也需要重新核对。Clash Verge Rev 使用 mihomo，不能把 CFW 的整个用户目录覆盖过去，再期待所有设置原样生效。

迁移前先记录 CFW「General」中显示的版本、端口、运行模式，以及「Profiles」里当前选中的配置名称。若旧环境是 CFW 0.20.39，这只是客户端版本，不代表订阅使用了哪些协议，也不代表它与当前 mihomo 的全部字段兼容。新客户端与内核的实际版本，应分别从当前安装的界面与启动日志确认。

迁移项目建议做法需要重新核对
订阅地址或 YAML 文件在新客户端重新导入下载结果、协议与策略组名称
自定义分流规则改为独立覆写或合并配置规则顺序、目标策略与资源路径
CFW Parsers 与脚本按原有目的重新实现脚本入口、执行环境与合并语义
端口与系统代理在新客户端重新设置端口冲突、代理绕过与应用配置
TUN 与后台服务由新客户端重新安装、授权权限、路由、DNS 与虚拟网卡
快捷键与开机启动逐项重建旧启动任务是否仍在运行

第一步：备份订阅、规则与本机参数

保存原始来源，不只保存当前节点列表

进入 CFW「Profiles」，记录正在使用的远程订阅地址。若菜单提供复制 URL 或编辑功能，可从对应入口读取；如果拿到的是本地文件，则复制该 YAML 文件。订阅链接通常含有访问令牌，应放在本机受限目录，不要上传到公开仓库，也不要把带令牌的截图发到公共讨论区。

用户目录常见于 %USERPROFILE%\.config\clash，但便携模式和自定义目录可能不同。应优先使用 CFW「General」中的「Home Directory」入口定位实际目录。退出客户端后复制整个目录，保留原始文件名；迁移时只从副本提取资料，不把该目录作为新客户端的数据目录。

区分原始订阅与最终运行配置

原始订阅可能只有节点与策略组，而最终运行配置还包含客户端注入的端口、DNS、TUN 和脚本结果。若只保存原始订阅，自定义规则可能丢失；若只保存最终配置，又可能把旧机器的路径和端口带进新环境。两份都保存，并在文件名中标注用途，比只留一张界面截图更可靠。

最终配置还可能包含代理密码、控制接口密钥等敏感信息。备份应限制访问，排障分享时只摘录相关字段。不要为了读取远程订阅，把链接交给不明订阅转换网站。

第二步：导入订阅，验证 mihomo 配置兼容性

  1. 从客户端下载页选择适合系统架构的 Clash Verge Rev 安装包。安装完成后，先保持系统代理与 TUN 关闭。
  2. 在新客户端「订阅」页面导入原始订阅 URL，或使用本地文件导入入口添加 YAML。不同版本的按钮名称可能略有差异，以页面显示为准。
  3. 选中新配置，检查配置校验与内核日志。先解决解析错误，再处理连接问题。
  4. 在「代理」页面确认策略组和节点已出现，选择一个已知可用的节点，再启用规则模式。

mihomo 可以读取大量 Clash 风格配置，但“能够解析”不等于“行为完全一致”。旧订阅里的协议参数、规则集格式和客户端专用扩展仍需要检查。尤其是旧配置中的 script: 分流，不应当作 CFW Parsers 的 JavaScript，也不能假定它在 mihomo 上原样运行；应按当前内核文档改写为支持的规则或逻辑规则。

按错误位置修复，不批量删除未知字段

需要直接测试 YAML 时，可使用与客户端相同版本的 mihomo 执行配置检查。下面是 Windows PowerShell 示例，前提是命令所在目录已有该内核文件和用于测试的配置；检查通过只说明配置可加载，不代表远端节点可连通。

.\mihomo.exe -t -f .\migration-test.yaml

第三步：重建规则覆写，避免更新订阅后丢失

不要把长期维护的自定义规则直接写入远程订阅缓存。下一次更新可能覆盖这些修改。应把“远程节点与策略组”和“本地长期设置”分开：前者交给订阅更新，后者通过 Clash Verge Rev 提供的合并配置或脚本机制处理，并确认关联到当前配置。

先迁移静态规则，再迁移脚本

CFW Parsers 描述的是客户端侧的预处理流程，不是通用内核配置。将含有匹配条件和处理步骤的 Parsers 文件直接粘贴进新客户端的合并编辑器，通常不会产生相同结果。建议先列出每段逻辑的目标，例如“把一个域名设为直连”“删除过期节点”“给策略组增加筛选条件”，再选用静态规则、合并或脚本逐项重建。

下面两条是可用于本地覆盖的规则片段，不是完整订阅。example.com 是文档示例域名，应按实际业务替换；这里使用内置策略 DIRECT，因此不依赖订阅的策略组名称。

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

需要动态处理时，核对脚本入口

若当前版本的脚本编辑器使用 main(config) 入口，可按下面形式前置一条规则。若编辑器自带不同模板，应遵循当前模板。脚本必须返回配置对象；这段代码只能放在脚本编辑器中，不能作为 YAML 导入。

function main(config) {
  const localRule = "DOMAIN-SUFFIX,example.com,DIRECT";
  const existingRules = Array.isArray(config.rules) ? config.rules : [];
  config.rules = [
    localRule,
    ...existingRules.filter((rule) => rule !== localRule)
  ];
  return config;
}

脚本会保留原有规则的相对顺序，同时避免示例规则重复出现。实际项目还应检查是否有范围更大的前置规则、是否依赖规则提供器，以及后续合并步骤会不会再次覆盖结果。迁移时每次只启用一项覆写，观察最终配置后再继续，排障范围会更清楚。

第四步：切换系统代理，重新配置端口与快捷设置

停止旧内核，再让新客户端接管

  1. 在 CFW「General」关闭「System Proxy」。如果启用了 TUN，也先关闭，再从托盘退出 CFW。
  2. 检查任务管理器，确认旧内核进程已经退出。若端口仍被占用，先确认进程归属，不要直接结束不明系统进程。
  3. 在 Clash Verge Rev「设置」中核对端口与系统代理选项。相关项目可能位于端口设置、系统设置或高级设置，具体分组随版本调整。
  4. 启用新客户端的系统代理，重新打开测试应用，在「连接」页面查看请求是否进入内核。

例如，旧软件被手动配置为连接 127.0.0.1:7890，新客户端却监听 7897，该软件不会因为切换系统代理而自动改端口。可选择在新客户端保留旧端口，或逐一修改浏览器扩展、终端环境变量和开发工具的手动代理。7890 与 7897 在这里是排查示例，不应据此认定某个版本的默认值。

netstat -ano | findstr ":7890"
netstat -ano | findstr ":7897"

输出中处于 LISTENING 状态的行可用于查找监听进程，最后一列是 PID。随后在任务管理器「详细信息」核对该 PID。控制接口端口与代理端口用途不同，例如配置中的 external-controller 不能拿来填写浏览器 HTTP 代理。

快捷键和启动项手工重建

第五步：最后迁移 TUN 与 DNS，分层验证连接

先验证系统代理，再启用 TUN。系统代理依赖应用遵循代理设置；TUN 通过虚拟网卡与路由接管流量，两者覆盖范围不同。若同时改变内核、规则、DNS 和 TUN，出现问题时很难判断故障来自哪一层。

在新客户端「设置」中安装或启用所需服务，并按提示完成管理员授权，然后再开启「TUN 模式」。不要把旧客户端的服务目录或虚拟网卡文件复制过来。迁移期间应避免与另一套 VPN、旧 TUN 服务同时接管默认路由。

DNS 配置要检查最终生效结果

若旧环境使用 fake-ip，先核对新运行配置中的 dns.enable、dns.enhanced-mode 与过滤列表。不要只在订阅文件里看到这些字段，就认为客户端最终一定照原样运行。界面设置、全局覆写和订阅都可能参与生成运行配置。

对于 mihomo 的 TUN，dns-hijack 可用于接管匹配的传统 DNS 流量，但不意味着会自动接管浏览器自带的加密 DNS。浏览器“安全 DNS”、系统加密 DNS 与其他 VPN 的解析行为也需要单独核对。修改后如遇到旧解析结果，可关闭相关应用并重试；Windows 的 ipconfig /flushdns 只清理系统 DNS 缓存，不会清除所有应用或内核缓存。

验证阶段检查内容判断依据
配置加载选中订阅并启动内核日志没有配置解析失败，节点与策略组可见
系统代理用遵循系统代理的应用访问连接页可见请求，匹配规则和出口符合预期
自定义规则访问规则覆盖的目标命中指定规则，而非提前落入其他规则
订阅更新手动更新一次当前订阅本地覆写保留，策略组引用仍有效
TUN 接管检查原本不使用系统代理的应用路由与连接记录符合设计，内网访问正常
重启恢复退出客户端并重新启动端口、服务、启动项与策略选择按预期恢复

常见迁移故障与回退顺序

订阅能导入，但浏览器打不开网页

先看内核是否运行，再看系统代理指向的地址与端口。若「连接」页完全没有请求，优先检查应用是否使用系统代理、手动代理是否仍指向旧端口，而不是立即更换节点。若已有连接记录，再根据命中规则、策略组选择和错误日志判断出口问题。

节点测试有延迟，实际访问仍失败

延迟测试只说明指定测试目标在当时得到了响应，不能证明所有网站、UDP 或 DNS 都正常。分别测试一个应直连的目标和一个应走代理的目标，观察两条请求的规则与出口。不要拿一次延迟数值替代整个迁移验收。

更新订阅后规则消失

检查修改是否写进了远程配置缓存，或覆写只关联到了另一个订阅。重新检查合并顺序，确认自定义规则没有被后续数组替换，也没有放在 MATCH 后面。规则采用从上到下的匹配流程，位置会直接影响结果。

暂时回退到 CFW 的操作顺序

  1. 在新客户端关闭系统代理与 TUN，再退出新客户端。
  2. 确认新内核已停止，相关端口不再被占用；不要在两个客户端之间反复抢占系统代理。
  3. 启动保留的旧环境，恢复原配置与原接管方式，记录新环境失败的具体日志。
  4. 根据记录修复新配置，再按相同顺序进行下一轮切换。

回退是短期排障措施，不改变旧客户端已停止维护的事实。完成订阅更新、规则命中、DNS、内网访问和重启恢复测试后，再清理旧启动项与后台服务。关于系统代理与 TUN 的基础设置，可继续查看使用指南；涉及 mihomo 字段含义时，应对照协议手册核实，不要用界面名称推断内核行为。

下载Clash平台与客户端选择