Clash for Windows 停更之后:迁移到 mihomo 内核客户端的替代方案与配置搬家
原客户端停止维护后该换哪个:对比主流 mihomo 内核图形客户端,说明订阅、规则与覆写脚本如何平滑迁移,以及迁移后需要复查的设置项。
先迁移订阅与规则，再恢复系统代理和 TUN
Clash for Windows 已停止维护。迁移的重点不是找一个界面完全相同的安装包，而是把订阅来源、自定义规则、覆写逻辑和系统接管设置分开搬走。建议先用新客户端的系统代理完成基本验证，确认规则和 DNS 正常后，再启用 TUN 模式。不要让两个客户端同时修改系统代理或接管路由。
Clash for Windows 是图形客户端，mihomo 是代理内核，二者不在同一层。mihomo 延续了 Clash 配置体系，并增加了协议与配置能力；采用该内核的客户端仍可能有不同的配置合并顺序、服务管理方式和脚本接口。旧 YAML 能被解析，不代表旧客户端的全部设置已经迁移。
Clash for Windows 替代方案怎么选
Windows 桌面用户可以先比较 Clash Verge Rev 与 Clash Nyanpasu。两者都是图形客户端，但不能因为都支持 mihomo，就假设配置目录、覆写格式或服务组件可以互换。下载前确认项目名称、当前发行说明、操作系统要求与实际启用的内核。
| 客户端 | 适合优先检查的能力 | 迁移时的检查点 |
|---|---|---|
| Clash Verge Rev | mihomo 配置、订阅管理、规则与脚本覆写、系统代理和 TUN 管理 | 检查订阅级与全局覆写的生效范围；TUN 使用前确认服务组件及权限 |
| Clash Nyanpasu | 图形化配置管理、配置处理链与代理状态查看 | 确认所用发行版支持并选择了 mihomo；重新核对配置处理顺序与脚本入口 |
按已有配置复杂度选择
- 只有一个订阅：重点看导入、更新、策略组选择和日志查看是否顺手，不必为暂时不用的功能增加迁移步骤。
- 已有规则与覆写：重点看规则能否前置插入、全局设置和订阅设置如何合并，以及能否查看最终运行配置。
- 依赖 TUN：重点检查服务安装、管理员权限、虚拟网卡和 VPN 共存情况。能打开 TUN 开关，不等于所有应用都已正确接管。
不要把下载文件名相近当成项目身份依据，也不要只看界面版本号。图形客户端版本和内核版本是两项信息，排查兼容性时应一起记录。安装入口集中在下载中心，本文不提供旧客户端安装包作为迁移终点。
迁移前备份：区分订阅原文与运行配置
以常见旧版 Clash for Windows 0.20.39 的界面名称为例，先检查 Profiles 中的配置来源，再到 Proxies 记录策略组选择，最后核对 General 中的端口、System Proxy、Allow LAN 与 TUN 状态。其他版本的入口可能不同，不要只按截图寻找按钮。
- 保存订阅来源。记录订阅 URL、配置名称、更新间隔，以及是否经过转换服务。URL 中的令牌相当于访问凭证，不要贴进日志截图。
- 保存订阅 YAML。这是重新导入与离线对照的基础。仅保存 URL，无法保留后来加在本地的规则。
- 保存最终运行配置。它适合对照实际生效字段，但可能已经混入客户端生成的端口、控制接口和缓存路径，不宜直接覆盖新客户端配置。
- 另存 Parsers、Mixin 与脚本。记录哪些修改只作用于某个订阅，哪些作用于所有配置。不要仅备份一份看似完整的 YAML。
- 记录外部依赖。包括
rule-providers、proxy-providers、本地规则文件、自定义 DNS 与控制面板连接参数。
旧配置目录不应整体覆盖新目录。客户端自己的数据库、缓存、服务状态和内核缓存可能不兼容。需要搬运的是明确识别的配置与规则文件，而不是旧程序的全部运行环境。
订阅导入：先让原始配置单独运行
- 在旧客户端关闭 System Proxy 与 TUN，退出程序，并确认旧服务没有继续接管网络。
- 打开新客户端，在订阅或配置管理页导入原来的订阅 URL。若只有本地 YAML，先作为本地配置导入，不要假设它会自动获得更新地址。
- 暂时不加自定义覆写，先更新一次订阅并启用该配置，检查是否出现节点和策略组。
- 确认运行模式为 Rule（规则），在策略组中重新选择节点。旧客户端的选择缓存通常不会随 YAML 一起迁移。
- 核对本地监听端口，再开启新客户端的系统代理，测试普通网页与预期代理的网站。
端口以运行值为准，不要沿用记忆
旧环境可能使用 7890，新客户端也可能使用其他端口。终端、浏览器扩展或开发工具若仍指向旧地址，即使系统代理正常，这些程序仍可能连接失败。下面是端口覆写片段，不是完整配置；客户端若通过界面管理端口，应优先在界面调整。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: infomixed-port 提供 HTTP 与 SOCKS 共用监听入口。Windows PowerShell 中可用下面的命令显式经过该 HTTP 代理测试连接；若实际端口不是 7890，应使用运行配置中显示的值。
curl.exe --proxy http://127.0.0.1:7890 --head https://example.com/这个测试只验证指定代理入口能否处理一次请求，不证明 TUN、生效规则和所有应用都正常。若返回 407 Proxy Authentication Required，应检查本地代理认证设置；若提示无法连接到 127.0.0.1，则先检查端口与内核运行状态。
规则与覆写脚本：迁移逻辑，不照搬接口
Clash for Windows 的 Parsers、Mixin 与新客户端的合并配置、脚本覆写不是同一套接口。尤其是 JavaScript 脚本，输入对象、入口函数、可用 API 和执行阶段都可能不同。不要把旧脚本改个扩展名后直接启用，也不要假设客户端脚本可以访问浏览器或 Node.js 的全部功能。
把旧修改拆成三类
- 字段覆盖：例如
log-level、allow-lan。确认客户端是否接管这些字段，再选择界面设置或覆写。 - 列表修改：例如增加规则、DNS 服务器、策略组成员。确认新工具是替换整个列表，还是支持前置与追加。
- 程序化处理：例如按节点名称筛选、批量重命名、动态生成策略组。按目标客户端当前的脚本接口重写，并比较输出配置。
规则采用自上而下匹配。原来要直连的公司域名，如果被追加到 MATCH 之后，就不会被命中。下面仅展示两条应放在兜底规则之前的规则，不是可单独运行的完整配置：
rules:
- DOMAIN-SUFFIX,corp.example,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolvecorp.example 用于演示内部域名匹配，实施时应填写实际管理的域名。不要用上述两行替换订阅的整个 rules 列表；正确做法是通过目标客户端支持的前置规则或脚本接口合并，并保留原有规则与兜底策略。
规则集与本地路径一起检查
rule-providers 中的 type、behavior、format 与文件内容必须匹配。旧的绝对路径在新安装目录下可能失效，相对路径也应按新客户端实际使用的内核工作目录核对。若出现 proxy group not found 一类提示，检查规则右侧引用的策略组名称是否存在，名称中的空格和大小写也要一致。
DNS、TUN 与外部控制：最后恢复的三组设置
DNS：保留用途，不机械复制全部字段
对照旧配置的 dns.enable、enhanced-mode、nameserver 和 fake-ip-filter。使用 Fake-IP 时，198.18.0.0/16 是常见的映射范围，不是远端节点地址。更换内核或 DNS 模式后，浏览器与系统可能仍缓存旧结果；先关闭重开测试应用，必要时在 Windows 执行 ipconfig /flushdns。
不要为消除一条解析错误就把所有 DNS 设置改成公共服务器。公司内网域名可能依赖内部 DNS，迁移时应验证内部域名、普通公网域名各一个，并结合日志确认请求经过了预期路径。
TUN：先处理权限，再观察路由
系统代理测试通过后，关闭其他 VPN 或虚拟网卡接管程序，再按新客户端要求安装服务组件或授予管理员权限。核对 tun.enable、stack、auto-route 与 dns-hijack 的最终值。不同协议栈和系统环境存在差异，不宜把某个 stack 值当成所有设备通用的修复方案。
TUN 关闭与开启时各测试一次：网页、内部站点、局域网设备以及需要 UDP 的应用。网页成功不等于 UDP 转发成功，后者还取决于节点协议、节点服务与规则。出现断网时，先关闭 TUN 回到已验证的系统代理基线，再逐项排查。
外部控制：不要把旧监听地址一起暴露
如果使用外部面板，重新检查 external-controller 和 secret。仅供本机访问时，可使用 127.0.0.1:9090 这样的回环监听地址；不要为了让旧面板立即连接，就直接改成所有网卡监听。旧面板保存的端口与密钥也需要同步更新。普通桌面使用不需要把控制接口开放到局域网。
迁移后连不上：按现象定位
| 现象或报错 | 优先检查 | 下一步 |
|---|---|---|
address already in use |
新旧内核是否同时占用代理或控制端口 | 退出旧客户端及残留服务，或为新配置选择空闲端口 |
| 订阅更新返回 401 或 403 | 订阅令牌、账户状态、请求地址与服务端限制 | 核对原始订阅来源，不要先改 DNS 或 TUN |
| YAML 解析失败 | 导入内容是否实际为 HTML、节点链接列表，或存在缩进错误 | 查看响应内容；YAML 缩进用空格，不用制表符 |
| 系统代理正常，终端失败 | 终端是否仍使用旧端口或环境变量 | 检查 HTTP_PROXY、HTTPS_PROXY 与工具自身代理配置 |
| 规则模式失败，全局模式可用 | 命中的规则、策略组选择与 DNS 结果 | 在连接记录中定位具体请求，不要长期靠全局模式掩盖错误 |
| 开启 TUN 后完全断网 | 服务权限、其他 VPN、路由与 DNS 接管冲突 | 先关闭 TUN 恢复基线，再分别测试服务与路由设置 |
报告问题时，提供操作系统版本、客户端版本、内核版本、出错时间和最小复现步骤。配置与日志应先删去订阅 URL、节点密码、控制密钥及敏感内部域名。继续排查可参考帮助中心与进阶配置。
验收与回退：更新一次，重启一次
- 订阅更新成功，节点与策略组完整，自定义规则没有被覆盖。
- 运行模式为预期值，常用策略组已重新选择，连接记录显示正确的规则命中。
- 浏览器、终端、内部站点分别通过测试；需要 TUN 时，补测局域网与 UDP 应用。
- 重启客户端后端口和覆写仍然正确；重启系统后服务与开机启动行为符合预期。
- 旧客户端的系统代理、TUN 和自动启动均已关闭，没有两个程序轮流修改系统设置。
需要回退时，先关闭新客户端的系统代理与 TUN，再退出新客户端及其服务，随后恢复旧环境。不要同时启动两套接管设置做对比。验收完成后再清理旧程序，保留一份脱敏的迁移记录，记录订阅来源、覆写文件位置和最终端口，方便下次更换设备时复用。