迁移选型 预计阅读 12 分钟

Clash 客户端停更之后:迁移到 mihomo 系客户端的替代路线

梳理原版内核停更后的生态变化,按 Android、桌面端分别列出仍在维护的 mihomo 系客户端,并说明配置文件迁移时需要调整的字段与注意事项。

先分清停更的是客户端还是内核

打开旧客户端的「关于」页面，先记录应用名称、应用版本和内核版本，再决定替换对象。客户端是负责导入订阅、显示节点和启动服务的界面；内核是读取配置、匹配规则和建立代理连接的程序。两者不是同一个项目，更新状态也不一定相同。

2023 年原版 Clash 相关项目停止公开维护后，旧安装包并不会按日期自动失效。已有节点可能继续连接，但新协议支持、系统兼容修复和后续问题处理不能据此得到保证。Clash for Windows、原版 Clash for Android 与 mihomo 也不能只凭名称相似就视为同一条更新线。

mihomo 是由 Clash.Meta 项目延续而来的代理内核。旧教程里的「Meta 内核」通常指这条技术路线，并不是另一个订阅服务。迁移的核心是选择仍在更新、能运行 mihomo 的客户端，再把订阅与本地设置分开搬过去。

Android 与桌面端分别选哪条路线

按系统筛选，再检查项目的正式发布记录、支持架构和内核说明。下面列出的是 mihomo 生态中的迁移候选，不是对某个历史安装包持续维护的保证。项目状态会变化，安装当天仍应确认近期发布与问题处理情况，不要仅凭下载文件的修改时间判断。

设备平台 迁移候选 安装前检查
Android Clash Meta for Android、FlClash Android 最低版本、ARM 架构、内核版本与 VPN 授权
Windows Clash Verge Rev、Clash Nyanpasu、FlClash 系统架构、实际使用的内核、TUN 服务安装要求
macOS Clash Verge Rev、FlClash、ClashX Meta Apple Silicon 或 Intel 安装包、网络权限与辅助服务
Linux Clash Verge Rev、FlClash 发行版包格式、桌面环境、TUN 权限与服务运行方式

Android：先迁移配置，再接管流量

习惯原版 Clash for Android 的配置、代理和日志页面，可以先评估 Clash Meta for Android；希望手机与电脑使用相近界面的，可以评估 FlClash。二者的菜单、备份格式和内置设置并不完全一致，不要把整个应用数据目录直接互换。

多数较新的 Android 手机使用 ARM64，但不能只看手机上市年份。先在下载说明中核对设备支持的 ABI，也就是应用二进制接口；确认支持 arm64-v8a 后再选 ARM64 包。Android 版本要求也应以对应发行版说明为准。

桌面端：先用系统代理验证，再考虑 TUN

Windows 与 macOS 用户可以先导入订阅、选定节点，只开启系统代理测试浏览器。Clash Nyanpasu 等支持不同内核选项的客户端，还要在内核管理处确认运行的是 mihomo。不要把客户端版本号当成内核版本号。

TUN 是用于接收设备网络流量的虚拟网络接口，覆盖范围通常比只修改系统代理更广，但涉及路由、DNS 与系统权限。旧客户端正常使用系统代理时，迁移第一轮也用同样方式测试，避免同时引入多个变量。

旧客户端里先备份这四类内容

  1. 订阅来源：保存原始订阅 URL、更新间隔和提供方说明。订阅 URL 往往带有账号令牌，不要放进公开笔记、截图或在线转换页面。
  2. 配置副本：导出当前可用的 YAML 文件。YAML 是以缩进表示层级的文本配置格式，编辑时保留空格缩进，不要混入制表符。
  3. 本地改动：记录自定义规则、覆写、脚本与 DNS 设置。客户端可能在启动时才把这些内容合并到运行配置，仅复制订阅文件会漏掉它们。
  4. 系统设置：记录代理端口、局域网共享开关、应用分流和自动启动设置。Android 的应用排除列表、桌面端的系统代理开关通常不是通用订阅的一部分。

如果旧界面提供「查看运行配置」，可额外保存一份作为对照，但不要直接覆盖新客户端的整个工作目录。运行配置可能含临时路径、控制接口密钥和已经展开的节点密码，既不便于跨设备复用，也不适合公开求助。

配置迁移：逐项检查字段与名称引用

在新客户端的订阅或配置页面，优先通过原始 URL 添加配置，再手动更新一次。只持有本地文件时，使用「从文件导入」一类入口。具体名称随客户端变化，关键是区分「订阅源文件」与「应用设置备份」，两者不能混用。

代理、策略组与规则要连起来检查

  • proxies 保存直接写入配置的节点；proxy-providers 保存外部节点提供器。使用后者时，还要确认下载地址能访问、本地缓存路径可写。
  • proxy-groups 定义策略组，例如手动选择组。组中引用的节点名、其他组名和提供器名称必须存在，大小写与空格也要一致。
  • rules 按顺序匹配连接。前面的规则先命中，不能把宽泛的 MATCH 规则放到需要继续匹配的规则之前。
  • rule-providers 引用外部规则集。检查其 type、behavior、format 与实际文件内容是否匹配；域名列表不能直接当成完整的 classical 规则集。

遇到「策略组不存在」时，先核对报错里的名称，不要马上更换节点。客户端覆写把「代理」改成「节点选择」，但自定义规则仍引用旧名称，也会导致配置加载失败。

端口与控制接口不要整段照搬

mixed-port 是同时接受 HTTP 与 SOCKS 代理连接的本地端口；external-controller 是供界面或管理工具调用的控制接口，不是代理端口。下面只是本地设置片段，不能作为完整订阅直接运行：

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

这段示例使用 7890，不代表所有客户端都默认使用它。若终端原先连接 127.0.0.1:7890，新客户端实际监听 7897，就要同步修改终端设置，或者在客户端支持的设置入口调整端口。

不要把旧文件中的 external-controller、secret、external-ui 与绝对路径直接搬到手机。新客户端可能自行管理控制接口和资源目录；把监听地址改成 0.0.0.0 还可能扩大接口可访问范围。没有明确需求时，保留应用管理的本机设置。

DNS、TUN 与旧脚本分开处理

DNS：先用新客户端提供的默认方案

DNS 是把域名转换成 IP 地址的过程。迁移后出现「节点延迟正常，网页打不开」，不一定是节点协议不兼容，也可能是域名解析路径发生变化。先保留新客户端推荐的 DNS 设置，确认可用后，再逐项迁移原来的自定义解析服务器。

fake-ip 是通过分配合成 IP 辅助分流的模式。如果旧配置使用 198.18.0.1/16 这样的地址范围，不要把它误判为节点真实 IP。切换 DNS 模式后，应重新建立测试连接；必要时重启应用或清理系统 DNS 缓存，避免旧结果影响判断。

TUN：不要同时照搬手机和电脑的路由参数

Android 客户端通常通过 Android 的 VpnService 接口接收流量，首次连接会出现系统 VPN 授权框。桌面端则可能需要安装辅助服务或授予管理员权限。两者都能接管流量，但系统授权方式、路由实现与可用选项不同。

tun.stack、auto-route 和 dns-hijack 应按目标客户端与系统检查。不要因为旧电脑配置写了某个虚拟网卡名，就把该名称写入手机配置。Android 还要检查「设置」→「网络和互联网」→「VPN」中的旧应用设置；部分厂商会把入口放在「连接与共享」中。

脚本：先判断是哪一层在执行

旧配置中的 script:、旧界面里的 JavaScript 覆写，以及第三方订阅转换模板，属于不同机制。不能假定 mihomo 会执行旧 Clash Premium 脚本，也不能把桌面客户端的覆写脚本直接导入 Android。先停用脚本，使用标准规则建立可用基线，再把必要逻辑改为目标客户端明确支持的规则或覆写。

按五步验证迁移结果

  1. 看配置加载：打开日志，确认没有 YAML 缩进错误、未知代理类型或找不到策略组的提示。加载失败时先解决首个错误，后续报错可能只是连带结果。
  2. 看订阅更新：手动更新一次，核对节点数量和账号有效期。HTTP 401 或 403 应先检查令牌与访问权限；不要把这类响应当成代理端口冲突。
  3. 看单个节点：在策略组内手动选择一个节点并执行连通性测试。延迟测试只说明指定测试请求的结果，不等于所有网站、所有协议都能使用。
  4. 看实际分流：保持 Rule 规则模式，分别访问预期直连与预期代理的目标，在连接列表中核对命中的规则、策略组和最终节点。
  5. 看系统接管：桌面端分别验证浏览器和终端；Android 分别验证浏览器、目标应用，以及锁屏后重新唤醒时的连接状态。

例如桌面端本地 HTTP 代理端口确认为 7890 时，可以用下面的命令单独检查代理请求。它只影响这一次请求，不会替你开启系统代理，也不能证明 TUN 路由已正常工作。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

这里的连接超时是 10 秒，总耗时上限是 20 秒，属于排查参数，不是实测速度。若日志出现 address already in use，先查旧服务是否仍占用端口；若出现 no such host，优先检查对应域名的解析过程；若是 context deadline exceeded，还需结合目标地址与连接阶段判断，不能直接认定订阅失效。

保留回退条件，避免订阅更新覆盖修复

完成第一轮验证后，再恢复自动启动、后台运行与自定义规则。Android 可在「设置」→「应用」→目标客户端→「电池」检查后台限制；设置名称随系统变化。若启用了「始终开启 VPN」或「阻止未使用 VPN 的连接」，确认绑定的是新客户端，否则旧应用停用后可能导致整机断网。

订阅下次更新后，再检查一次自定义规则是否仍在。直接编辑订阅下载生成的 YAML，通常会在更新时被覆盖。长期修改应放入客户端支持的覆写、合并配置或独立规则提供器中，并确认最终运行配置里的规则顺序。

  • 旧配置与新配置分别保存，文件名带上日期，避免混淆。
  • 记录客户端版本、mihomo 内核版本和复现步骤，便于定位兼容问题。
  • 求助时只分享脱敏日志，移除订阅令牌、节点密码和控制接口密钥。
  • 需要回退时，先关闭新客户端的系统代理或 VPN，再恢复旧服务，避免残留路由。

迁移完成的判断标准不是新界面能打开，而是订阅能更新、规则能命中、目标应用能连接，且重启或锁屏后仍符合预期。先完成这条最短验证链，再调整 DNS、TUN 和复杂覆写，排错范围会更清楚。

下载客户端