Clash for Windows 停更后如何迁移:订阅、覆写脚本与常用设置搬家对照

先分清需要搬走的四类内容

Clash for Windows（下文简称 CFW）停止维护后，迁移的重点不是把旧程序目录完整复制到新客户端，而是分别处理订阅来源、配置加工逻辑、代理设置和 Windows 集成。本文以迁移到 Clash Verge Rev 为主线。其他使用 mihomo 内核的客户端也可以沿用检查顺序，但菜单名称、脚本入口和数据目录不能直接照搬。

客户端与内核是两层软件。界面负责订阅下载、开机启动和系统代理开关；mihomo 内核负责读取最终配置、监听端口和执行分流。旧客户端的界面配置文件，不等于可以交给新内核读取的 YAML 文件。

旧客户端中的内容	迁移方式	需要重新检查
Profiles 中的订阅	重新导入原始订阅地址	有效期、返回格式、节点和策略组
Parsers 与自定义规则	整理意图，改写为目标客户端的覆写	执行顺序、规则顺序、策略组名称
System Proxy 与监听端口	在新客户端中重新设置	实际监听地址、HTTP 与 SOCKS 端口
Service Mode、TUN、开机启动	重新安装或启用对应功能	服务权限、DNS、路由和启动入口

替代客户端如何选

希望保留桌面订阅管理与覆写工作流：可以优先检查 Clash Verge Rev，重点确认当前发行版的脚本、合并配置及服务模式说明。
更重视不同设备上的操作一致性：可以比较 FlClash 等客户端，但不要假定其覆写脚本与 CFW Parsers 兼容。
只需要常规订阅与规则模式：先从导入订阅、选择策略组和系统代理开始，不必为了迁移而立即开启 TUN。

具体客户端入口见客户端对比。安装前确认 Windows 架构和发行说明，安装后在「关于」页记录客户端版本与内核版本。遇到问题时，这两项信息比只写“最新版”更有用。

备份旧配置，保留可回退的连接方式

先让 CFW 保持可用，再做备份。常见安装方式的数据位于用户目录下的 .config/clash，但便携模式和自定义启动参数可能改变位置。应从旧客户端的配置目录入口定位实际文件夹，不要只根据网上给出的路径寻找。

保存订阅原始地址，并记录订阅名称、更新时间、更新间隔。地址通常包含访问凭据，应只保存在本地可信位置。
备份本地 YAML、Parsers 内容及相关脚本。记录每段加工逻辑的目的，例如“把开发站点加入指定策略组”，而不只保存代码。
记录当前模式、选中的策略组、HTTP/SOCKS 端口、是否允许局域网连接，以及 TUN 和 DNS 的自定义项。
记录开机启动、服务模式和系统代理状态。先截图，再退出旧客户端，避免读取尚未写入磁盘的配置。
把备份复制到独立文件夹。不要让新客户端直接使用旧客户端的数据目录，也不要在首次测试前卸载旧程序。

开始新客户端测试前，关闭 CFW 的系统代理和自动启动，并确认其内核进程已经结束。两个客户端即使使用不同端口，也可能交替改写 Windows 系统代理；两个 TUN 实例同时运行还可能导致路由与 DNS 行为难以判断。

先导入原始订阅，再检查生成配置

在 Clash Verge Rev 的「订阅」页面使用导入入口，粘贴原始订阅地址，再选中导入的配置。不同发行版的按钮文字可能是「导入」或「新建」，应以当前版本为准。此时先不要附加旧脚本，目的是确认订阅本身能被新客户端下载并被 mihomo 接受。

不要把三种地址混在一起

订阅地址：返回节点或完整配置，通常带有令牌，可以作为更新来源。
服务商用户中心：返回登录页面，复制到订阅框后常见结果是 HTML 解析错误。
本地导出的 YAML：可以用于离线排查，但通常不会自动恢复原订阅的更新关系。

导入后检查节点数量、策略组和规则是否存在。节点数不同不一定代表丢失：返回内容可能受订阅参数、User-Agent 或服务商模板影响。先对照原始响应，再考虑调整请求头；不要把包含凭据的地址交给不明在线转换服务。

按三个层次验证

下载层：订阅更新成功，返回的不是登录页、过期提示或空内容。
配置层：内核成功启动，日志没有未知字段、策略组引用不存在或 YAML 类型错误。
连接层：选定一个可用节点，用实际请求测试。延迟测试成功只说明测试目标可达，不能替代浏览器访问与分流验证。

若原订阅需要 CFW 的 Parsers 才能正常使用，应先区分“格式转换”与“规则追加”。普通规则追加可以在下一步重建；如果返回格式根本不适合 mihomo，应向订阅提供方索取适配格式，而不是依靠复制旧目录解决。

Parsers 迁移：保留逻辑，不复制入口语法

CFW 的 Parsers 可以按订阅 URL 匹配，再执行 YAML 修改或 JavaScript。Clash Verge Rev 的合并配置、脚本配置使用自己的调用约定与作用范围。旧代码中的 parsers、reg、yaml 等外层结构不能当作普通 mihomo 字段粘进最终配置。

建议先把旧逻辑拆成三组：追加或删除规则、修改 DNS 等顶层字段、重写节点或策略组。每次只迁移一组，应用后查看客户端提供的最终配置或运行配置，再继续下一组。需要精确字段说明时，查阅规则语法与DNS 配置。

示例：把 GitHub 域名加入已有策略组

以下示例适用于采用 function main(config) 入口的 Clash Verge Rev JavaScript 脚本配置，不是 CFW Parsers 的完整替代文件。示例要求订阅中已经存在名为「节点选择」的策略组；使用前应核对真实名称，大小写和空格都要一致。

function main(config) {
  const groups = Array.isArray(config["proxy-groups"])
    ? config["proxy-groups"]
    : [];

  if (!groups.some(group => group.name === "节点选择")) {
    throw new Error("未找到策略组：节点选择");
  }

  if (!Array.isArray(config.rules)) {
    throw new Error("当前配置缺少 rules 列表");
  }

  const customRule = "DOMAIN-SUFFIX,github.com,节点选择";
  config.rules = [
    customRule,
    ...config.rules.filter(rule => rule !== customRule)
  ];

  return config;
}

这段脚本把规则放到最前，并避免重复添加完全相同的条目。它只处理 github.com 及其子域名；GitHub 使用的其他资源域名不会因此自动纳入。迁移时应保留明确的匹配范围，不要把一条示例扩展成未经验证的完整站点规则集。

规则顺序与合并方式是重点

规则通常按顺序匹配：自定义规则放在最终兜底的 MATCH 后面，通常不会被执行。
数组不一定自动追加：不同合并入口可能替换整个 rules 数组。修改后要检查原订阅规则是否仍然存在。
订阅级与全局覆写范围不同：仅服务于某个订阅的策略组规则，应绑定该订阅，避免切换后引用不存在的组。
每次更新都会重新生成配置：直接修改缓存或生成文件容易在更新后丢失，应把改动放在客户端支持的持久化覆写入口。

重设系统代理与端口，确认只有一个内核监听

不要根据旧界面直接假定新端口也是 7890。以下把 127.0.0.1:7890 作为混合代理端口示例，实际操作以新客户端显示的值为准。mihomo 的 mixed-port 可以在同一端口接收 HTTP 和 SOCKS 代理请求；单独的 HTTP、SOCKS 监听则可能使用不同端口。

先检查监听，再打开系统代理

在 PowerShell 中执行下面的命令，查看示例端口的监听进程。若新客户端提示端口被占用，先用进程 ID 定位程序，不要直接结束不认识的系统进程。

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Name "*clash*", "*mihomo*" -ErrorAction SilentlyContinue |
  Select-Object Id, ProcessName, Path

确定监听正常后，在新客户端打开「系统代理」。Windows 11 可通过「设置」→「网络和 Internet」→「代理」检查手动代理地址；Windows 10 对应路径为「设置」→「网络和 Internet」→「代理」。端口应与新客户端的 HTTP 或混合端口一致。

如果只是本机使用，通常不需要开启允许局域网连接。迁移时不要为了消除连接报错就把监听地址改成所有网卡，也不要把控制接口开放给局域网。控制接口地址和密钥属于另外一组配置，并不是系统代理端口。

用显式代理请求隔离问题

curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/
curl.exe --proxy socks5h://127.0.0.1:7890 --head --max-time 15 https://example.com/

示例设置了 15 秒超时，且显式指定代理，不依赖浏览器是否读取系统设置。第二条命令的 socks5h 让目标域名交给代理侧解析。收到 HTTP 响应说明这条测试路径已建立，但仍需到连接面板检查命中的规则、策略组和出站节点。

浏览器能用而终端不能用时，继续检查终端环境变量与应用自身设置。HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 可能仍指向旧端口；WinHTTP 代理也与 Windows 用户级系统代理分开管理。不要把一次系统代理开关理解为所有应用都已迁移。

TUN 与 DNS 放到基础连接通过之后

系统代理测试通过后，再决定是否需要 TUN。TUN 通过虚拟网卡与路由接管流量，可以覆盖部分不遵循系统代理的应用，但它并不意味着所有流量必然走远端代理。最终去向仍由规则、路由排除项和直连策略决定。

先关闭旧客户端的 TUN，确认旧内核与旧服务不会自动重启。
按新客户端当前版本的说明安装或启用服务模式。旧 CFW 的服务不能直接当作新客户端的服务使用。
先保留新客户端生成的 TUN 基础设置，不要同时搬入旧虚拟网卡参数、DNS 劫持规则和自定义路由。
打开 TUN 后测试普通网站、局域网设备以及休眠唤醒。企业 VPN 和其他虚拟网卡应分别测试，避免同时启用后无法定位冲突。

DNS 需要单独核对 enhanced-mode、fake-ip-filter、上游解析器和客户端生成的覆写。旧配置使用 fake-ip，不代表应把所有旧 DNS 字段原样复制；字段支持情况应以当前 mihomo 版本为准。涉及规则化解析时，还要检查域名规则与 DNS 请求路径之间的关系。

开启 TUN 后只有公司内网域名失败，优先检查企业 DNS 和分流要求；只有局域网地址失败，检查路由与直连规则。不要先把整个内网范围送到远端节点。关闭 TUN、恢复系统代理测试，是区分订阅问题与虚拟网卡问题的有效方法。

更新验证、故障定位与旧客户端清理

迁移完成不应只以“网页能打开”为标准。至少手动更新一次订阅、重启一次客户端，并验证一次 Windows 登录后的自动启动。只有更新后自定义规则仍保留，才说明覆写真正进入了持久化流程。

现象	优先检查	下一步
导入后节点为空	订阅响应、有效期、格式	暂停覆写，单独验证原始订阅
配置应用失败	脚本报错、规则目标、字段类型	停用最近增加的那一项修改
更新后规则消失	是否修改了生成文件	迁入持久化脚本或合并配置
本地端口连接被拒绝	内核状态、实际端口、占用进程	先恢复监听，再检查网络
重启后代理地址变回旧值	旧客户端自启、旧服务、其他代理程序	只保留一个代理管理入口
TUN 开启后内网失效	路由、DNS、企业 VPN	退回系统代理，逐项复测

完成迁移前的检查清单

订阅可以手动更新，节点与策略组符合预期。
自定义规则命中正确，规则中的策略组名称真实存在。
正常退出和重新启动后，系统代理端口没有被旧程序改回。
需要代理的浏览器、终端或其他应用分别通过测试。
若启用 TUN，局域网、DNS、休眠唤醒和其他 VPN 已分别检查。
原订阅地址、覆写脚本与设置记录已保存在独立备份中。

通过这些检查后，再卸载旧客户端，并使用旧客户端提供的管理方式移除不再需要的服务。若需要临时回退，先关闭新客户端的系统代理与 TUN、退出其内核，再启动旧客户端；不要让两套程序同时接管网络。迁移后的日常设置可继续参考连接验证教程，订阅维护步骤见订阅导入说明。