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

停更影响与迁移范围

Clash for Windows 停止维护后，已有安装并不会立即失效。本地配置、已经下载的订阅和代理规则仍可能继续运行，但客户端不再持续适配操作系统变化，也不会跟进新的 mihomo 内核字段、TUN 实现和安全修复。继续使用旧版本时，常见问题不是“节点突然全部失效”，而是订阅格式更新后无法完整读取、系统代理状态没有正确还原、TUN 服务与新版操作系统发生冲突，或者新的规则字段被旧内核忽略。

迁移时需要区分三类数据。第一类是订阅入口，包括订阅地址、远程配置更新时间和配置名称；第二类是用户修改，例如自定义规则、覆写字段、脚本处理和策略组选择；第三类是设备接管状态，包括系统代理、开机启动、局域网访问、TUN 服务和 DNS 设置。只复制一个 YAML 文件，通常不能覆盖这三类数据。

如果日常配置完全来自订阅，迁移重点是重新导入订阅，并在新客户端里恢复策略组选择。若曾在 Clash for Windows 中使用 Mixin、Parsers、Script 或手动编辑配置，则要单独记录这些改动。不同图形客户端对覆写功能的名称和格式并不一致，旧客户端里的 JavaScript 解析器也不能直接视为通用配置。

迁移前备份订阅与本地修改

记录订阅入口

打开 Clash for Windows 的 Profiles 页面，确认正在使用的是远程订阅还是本地配置。远程订阅应保存原始订阅地址，而不是只保留客户端缓存生成的 YAML。原始地址可以让新客户端重新拉取最新节点、策略组和规则；缓存文件只能反映某一次更新时间的内容，后续也可能因为远程规则集路径变化而加载失败。

订阅地址通常包含用于识别账户的参数，应当按密码信息处理。不要把地址写入公开截图、问题反馈或公开代码仓库。若服务提供方允许重置订阅链接，在地址已经暴露时应先重置，再向新客户端导入新的地址。

导出本地配置

对于手动维护的 YAML，可以从客户端打开配置所在目录，将正在使用的主配置及其引用文件复制到单独目录。需要一起检查的文件包括代理提供器、规则提供器、本地规则集和证书相关文件。主配置中的相对路径依赖原目录结构，移动文件后要保持层级一致，或者在新客户端中重新指定路径。

配置中最值得单独记录的字段如下：

• mode：当前使用规则模式、全局模式还是直连模式。
• proxies 与 proxy-providers：手动节点和远程节点提供器。
• proxy-groups：策略组名称、类型、引用关系及健康检查地址。
• rules 与 rule-providers：自定义规则顺序和外部规则集。
• dns：DNS 是否启用、工作模式、上游服务器及排除范围。
• tun：虚拟网卡、自动路由、DNS 劫持和接口选择。

如果只是从订阅导入配置，不建议在订阅生成的 YAML 里长期直接修改。下一次更新可能覆盖这些内容。迁移到新客户端后，应优先使用客户端提供的覆写、扩展脚本或配置合并功能保存用户改动，并确认该功能会在每次订阅更新后重新执行。

制作迁移记录

在关闭旧客户端前，记录当前选中的策略组节点、系统代理端口、是否允许局域网连接、TUN 是否启用，以及哪些应用依赖代理。策略组选择一般保存在客户端自己的数据库或缓存中，不一定写回订阅 YAML。即使组名和节点名完全相同，新客户端首次加载时也可能回到组内第一项，需要手动重新选择。

替代客户端怎么选

选择替代客户端时，不应只比较界面。更重要的是内核、平台支持、配置兼容性和接管方式。目前持续更新的客户端多以 mihomo 作为核心。mihomo 延续 Clash 配置体系，并增加规则集、DNS、流量嗅探和 TUN 等能力。客户端负责配置管理和系统集成，内核负责解析配置、建立连接及执行规则。

Windows 用户通常需要确认安装包对应 x64、ARM64 等设备架构。macOS 还要区分 Apple 芯片和 Intel 处理器。Linux 用户除架构外，还应检查桌面环境、软件包格式和系统服务权限。客户端能否启动只是第一步，系统代理开关、TUN 驱动或服务能否正确安装，才决定流量是否可以稳定接管。

如果原配置包含 mihomo 专用字段，应选择明确使用 mihomo 内核并保持更新的客户端。若配置只包含基础端口、普通节点、策略组和规则，大多数兼容 Clash 配置的客户端都可以读取。图形客户端自己的覆写数据库、界面偏好和快捷设置则不属于 YAML 标准，通常不能跨客户端直接复制。

从 Clash for Windows 转移到新客户端

第一步：解除旧客户端的流量接管

1. 在 Clash for Windows 中关闭 System Proxy。
2. 若已开启 TUN Mode，先关闭 TUN，再等待网络接口恢复。
3. 退出客户端，确认后台进程已经结束。
4. 检查操作系统代理设置，确认没有残留指向旧端口的手动代理。

这一步用于避免端口冲突和重复路由。两个客户端同时启用系统代理时，最后写入系统设置的一方通常会成为入口，但另一个客户端仍可能占用端口。两个 TUN 同时运行则可能产生默认路由竞争、DNS 查询绕行或局域网访问异常。

第二步：安装并首次启动新客户端

从客户端项目提供的发布渠道获取与操作系统及处理器架构匹配的安装包。首次启动后先不要立即开启系统代理或 TUN，先查看内核状态与配置目录是否正常。部分客户端会单独更新 mihomo 内核；如果界面显示内核未就绪，应先按客户端提示完成核心安装或切换。

第三步：重新导入订阅

在新客户端的订阅或配置入口粘贴原始订阅地址，执行下载并设为当前配置。加载成功后检查节点数量、策略组名称和规则数量是否与旧客户端大致一致。数量不必逐项完全相同，因为订阅服务可能在迁移期间更新内容，但不应出现配置为空、只有少量节点或全部策略组缺失。

如果订阅返回“格式错误”，先确认复制的地址没有多余空格和换行，再尝试通过浏览器或服务方控制台重新获取链接。若订阅内容由旧版 Clash 格式生成，而新客户端使用 mihomo，一般可以读取基础字段；真正容易出错的是缩进不正确、引用文件不可访问、策略组引用了不存在的节点，或订阅响应实际返回了登录页面。

第四步：迁移自定义规则和覆写

将旧配置中的个人规则按原顺序加入新客户端支持的覆写位置。Clash 规则从上到下匹配，第一条命中的规则决定流量去向，因此顺序比规则数量更重要。局域网直连、指定域名代理、应用进程规则和最终兜底规则之间不能任意交换。

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

上例仅说明顺序结构。实际使用时，Proxy 必须与配置中的策略组名称完全一致。组名包含空格或中文时也要逐字对应。若订阅每次更新都会重建策略组，应将自定义规则指向稳定存在的组名，避免更新后出现“找不到策略组”的加载错误。

Clash for Windows 的 Parsers 可能使用 JavaScript 修改订阅结果，这类逻辑不能直接粘贴到所有新客户端。应先理解脚本修改了哪些字段，再改写为目标客户端支持的覆写、合并配置或扩展脚本。不要在不了解执行阶段的情况下同时启用多套覆写，否则可能出现端口被重复修改、DNS 字段被后执行的配置覆盖等问题。

第五步：恢复策略选择和更新周期

逐个打开策略组，恢复常用节点或自动选择方式。对于 url-test、fallback 等自动组，确认健康检查能够执行；对于 select 手动组，确认当前选项不是失效节点。随后设置订阅更新间隔，并手动更新一次，观察覆写内容是否仍然存在。

系统代理与 TUN 设置如何恢复

订阅加载完成不等于设备流量已经进入 Clash。新客户端仍需要建立流量入口。系统代理和 TUN 是两种不同的接管方式，应先从系统代理开始验证，再根据应用兼容性决定是否开启 TUN。

先测试系统代理

开启新客户端的系统代理后，操作系统会把支持系统代理设置的 HTTP 或 SOCKS 流量发送到本地监听端口。浏览器和多数桌面应用通常可以直接使用这种方式。打开客户端连接记录，访问一个测试站点，确认日志中出现域名、命中规则和最终策略组。

若开启后完全无法联网，检查新客户端监听端口是否被其他程序占用，系统代理是否写入了正确的本地地址，以及配置是否处于 Rule 模式。关闭客户端后系统仍无法联网，则应进入操作系统网络设置，清除残留的手动代理。

再配置 TUN

游戏、命令行工具、部分商店应用和不读取系统代理的软件，可能需要 TUN 接管。TUN 会创建虚拟网络接口，把符合路由条件的 IP 流量交给 mihomo。首次开启通常需要管理员权限，并可能安装系统服务或虚拟网卡组件。

迁移 TUN 时不要直接照抄旧客户端的开关状态。先使用新客户端推荐的默认设置，确认虚拟接口成功建立，再检查 auto-route、strict-route、DNS 劫持和接口自动识别。不同操作系统对这些字段的实现存在差异，新客户端也可能通过界面生成对应配置。

如果 TUN 开启后局域网打印机、NAS 或路由器管理页无法访问，先检查私有网段是否保持直连，并查看严格路由是否改变了本地访问路径。若只有域名访问异常而直接 IP 正常，重点检查 DNS 模式、Fake-IP 排除列表和上游 DNS 可达性，而不是反复切换节点。

迁移后的检查清单

完成订阅导入和流量接管后，按以下顺序检查。每完成一项再进入下一项，可以快速判断问题位于配置、规则还是系统入口。

1. 内核状态：客户端显示 mihomo 正常运行，没有持续重启或配置解析错误。
2. 订阅更新：手动更新可以完成，更新时间发生变化，节点与策略组正常显示。
3. 配置模式：确认当前是需要的 Rule、Global 或 Direct 模式，迁移后不要默认沿用界面初始值。
4. 策略组：手动组已恢复选择，自动组可以完成延迟测试，规则引用的组名全部存在。
5. 系统代理：浏览器访问产生连接记录，关闭系统代理后网络设置能够正确还原。
6. DNS：域名解析稳定，日志中没有连续超时；局域网域名和特殊域名按预期处理。
7. TUN：仅在确有需要时开启，并验证不读取系统代理的应用能够进入连接记录。
8. 局域网：路由器、NAS、打印机和共享服务仍可访问，私有地址没有被错误送往代理。
9. 开机启动：确认启动项只保留新客户端，并检查系统代理或 TUN 是否会按预期恢复。
10. 旧客户端处理：稳定使用一段时间后再卸载旧客户端，卸载前确认备份目录不在应用数据清理范围内。

常见迁移故障定位

订阅导入成功但没有节点

先查看订阅响应是否是有效配置。有些地址需要在服务方控制台重新生成，过期链接可能返回提示文本而不是 YAML。还要确认客户端没有启用错误的订阅转换模板，以及配置文件中的节点提供器地址可以访问。

配置可以加载但规则全部走兜底

检查自定义规则是否放在 MATCH 之后。MATCH 是最终规则，后续条目不会再被执行。若使用远程规则提供器，还要确认 rule-providers 下载成功，并且规则中的 RULE-SET 名称与提供器名称一致。

系统代理开启后部分应用不生效

这通常表示应用没有读取操作系统代理，而不是订阅导入失败。先在客户端日志中确认浏览器流量正常，再为目标应用设置其自身代理，或在确认权限和路由设置后使用 TUN。不要因为单个应用没有记录就立即修改整套 DNS 配置。

TUN 开启后断网

先关闭 TUN，确认系统代理模式仍能工作。随后检查虚拟网卡服务权限、默认接口识别、路由冲突和 DNS 上游。设备中运行的其他网络过滤器、虚拟机网络、企业 VPN 也可能改写路由。定位时每次只启用一种接管工具，避免多个变量同时变化。

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

这说明规则直接写入了订阅缓存文件，更新时被远程内容覆盖。应把规则移到新客户端提供的持久覆写位置，并确认覆写在订阅解析之后执行。迁移完成后至少手动更新两次，用于验证规则、DNS 和策略组修改能够持续保留。