客户端选型 预计阅读 13 分钟

Clash for Windows 停更后怎么办：迁移到 mihomo 内核客户端的完整方案

梳理停更后可继续使用的客户端选择，讲清配置文件与订阅如何原样迁移、哪些字段需要改写，以及桌面与安卓多端配置保持一致的做法。

先判断需要迁移的是客户端、订阅还是本地配置

Clash for Windows 停止维护后，已有安装并不会立刻失效。只要订阅地址仍可访问、节点协议仍被当前内核支持，旧客户端通常还能加载配置并转发流量。真正的问题是内核长期不更新后，新协议字段、规则语法、DNS 行为和系统兼容性不会继续跟进。继续保留旧版本适合作为短期过渡，不适合作为长期配置入口。

迁移前先区分三类数据。客户端是图形界面与系统集成层；订阅是服务端生成配置的入口；本地 YAML 则可能包含手写节点、规则集、DNS 与 TUN 参数。三者不能混为一个文件处理。只有订阅用户时，迁移通常只需保存订阅 URL。存在手写规则或覆写时，还要单独导出配置与记录本机参数。

迁移目标

优先选择仍在维护、内核采用 mihomo、能够显示内核版本并支持配置校验的客户端。mihomo 延续 Clash 配置体系，并扩展协议、规则集、DNS、TUN 与流量嗅探能力，旧配置通常可以直接导入后再按设备修正。

迁移前应保存的内容

从 Clash for Windows 找到配置

在 Clash for Windows 中先进入「Profiles」，确认当前配置名称。订阅配置可记录页面中的订阅地址；本地配置可通过配置菜单打开文件所在位置。常见数据目录位于 %USERPROFILE%\.config\clash，但便携版、自定义 Home Directory 或不同发行包可能使用其他路径，应以客户端显示的目录为准。

复制目录时重点查看 config.yaml、订阅生成的 YAML、Provider 缓存和自定义脚本。缓存文件不是迁移核心，新的 mihomo 客户端会重新下载代理提供者与规则集。需要保留的是原始配置和能够再次获取配置的地址。

选择 mihomo 客户端时看内核与系统能力

迁移不等于寻找一个外观完全相同的 Clash for Windows。更可靠的选型方法是先核对内核，再看系统接管方式和配置管理。桌面端需要系统代理、TUN、开机启动和配置更新；安卓端需要 Android VPN 权限、按应用分流、后台运行和电池策略适配。

桌面端需要核对的项目

  1. 内核信息可见：在「设置」或「关于」页面能够确认使用 mihomo，并显示具体版本号。
  2. 配置校验明确：导入失败时应指出 YAML 行号或字段，而不是仅显示启动失败。
  3. 系统代理可控制：能够设置 HTTP、SOCKS 或 Mixed 端口，常见默认值为 7890。
  4. TUN 状态可确认：能显示虚拟网卡是否建立，并提示管理员权限或服务安装状态。
  5. 覆写与订阅分离：订阅更新后，本机端口、DNS 和 TUN 修改不应被整份覆盖。

安卓端需要核对的项目

客户端界面名称可能不同，但内核能力应以实际版本和配置测试为准。导入后可在日志中寻找 mihomo 启动信息，再访问一个网页，确认连接记录同时显示目标域名、命中规则和出站策略。如果只看到界面显示“已连接”，不能证明 DNS 与规则链都正常。

订阅迁移：优先重新导入原始地址

仅使用机场或服务商订阅时，最稳妥的方式不是复制 Clash for Windows 生成后的 config.yaml，而是在新客户端中重新添加原始订阅 URL。桌面端通常从「配置」→「新建」→「URL」添加；安卓 mihomo 客户端通常从「配置」→右上角“+”→「从 URL 导入」添加。填写名称后立即更新一次，再检查代理组和节点数量。

  1. 在旧客户端记录订阅更新时间、节点数量和主要策略组名称。
  2. 在新客户端添加同一订阅地址，设置更新周期，例如 1440 分钟。
  3. 更新完成后选择该配置，并等待内核重新加载。
  4. 进入「代理」页面，确认 GLOBAL、DIRECT、REJECT 以及自定义策略组能够正常显示。
  5. 依次测试至少两个节点，记录延迟和实际连通状态。

延迟数值只能用于初步筛选。一个节点显示 42 ms，并不等于下载速度一定高于 95 ms 的节点。迁移验收时可进行三组具体检查：网页首次打开是否在 2 秒内完成、连续播放 1080p 视频是否频繁缓冲、同一测试文件的稳定速率是否明显低于迁移前。若所有节点都异常，应先检查 DNS、系统代理和 TUN，而不是反复更换订阅。

订阅地址属于敏感配置

订阅 URL 往往包含用于识别账户的令牌。不要把完整地址写入公开日志、截图、代码仓库或共享 YAML。多设备使用时，应在每台设备的客户端中直接保存地址。

为什么不建议长期复制生成后的配置

生成配置是某次订阅更新的结果，其中节点地址、证书参数、策略组和规则都可能继续变化。直接复制可以用于临时恢复，但不会自动获得后续更新。如果配置内还有 proxy-providers 或 rule-providers，复制时也要保证 Provider URL 仍然有效，并确认本地缓存路径能由新客户端重新创建。

本地 YAML 迁移：先校验，再改设备相关字段

mihomo 对经典 Clash 配置有较高兼容性，常见的 proxies、proxy-groups、rules、proxy-providers 和 rule-providers 可以继续使用。迁移时不应先大规模改写语法，而应保存原文件副本，直接导入并读取第一条明确错误。一次只修改一类字段，更容易定位问题。

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

external-controller: 127.0.0.1:9090

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - 自动选择
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

上例使用 7890 作为 Mixed 入站端口，9090 作为外部控制端口，DNS 监听 1053。这些值可以在桌面系统使用，但不能机械复制到所有设备。安卓客户端通常由自身管理 VPN 入站和控制接口，手写的监听地址可能与客户端内置服务冲突。

通常可以原样保留的字段

需要按设备检查或改写的字段

TUN 配置不要整段跨平台复制

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
  dns-hijack:
    - any:53

桌面端的 TUN 通常需要管理员权限或系统服务支持；安卓端则依赖系统 VPN 接口。同一台安卓设备同一时间只能维持一个主要 VPN 接管工具。若手机上同时运行其他 VPN、企业工作资料 VPN 或本地防火墙，mihomo 客户端可能无法建立接口。

迁移后若网页能打开但应用无法联网，可先在「设置」→「网络」中将 TUN stack 从 system 切换为 mixed 或 gvisor 进行对比，再检查按应用代理列表。切换后应完全停止并重新启动服务，避免旧虚拟接口状态干扰结果。

桌面与安卓多端保持一致的正确分层

多端一致不代表每台设备使用完全相同的一份 YAML。更合理的结构是把节点、远程规则和策略组作为公共层，把端口、TUN、局域网访问、应用分流和系统权限作为设备层。公共层由订阅或 Provider 更新，设备层放在各客户端的覆写功能中。

适合跨设备共享的内容

应在每台设备单独维护的内容

例如，桌面端可以保留 mixed-port: 7890，让浏览器或开发工具手动连接 127.0.0.1:7890；安卓端不需要其他应用填写这个端口，而是由 VPN 接口统一接管。将桌面端口配置视为“跨端必需项”，容易造成安卓端启动冲突或产生无效设置。

策略组选择不会天然同步

即使桌面和安卓使用同一订阅，客户端本地选择的节点也通常不会自动同步。桌面端将「节点选择」设为某个香港节点，不会让手机立即选择同一节点。若希望多端行为稳定，可让主策略组引用 url-test 自动测速组，并设置合理的测试地址、间隔和容差。

proxy-groups:
  - name: 自动选择
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 节点选择
    type: select
    proxies:
      - 自动选择
      - DIRECT

这里的 interval: 300 表示每 300 秒测试一次，tolerance: 50 表示延迟差异不超过 50 ms 时减少频繁切换。测试 URL 应保持稳定并返回小体积响应。不同网络下的结果仍可能不同，因此手机使用蜂窝网络时选中的节点不一定与桌面宽带相同。

迁移后的验证顺序与常见故障

迁移完成后不要只检查一个网页。应从配置加载、DNS、规则命中、节点连通和系统接管五个层级依次验证。这样可以判断问题发生在配置解析、域名解析、策略选择还是虚拟网卡。

  1. 配置加载：日志中没有 YAML 解析错误、重复端口或 Provider 下载失败。
  2. DNS 解析：域名请求能够返回结果，日志中没有连续的 timeout、SERVFAIL 或循环查询。
  3. 规则命中：访问常用站点时，连接记录显示预期规则和策略组。
  4. 节点连通：至少测试两个不同地区节点，排除单节点故障。
  5. 系统接管：关闭系统代理或停止 VPN 后网络路径发生预期变化，重新启动后恢复。

导入成功，但所有节点都超时

先检查手机或电脑的系统时间，证书握手对时间偏差较敏感。然后更新订阅，确认节点参数不是旧缓存。若只有域名节点超时而 IP 节点可用，应重点检查 DNS。若日志显示 connection refused，则可能是节点服务端口不可达；显示 i/o timeout 时，还需排查本地网络、路由和防火墙。

规则模式下部分应用无法联网

将模式临时切换到 Global 仅用于定位。如果 Global 可用而 Rule 不可用，问题通常位于规则、策略组或规则集更新。检查最终 MATCH 指向的策略组是否存在，再确认该组已经选中可用节点。完成诊断后应切回 Rule，而不是长期用 Global 掩盖规则错误。

安卓启动后很快被系统停止

进入 Android「设置」→「应用」→对应客户端→「电池」，选择允许后台运行或不受限制；再检查「设置」→「网络和互联网」→「VPN」中的连接状态。不同厂商菜单名称会有差异。若开启始终开启的 VPN，还要确认没有将另一个 VPN 应用设置为同一角色。

订阅更新后本地规则消失

这说明修改直接写在订阅生成文件中，而更新操作覆盖了整份配置。应恢复原订阅，把设备规则移动到客户端的覆写、合并配置或单独 Provider 中。公共订阅负责更新节点，本地覆写负责固定设置，两层分开后才能持续维护。

保留回退窗口

新客户端稳定运行数天后再清理旧目录。期间不要让两个客户端同时启用系统代理或 TUN。需要对照时，先完整停止一个客户端，再启动另一个，并确认系统代理地址与 VPN 图标已经切换。

迁移完成后的维护方式

迁移完成后，建议记录客户端版本、mihomo 内核版本、订阅更新周期和关键覆写。出现问题时先比较最近一次客户端更新、内核更新和订阅更新的时间，通常可以快速缩小变化范围。客户端界面版本与内核版本是两个概念，排查协议或规则行为时应优先记录内核版本。

配置文件也应保持可读。策略组使用稳定名称，规则按用途分段，Provider 采用明确的更新周期。修改前复制一份可正常启动的版本；调整 DNS、TUN 或规则集时一次只改一个模块，并在日志中验证结果。这样即使后续更换另一款 mihomo 客户端，公共配置仍可继续使用。

对大多数用户而言，迁移路径可以收敛为三步：保存订阅和旧 YAML，选择仍维护的 mihomo 客户端，最后将桌面与安卓的设备参数分别配置。订阅负责节点更新，公共规则负责流量决策，本机覆写负责系统差异。按这个边界管理，比复制整份旧目录更稳定，也更便于后续排错。

前往安装包页面