Clash for Android 停更后的迁移路线:配置备份与替代客户端

先备份，再迁移：旧客户端暂时保留

Clash for Android（下文简称 CFA）停止维护，不等于已经保存的配置会立即失效。真正需要处理的是后续 Android 系统兼容、内核问题修复和订阅格式变化。迁移时先保留旧应用及其数据，等新客户端通过联网、锁屏和订阅更新测试，再决定是否卸载。

客户端是提供配置管理和界面的应用；内核是实际处理代理连接、DNS 与规则的组件。旧应用能读懂的配置，新应用不一定完全照原样执行；反过来，新订阅使用的字段也可能超过旧内核的支持范围。因此，迁移不是只把一个链接粘贴过去，还要还原本地设置。

1. 先记录旧客户端当前启用的配置、运行模式和策略组选择。
2. 分别保存订阅地址、本地 YAML 配置和应用里的覆写设置。
3. 安装候选客户端，先导入一份配置，不要同时更换订阅服务。
4. 停止旧客户端后再启动新客户端，逐项核对网络行为。

配置备份清单：订阅、YAML 与覆写分开保存

订阅地址不等于完整备份

订阅是客户端下载远程配置的入口，地址里经常带有账户令牌。它能恢复服务端提供的节点和规则，却不保证恢复你后来增加的直连域名、节点选择、电池设置或绕过应用名单。订阅失效后，只有链接也无法重新取回原来的内容。

以常见 CFA 2.5.x 界面为参照，先进入「配置」，找到当前使用的配置，再打开该条目的编辑或管理入口，查看来源 URL；若界面提供导出或分享文件功能，把 YAML 保存到本地。不同构建的按钮名称可能不同，找不到导出入口时，至少保留原始订阅地址及手动修改记录，不要把分享链接误当成已导出的文件。

截图记录设置，但隐藏凭据

在 CFA 的「设置」→「覆写」中检查是否启用了独立覆盖项，再到「设置」→「网络」核对分应用代理相关选项；具体分组以已安装版本为准。需要记录的不只是开关，还包括名单属于“仅代理这些应用”还是“绕过这些应用”。名单相同、模式相反，会让迁移后的流量走向完全相反。

备份文件建议放在受设备锁保护的位置，另存一份到自己控制的加密存储。订阅 URL、节点密码、UUID 和控制接口密钥都属于敏感信息。给别人看日志或配置前，先移除这些内容，不要把完整配置上传到公开的在线转换工具。

替代客户端怎么选：先看内核与设备条件

挑选仍在维护的替代客户端，重点是它当前发布的安装包，而不是名称里是否带 Clash。可以从本站的选型指南了解候选范围，再核对项目发布页、更新记录、最低 Android 版本以及应用内显示的内核版本。本文不把某个历史版本号当成“长期最新版本”。

Clash.Meta 后续以 mihomo 名称继续发展，二者存在演进关系，但“使用 mihomo”也不意味着每个客户端都开放同样的设置。图形界面可能只支持部分覆写项，订阅更新、后台服务和配置合并也由客户端负责。若依赖特定协议或规则字段，应对照候选内核的对应版本文档，而不是只比较界面。

• 主要靠订阅使用：可先考察下载页中的 Clash Plus、FlClashs 等 Android 候选项，重点检查远程配置更新、配置切换、日志和后台运行入口。
• 维护手写配置：优先验证本地 YAML 导入、配置覆写、规则集加载和错误行号提示。不要假设客户端会保留所有未知字段。
• 使用旧手机：核对最低系统要求和 CPU 架构。64 位 ARM 设备通常选择 arm64 包；仅支持 32 位的系统不能因为处理器型号较新就直接安装 arm64 包。
• 依赖分应用代理：确认客户端支持所需的包含或排除模式，并实际测试工作资料、双开应用等特殊环境。

导入配置与建立 VPN：先减少变量

先导入同一份订阅

1. 在新客户端的配置管理页选择 URL 导入或新建远程配置，填写备份的完整订阅地址。
2. 等待下载与解析完成，确认出现预期策略组，而不只是显示一个配置名称。
3. 切换到规则模式，选择与旧客户端相同的手动策略组及节点。
4. 停止 CFA 的代理服务，再启动新客户端，接受 Android 系统弹出的 VPN 连接请求。

Android 客户端常通过 VpnService 建立本地 VPN 接口，把设备流量交给内核处理；这与订阅服务器本身不是一回事。同一用户环境通常只能有一个活动 VPN。若设备正运行企业 VPN、其他代理或基于 VPN 的过滤应用，需要先处理冲突，不能依靠同时启动两个应用来比较速度。

本地端口按需恢复

如果只有手机应用通过系统 VPN 上网，本地 HTTP 或 SOCKS 端口往往不是第一排查点。若终端工具曾连接 127.0.0.1:7890，则要在新客户端启用对应的本地监听。下面只是监听与模式的局部示例，不包含节点、策略组和完整规则，不能单独作为订阅使用。

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

mixed-port 表示在同一端口接受 HTTP 和 SOCKS 代理连接；应用可能会覆写这里的监听设置，应以运行日志和实际连接为准。若原配置带有 external-controller，也要检查监听地址和访问密钥，不要为了恢复旧面板而把控制接口直接开放给局域网。

核对规则与 DNS：能连上不代表已经迁移完成

规则名称、顺序与模式一起检查

规则按顺序匹配，通常先命中的条目决定流量交给哪个策略。订阅中的 rules 引用了哪个策略名，该策略就必须在新配置中存在。把原来的“自动选择”组改名，却没同步修改规则，会造成解析失败或行为异常；客户端也可能在导入过程中重新生成策略组，需要检查实际运行配置。

• 确认日常模式是规则模式；全局模式不能用来验证分流是否正确。
• 核对自己添加的域名规则是否仍在宽泛规则之前。
• 检查 rule-providers 的下载状态；订阅更新成功，不代表外部规则集也已下载成功。
• 打开连接记录，查看目标域名、命中规则、所选策略和实际节点，别只看主界面的延迟。

DNS 覆写先对齐，再考虑调整

DNS 是把域名解析为地址的过程。迁移时先核对 dns.enable、enhanced-mode、nameserver、fake-ip-filter 和 IPv6 相关设置，保留原有意图。不要一边换客户端，一边把 DNS 服务、Fake-IP 模式和规则全部换掉，否则出错后很难定位是哪项变化造成的。

Fake-IP 会向应用返回用于映射的虚拟地址，再由内核关联真实域名；常见配置会使用 198.18.0.1/16 这一地址范围，但具体范围以配置为准。看到这个范围不应立即判定 DNS 故障。若局域网设备发现或个别应用异常，应先检查过滤列表、局域网绕过和应用名单，而不是随意更改整个地址段。

Android 的「设置」→「网络和互联网」→「私人 DNS」也可能影响解析路径，部分厂商将它放在「连接与共享」中。先记录原值，再做单项对照测试；不要直接认定必须长期关闭。代理服务已启动但出现域名解析超时，应结合日志判断是上游 DNS 不通、解析连接走错出口，还是系统设置与客户端接管方式不匹配。

迁移验收：联网、更新和锁屏分开测

先使用同一个 Wi-Fi、同一个节点和同一份配置，避免把移动网络波动当成客户端差异。下面的时间是建议测试窗口，不是本站实测成绩，也不是所有设备都应达到的性能指标。

1. 基础联网约 5 分钟：访问一个预期直连的服务和一个预期代理的服务，在连接记录里分别核对规则与出口。
2. 局域网测试：打开家中路由器管理页，或访问自己已知的局域网设备。失败时检查地址绕过、路由和分应用设置。
3. 订阅更新一次：手动触发更新，确认更新后仍能解析、策略组仍存在、本地覆写仍生效。
4. 锁屏约 15 分钟：重新解锁后检查服务状态，再打开需要联网的应用。只看通知栏图标不足以证明连接正常。
5. 网络切换一次：从 Wi-Fi 切到移动数据，再切回，观察是否恢复连接以及日志是否反复出现超时。

若锁屏后服务退出，进入系统「设置」→「应用」→目标客户端→「电池」，检查是否允许后台活动；厂商系统还可能要求开启自启动或取消后台限制。若此前在系统 VPN 页面为 CFA 开启了「始终开启的 VPN」，迁移时要改为新客户端。启用了「阻止未使用 VPN 的连接」时，VPN 未建立会导致设备无法联网，切换应用前尤其要核对。

全部通过后，继续保留旧配置备份，观察一到两天再卸载 CFA。回退时先停止新客户端并检查系统 VPN 绑定，再启动旧应用；若订阅本身已经变化，旧应用也可能无法解析，因此本地备份仍然有用。

迁移常见问题