原客户端停更之后：迁移到 mihomo 内核客户端的选型与配置搬家步骤

1. 先分清客户端、内核与订阅

Clash for Windows（CFW）原项目已停止维护。旧安装程序仍可能启动，已有节点也可能继续连接，但这不代表图形界面、依赖组件和代理内核仍会获得修复。迁移的目标不是把旧程序换一个名字，而是把订阅来源、本地规则和系统接管方式迁入仍在维护的客户端。

Clash Meta 是 Clash 的衍生内核项目，后来更名为 mihomo。图形客户端负责订阅管理、托盘菜单、系统代理和服务安装；mihomo 内核负责解析配置、建立连接、DNS 与规则匹配。选择支持 mihomo 的客户端，并不意味着它能直接读取 CFW 的整个用户目录。

订阅：通常是带访问凭据的 URL，返回节点列表或完整 YAML 配置。账号权限、流量和有效期仍由订阅提供方管理。
内核配置：常见键有 proxies、proxy-groups、rules、dns 与 tun。
客户端数据：包含订阅索引、界面偏好、更新计划、覆写挂载关系等，格式由客户端决定。
系统接管：系统代理、TUN 虚拟网卡、后台服务属于另一层状态，不能只靠复制 YAML 完成迁移。

2. 按平台选择 mihomo 客户端

先看系统架构，再看配置编辑与覆写能力。安装包名称中的 x64、ARM64 对应不同处理器；macOS 的 Apple 芯片与 Intel 版本也要区分。客户端发布号与内核版本是两套编号，安装后应在“关于”或“内核”页面分别记录，不能仅凭界面名称判断正在运行的内核。

平台	可评估的客户端	迁移前重点确认
Windows	Clash Verge Rev、Clash Nyanpasu、FlClash	订阅覆写入口、服务安装权限、开机启动和 TUN 接管方式。
macOS	Clash Verge Rev、FlClash、ClashX Meta	芯片架构、系统代理授权，以及所选发行版提供的增强接管能力。
Linux	Clash Verge Rev、FlClash，或独立 mihomo 内核	发行版包格式、桌面托盘支持、服务权限和配置目录。
Android	FlClash 等基于 mihomo 的客户端	VPN 授权、后台运行限制、分应用代理及订阅更新方式。
iOS / iPadOS	先检查客户端明确支持的订阅格式	支持 Clash 配置不等于使用 mihomo；规则与脚本可能需要重新适配。

桌面端先检查三个功能入口

在“订阅”或“配置”页面确认可以从 URL 导入，并能单独更新当前订阅。
在“设置”中找到端口、系统代理、TUN 和内核日志；记录当前值，不急于开启所有功能。
找到配置覆写、合并配置或脚本入口，确认它作用于单个订阅还是全局配置。

菜单名称会随客户端和版本变化。以 Clash Verge Rev 为例，可先从「订阅」导入链接，再到「设置」查找系统代理、虚拟网卡及服务相关选项。若界面入口不同，先依据当前版本文档核对，不要直接套用 CFW 的菜单路径。各平台安装入口集中在客户端下载页。

3. 备份 CFW 配置，建立迁移清单

Windows 上 CFW 常见用户目录是 %USERPROFILE%\.config\clash，但便携部署、启动参数或自定义目录可能改变位置。应从旧客户端的「General」→「Home Directory」打开实际目录；若界面提供的是路径字段或打开目录按钮，以显示位置为准。

退出旧客户端后，把整个配置目录复制到仅本人可访问的备份位置，再单独整理以下内容。只保存当前选中的 YAML，往往会漏掉订阅地址和配置增强逻辑。

订阅来源：保存原始 URL、订阅名称、更新间隔，以及是否为本地文件。不要只记录节点名称。
本地配置：保存 profiles 中使用的 YAML 和相关资源，标明哪个文件是手写配置、哪个会被订阅刷新。
增强内容：导出或复制 CFW 的 Parsers、合并规则、脚本和它们的匹配条件。
运行参数：记录 HTTP、SOCKS 或混合端口，是否允许局域网访问，以及 DNS、TUN、绕过地址设置。
策略选择：记下常用代理组当前选中的节点；选择缓存不一定能跨客户端恢复。

4. 先迁移订阅，再检查代理组与规则

第一轮只验证基础连接

关闭旧客户端的系统代理、TUN 和自动启动，然后退出旧程序；如果安装过后台服务，还要确认服务不再运行。
打开新客户端，用原始订阅 URL 新建订阅。不要把旧客户端整个数据目录覆盖到新目录。
更新订阅并选中配置，查看日志是否出现 YAML 解析错误、未知协议或代理组引用不存在等信息。
选择规则模式，手动选定一个节点。先使用系统代理验证浏览器，暂时保持 TUN 关闭。

订阅可能只包含节点，也可能包含完整的 proxy-groups 和 rules。节点型订阅需要搭配客户端模板或自己的主配置；如果导入后只有节点、没有可用策略组，应该先确认订阅类型，而不是直接归因于 mihomo 不兼容。

规则迁移必须保持顺序与引用一致

rules 从上到下匹配，MATCH 通常放在最后。自定义域名规则应插入兜底规则之前；规则引用的代理组名称必须与 proxy-groups 一致，包括空格和大小写。以下是用于说明顺序的规则片段，不是完整订阅配置：

规则片段：优先匹配局域网与指定域名

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,出口选择

这个片段要求已有名为“出口选择”的代理组。示例域名仅用于展示语法，应换成实际需要直连的域名。若使用客户端的“前置规则”功能，通常只需要填写列表项，不要再套一层 rules:。具体输入格式以该入口的说明为准。

使用 rule-providers 时，还要迁移每个 provider 的 type、behavior、format、url、path 与更新间隔。相对 path 依赖新内核的工作目录；旧缓存目录没有一起迁移时，需要允许重新下载，不能把“规则文件不存在”当作节点故障。

5. 将 Parsers 与覆写脚本改成新客户端格式

CFW 的 Parsers 不是 mihomo 的通用配置标准。即使两边都允许写 JavaScript，它们接收配置的参数、返回值、执行顺序和可用接口也可能不同。把旧脚本原样粘贴到新客户端，可能出现脚本不执行、订阅更新失败，或成功执行却覆盖了其他设置。

优先把固定修改变成声明式覆写

端口、模式和局域网开关这类固定值，优先使用新客户端的设置界面或合并配置。下面展示迁移时需要核对的键，不建议直接覆盖订阅中的整个配置：

本地运行参数示例

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

mixed-port: 7890 让同一端口接收 HTTP 与 SOCKS 请求，但客户端可能在最终配置阶段重新写入端口。更改后应打开实际运行配置确认，而不是只看覆写文件。列表合并也要特别小心：有的入口替换整个 rules 数组，有的支持前置与追加，两者结果完全不同。

需要脚本时，逐项重建转换逻辑

先描述旧脚本的目的，例如删除特定节点、添加代理组、修改 DNS，避免把历史遗留逻辑全部带走。
按新客户端文档提供的脚本入口编写，确认函数签名、返回完整配置的方式，以及异常如何显示。
一次只迁移一项修改。执行后检查节点数量、代理组成员和规则顺序，再进行下一项。
手动更新一次订阅，检查本地修改是否仍然存在；只有更新后仍生效，才说明覆写挂载正确。

不要把旧 Clash 的内核脚本配置与客户端 JavaScript 预处理混为一谈。遇到 script 等历史字段，应核对 mihomo 当前支持情况，并尽量转换为明确的规则、规则集或客户端预处理逻辑。

6. 分开验证端口、DNS 与 TUN 模式

浏览器能访问，只证明这一条访问路径可用。命令行工具、游戏、局域网设备与 UDP 流量可能走不同路径。迁移验证应按层进行，每次只改变一个变量。

验证层	具体操作	重点观察
本机端口	检查新客户端混合端口是否为 7890。	日志有无端口占用；终端代理环境变量是否还指向旧端口。
显式代理	使用 curl 指定 127.0.0.1:7890 发起请求。	连接记录是否出现，命中规则和出口是否符合预期。
系统代理	开启系统代理后，用浏览器访问实际业务站点。	应用是否遵循系统代理，是否受旧 PAC 设置影响。
DNS 与 TUN	基础连接通过后再启用 TUN，分别测试域名、局域网与 UDP 应用。	DNS 接管、路由冲突、虚拟网卡权限和本地服务访问。

Windows PowerShell 可用以下命令检查端口与显式 HTTP 代理。这里指定 curl.exe，避免旧版 PowerShell 中 curl 别名带来的参数差异；测试地址应换成需要验证的实际服务。

Windows PowerShell

Get-NetTCPConnection -LocalPort 7890 -State Listen
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com

显式 HTTP 代理请求不能证明 UDP 已经接管。启用 TUN 后，应另行测试需要 UDP 的应用，并查看连接记录。DNS 方面，如果旧配置使用 enhanced-mode: fake-ip，还要核对 fake-ip-filter 与本地域名解析需求；企业内网域名通常依赖内部 DNS，不能简单统一交给公共解析服务。

必要时用内核检查配置

若已取得独立 mihomo 可执行文件，可在配置目录执行语法检查。下例适用于 Windows 当前目录内同时存在内核与配置的情况；客户端内部生成的配置应优先使用其内置检查功能。

检查 config.yaml

.\mihomo.exe -t -d . -f .\config.yaml

-t 用于测试配置，-d 指定工作目录，-f 指定配置文件。检查通过不等于节点可达，也不能验证订阅权限、远端规则下载和实际 DNS 行为，仍需结合运行日志排查。

7. 完成更新测试，再清理旧客户端

建议至少完成一次手动订阅更新、一次系统重启，以及一次日常网络切换。重启后确认只有新客户端自动启动；从有线网络切换到 Wi-Fi 后，再检查 TUN 路由和局域网访问。这样的验证比单次延迟测试更接近实际使用。

更新检查：订阅刷新后，自定义规则、策略组和 DNS 覆写仍然生效。
业务检查：浏览器、终端、开发工具、局域网服务分别验证，不能只测一个网页。
服务检查：旧客户端的后台服务、开机任务和系统代理设置不再接管网络。
回退准备：保留受保护的原始备份，记录新客户端版本、内核版本及迁移日期。

只有新配置稳定后，再通过旧客户端原有的服务管理入口卸载后台服务并清理程序。若迁移失败，需要回退时，先关闭新客户端的 TUN 与系统代理并退出内核，再恢复旧环境；不要同时启动两套程序来比较结果。