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

Clash for Windows（下文简称 CFW）原项目已于 2023 年停止维护。已安装的程序不一定立即失效，但后续系统兼容、协议支持和问题修复不能继续依赖原项目。迁移的目标不是复制整个安装目录，而是保留订阅来源、分流意图和必要设置，再由新客户端重新建立运行环境。

客户端负责界面、订阅管理、系统代理和服务控制；内核负责解析配置、建立连接与执行规则。CFW 历史上存在不同内核使用方式，不能只凭客户端名称判断旧配置的能力。迁移前应记录实际运行的内核类型与版本，再检查新客户端内置的内核，而不是把两个软件的客户端版本号直接比较。

  • 优先迁移：订阅地址、本地 YAML、自定义规则、策略组名称、规则集来源。
  • 单独重建：系统代理开关、开机启动、服务权限、TUN 网卡与路由设置。
  • 按需保留：策略组当前选择、测速参数、DNS 设置和应用单独指定的代理端口。
  • 不要直接覆盖：旧客户端数据库、内核可执行文件、缓存目录和虚拟网卡驱动。

替代客户端：按平台与配置方式选择

Windows 桌面用户可以优先比较 Clash Verge Rev 与 FlClash。两者都围绕 mihomo 内核提供配置管理，但界面组织、配置增强入口和系统集成方式不同。Linux 与 macOS 用户也需要核对安装包架构，Android 用户则不能沿用 Windows 的安装包与系统代理操作。

客户端 平台覆盖 内核与迁移重点
Clash Verge Rev Windows、macOS、Linux 使用 mihomo；适合以桌面订阅管理、配置增强和系统集成为主的使用方式。
FlClash Windows、macOS、Linux、Android 使用 mihomo；适合希望在桌面与 Android 使用相近操作结构的用户，权限设置仍需逐平台处理。
Clash Nyanpasu Windows、macOS、Linux；本站提供的安装包范围以下载页为准 内核选项随发行版变化；导入前确认实际选择的内核，使用 mihomo 配置时选择匹配内核。
ClashX Meta macOS 面向 Meta/mihomo 生态；Windows 的服务、启动项和网络设置不能直接迁入。

内核版本以本机实际输出为准

客户端更新与内核更新不是同一个版本序列，同一客户端也可能允许切换内核。先在客户端的内核信息或日志中记录版本；若能定位实际内核文件，可以在终端读取版本。下面的命令需要在对应可执行文件所在目录运行，文件名以安装内容为准：

# Windows PowerShell
.\mihomo.exe -v

# macOS / Linux
./mihomo -v

不要为了显示较新的版本号而直接替换旧客户端内的内核。控制接口、启动参数和目录约定可能不匹配。选型时先核对订阅需要的协议，再确认目标客户端实际内核支持情况；不能把“能够导入 Clash 配置”理解为支持全部 mihomo 扩展字段。

迁移前备份：保存源文件与最终生效配置

旧客户端中看到的订阅文件，可能不是内核最终读取的内容。CFW 的 Parsers、Mixin 或手工修改可能在订阅之后继续改变端口、规则和策略组。如果只保存订阅链接，后加的规则很容易在新客户端里消失。

  1. 记录当前状态。保存客户端版本、内核版本、当前配置名称、运行模式，以及系统代理和 TUN 是否开启。
  2. 备份订阅来源。保存原始订阅 URL 与提供方名称。订阅 URL 往往含访问令牌，不要放入公开笔记或截图。
  3. 复制本地文件。从旧客户端打开配置所在目录，复制 YAML、引用的本地规则集和自定义处理脚本到独立备份目录。
  4. 记录处理结果。如旧客户端提供运行配置查看入口，另外保存最终配置，标清它与原始订阅的区别。运行配置可能含明文节点凭据，应按敏感文件保存。
  5. 保存系统设置。记录 HTTP/SOCKS 端口、局域网共享、绕过列表，以及浏览器或命令行工具中单独设置的代理地址。

Windows 可以通过「设置」→「网络和 Internet」→「代理」查看当前手动代理。若旧配置使用 127.0.0.1:7890，应把这个地址与端口记下来；它只是常见示例，不代表每台电脑都使用 7890。macOS 可在「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」核对，菜单名称可能随系统版本略有变化。

订阅导入：先复现连接，再恢复增强功能

在新客户端的订阅或配置页面添加原始订阅 URL，完成更新后选中该配置。不同发行版的入口可能叫“配置”“订阅”或“Profiles”，实际操作的关键是确认下载成功、内核加载成功，并且节点列表不是空的。若需要登录订阅提供方重新生成链接，应先确认新链接的格式与 mihomo 兼容。

  1. 关闭旧客户端的系统代理、TUN 和后台服务，再退出旧客户端。仅关闭窗口可能仍保留托盘进程。
  2. 在新客户端导入一份配置，先使用规则模式，不急于启用 TUN、局域网共享或开机启动。
  3. 选择一个已知可用的节点，检查连接日志，再开启系统代理并访问日常需要的站点。
  4. 确认基础连接正常后，再加入自定义规则、DNS 配置、规则集与配置增强。
  5. 手动更新一次订阅，检查增强内容是否仍然存在，避免只在当前文件中修改成功。

端口冲突先处理进程，不反复改配置

旧内核与新内核不能同时监听同一地址的同一端口。如果日志出现 address already in use，先检查 7890 的监听进程，而不是连续更换端口。下面是诊断示例：

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

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

如果确认需要改为 7891，浏览器扩展、终端环境变量及其他手动代理客户端也必须同步修改。系统代理开关通常只影响遵循系统设置的应用，不能保证所有程序自动跟随。

规则与自定义配置：检查引用、顺序和覆盖关系

mihomo 能处理许多 Clash 风格配置，但迁移不是字段逐字照抄。首先核对 proxies、proxy-providers、proxy-groups 和 rules 之间的名称引用。策略组被改名后，规则目标仍写旧名称就可能加载失败。规则从上向下匹配，兜底的 MATCH 应放在最后，否则后续规则没有机会生效。

用最小骨架确认本地配置加载

下面是供新客户端加载验证的最小 YAML。它只包含直连，不提供代理节点，也不能代替正式订阅。确认内核能加载后，再把真实节点或 provider 与策略组接入；不要把这份骨架直接覆盖到订阅文件上。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 业务出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,业务出口

这里的 业务出口 同时出现在策略组名称与规则目标中，两处必须一致。mixed-port 在同一端口提供 HTTP 与 SOCKS 代理入口。示例没有配置 external-controller，因此不会额外开放控制接口；如果客户端自行管理控制接口，应遵循客户端生成的配置。

订阅增强与规则集逐项迁移

  • Parsers 与 Mixin：属于客户端侧处理机制，不是通用的内核配置段。应把实际效果改写到新客户端提供的合并或脚本入口，不能假定旧脚本可原样执行。
  • 规则集：保留 rule-providers 的来源、behavior、format 与更新间隔，并检查 RULE-SET 中的名称引用。
  • 本地路径：旧目录里的相对路径在新工作目录下可能失效。迁移本地规则文件后，重新确认内核实际解析的路径与读取权限。
  • 旧脚本模式：若旧配置依赖 Clash Premium 的脚本能力，不能假设 mihomo 提供同样的运行方式。应将分流需求改为目标内核支持的规则或客户端处理逻辑。
  • 策略组状态：组定义能迁移，不代表当前选择会迁移。重新选择出口后，再观察自动测速和故障切换是否符合预期。

DNS 与 TUN：最后启用，单独验证

先用系统代理确认连接与规则，再启用 TUN，能减少同时排查 DNS、路由和权限的难度。TUN 在虚拟网卡层接管流量，通常需要系统权限或后台服务；Windows 服务安装、macOS 网络授权与 Android VPN 授权不是同一种机制，必须在目标系统重新完成。

DNS 配置应作为一个整体迁移。fake-ip 模式返回用于映射域名的地址，并不单独保证 DNS 请求一定经过代理。还要核对 DNS 上游、nameserver-policy、相关路由，以及 TUN 的 DNS 劫持设置。浏览器自带的安全 DNS、应用内 DoH 和其他 VPN 也可能改变解析路径。

  • 局域网服务：测试路由器管理页、NAS 和打印机。若本地域名依赖路由器 DNS，确认对应查询仍交给合适的本地解析器。
  • 工作网络：测试公司内网域名和 VPN。多个虚拟网卡同时改写默认路由时，应分别关闭再定位冲突来源。
  • DNS 缓存：切换 Fake-IP 模式或解析策略后，重启测试应用；Windows 可按需执行 ipconfig /flushdns 清理系统 DNS 缓存。
  • 监听范围：只有明确需要其他设备接入时才开启局域网共享，并检查防火墙规则。单机迁移不需要把代理端口暴露到局域网。

如果系统代理正常、TUN 开启后异常，优先检查权限、路由和 DNS，不要马上更换订阅。节点测速成功也只说明某条测试请求可完成，不能证明应用流量已被正确接管。

验收与回滚：更新订阅后再停用旧环境

迁移验收至少覆盖普通浏览器、手动指定代理的工具和需要 TUN 的应用。以下表格记录的是检查动作与预期结果，不是预先给出的实测成绩。建议对同一目标连续操作三次，并记录时间、命中规则和出口，避免把偶发连接成功当作迁移完成。

检查动作 预期结果 异常时先查
访问一个应直连的站点 连接记录命中预期直连规则 规则顺序、策略组引用、运行模式
访问一个应代理的站点 命中预期组，并使用选定出口 节点选择、订阅有效性、应用代理设置
访问局域网设备与内网域名 地址可达，解析结果符合本地网络要求 本地 DNS、Fake-IP 排除、TUN 路由
手动更新订阅并重启客户端 自定义规则仍生效，配置无加载错误 增强入口、覆盖顺序、文件路径
重启操作系统 启动项、服务与代理状态符合预期 旧启动项残留、权限、服务启动状态

失败时按相反顺序回滚

先关闭新客户端的 TUN 与系统代理，再停止后台服务，确认监听端口已经释放。随后启动旧客户端并恢复原配置与原代理状态。两个客户端不要同时争用系统代理或 TUN 路由。若新客户端已退出但浏览器仍无法联网，检查系统是否残留指向 127.0.0.1:7890 的手动代理，而该端口已经没有服务监听。

完成订阅更新、系统重启与常用应用验证后，再移除旧开机启动项并卸载旧客户端。保留一份离线配置备份及迁移记录，记录新客户端版本、实际内核版本、端口和增强规则入口。这样后续出现订阅变更或系统升级问题时，可以区分故障来自客户端、内核还是配置，而不必重新猜测整个链路。