Clash for Windows 停更后怎么迁移：客户端替代与配置转移方案

Clash for Windows 停止维护后，继续保留旧版本并不等于现有配置会立刻失效。订阅地址、代理节点、策略组和分流规则通常仍由配置文件提供，客户端主要负责配置管理、内核启动、系统代理、TUN 接管和界面操作。迁移的重点因此不是寻找外观完全一致的软件，而是确认新客户端能否运行相应内核、读取现有配置语法，并正确接管操作系统网络设置。

较稳妥的迁移方式是先备份旧数据，再选择仍有维护活动的桌面客户端，通过订阅地址或原始 YAML 重新导入，最后逐项检查规则模式、策略组、DNS、系统代理和 TUN。不要在旧客户端仍接管流量时直接开启新客户端，否则两个程序可能同时修改系统代理、虚拟网卡或服务状态，使故障来源变得难以判断。

先判断需要迁移的是订阅、配置还是运行环境

Clash for Windows 中可见的“配置”可能来自不同来源。最常见的是远程订阅：客户端保存订阅 URL，更新后下载一份 YAML，再从中读取节点、策略组和规则。第二类是手动导入的本地 YAML，例如自行编写的分流文件。第三类则是客户端自身设置，包括开机启动、系统代理端口、界面偏好、配置覆写、脚本处理和 TUN 服务。这三类数据的可迁移程度并不相同。

如果原来只是导入服务商提供的订阅，并未手动修改 YAML，那么迁移通常很简单：记录订阅 URL 和常用策略组选择，在新客户端重新导入即可。如果长期维护自定义规则、代理提供者或 DNS 参数，则应把原始 YAML、外部规则文件和相关路径一起整理，而不是只复制旧客户端当前生成的运行配置。

替代客户端怎么选：内核、平台和配置能力

桌面替代方案应先看维护状态，再看操作系统支持与内核能力。Clash Verge Rev 是面向 Windows、macOS 和 Linux 的桌面客户端，使用 mihomo 内核，适合需要规则分流、配置管理、系统代理和 TUN 的用户。mihomo 延续了 Clash 配置体系，并扩展了规则集、协议、DNS 和流量接管能力，因此大量常规 Clash YAML 可以继续使用。

其他仍有维护活动的 mihomo 图形客户端也可以作为候选，但选择时不要只比较界面。更关键的是发布频率、所用内核版本、配置文件保存方式、系统代理恢复机制、TUN 服务安装方式，以及是否能查看连接、日志和规则命中结果。维护情况可能随时间变化，应以项目当前发布记录和说明文档为准。

选择替代客户端时检查六项

1. 平台覆盖：确认客户端明确支持当前 Windows、macOS 或 Linux 版本，并选择对应处理器架构。
2. 内核类型：优先确认是否使用 mihomo，以及客户端是否允许查看或更新内核版本。
3. 配置兼容：检查是否支持订阅、本地 YAML、代理提供者、规则提供者和自定义 DNS。
4. 接管方式：确认系统代理和 TUN 是否分开控制，退出程序时能否恢复系统设置。
5. 诊断能力：连接列表、实时日志、规则匹配和 DNS 日志有助于定位迁移问题。
6. 配置维护：确认订阅更新、覆写或合并机制，避免每次更新都覆盖本地调整。

旧版 Clash for Windows 的某些配置可能依赖当时的 Clash Premium 行为，也可能通过客户端专属的 parser 功能改写订阅。mihomo 对常见节点、策略组和规则语法兼容度较高，但客户端专属脚本、JavaScript 解析逻辑和界面设置不属于通用 YAML 标准，通常需要重建。选型前可先查看客户端对比，再根据平台和配置复杂度决定。

迁移前如何备份 Clash for Windows 数据

备份的目标是保留可恢复信息，而不是把整个旧目录原样覆盖到新客户端目录。开始前先打开 Clash for Windows，记录当前启用的配置名称、代理模式、常用策略组选择、系统代理状态和 TUN 状态。若订阅 URL 能在配置管理界面查看，应单独保存；若订阅地址包含访问令牌，应把备份放在受控位置，不要粘贴到公开截图、日志或论坛。

随后退出 Clash for Windows，并确认托盘进程已经结束。Windows 上的旧数据常见于用户目录下的配置目录，但具体位置会因安装方式和版本不同而变化。与其假设固定路径，更可靠的方法是从客户端设置或配置管理界面打开数据目录，然后复制整个目录作为只读备份。

建议保留的内容

• 订阅 URL、订阅名称以及最后一次成功更新时间；
• 自行编写的 YAML 文件和其中引用的本地规则文件；
• 当前运行配置，用于迁移后逐段比对；
• 策略组的常用选择，例如自动选择、故障转移或指定节点；
• 自定义端口、局域网访问、DNS 监听和控制器设置；
• 覆写、合并或 parser 脚本的源文件与处理逻辑说明。

备份完成后，在旧客户端中关闭系统代理和 TUN，再正常退出。可以打开操作系统代理设置，确认手动代理没有继续指向旧的本地端口。如果旧 TUN 服务仍驻留，应先通过旧客户端提供的服务管理入口停止或卸载，再安装新客户端的对应服务。

订阅与 YAML 配置转移步骤

方案一：重新导入订阅 URL

对大多数用户而言，重新添加订阅是首选方案。安装新客户端后先保持系统代理和 TUN 关闭，进入配置或订阅页面，粘贴原订阅 URL，等待客户端下载并解析配置。导入完成后检查节点数量、策略组名称和规则数量是否符合预期，再手动选择常用策略。

订阅导入成功只说明 YAML 可以读取，不代表流量已经正常。还需查看配置是否包含最终兜底规则，例如 MATCH，以及主要策略组是否引用了有效节点。部分订阅会根据客户端请求头返回不同格式；如果新客户端收到空配置或格式错误，应先在订阅服务提供方的管理页面重新获取适用于 Clash 或 mihomo 的订阅地址。

方案二：导入本地 YAML

本地配置应从新客户端的文件导入功能添加。导入前可以用文本编辑器检查主要段落，包括 proxies、proxy-providers、proxy-groups、rule-providers、rules 和 dns。策略组引用的节点或提供者名称必须真实存在，规则中引用的策略组也必须与定义名称完全一致。

mode: rule
mixed-port: 7890

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT

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

上面的结构展示了最基本的引用关系：规则把流量交给 PROXY，而 PROXY 策略组必须已经定义。实际迁移时不应机械照抄示例端口或规则，而应保留原配置需求，并根据新客户端占用情况调整。若配置引用相对路径文件，应确认新客户端的工作目录；更换应用后，相同相对路径可能指向不同位置。

方案三：重建覆写和合并逻辑

一些 Clash for Windows 用户通过 parser 给订阅追加规则、删除策略组或改写节点名称。这类逻辑通常不能作为普通 YAML 导入。迁移时应先获得订阅生成的基础配置，再使用新客户端支持的覆写、合并或脚本机制重建相同目标。

重建时宜把操作拆小：先追加一个策略组，再添加对应规则，确认配置能加载后继续。一次性迁移大量脚本会让语法错误、名称引用错误和规则顺序问题混在一起。规则具有自上而下、命中即停止的特点，新增规则应放在合适位置，不能只确认规则内容存在。

TUN、DNS 与系统代理不能直接照搬

系统代理只影响遵循操作系统代理设置的应用，常见浏览器和部分桌面软件会进入本地 HTTP 或 SOCKS 端口。TUN 则通过虚拟网络接口和路由接管更多流量，包括不读取系统代理的程序。两者属于运行环境设置，不是订阅中的节点数据，因此更换客户端后必须重新配置。

建议先用系统代理完成基础验证。选择一个可用节点，启用规则模式和系统代理，确认网页访问、规则命中和 DNS 解析正常。基础链路稳定后再开启 TUN，并按照新客户端提示安装服务或授予管理员权限。这样出现问题时，可以明确区分是配置文件错误，还是虚拟网卡、权限和路由造成的。

DNS 配置尤其需要谨慎。mihomo 常见的增强模式包括 fake-ip 和 redir-host，具体可用项取决于内核版本和配置。迁移后如果网页能打开但某些局域网域名、游戏或企业软件异常，应检查 DNS 监听地址、增强模式、排除列表、上游服务器和规则模式，而不是立即更换节点。

如果原配置启用了局域网访问，还应重新核对 allow-lan、监听地址和操作系统防火墙。监听在环回地址只供本机使用，监听所有接口则可能允许同一网络中的设备连接。迁移时应按实际共享需求配置，不要因为旧设置存在就直接复制。

迁移完成后如何确认流量走向

迁移验证应从配置加载、节点连接、规则匹配到系统恢复逐层进行。只测试一个网页容易掩盖问题，因为浏览器缓存、连接复用和应用自身 DNS 都可能影响结果。可以按照下面的顺序检查：

1. 启动新客户端，确认日志中不存在 YAML 解析、策略组引用或端口占用错误。
2. 更新订阅，确认更新时间、节点数量与策略组结构合理。
3. 在规则模式下选择明确的策略组出口，并测试普通网页连接。
4. 打开连接或日志页面，查看目标域名命中了哪条规则以及最终策略。
5. 分别测试应直连和应代理的域名，确认 DIRECT 与代理策略符合预期。
6. 启用 TUN 后测试不读取系统代理的应用，并观察对应连接是否进入内核。
7. 退出客户端，确认系统代理被恢复，网络不会继续指向已经停止的本地端口。

如果规则命中结果与旧客户端不同，先比较两边实际加载的最终配置，而不是只比较订阅名称。订阅更新、客户端覆写、规则集下载失败和内核特性差异都可能改变最终内容。mihomo 的连接详情通常会显示规则类型、策略链和出口节点，这些信息比单纯观察访问速度更适合判断分流是否正确。

迁移后常见问题与处理顺序

订阅能导入，但没有节点

先确认订阅地址是否仍在有效期内，以及返回内容是否为 Clash 或 mihomo 配置。某些地址需要在服务管理页面转换格式。若浏览器打开后得到登录页面、错误文本或其他客户端格式，新客户端自然无法生成节点列表。

配置提示策略组不存在

检查 rules 中使用的策略名称是否与 proxy-groups 完全一致，包括大小写、空格和符号。若策略组引用 use，还要确认对应 proxy-providers 已定义且下载成功。手动删除策略组后，引用它的规则也需要同步调整。

启动时提示端口被占用

旧客户端或旧内核进程可能仍在后台监听端口。先完全退出两个客户端，在任务管理器或系统监视工具中确认相关进程结束，再重新启动新客户端。也可以暂时修改新客户端的混合端口，但系统代理必须同步指向新端口。

开启 TUN 后无法联网

先关闭 TUN，确认系统代理模式是否正常。如果系统代理可用，重点检查 TUN 服务、权限、虚拟网卡、路由和 DNS。曾安装过多个客户端时，还应确认旧服务没有继续运行。处理完服务冲突后再重启系统，避免残留路由影响判断。

订阅更新后自定义规则消失

这通常说明修改直接写进了订阅缓存。远程更新会重新下载配置并覆盖缓存内容。应使用新客户端的覆写或合并机制维护本地规则，或者建立独立的 YAML，并让远程节点通过代理提供者方式更新。具体字段与操作方式可参考技术参考。

旧客户端是否应该立刻删除

完成备份后可以先保留安装文件和数据目录，但不要让旧客户端开机启动，也不要与新客户端同时接管系统代理或 TUN。经过几天使用，确认订阅更新、规则分流、休眠恢复和退出恢复均正常后，再清理旧程序及其服务更稳妥。

迁移结论：保留配置来源，重新建立运行环境

Clash for Windows 停更后的迁移核心可以概括为两部分：可复用的是订阅、节点、策略组和通用规则；需要重建的是客户端设置、覆写逻辑、系统代理、TUN 服务和部分 DNS 行为。对于普通订阅用户，重新导入订阅并核对策略组通常已经足够。对于维护自定义 YAML 的用户，则需要重点检查名称引用、规则顺序、外部文件路径和内核语法。

选择替代客户端时，持续维护、mihomo 内核支持、诊断能力和系统接管稳定性比界面相似度更重要。迁移完成后保留一份原始配置备份，并记录新客户端中的关键设置。以后更换设备或客户端时，就能从明确的数据来源恢复，而不必依赖某个程序生成的临时缓存。