Clash 客户端停更后如何迁移：配置保留与替代软件选择

先区分客户端、内核与配置

Clash 客户端停止维护，不等于已有订阅和 YAML 配置同时失效。迁移前最重要的一步，是把图形界面、代理内核、配置文件和订阅服务拆开理解。图形客户端负责下载配置、切换策略组、控制系统代理和展示连接记录；内核负责解析规则、建立代理连接、执行 DNS 与 TUN 等网络功能；配置文件则保存端口、节点、策略组和规则之间的关系。

一些旧桌面客户端使用早期 Clash 内核，另一些客户端已经转向 Clash Meta，也就是现在常见的 Mihomo 内核。Mihomo 延续了 Clash 配置体系，并增加了更多协议、规则集、DNS 和流量接管能力。迁移到 Mihomo 客户端时，常规的 proxies、proxy-groups、rules 与 proxy-providers 通常可以继续使用，但旧客户端专属的界面设置、脚本、数据库和服务安装状态不能当作通用配置直接复制。

因此，迁移目标不是把旧程序目录完整搬到新程序，而是保留能够跨客户端复用的数据，再让新客户端重新创建运行环境。这样可以避开旧版本缓存、失效数据库、端口锁定和驱动残留造成的问题。

迁移前需要保存哪些内容

不要在卸载旧客户端后才寻找配置。部分程序会把配置放在用户数据目录，卸载操作也可能同时清理应用数据。建议先保持旧客户端可运行，完成以下备份，再处理新旧程序切换。

订阅地址与配置文件

如果配置来自订阅，先记录原始订阅地址，并确认它仍可更新。客户端列表中显示的配置名称只是本地标签，不能替代订阅 URL。若服务方提供了专用转换链接，还应记录原始订阅与转换规则之间的关系，以免迁移后得到不同格式的配置。

对于手工维护的配置，应导出完整 YAML，而不是只复制节点段。策略组会通过节点名称或 Provider 名称建立引用，规则又会引用策略组；只保留 proxies 段会让这条引用链断开。配置引用了本地规则集、脚本或覆写文件时，也要一并复制对应文件。

本地覆写与自定义规则

很多客户端会在订阅配置之外提供覆写功能，例如强制修改 DNS、追加规则、改变监听端口或启用局域网访问。这些内容可能保存在客户端数据库中，并不会写回订阅 YAML。迁移前应逐项查看“覆写”“全局扩展”“合并配置”或类似页面，记录实际生效的设置。

规则顺序必须保留。Clash 规则通常从上到下匹配，连接在命中第一条规则后停止继续检查。如果把自定义直连规则追加到 MATCH 之后，它就永远不会生效。迁移时即使规则文本完全相同，合并位置发生变化也可能导致路由结果不同。

端口、局域网与控制接口

记录旧客户端使用的 mixed-port、HTTP 端口、SOCKS 端口、是否允许局域网连接，以及外部控制器地址。浏览器插件、终端环境变量、下载工具和其他应用可能仍指向旧端口。如果新客户端随机分配端口，而外部程序继续连接旧端口，就会出现“客户端正常但部分软件无法联网”的现象。

external-controller 和控制密钥主要供图形界面或外部面板调用，不应直接照搬到一个已经占用相同端口的并行实例。新旧客户端同时运行时，也不能让它们监听同一个代理端口。

敏感信息的保存方式

订阅 URL 往往包含用于识别账户的访问参数，完整 YAML 也可能包含服务器地址、认证信息和控制密钥。备份文件应保存在受控目录，不要把完整内容贴到公开问题区、截图或公开代码仓库。需要展示错误时，可以保留字段结构并删去认证值。

推荐的 Clash 配置迁移步骤

1. 更新并导出旧配置。在旧客户端中执行一次订阅更新，确认策略组和节点列表能够正常载入，然后保存订阅地址、YAML 与自定义规则。
2. 记录当前网络设置。保存代理端口、系统代理状态、TUN 状态、DNS 模式和局域网开关。终端单独设置了代理环境变量时，也应记录变量所用端口。
3. 关闭旧客户端的接管功能。先关闭系统代理和 TUN，再完全退出旧客户端。只关闭窗口不一定会停止后台内核，应在任务管理器或系统活动监视器中确认进程已经结束。
4. 安装并启动新客户端。第一次启动时先使用默认设置，不要立刻复制旧客户端整个数据目录。确认新客户端的内核可以正常运行，再导入配置。
5. 优先重新添加订阅。订阅仍有效时，在新客户端中重新添加 URL，通常比复制缓存文件更可靠。手工配置则通过本地文件导入，并保持关联文件的相对路径。
6. 重新应用覆写。按照新客户端支持的格式设置 DNS、端口、自定义规则和 Provider。不同客户端的覆写语法不一定兼容，不能仅凭文件扩展名判断。
7. 先验证普通代理，再启用 TUN。先使用系统代理测试网页和连接记录，确认节点、策略组与规则正常，再单独开启 TUN。分阶段验证更容易确定错误来自配置还是流量接管。
8. 稳定后再移除旧客户端。保留旧配置备份一段时间，但不要让两个客户端同时修改系统代理或接管默认路由。

一个可迁移的基础配置通常具有清晰的引用关系。下面的示例省略具体节点，使用 Provider 提供节点，并由策略组和规则继续引用：

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

proxy-providers:
  provider-main:
    type: http
    url: "https://example.com/profile.yaml"
    path: ./providers/main.yaml
    interval: 86400
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

proxy-groups:
  - name: PROXY
    type: select
    use:
      - provider-main

rules:
  - DOMAIN-SUFFIX,example.net,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

导入后如果出现“Provider 不存在”或策略组为空，应依次检查 Provider 名称、下载状态和策略组中的 use 引用。文件路径以配置文件所在位置为基准时，移动 YAML 却没有移动规则集或 Provider 缓存，也会导致加载失败。对于远程 Provider，缓存可以由新客户端重新下载，不必从旧数据库中强行复制。

不同平台如何选择替代客户端

替代软件不应只按界面相似度选择。更实用的判断维度包括：是否持续维护、采用什么内核、能否导入现有配置、是否支持系统代理与 TUN、日志是否便于排障，以及安装包是否匹配系统和处理器架构。迁移到采用 Mihomo 内核的客户端时，通常能继续使用主流 Clash 规则结构，但图形界面的操作路径会有所不同。

Windows

Windows 用户应优先选择持续维护、明确标注 Mihomo 内核并支持服务模式或 TUN 管理的桌面客户端。普通网页和多数桌面软件只需要系统代理；游戏、命令行程序或不读取系统代理的应用，才可能需要 TUN。开启 TUN 往往涉及管理员权限、网络适配器和系统服务，因此应先完成普通代理测试。

还要确认安装包架构。多数现代电脑使用 x64，Windows on ARM 设备可能需要 arm64 构建。迁移期间若系统代理开关无法恢复，可以先退出所有代理客户端，再到 Windows 代理设置中检查手动代理是否仍指向旧端口。

macOS

macOS 替代客户端应匹配 Apple 芯片或 Intel 处理器。Apple 芯片通常选择 arm64 或 universal 构建，Intel 设备选择 x64 构建。系统首次运行时可能要求确认网络扩展、辅助服务或 VPN 配置，这些授权属于 TUN 接管流程，不是 YAML 配置的一部分。

从旧客户端迁移后，如果菜单栏显示代理已启用但应用仍直连，应检查当前网络服务的系统代理是否被正确写入。macOS 可能同时存在 Wi-Fi、有线网络和其他网络服务，客户端修改的服务与当前实际使用的服务不一致时，也会造成代理状态看似开启但流量未经过内核。

Android

Android 上的 Clash 类客户端通常通过系统 VPN 接口接管流量，而不是桌面系统代理。迁移重点是重新导入订阅、允许创建 VPN 连接，并检查分应用代理、绕过设置和电池后台限制。旧客户端导出的应用分流名单不一定能被新客户端识别，需要重新选择哪些应用经过代理。

如果设备已经存在其他 VPN、广告过滤或工作资料网络，系统通常不能同时让多个普通 VPN 接口生效。测试新客户端时应先停止其他 VPN 服务。Android 安装包还要匹配 arm64-v8a 等处理器架构；不确定时可选择客户端正式提供的通用构建，但文件体积通常更大。

Linux

Linux 用户可以选择图形客户端，也可以直接运行 Mihomo 内核并配合 systemd 管理。桌面环境的系统代理只影响遵循该设置的程序，终端工具仍可能需要 http_proxy、https_proxy 和 all_proxy 环境变量。使用 TUN 时，还要检查内核权限、路由表和 DNS 管理方式。

从图形客户端迁移到命令行内核时，尤其要保留配置引用的相对目录，并明确工作目录。相同的 YAML 在不同启动目录下运行，外部规则文件和 Provider 路径可能解析到不同位置。建议把配置、Provider 与规则集放入固定目录，再由服务参数明确指定配置路径。

iPhone 与 iPad

iOS 和 iPadOS 不能直接安装桌面或 Android 的 Clash 客户端。应选择平台允许安装、支持所需协议与规则格式的网络工具，并根据其导入能力转换配置。Clash YAML 不一定能被所有 iOS 客户端原样读取，策略组、脚本、规则集和 DNS 字段可能需要按目标应用文档调整。迁移前先确认订阅服务是否提供对应格式，比手工复制节点更稳妥。

订阅、规则与 DNS 的兼容性检查

配置能够导入，只代表 YAML 语法通过，不代表所有连接都会按预期路由。迁移后应检查订阅更新、节点连通、策略组引用、规则命中和 DNS 解析五个层面。

订阅更新失败

先查看错误发生在下载阶段还是解析阶段。下载超时通常与网络、订阅地址或代理回环有关；解析失败则可能是返回内容不是 YAML、订阅转换格式错误，或配置包含当前内核不识别的字段。如果客户端支持“通过代理更新订阅”，首次启动时应谨慎使用，因为此时还没有可工作的节点，容易形成更新依赖。

规则集无法载入

旧配置可能通过 rule-providers 引用远程规则集。迁移后要检查行为类型、格式、URL、保存路径和规则中的引用名称。规则 Provider 的名称与策略名称是两套概念，不能互换。使用 GEOIP、GEOSITE 等规则时，还应确认客户端能下载并加载相应地理数据库。

DNS 行为变化

旧客户端与新客户端可能使用不同的默认 DNS 配置。启用 fake-ip 后，内核会向应用返回保留地址，再根据内部映射处理真实连接；redir-host 的解析路径不同。迁移时不要在尚未理解旧设置的情况下直接复制整个 DNS 段，尤其要检查监听地址、上游服务器、回退规则和 Fake IP 排除列表。

出现网页偶尔打不开、局域网设备域名失效或某些应用登录异常时，可以暂时关闭自定义 DNS 覆写，使用新客户端默认值复测。如果默认配置正常，再逐项恢复旧设置。一次修改多个 DNS 字段会让排障失去对照。

TUN 模式迁移与常见故障

TUN 模式会创建虚拟网络接口，并通过路由或系统网络扩展把更多流量交给内核处理。它能覆盖不遵循系统代理的应用，但也比普通系统代理更依赖操作系统权限。旧客户端的 TUN 驱动、服务注册信息和路由状态不应复制到新客户端。

正确顺序是先在旧客户端关闭 TUN，完全退出并确认虚拟接口不再工作，然后让新客户端按自身流程安装服务或申请权限。新旧客户端同时启用 TUN，可能出现默认路由竞争、DNS 被反复改写、网络循环或断网。

开启 TUN 后完全断网

• 检查当前策略组是否选择了可用节点，最终规则是否指向存在的策略组。
• 检查系统中是否还有其他 VPN、代理工具或网络过滤程序占用路由。
• 确认客户端服务具有所需权限，虚拟接口创建过程没有报错。
• 暂时关闭自定义 DNS 与复杂路由设置，使用客户端默认 TUN 配置测试。
• 关闭 TUN 后确认普通系统代理仍能工作，以区分节点问题和接管问题。

浏览器正常但终端失败

这通常说明浏览器使用了系统代理，而终端程序没有读取系统代理。可以让终端工具显式连接新客户端的 HTTP 或 SOCKS 端口，或者启用配置正确的 TUN。迁移后要同步更新环境变量中的旧端口；仅在图形客户端中改变监听端口，不会自动修改 shell 配置文件。

关闭客户端后仍显示代理

客户端异常退出时，系统代理可能没有恢复。此时应先在操作系统网络设置中关闭手动代理，再重新启动新客户端。不要通过反复启动多个旧客户端来争夺系统代理状态，这会让当前配置更难判断。若 TUN 服务仍在后台运行，还应通过新客户端提供的服务管理功能停止它，必要时重启系统以清理临时路由。

迁移完成后的验证清单

迁移完成不应只用“网页能打开”作为判断标准。一个完整验证过程至少包括以下项目：

• 订阅可以手动更新，更新后配置不会丢失自定义规则。
• 策略组内能够看到预期节点，自动测速或健康检查可以执行。
• 访问不同类型的站点时，连接记录命中预期规则和策略。
• 系统代理关闭后流量恢复直连，重新开启后端口与客户端一致。
• TUN 开启和关闭都不会留下异常路由，局域网访问符合配置。
• 终端、浏览器和需要代理的独立应用均使用正确端口。
• 重启操作系统后客户端能够按预期启动，配置和权限仍然有效。
• 旧客户端已退出，不再自动启动或修改系统代理。

验证稳定后，可以卸载旧客户端并保留一份整理过的配置备份。备份中应写明创建日期、适用内核和依赖文件，避免数月后无法判断文件来源。订阅配置仍应通过客户端定期更新，本地自定义规则则建议单独保存，减少订阅覆盖带来的丢失风险。

客户端迁移的关键不是复制更多文件，而是明确哪些数据属于通用 Clash 配置，哪些状态属于旧程序。先备份订阅与规则，再分阶段验证系统代理、DNS 和 TUN，可以把停更客户端带来的切换风险限制在可定位的范围内。