Clash 客户端停更后如何迁移:配置导出、替代方案与订阅无缝切换

先确认需要迁移的不是一个安装包

Clash 客户端停止维护后，真正需要转移的是订阅入口、本地配置、策略选择和系统代理状态。旧程序本身通常没有继续复制的价值。以 Clash for Windows 为例，项目停止更新后，已有版本仍可能暂时运行，但内核、协议实现、系统兼容性和安全修复不会继续跟进。系统升级、订阅格式变化或证书策略调整，都可能让原本正常的配置突然失效。

迁移前先区分“客户端”和“内核”。客户端负责配置管理、托盘菜单、系统代理、日志和界面；内核负责监听端口、解析规则、建立代理连接。较新的客户端通常采用 mihomo 内核，它继承 Clash Meta 的能力，支持更多代理协议、规则集、流量嗅探和较完整的 TUN 配置。旧客户端使用的经典 Clash 配置大多可以导入 mihomo，但反方向不一定兼容。

迁移原则

先保存订阅地址与当前 YAML，再安装新客户端并完成离线检查。确认新客户端可以接管系统代理或 TUN 后，最后退出旧客户端。不要同时让两个内核监听相同端口。

需要保存的四类内容

订阅 URL：优先保存原始订阅链接，而不是只复制订阅转换后生成的 YAML。原始链接通常包含访问令牌，应作为敏感信息保管。
本地配置：包括手写的规则、代理组、DNS、TUN、规则集地址和局域网访问设置。
策略状态：记录常用代理组当前选择，例如“节点选择”“流媒体”“下载”分别使用哪个节点或子策略组。
网络参数：记录混合端口、控制端口、系统代理开关、绕过列表和局域网监听范围。

只复制节点名称并不完整。节点可以由订阅重新生成，但手写规则、覆写脚本、代理组选择和 DNS 排除项通常保存在客户端本地。迁移后出现“节点能测速但网页打不开”，经常就是这些本地设置没有同步。

导出订阅与配置：旧客户端仍能打开时的处理顺序

第一步：记录订阅来源和更新时间

打开旧客户端的配置或 Profiles 页面，逐个记录配置名称、订阅地址、最后更新时间和自动更新间隔。若界面提供“复制订阅链接”“编辑配置”或“在文件夹中显示”，优先使用这些入口。不要从日志中截取链接，因为日志可能对令牌做了截断，也可能显示的是重定向后的临时地址。

建议将迁移记录整理成一个本地文本文件，至少包含以下字段。令牌部分不要上传到网盘公开目录、代码仓库或截图分享平台。

配置名称：日常规则
订阅来源：https://example.invalid/api/v1/client/subscribe?token=已隐藏
旧客户端更新间隔：1440 分钟
模式：rule
混合端口：7890
外部控制端口：9090
常用策略：节点选择 → 自动选择
本地覆写：dns.yaml、rules.yaml

第二步：导出正在生效的 YAML

在旧客户端中找到“编辑配置”“查看配置文件”或“打开配置目录”，复制当前生效的 YAML。Windows 上部分旧版 Clash 客户端会把数据保存在用户目录下的 .config/clash，macOS 与 Linux 的旧工具也常使用 ~/.config/clash。不同分支可能改用应用数据目录，因此应以界面的“打开目录”结果为准，不要只凭固定路径搜索。

备份时不仅要保存主配置，还要查看主文件引用的其他资源。以下字段意味着配置依赖外部文件或远程内容：

proxy-providers：代理提供者，可能引用本地文件或远程订阅。
rule-providers：规则集提供者，可能使用 YAML、文本或 MRS 行为格式。
script：旧配置中的脚本规则，迁移前需要确认新内核是否仍支持相同写法。
dns.nameserver-policy：按域名指定 DNS 的策略，遗漏后会改变解析路径。
tun：虚拟网卡、自动路由、DNS 劫持和严格路由参数。

第三步：保存覆写内容，而不是复制运行缓存

GeoIP 数据库、规则集缓存、订阅缓存和运行日志可以由新客户端重新下载。真正需要保存的是用户主动编辑的覆写文件。若旧客户端带有“全局扩展配置”“Mixin”“预处理”“覆写”或“脚本”功能，应逐项复制其原文，并记录它在主配置之前还是之后执行。执行顺序不同，最终的 dns、rules 和 proxy-groups 结果也会不同。

按平台选择仍在维护的客户端

选择替代客户端时，不要只比较界面。先确认系统版本、内核类型、配置导入方式、TUN 权限流程和更新渠道。对于已有 Clash 配置的用户，采用 mihomo 内核、允许导入 URL 与本地 YAML、可以查看实际运行配置的客户端，迁移成本通常较低。

平台	迁移重点	选择时核对
Windows	系统代理、服务模式、TUN 驱动	是否能清理旧代理、是否支持 mihomo、是否提供运行日志
macOS	网络扩展、管理员授权、钥匙串提示	系统版本要求、TUN 授权路径、退出时是否还原代理
Android	VPN 权限、电池优化、后台保活	是否支持本地配置、按应用分流、始终开启 VPN
Linux	桌面代理、权限、透明代理	发行版架构、内核权限、托盘与自启动方式

FlClash 可作为 Windows、macOS、Linux 与 Android 上的迁移目标。它提供订阅配置、本地配置、系统代理和 TUN 相关入口，适合把旧 Clash 配置迁移到 mihomo 运行环境。安装前应先核对下载页标注的系统与架构，例如 Windows 的 x64、Linux 的 x64 或 arm64，避免把架构不匹配误判成配置错误。

不要让两个客户端同时接管网络

旧客户端与新客户端同时启动时，最常见的冲突是端口占用。许多 Clash 配置使用 7890 作为 HTTP、SOCKS 或混合端口，外部控制器常用 9090。如果旧内核还在监听，新内核日志会出现 address already in use 或绑定失败。

在旧客户端关闭系统代理与 TUN。
完全退出旧客户端，确认托盘图标消失。
Windows 可在终端执行 netstat -ano | findstr :7890 检查端口。
macOS 与 Linux 可执行 lsof -i :7890 查看占用进程。
确认端口释放后再启动新客户端。

若必须短时间并行比较配置，可把新客户端的混合端口暂时改为 7891，但不要同时打开两个系统代理或两个 TUN。测试结束后再统一端口，避免浏览器、终端和开发工具分别指向不同内核。

在 FlClash 中导入：订阅优先，本地 YAML 作为兜底

使用订阅 URL 导入

启动 FlClash 后进入“配置”页面，选择从 URL 添加配置，粘贴保存的订阅地址并执行更新。导入完成后先不要立即开启系统代理，先查看配置是否生成节点、代理组和规则。正常的订阅至少应能看到代理节点、一个或多个策略组，以及规则列表；只有节点而没有规则的配置，可能是节点订阅而不是完整 Clash 配置。

自动更新间隔可按订阅服务的变化频率设置。日常使用建议设置为 1440 分钟，即每天一次；节点变化频繁时可设为 360 分钟。过短的间隔会增加请求次数，也可能触发订阅服务的频率限制。迁移当天建议先手动更新一次，确认返回内容有效，再启用自动更新。

导入本地 YAML

如果原订阅地址已经失效，但旧客户端还能显示当前配置，可以先导入备份的 YAML。需要明确的是，本地 YAML 保存的是导出时的节点和规则快照，不能自动获得服务端后续变更。恢复网络后应尽快替换为有效订阅，或把节点与规则迁入自己的受控配置。

导入前可使用 mihomo 的配置检查命令验证语法。若系统中有独立 mihomo 可执行文件，可在终端运行：

mihomo -t -f ./config.yaml

检查通过只代表 YAML 可解析，不代表每个远程规则集、节点地址和 DNS 服务器都可访问。若提示缩进错误，应确认 YAML 使用空格而不是 Tab；若提示重复键，应检查合并配置时是否出现了两个同级 dns 或 rules 字段。

核对参数路径

导入后进入“设置”→“参数设置”，核对运行模式、混合端口、局域网访问和外部控制设置。配置页面负责订阅内容，参数设置负责客户端运行方式，两者不要混为一处。若配置文件明确写了 mixed-port: 7890，界面又设置了不同端口，应以客户端最终生成的运行配置和日志为准。

第一次启动建议

先使用规则模式，关闭 TUN，仅开启系统代理完成基础连通测试。HTTP 与 HTTPS 流量确认正常后，再配置 TUN、按应用代理或局域网访问。这样可以把订阅问题与虚拟网卡问题分开排查。

迁移后必须核对的规则、DNS 与 TUN

规则顺序是否被保留

Clash 规则从上到下匹配，命中后停止继续查找。迁移时即使所有规则都存在，顺序改变也会产生不同结果。检查最终规则中是否先处理局域网与直连域名，再处理业务规则和代理规则，最后保留兜底项。典型结构如下：

rules:
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - DOMAIN-KEYWORD,streaming,媒体策略
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

MATCH 应位于最后。若它被提前放置，后面的规则永远不会生效。迁移后还要检查代理组名称是否与规则第三项完全一致，包括空格、大小写和中文字符。规则指向“节点选择”，但代理组被改名为“代理选择”时，内核会报告找不到策略。

DNS 是否延续原来的工作模式

mihomo 常见的 DNS 增强模式包括 fake-ip 与 redir-host。旧客户端使用 fake-ip 时，新客户端不应在未评估的情况下切换模式。典型 Fake IP 地址池为 198.18.0.1/16，该网段用于基准测试，不应被当作真实公网地址。看到域名解析到 198.18.x.x，不等于 DNS 故障。

重点检查以下字段：

dns.enable 是否为 true。
enhanced-mode 是否与旧配置一致。
nameserver 与 proxy-server-nameserver 是否可以在当前网络访问。
fake-ip-filter 是否保留局域网设备、时间同步、游戏平台和打印机域名。
nameserver-policy 是否仍按预期处理国内外域名。

如果迁移后只有代理节点域名解析失败，应优先检查 proxy-server-nameserver。这个字段用于解析代理服务器自身的域名，不能依赖尚未建立的代理连接，否则可能形成解析环路。测试时可在日志中搜索 DNS、lookup、timeout 和节点域名。

TUN 模式分阶段开启

TUN 会接管比系统代理更多的流量，包括不读取操作系统代理设置的应用。Windows 首次启用可能需要管理员权限与虚拟网卡组件；macOS 需要批准网络扩展；Android 会显示 VPN 连接授权。迁移时应先证明普通系统代理可用，再开启 TUN。

开启后检查 auto-route、strict-route、DNS 劫持和接口选择。若局域网设备无法访问，可先检查私有网段是否被错误送入代理。常见私有地址包括 10.0.0.0/8、172.16.0.0/12 与 192.168.0.0/16。企业 VPN 与 TUN 同时运行时还可能争夺默认路由，需要根据单位网络要求为目标网段保留直连。

无缝切换的验证清单

“导入成功”只说明客户端接受了配置。真正完成迁移，需要验证系统代理、规则命中、DNS、订阅更新和退出恢复。建议按以下顺序执行，每一步通过后再进行下一步。

内核启动：日志没有端口占用、YAML 解析失败或规则组缺失。
节点测试：选择一个延迟稳定的节点，进行 TCP 或 URL 测试。延迟数值只能表示测试目标可达，不代表所有网站都能访问。
系统代理：开启系统代理，确认浏览器流量出现在连接记录中。
规则命中：分别访问应直连与应代理的目标，查看日志中的策略组名称是否符合预期。
DNS 检查：确认没有持续的解析超时，局域网域名与常用站点均能解析。
订阅更新：手动更新一次，记录耗时与返回状态，确认配置不会被空内容覆盖。
TUN 测试：在系统代理通过后开启 TUN，测试不读取系统代理的应用。
退出恢复：退出新客户端，确认操作系统代理设置恢复，浏览器不再指向已关闭的 127.0.0.1:7890。

切换期避免流量绕过

如果工作环境要求所有外部流量必须经过代理，迁移时不要依靠“快速切换”碰运气。可以先断开需要保护的业务应用或临时关闭网络，在新客户端加载配置并开启系统代理或 TUN 后再恢复连接。浏览器已有的长连接、下载任务和即时通信连接不会必然因为代理切换而重新建立，应主动重启相关应用。

Android 上可在系统 VPN 设置中检查“始终开启的 VPN”和“屏蔽未使用 VPN 的连接”；具体选项名称因系统厂商而异。Windows 与 macOS 则应检查旧客户端退出后是否留下手动代理。系统代理地址若仍指向 127.0.0.1，但对应端口没有进程监听，表现通常是所有浏览器页面都无法打开。

常见迁移故障与处理方式

订阅更新成功，但节点列表为空

先查看订阅响应是否为完整 Clash YAML。有些服务会根据 User-Agent 返回不同格式，也可能返回登录页面、错误 JSON 或只包含节点链接的文本。尝试在新客户端的订阅设置中选择兼容的请求方式；若服务明确要求专用 User-Agent，应按服务说明设置。不要把网页中的账户中心地址当作订阅 URL。

节点可用，但所有流量都走直连

确认运行模式不是 direct，并在“设置”→“参数设置”中检查模式是否为规则模式。随后查看规则末尾是否存在 MATCH，以及该规则指向的代理组当前是否选择了 DIRECT。部分配置会记住策略组状态，新客户端第一次导入时则使用组内第一个选项，两者可能不同。

网页能打开，命令行工具不走代理

系统代理主要影响遵循操作系统设置的程序。命令行工具可能需要显式设置 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY，也可以通过 TUN 接管。若混合端口为 7890，临时测试可把代理地址设为 http://127.0.0.1:7890。测试完成后记得清理终端环境变量，避免客户端退出后命令仍指向失效端口。

开启 TUN 后局域网设备失联

先关闭 TUN 验证问题是否由路由接管引起，再查看连接记录中打印机、NAS 或路由器地址的策略。私有网段通常应直连，但企业网络可能使用其他地址范围。不要简单删除全部 TUN 配置；应根据实际网段补充直连规则，并检查严格路由与其他 VPN 是否冲突。

迁移后可以删除旧客户端吗

完成至少一次订阅更新、一次系统重启和一次 TUN 测试后，再卸载旧客户端更稳妥。卸载前保留 YAML 与订阅记录，但不要继续保留旧客户端自启动。Windows 可在“设置”→“应用”→“启动”检查启动项；macOS 可在“系统设置”→“通用”→“登录项与扩展”检查旧程序是否仍被允许后台运行。

一份可执行的迁移顺序

配置较简单时，整个迁移可在约 20 至 40 分钟内完成；包含自定义规则集、企业 VPN 和 TUN 的环境，应预留单独测试时间。按下面的顺序操作，可以减少回滚成本：

在旧客户端复制订阅 URL，导出当前 YAML 与所有覆写文件。
记录模式、端口、策略组选择、DNS 模式和 TUN 开关。
下载与系统架构匹配的新客户端，暂时不要启用自启动。
关闭旧客户端的系统代理与 TUN，然后完全退出旧进程。
向 FlClash 导入订阅 URL；地址失效时再导入本地 YAML。
检查代理组、规则数量、DNS 字段和远程规则集状态。
先开启系统代理验证浏览器与规则命中，再开启 TUN。
手动更新订阅，重启系统并复测一次。
关闭旧客户端自启动，确认新客户端稳定后再卸载旧程序。

迁移的核心不是把旧目录搬到新目录，而是重建一条可验证的配置链：订阅能够更新，YAML 能被 mihomo 解析，规则指向存在的策略组，DNS 可以解析节点与目标域名，系统代理和 TUN 只由一个客户端接管。逐项确认后，客户端停更不会迫使用户重做全部规则，也不会中断原有订阅使用。