迁移结论：换客户端，保留订阅与规则

Windows 用户可先比较 Clash Verge Rev 与 FlClash；macOS 用户再考虑 ClashX Meta；Linux 用户按发行版选择安装包；Android 用户可从 FlClash 开始。旧 CFW 不必先卸载。先备份，再导入新客户端，验证规则、DNS 与代理接管，最后关闭旧程序的自启动。

Clash for Windows 通常简称 CFW，原项目在 2023 年停止维护。常见末期版本为 0.20.39。它是图形客户端，不等于所有 Clash 内核，也不等于订阅服务。更换界面不会自动更换服务商；使用相同订阅时，可用代理仍取决于订阅提供方。

迁移时分清三个层次

  • 客户端：管理订阅、系统代理、服务权限与配置覆写，菜单和文件结构各不相同。
  • 内核：解析 YAML、执行代理协议、规则和 DNS。Clash Meta 后续以 mihomo 名称发展，新客户端是否支持某个字段，要看实际内核。
  • 订阅：提供节点或完整配置。节点列表与完整 Clash 配置不是同一种输入，导入前需要确认格式。

替代客户端：按平台与配置能力选择

优先选发布记录仍在更新、能说明内核版本、支持配置导出与日志查看的项目。维护状态会变化，下面是迁移候选清单，不把项目名称当作永久维护承诺。安装前从项目发布页确认近期版本、系统要求和已知问题，入口可从客户端下载页查找。

平台 候选客户端 迁移重点
Windows Clash Verge Rev、FlClash 核对覆写方式、服务模式、系统代理与 TUN 权限；不要复制 CFW 整个用户目录。
macOS Clash Verge Rev、FlClash、ClashX Meta 区分 Apple Silicon 与 Intel 安装包；重新授权网络接管所需组件。
Linux Clash Verge Rev、FlClash 核对 DEB、RPM 等包格式及发行版要求；桌面代理设置与 TUN 路由分别验证。
Android FlClash 按设备架构选包，确认 VPN 授权、应用分流和后台运行限制。
iOS 支持相应订阅格式的 iOS 客户端 先查配置格式和网络扩展能力；不能安装桌面 CFW，也不能假定可原样执行 CFW 脚本。

有覆写需求，先看配置机制

只需要订阅导入和手动选代理，选择成本较低。有自定义规则、DNS 或脚本时，应先确认新客户端能否把本地修改持久叠加到订阅之上。Clash Verge Rev 的合并配置、脚本处理与 CFW 的 Parsers 机制不是一套接口；FlClash 的配置处理也不能按 CFW 文件结构推断。具体名称以安装版本界面为准。

不要把“内置 mihomo”理解成“所有 CFW 功能完全兼容”。内核能识别的 YAML 字段，与界面如何保存、更新和生成配置，是两个问题。更多选型差异可查客户端对比。

备份清单：订阅地址、最终配置与本地修改

先在旧 CFW 中关闭自动更新订阅，避免整理期间配置变化。打开 Profiles（配置），记录当前启用的配置、订阅来源和更新时间；打开 Proxies（代理），记录每个手动选择组当前使用的选项；在 General（常规） 与 Settings（设置） 中记录端口、系统代理、TUN 和配置处理设置。

  1. 保存订阅地址：保留完整 URL，包括查询参数。订阅 URL 可能含访问令牌，按密码管理，不粘贴到公开讨论区。
  2. 保存原始 YAML：对正在使用的配置建立副本，标注它是订阅原文件还是经过处理的文件。界面中的编辑功能不一定展示最终运行内容。
  3. 保存覆写来源：分别复制 Parsers 设置、外部脚本、自定义规则、规则提供者地址与本地文件。
  4. 记录运行参数：例如实际混合端口 7890、监听地址、代理模式、DNS 模式和 TUN 开关。7890 是常见端口，不是每台设备的固定值。
  5. 记录特殊用途：浏览器扩展、终端环境变量、局域网设备或开发工具是否显式连接旧代理端口。

用户目录只作备份，不直接覆盖新程序

Windows 的常见 CFW 用户配置位置是 %USERPROFILE%\.config\clash，便携模式或自定义目录可能不同。应以旧客户端显示的实际路径为准。复制整个目录可以留作回滚资料，但不要把其中的数据库、缓存和客户端设置直接覆盖到新客户端目录。

订阅迁移：先验证原配置，再叠加覆写

首次导入先关闭新客户端的系统代理与 TUN，不急着接管网络。使用新客户端的订阅或配置导入功能添加原地址；如果订阅暂时不可访问，可导入备份 YAML 作为离线验证，但它不会自动获得后续节点更新。

  1. 检查导入日志，确认内容是 YAML 配置，而不是登录页面、错误页面或仅含代理链接的文本。
  2. 核对代理数量、策略组名称与规则数量；确认原来的手动选择组仍然存在。
  3. 启用这份配置，先运行内核配置检查，再查看启动日志是否出现字段不支持、目标不存在或文件读取失败。
  4. 检查实际生成配置。客户端全局设置可能覆盖订阅中的端口、DNS 或 TUN 字段。
  5. 原配置可启动后，再逐项添加覆写，每次只迁移一类修改。

订阅导入成功，仍可能不是同一套行为

旧配置可能依赖 CFW 特有的预处理，服务商返回的原始内容并不包含那些修改。另一种情况是订阅包含新内核支持的协议，旧客户端没有完整识别；迁到 mihomo 后代理列表反而出现差异。应比较实际生成内容，不能仅以“导入成功”判断迁移结束。

保留原服务商提供的兼容订阅入口。需要转换格式时，优先使用服务商或客户端明确支持的方法；把带令牌的地址交给陌生在线转换站，会增加订阅信息暴露风险。

自定义规则与脚本：迁移结果，不照搬接口

CFW 的 Parsers 可以通过匹配订阅 URL、合并字段或 JavaScript 改写配置。新客户端的脚本入口参数、返回值和运行环境可能不同。同样是 JavaScript，也不能保证旧文件直接执行。先把脚本拆成具体需求：追加规则、调整策略组、替换 DNS，还是修改代理名称。

规则先后顺序比复制数量更重要

规则通常从上到下匹配，命中后使用对应目标。具体域名规则应放在宽泛规则之前，最终兜底 MATCH 放最后。下面只是可以并入完整配置的规则片段，用于让本地名称和私有 IPv4 地址直连，不包含代理节点，也不是完整订阅。

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

迁移时应把这些条目插入现有规则的合适位置，而不是用片段替换整个 rules 列表。数组究竟被追加、前置还是整体覆盖，取决于新客户端的覆写机制，需要在生成配置中检查。

  • 策略组引用：原规则引用的组名必须在完整配置的 proxy-groups 中存在，名称与大小写保持一致。
  • 规则提供者：迁移 rule-providers 时同时检查 behavior、格式、URL 和本地路径，不要只复制 RULE-SET 条目。
  • 本地文件：旧目录的绝对路径在新客户端中通常失效；相对路径也需要确认以哪个配置目录为基准。
  • 重复规则：订阅已经包含的私网直连规则无需再次堆叠；重点是匹配位置和目标正确。

脚本按功能分批重写

先迁移纯 YAML 能表达的修改，再处理必须使用脚本的部分。每次执行后对比策略组、规则和 DNS，留意脚本是否改变了节点名称，导致策略组继续引用旧名称。不要把旧脚本中的文件访问、网络请求或第三方依赖视作新环境必然支持的功能。

更新订阅后再检查一次：如果自定义规则消失，说明修改只落在了临时生成文件，没有进入持久覆写层。相关字段可继续查阅YAML 配置说明。

端口、DNS 与 TUN：切换接管时避免双实例

配置能启动后再切换网络接管。先关闭 CFW 的系统代理与 TUN，然后正常退出 CFW；确认它的后台服务或残留进程没有继续监听端口，再打开新客户端的系统代理。两个程序同时争用系统代理或路由，常会造成连接时好时坏。

混合端口改变，应用内代理也要改变

假设旧客户端监听 127.0.0.1:7890，新客户端实际监听 127.0.0.1:7897，浏览器扩展、终端与开发工具里的手动代理都要同步。端口可以保持原值，但前提是旧进程已释放它。以下是监听参数示例，应以新客户端最终运行配置为准。

mixed-port: 7897
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

mixed-port 同时提供 HTTP 与 SOCKS 代理入口，不等于外部控制 API 端口。不要为了搬家而开放外部控制接口到所有网卡；原先有局域网共享需求的设备，应另行核对监听范围、防火墙和访问限制。

DNS 不宜连同旧缓存一起搬

记录旧配置使用 fake-ip 还是 redir-host，以及上游解析器、域名策略和过滤名单，再检查新客户端是否覆盖了它们。迁移后出现“节点可连、网站打不开”，应查看 DNS 请求与规则命中，而不是立即重复换节点。清理缓存或切换模式只能作为有依据的排查步骤，不能代替检查配置。

TUN 最后启用

先用系统代理验证浏览器，再启用 TUN 验证不遵循系统代理的程序。Windows 可能需要客户端服务与管理员授权，macOS 需要对应的权限组件，Linux 需要足够的网络管理权限；Android 则通过系统 VPN 授权工作。已有企业 VPN、其他代理软件或虚拟机网络时，要额外检查路由与 DNS 冲突。

验收与回滚：更新一次订阅后再卸载 CFW

迁移完成的标准是原有用途能够重现，而不是延迟测试出现数字。建议按下面的检查表逐项记录结果。不要编造一组测速数值作为成功凭据，同一节点在不同时间的延迟也不能证明规则与 DNS 正确。

  1. 网页连接：分别访问预期直连和预期代理的网站，在日志或连接列表中核对命中的规则与策略组。
  2. 本地资源：确认路由器管理页、局域网服务与公司内网仍可按预期访问。
  3. 应用连接：检查浏览器之外的开发工具或其他程序，区分它使用系统代理、手动代理还是 TUN。
  4. 订阅更新：手动更新一次，确认自定义规则、策略组调整和 DNS 覆写仍存在。
  5. 重启恢复：重启新客户端，检查当前配置、选定代理、服务权限与开机启动状态。
  6. 权限收尾：关闭旧 CFW 自启动与旧服务，保留离线备份，确认新程序退出后系统代理能正常恢复。

异常时按层回退

新程序不能启动，先移除覆写，验证原始订阅；能启动但不能上网，先关 TUN，仅验证系统代理；浏览器正常但某个应用失败，再检查该应用的代理地址和路由。日志应按操作时间读取，先找第一条配置或连接错误，避免被后续重复超时带偏。

确需短期回到旧客户端时，先关闭新客户端的接管并退出，再启动备份的旧环境。不要同时开启两套系统代理或 TUN。备份中含订阅令牌、控制接口密钥和代理凭据，保存到受保护的位置；待新配置稳定、更新与重启均通过验证后，再处理旧安装。

迁移最关键的四项是：订阅来源保留、覆写来源可追溯、端口与接管一致、更新后规则仍生效。按这个顺序做，客户端替换就不需要演变成整套配置重建。