Clash for Windows 停更后如何迁移：客户端替代与配置兼容指南

先选持续维护的客户端，再迁移订阅与规则

Clash for Windows 停止维护后，不建议继续把它作为长期主客户端。迁移的重点不是找到界面完全相同的软件，而是确认新客户端使用的内核、支持的配置字段、系统代理实现和 TUN 能力符合当前需求。对于 Windows、macOS 与 Linux 桌面环境，优先考察采用 mihomo 内核且仍在维护的图形客户端；需要轻量部署或远程管理时，可以直接使用 mihomo 命令行核心配合控制面板；Android 与 iOS 则应按各自平台支持的客户端重新导入订阅，不能直接复制桌面程序目录。

大多数标准订阅可以在新客户端中重新添加，不必把旧客户端的全部运行目录搬过去。真正需要单独处理的是本地 YAML 配置、规则集、策略组选择、覆写内容、脚本、订阅更新地址以及局域网共享参数。Clash for Windows 的界面设置、JavaScript Parser、特定版本的 Profiles 数据结构和系统代理状态，并不等同于通用 Clash 配置，直接复制后可能出现配置无法加载、规则顺序变化或 DNS 行为不同。

按系统、内核和维护状态选择替代客户端

替代客户端的名称相近，但它们并不是同一个项目的连续版本。选择时应把“图形界面”和“代理内核”分开判断：界面负责配置管理、订阅更新、系统代理开关和日志展示，内核负责协议连接、规则匹配、DNS、TUN 与流量转发。采用 mihomo 内核的客户端通常能够识别更多现代配置字段，但具体支持程度仍受客户端版本、内核版本和操作系统权限影响。

如果原来只使用“规则模式、订阅更新、系统代理”三项功能，迁移到主流 mihomo 桌面客户端通常比较直接。若旧环境依赖 TUN、脚本覆写、复杂 DNS、局域网共享或多个代理提供者，则应先阅读目标客户端的配置说明，再做小范围测试。不要仅凭界面截图判断兼容性，同一个客户端在不同版本中可能更换内核或调整配置存储方式。

Windows 用户优先检查服务模式

Windows 下的普通系统代理主要影响遵循系统代理设置的应用，而游戏、命令行程序、部分商店应用和自行建立网络栈的软件可能不会经过该入口。需要接管更多流量时，通常要使用 TUN。TUN 涉及虚拟网卡、管理员权限、路由表和 DNS 接管，因此迁移后应先验证普通系统代理，再单独开启 TUN，避免同时排查多个变量。

macOS 与 Linux 用户关注权限和桌面环境

macOS 的系统扩展、网络权限和后台项目设置会影响 TUN 与开机启动。Linux 则需要考虑桌面环境的代理设置、NetworkManager、systemd 服务以及内核网络权限。客户端宣称支持某个平台，只表示可以运行，并不保证每种桌面环境都能自动写入系统代理。对服务器或无桌面环境而言，mihomo 核心配合配置文件通常比桌面客户端更合适。

订阅能导入，不代表旧配置可以原样复制

Clash 配置通常使用 YAML，但“都是 YAML”不等于字段完全兼容。标准代理节点、代理组和规则具有较高可迁移性；与具体内核、图形客户端或操作系统耦合的部分则需要重新检查。迁移时可以把内容分成四层：订阅数据、核心配置、客户端覆写以及系统状态。

1. 订阅数据：包括订阅地址、节点、策略组和远程规则提供者。最稳妥的方法是在新客户端中重新添加订阅地址，让目标客户端自行下载和解析。
2. 核心配置：包括端口、运行模式、DNS、TUN、规则、代理组、外部控制器和局域网监听。应按目标内核文档检查字段。
3. 客户端覆写：包括订阅合并、全局扩展、配置预处理、脚本和界面保存的附加项。这一层往往不能跨客户端直接复用。
4. 系统状态：包括系统代理、虚拟网卡、服务、启动项、防火墙放行和本地端口占用。复制配置文件不会自动迁移这些状态。

通常可以保留的配置部分

常见的 proxies、proxy-groups、rules、proxy-providers 与 rule-providers 可以作为迁移基础。使用 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP 和 MATCH 等规则类型时，应继续保持从上到下匹配的顺序。首条命中的规则决定流量去向，迁移中如果客户端自动插入规则或覆写规则列表，结果可能与旧环境不同。

需要重新核对的配置部分

• tun 下的网络栈、自动路由、接口检测和 DNS 劫持选项。
• dns 下的 enhanced-mode、Fake IP 范围、回退解析器和域名过滤列表。
• external-controller、控制器监听地址和访问密钥。
• allow-lan、bind-address 与本地防火墙规则。
• 仅由旧客户端解释的 Parser、JavaScript 脚本、快捷命令和界面覆写。
• 仅在特定内核中存在的协议参数、规则类型和嗅探配置。

下面是一份用于迁移验证的简化结构，重点是确认端口、模式、DNS 与规则能够被新内核加载。示例不包含真实节点，实际使用时应从订阅导入节点与策略组，而不是把敏感连接信息写入公开文档。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

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

这段配置中的 PROXY 必须对应实际存在的代理组，否则内核会报告策略目标不存在。DNS 地址也只是结构示例，应根据网络环境、隐私要求和订阅说明选择。若迁移前使用 redir-host，切换到 fake-ip 后可能改变局域网域名、特殊应用和连接测试工具的表现，因此不要在首次导入时顺便更改 DNS 模式。

备份配置来源，而不是复制整个运行状态

开始迁移前，先在旧客户端中记录当前能正常工作的基线。备份的目标是能够解释“原来如何连接”，而不是让两个客户端共享同一个数据目录。不同客户端可能同时写入配置索引、缓存和策略选择记录，共用目录容易造成文件格式冲突。

建议保留的内容

• 有效的订阅地址及其用途，区分主订阅、测试订阅和本地配置。
• 手工维护的 YAML 文件、规则文件、代理提供者与规则提供者地址。
• 当前使用的代理模式，例如规则、全局或直连。
• 常用策略组的选择结果，例如自动选择、故障转移或指定节点。
• 混合端口、HTTP 端口、SOCKS 端口和外部控制端口。
• DNS 增强模式、TUN 状态、局域网访问状态和监听地址。
• 需要保留的 Parser 或覆写逻辑，并用文字说明它具体修改了哪些字段。

订阅地址和本地配置可能包含访问凭据，不应粘贴到公开日志、截图或在线格式化工具。备份文件应存放在当前账户可控的位置。若准备重装系统，还应额外记录客户端版本、核心版本和系统架构，因为相同配置在不同核心版本上可能表现不同。

退出旧客户端前记录端口占用

Clash 系客户端常用 7890 一类本地端口，但实际端口可能已经修改。迁移后如果新客户端提示监听失败，常见原因是旧进程没有退出、另一个代理程序仍占用端口，或系统服务继续在后台运行。关闭窗口不一定等于退出进程，应从客户端菜单正常退出，并检查任务管理器或系统进程列表。

用最小配置建立连接，再逐项恢复高级功能

一次性导入所有旧设置会让故障来源难以定位。更可靠的顺序是先验证客户端和内核能启动，再验证订阅解析、节点连接、规则匹配，最后处理 TUN、DNS 覆写与局域网共享。

1. 确认系统和处理器架构。

   Windows 需要区分 x64、ARM64 等架构，macOS 需要区分 Apple 芯片与 Intel 机型，Linux 还要确认发行版、包格式和桌面环境。安装包架构不匹配时，程序可能无法启动或无法安装系统服务。

2. 安装目标客户端并检查内核。

   首次启动后查看客户端显示的核心名称与版本。若准备使用 mihomo 配置扩展，应确认当前实际运行的是 mihomo，而不是仅凭客户端名称推断。

3. 彻底退出旧客户端。

   关闭旧客户端的系统代理和 TUN，再退出后台进程。不要让新旧两个客户端同时修改系统代理、路由和 DNS。

4. 重新添加订阅。

   优先使用原订阅地址在新客户端中创建配置。更新完成后检查是否生成节点和策略组，并确认配置页面没有解析错误。订阅服务提供的格式若只面向特定客户端，应先确认它是否提供 Clash 或 mihomo 格式。

5. 先启用规则模式与系统代理。

   选择一个可用节点或策略组，保持 TUN 关闭，通过浏览器测试基本连接。此时应查看内核日志，确认域名解析、规则命中和代理握手均正常。

6. 恢复自定义规则与覆写。

   每次只增加一类改动，例如先恢复规则提供者，再恢复代理组调整，最后处理 DNS。添加后立即重新加载配置并观察错误位置。

7. 按需启用 TUN。

   确认普通系统代理可用后，再授予必要权限并打开 TUN。测试完成后检查路由、DNS 和虚拟网卡是否在客户端退出时正确恢复。

8. 最后配置开机启动和局域网共享。

   只有在日常连接稳定后再设置自动启动。局域网共享还需要绑定合适地址、设置防火墙规则，并限制在可信网络中使用。

从内核启动、规则命中到系统恢复逐层检查

“浏览器可以打开网页”只能证明部分链路有效。完整迁移还需要确认订阅能更新、规则结果符合预期、其他应用能按需要接入代理，以及退出客户端后系统网络能够恢复。

第一层：配置是否被内核接受

先查看启动日志。YAML 缩进错误、重复字段、代理组引用不存在、规则提供者下载失败和端口冲突通常会在这一层出现。配置解析失败时不要反复切换节点，应先定位日志中的字段名和行号。若本地配置可以加载而订阅配置不能加载，问题更可能位于订阅格式或覆写过程。

第二层：节点与 DNS 是否工作

连接测试应同时观察延迟测试和实际请求。延迟测试成功不代表所有目标站点都能访问，因为测试地址、DNS 结果、规则路径和协议握手可能不同。出现域名无法访问但 IP 连接正常时，优先检查 DNS；出现所有节点同时超时，则检查本地网络、防火墙、订阅有效性和系统时间。

第三层：规则是否按预期命中

打开客户端连接记录，查看目标域名命中了哪条规则以及最终使用哪个策略组。若流量意外直连，检查高优先级的直连规则是否覆盖了后续代理规则；若所有流量都走代理，检查当前是否误选全局模式，或 MATCH 前缺少必要的直连规则。使用规则提供者时，还要确认远程文件已成功下载并被配置引用。

第四层：系统代理与 TUN 是否冲突

启用 TUN 后，一些客户端仍会同时保留系统代理，这在特定环境下可能造成重复接管或排查混乱。应根据目标客户端的实现选择推荐组合。若只有浏览器可用而其他应用不可用，说明普通系统代理可能已经生效，但目标应用不读取该设置；若启用 TUN 后全部断网，应检查虚拟网卡权限、自动路由、DNS 劫持和其他 VPN 软件。

第五层：退出后的网络恢复

退出新客户端后，确认系统代理已关闭、浏览器可以直连允许访问的站点、DNS 没有继续指向失效的本地监听端口。Windows 可检查系统代理页面，macOS 可检查当前网络服务的代理项，Linux 则根据桌面环境和启动方式检查环境变量、桌面代理及 systemd 服务。若退出后仍无法联网，先清除残留代理状态，再检查虚拟网卡和路由。

迁移完成后的长期维护要点

新客户端稳定运行后，还需要把维护来源固定下来。客户端、代理内核、订阅与规则数据库是四个独立更新环节，不应把所有异常都归因于客户端。界面更新可能改变配置管理方式，内核更新可能增加或调整字段，订阅更新会改变节点和策略组，规则数据库更新则影响域名与地址分类。

日常使用中，建议保留一份结构简单的应急配置，并记录当前稳定版本。更新前先阅读变更说明，更新后依次检查内核启动、订阅刷新、常用规则和 TUN。若工作环境对连续性要求较高，可以推迟重大版本切换，先在独立配置中测试。客户端替代的最终目标是建立可验证、可回退的配置链路，而不是持续追逐界面或功能数量。

如果还未确定目标客户端，可先查看本站的客户端对比与概念速查，再根据操作系统、是否需要 TUN、是否维护本地规则和是否需要局域网共享做选择。完成安装后，按使用教程建立最小可用配置，比直接导入全部旧数据更容易定位问题。