Clash for Windows 停更之后:替代客户端怎么选,旧配置如何平移

先给结论：迁移配置，不复制整个客户端目录

Clash for Windows（下文简称 CFW）已于 2023 年停止维护，常见的最后公开版本为 0.20.39。已有安装可能仍能启动，但能够启动不等于内核、依赖与系统适配仍在更新。遇到新协议无法识别、系统升级后服务异常等问题，应优先考虑迁移，而不是反复重装同一个旧安装包。

Windows 用户可以先比较 Clash Verge Rev 与 Clash Nyanpasu；希望在桌面和 Android 上采用相近操作方式的用户，可以同时考察 FlClash。选择时要分别确认图形客户端和所带内核的发布状态，不能只凭项目名称中的 Clash 判断兼容性。安装包来源、当前支持的平台与架构，可从客户端下载页核对。

替代客户端怎么选：看内核、配置入口与系统集成

图形客户端主要管理订阅、托盘菜单、系统代理和服务安装；内核负责代理协议、规则匹配、DNS 与连接转发。Clash Meta 后续以 mihomo 名称继续发展，但这不意味着每个名为 Clash 的客户端都使用相同内核，更不意味着旧界面脚本能直接交给新内核运行。

下载前核对三个条件

• 系统与架构：在 Windows「设置」→「系统」→「系统信息」查看系统类型。x64 与 ARM64 不是同一架构，按项目实际提供的包选择，不凭文件大小判断。
• 项目发布记录：查看官方仓库的 Releases、最近修复内容与系统支持说明。衍生客户端的名称相似，维护状态需要逐个确认。
• 必需功能：如果只是浏览器访问，系统代理可能已经足够；确实需要接管不遵循系统代理的应用，再考察 TUN、服务权限和 DNS 配置。

不建议把“支持更多开关”作为唯一选择标准。对于现有订阅能正常使用的用户，能看清最终配置、能保留本地规则、能稳定恢复系统网络，通常比界面里多一个实验选项更重要。

迁移前备份：订阅、规则与界面设置分开保存

先在 CFW 的「Profiles」记录当前启用的配置，在「Proxies」记录模式和各代理组选择，再到「Settings」找到并打开实际配置目录。默认安装常见目录为 %USERPROFILE%\.config\clash，但便携方式或自定义路径可能不同，应以客户端打开的目录为准。

1. 保存订阅来源：记录订阅地址、更新间隔与服务提供方说明。订阅链接通常带有访问凭据，应存入受保护的本地记录，不要贴到公开论坛或截图中。
2. 备份配置文件：退出 CFW 后复制配置目录；另外保存当前配置的 YAML 文本，便于逐项比较。导出的节点列表不能替代订阅地址，后续自动更新仍需要原始来源。
3. 单独保存定制内容：包括 Parsers、Mixin、自定义规则、规则集地址、本地文件和 DNS 覆写。记录哪些内容来自订阅，哪些是后来手动添加的。
4. 记录系统集成：保存 HTTP、SOCKS 或 mixed 端口，系统代理、开机启动、服务模式以及 TUN 的启用状态。不要把缓存、旧服务程序和旧内核一起覆盖到新安装目录。

备份目录里可能含节点密码、订阅令牌和外部控制接口密钥。迁移完成后仍需妥善保管；如果曾误公开这些内容，应从对应服务端更换凭据，而不是只删除本地截图。

订阅平移：先让原始配置正常运行

第一轮只导入订阅，不启用旧脚本

退出 CFW，并关闭它的系统代理、TUN 和开机启动。打开新客户端，在订阅管理区域使用原订阅地址导入；例如 Clash Verge Rev 通常在「订阅」页提供导入入口，按钮名称与位置以安装版本为准。导入成功后手动更新一次，并确认这份配置已经被选中启用，而不仅是出现在列表中。

接着查看代理组是否齐全，尤其是自动选择、故障转移以及自行命名的分流组。旧客户端里保存的节点选择不一定会迁移，组名相同也不代表已选中相同节点。先手动选择一个已知可用的节点，再打开规则模式测试基础访问。

导入失败时按错误类型处理

• 返回 HTML 或登录页面：检查订阅是否过期、是否复制了网页地址，以及是否需要重新获取订阅链接；网页能打开不代表返回的是 YAML。
• 提示未知代理类型或字段：核对实际运行的内核与订阅格式。先使用服务方提供的 Clash 或 mihomo 对应订阅，不要随意删除节点字段来绕过错误。
• 代理组引用不存在：检查组内节点名、嵌套组名以及 use 引用的 provider 名称，名称需要准确对应。
• 本地配置可用，在线更新失败：检查系统时间、订阅服务器连通性与更新请求使用的网络路径，不要先把问题归因于规则模式。

迁移本地 YAML 时，特别检查 rule-providers 与 proxy-providers 中的相对路径。把旧文件复制到新目录后，引用路径未必仍然成立；外部规则集的格式也必须和声明的 type、behavior 相符。

规则与覆写：按最终生成的 YAML 逐项迁移

CFW 的 Parsers 属于客户端侧的配置处理机制，不能直接当作 mihomo 内核字段使用。旧脚本的函数入口、注入对象和执行时机可能与新客户端不同。应将旧逻辑拆成“增加规则”“修改 DNS”“调整代理组”等具体需求，再用目标客户端支持的合并配置或脚本机制重写。

先迁移确定性规则，再恢复复杂处理

下面仅展示两条局域网直连规则的写法，不是一份完整订阅，也不应直接替换原来的 rules 列表。若确实需要这些规则，应通过客户端提供的规则前置功能或配置编辑入口，将它们加入原有规则链，并保留末尾兜底规则：

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve

192.168.50.0/24 只是示例网段，应按实际局域网地址调整。规则通常自上而下匹配；本地例外应放在会提前命中的宽泛规则之前，末尾的 MATCH 负责兜底。若规则目标是自定义代理组，该组必须真实存在，不能照搬旧名称后就假定配置有效。

DNS 与 Fake-IP 单独迁移

不要一次性复制整段旧 DNS 配置。先用新客户端默认方案建立可用基线，再按需要迁移自定义解析服务器、域名策略和 Fake-IP 排除项。Fake-IP 用保留地址建立域名映射，它不是实际代理节点地址；启用后出现异常，应结合客户端 DNS 日志和应用行为定位，而不是看到虚拟地址就认定配置出错。

对于依赖局域网发现、私有域名或固定 DNS 的应用，应单独验证解析结果和连接路径。修改 DNS 模式后，可关闭相关应用重新测试；Windows 也可执行 ipconfig /flushdns 清理系统解析缓存，但这不会清除所有浏览器与应用自己的缓存。

端口、系统代理与 TUN：分三步验证

第一步：验证本地代理监听

CFW 常见 HTTP 端口为 7890、SOCKS 端口为 7891，外部控制接口常见为 9090；实际值仍以旧配置为准。新客户端可能使用其他端口，例如 7897。控制接口不是浏览器代理端口，不能把它填进应用的 HTTP 代理设置。

假设新客户端明确显示 mixed 端口为 7897，可以在 PowerShell 执行以下命令。第一条确认监听进程，第二条通过显式代理访问测试地址；测试不需要先开启系统代理。

Get-NetTCPConnection -State Listen -LocalPort 7897
curl.exe -I --proxy http://127.0.0.1:7897 https://example.com/

收到 HTTP 响应说明该次请求已取得响应，但不等于所有分流规则都正确。若提示连接被拒绝，先检查内核是否启动及端口是否一致；若提示端口占用，检查旧客户端或其他代理程序是否仍在后台运行，不要盲目结束不明系统进程。

第二步：启用系统代理

本地代理测试通过后，开启新客户端的系统代理，再到 Windows「设置」→「网络和 Internet」→「代理」检查地址与端口。浏览器能访问而某个应用不能访问，可能是应用不遵循系统代理、使用独立代理设置，或有其他网络限制，应先检查该应用配置。

第三步：按需启用 TUN

TUN 通过虚拟网络接口接管流量，通常涉及服务权限、路由和 DNS。系统代理正常后，再按客户端提示安装或启用服务模式，最后打开 TUN。每一步都测试一次，避免服务、DNS 和路由同时变化后难以定位原因。

若启用 TUN 后企业 VPN、局域网访问或虚拟机网络异常，应先关闭 TUN 验证是否恢复，再检查路由冲突与排除设置。不要让两个客户端同时运行 TUN，也不要为了启用它而长期把所有桌面程序都以管理员身份运行。

迁移验收与回退清单

一次网页访问成功，只能说明某条路径可用。完成以下检查后，再移除旧客户端；这样可以区分订阅问题、规则问题和系统接管问题。

• 订阅更新：手动更新成功，当前启用配置和更新时间正确，本地覆写在更新后仍保留。
• 规则命中：在连接列表或日志中核对至少一条直连请求和一条代理请求，检查命中的规则、代理组与最终节点。
• 应用覆盖：分别测试浏览器、开发工具和确实需要代理的其他应用，不把浏览器结果等同于全系统结果。
• 本地网络：测试路由器管理页、局域网服务和公司内部域名；使用 TUN 时尤其需要检查。
• 重启恢复：重新启动客户端，再重启系统，确认开机启动、服务、代理组选择与系统代理状态符合预期。
• 退出恢复：正常退出客户端后检查系统代理是否恢复。若留下失效地址，到 Windows 代理设置关闭手动代理，再排查退出流程。

需要回退时，先关闭新客户端的系统代理和 TUN，再退出其内核；随后恢复备份中的旧配置，并确保只有一个客户端接管网络。回退用于对照故障，不代表停更客户端重新获得维护。确认新环境稳定后，可卸载旧程序，并按旧客户端提供的方式移除不再使用的服务，保留必要的离线备份即可。

整个迁移过程最重要的是可验证：先保留订阅原貌，再迁移个性化规则；先确认本地端口，再启用系统接管。需要进一步理解规则、DNS 与 TUN 的关系，可查阅使用手册；常见安装与连接问题可在常见问题中按现象排查。