Clash for Windows 停更后如何迁移:替代客户端与配置搬家清单

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

Clash for Windows，通常简称 CFW，虽然名字带有 Windows，也曾提供 Linux 和 macOS 版本。它负责订阅管理、代理组选择和桌面开关；真正处理连接的是随客户端运行的代理内核。CFW 停止维护后，旧安装仍可能启动，但这不代表它能持续适配新的系统、协议或安全修复。

迁移不等于重买订阅，也不等于把整个旧目录覆盖到新目录。应当分别处理三层内容：客户端里的操作设置、内核读取的 YAML 配置，以及服务商提供的订阅地址。三者有交集，但不能互相替代。

• 客户端设置：开机启动、系统代理、快捷键、界面偏好和后台服务，通常需要在新程序中重新设置。
• 内核配置：节点、代理组、规则、DNS 与 TUN 字段，需要检查新内核是否接受。
• 订阅地址：用于重新获取远程内容。仅保存一份下载后的 YAML，并不等于保留了自动更新能力。

按系统选择替代路线

如果原来主要使用 Clash YAML，优先选择能够读取这类配置的客户端，迁移成本通常更低。mihomo 是原 Clash Meta 项目延续使用的名称，支持更多协议与规则能力，但客户端是否开放对应开关、打包了哪个内核版本，仍要以实际安装为准。选择前可以先看客户端对比，再检查项目近期发布记录和对应系统安装包。

Linux 用户先看安装格式

Ubuntu、Debian 系发行版通常选择 DEB，Fedora 等系统通常选择 RPM；包格式相同，也不表示依赖一定满足。在终端运行 uname -m，输出 x86_64 通常对应 x64，aarch64 通常对应 ARM64。不要用“能下载到”代替“适合当前设备”的判断。

移动端不要直接复制桌面接管方式

Android 的 VpnService 是系统提供的流量接管接口，不是照搬 Linux 上的服务模式。iOS 客户端也可能采用不同的配置格式；支持相同节点协议，并不意味着能完整导入 Clash 的代理组和规则。先用一个配置验证导入，再决定是否迁移全部配置。

旧版 Clash for Android 同样属于需要留意维护状态的归档路线，不适合仅因为名称熟悉就作为长期替代方案。上表是选型入口，不是对未来维护状态的保证。

备份订阅和本地修改

先让旧客户端保持可回退状态，不急着卸载。在 CFW 的 Profiles 页面核对每一项配置，记录名称、来源、当前选中项和更新间隔。订阅链接应从原服务后台或客户端提供的复制入口保存；如果只有本地文件，记录“本地导入”，不要误认为它能够自动更新。

1. 导出原始配置：保存正在使用的 YAML，也保留尚未被客户端处理的原始订阅内容，文件名带上备份日期。
2. 单独保存加工逻辑：检查 CFW 的 Parsers、Mixin，以及手动增加的规则。这些客户端层面的设置不一定包含在订阅文件里。
3. 记录运行参数：抄下 HTTP、SOCKS 或混合端口，是否允许局域网连接，当前模式与 DNS 设置。
4. 保存外部依赖：本地规则集、证书文件和被配置引用的其他文件，不能只复制主 YAML 而漏掉它们。
5. 记录代理组选择：记下常用组与节点名称。旧缓存可能无法被新客户端读取，最好准备一份文字清单。

Linux 上可以先建立一个仅当前用户可访问的备份目录，再把导出的文件放进去。下面的命令只创建目录并限制权限，不会替你寻找或导出旧配置：

mkdir -p "$HOME/cfw-migration"
chmod 700 "$HOME/cfw-migration"
# 将导出的配置和迁移记录放入此目录后，再收紧文件权限：
find "$HOME/cfw-migration" -type f -exec chmod 600 {} \;

导入配置，不覆盖整个旧目录

新客户端首次启动后，先保持 TUN 和系统代理关闭，导入一份配置并查看解析结果。有订阅链接时优先重新导入链接；只有本地 YAML 时按本地配置导入。若客户端提供不同的导入类型，要区分“远程配置”和“本地文件”，避免后续更新按钮看似存在却没有可用来源。

先处理字段兼容，再处理规则取舍

大多数常见的 proxies、proxy-groups、rules 结构可以继续使用，但仍需检查解析日志。原版内核特有的脚本能力、CFW 专属加工语法和旧实验字段，不能默认在 mihomo 中原样生效。遇到错误时先定位报错字段，不要为了让文件加载而批量删除所有未知内容。

• 节点协议：VLESS、Hysteria2 等能力取决于目标内核；配置被加载不等于每个节点都已成功建立连接。
• 规则提供器：rule-providers 的下载地址、行为类型和格式必须匹配，留意日志中的下载或解析失败。
• 本地路径：Windows 的盘符路径不能直接用于 Linux；相对路径的解析位置应以新客户端的配置目录和内核行为为准。
• 规则顺序：规则通常从上到下匹配。自定义规则放在最终 MATCH 之后，通常不会获得预期效果。

把自定义修改放进持久化覆写

不要只编辑下载后生成的订阅文件，否则下次更新可能覆盖修改。优先使用新客户端支持的覆写、合并或脚本机制，并核对实际合并结果：有的机制替换整个规则数组，有的可以前置规则，不能只凭功能名称判断。先加一条容易验证的规则，更新一次订阅，再检查它是否仍在。

CFW 的 Parsers 或 Mixin 应逐项改写为目标客户端支持的方式，而不是复制原有包装结构。字段作用可结合内核与配置参考核对。

系统代理与 TUN 分开验证

最常见的迁移故障不是节点损坏，而是两个客户端争用同一个端口，或者旧系统代理还指向已经退出的程序。切换前，在 CFW 的 General 页面关闭 System Proxy；如果曾启用 TUN，也先关闭并正常退出旧客户端，再启动新客户端。

第一轮只测本地代理端口

下面假定新客户端已明确设置 mixed-port: 7890，监听在本机回环地址。7890 只是本次检查用的具体端口，不是所有客户端的默认值。请以界面或生效配置为准，使用你有权访问的测试地址：

# 查看 Linux 上 7890 端口的监听状态
ss -lntp 'sport = :7890'

# 显式通过 HTTP 代理发起请求，不依赖桌面系统代理
curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  --output /dev/null --write-out 'HTTP %{http_code}\n' \
  https://clash86.com/

连接被拒绝通常意味着没有监听、端口填错或进程启动失败；超时则需要继续查看内核日志、节点连接和 DNS。即使得到 HTTP 响应，也只说明这次请求得到了响应，仍应在客户端连接记录中确认它使用了预期规则和代理组。

第二轮再打开系统代理

本地端口可用后，再让新客户端设置系统代理，并用浏览器测试。系统代理主要覆盖遵循相关设置的应用；终端程序是否读取代理，还取决于环境变量和程序自身参数。GNOME 桌面可运行 gsettings get org.gnome.system.proxy mode 查看桌面代理模式，但该结果不能代表所有应用都已走代理。

最后按需要启用 TUN

TUN 用于接管更多不遵循系统代理的连接，需要相应权限或客户端服务。先确认新客户端的服务授权，再启用 TUN；不要让新旧两个虚拟接口同时接管默认路由。Linux 上可用 ip rule 和 ip route show table all 辅助检查，但不要照搬网络帖子中的批量删路由命令。详细步骤见TUN 模式教程。

用验收清单确认迁移完成

延迟测试通过不代表迁移结束。它通常只验证测试目标的可达性，不能代替实际业务、规则匹配和 DNS 检查。建议使用同一网络，按下面的顺序验证，每次只改变一个设置，方便定位问题。

如果启用了 fake-ip，发现内网站点解析异常，应结合 DNS 配置和 fake-ip-filter 排查；不要简单把所有 DNS 问题归为“节点不好”。IPv6 也需要单独确认：能访问 IPv4 站点，不代表 IPv6 连接同样经过预期路径。

手机还应增加一次锁屏测试。Android 设备锁屏后断开，先检查电池优化、自启动和后台限制；这类问题与桌面端 YAML 是否成功导入不是同一回事。

保留回退窗口，再清理旧安装

完成首次验证后，至少覆盖一次重启、一次网络切换和一次订阅更新，再考虑卸载 CFW。保留备份不等于让旧客户端继续开机运行：应关闭它的开机启动，并确认旧后台服务不会抢占端口。删除程序文件也不一定会自动撤销系统服务或网络设置，清理方式应以原安装方式为准。

1. 在新客户端中完成正常退出测试，确认普通网络能恢复。
2. 保留订阅来源、本地覆写和迁移记录；确认备份能被实际读取。
3. 取消旧程序的开机启动，按它原来的服务管理或卸载方式清理后台组件。
4. 若需要回退，先关闭新客户端的系统代理与 TUN，再启动旧环境，避免双重接管。

迁移的终点不是界面看起来相似，而是订阅能更新、规则能解释、退出能恢复。按“备份 → 导入 → 本地端口 → 系统代理 → TUN → 重启验收”的顺序操作，遇到问题时就能知道卡在哪一层，而不必一次重装所有组件。