先区分：界面闪退，还是 mihomo 内核退出

双击客户端后没有窗口，并不一定是程序崩溃。有些客户端会恢复上次的“启动后最小化”设置，只在通知区域保留图标。先点击任务栏右侧的展开箭头，再打开「任务管理器」→「详细信息」，查看客户端进程是否仍在运行。确认没有隐藏窗口，再进入下面的排查。

Clash 客户端包含界面、配置管理和代理内核等部分。界面可以正常打开，但 mihomo 内核启动失败；也可能内核仍在后台运行，而界面渲染已经失败。这两种情况的处理方向不同，不能只凭“打不开”三个字判断。

可见现象先查什么可记录的线索
窗口出现后立即消失应用崩溃记录、配置残留故障模块、异常代码、发生时间
白屏，但进程一直存在界面运行库、渲染进程是否使用 WebView2、是否有渲染错误
卡在启动页或提示连接内核失败服务状态、控制接口、内核日志服务错误、监听地址、配置解析错误
窗口正常，但网页无法打开系统代理、节点和规则实际代理端口、连接日志、命中策略

第一步：记录版本与 Windows 错误，避免反复重装

先记下客户端名称、完整版本号、Windows 版本以及安装包架构。客户端版本和 mihomo 内核版本是两项信息，不能互相替代。能打开界面时，从「关于」或版本信息页记录；打不开时，可查看安装包名称及可执行文件「属性」→「详细信息」。文件属性不一定包含内核版本，缺失时如实注明。

  1. 按 Win + R，运行 winver，记录 Windows 版本和操作系统内部版本。
  2. 进入「设置」→「系统」→「系统信息」，查看“系统类型”，区分 x64 与 ARM64，按客户端发布说明选择对应构建。
  3. 按 Win + R，运行 perfmon /rel，在可靠性监视器中找到刚才的应用失败记录，打开技术详细信息。
  4. 如果没有对应条目，再运行 eventvwr.msc，查看「Windows 日志」→「应用程序」，按启动失败的时间查找错误。

重点保留“故障应用程序名称”“故障模块名称”“异常代码”和时间。某个系统 DLL 出现在记录里，只能说明崩溃经过了该模块，不能据此认定这个 DLL 损坏。不要从陌生下载站单独补 DLL，也不要同时更改运行库、服务和配置，否则无法判断哪一步真正有效。

第二步：白屏先确认客户端是否依赖 WebView2

WebView2 并不是所有 Clash 客户端的共同依赖。基于 Tauri 的 Windows 客户端通常使用它显示界面；旧版 Clash for Windows 使用 Electron，通常带有自己的 Chromium；Flutter 客户端也不能直接套用 WebView2 修复方法。先查看当前客户端的项目说明与安装提示，再决定是否处理运行库。

检查与修复顺序

  1. 打开 Windows 11「设置」→「应用」→「已安装的应用」，搜索 Microsoft Edge WebView2 Runtime。Windows 10 可在「应用和功能」中查找，部分系统也可通过「控制面板」→「程序和功能」查看。
  2. 如果客户端明确要求 WebView2，而系统没有安装，使用微软官方发布的 Evergreen 运行时安装器。离线环境应选择与系统架构匹配的独立安装包。
  3. 如果已经安装，先关闭依赖它的应用，再使用系统提供的“修改”或安装器提供的修复入口；具体入口随运行时安装方式变化，不必强行寻找同名按钮。
  4. 安装或修复完成后重新启动客户端。安装器要求重启 Windows 时，先完成重启，再进行下一项测试。

电脑装有 Microsoft Edge 浏览器，不代表客户端所需的 WebView2 运行时一定完整。反过来，白屏也不等于 WebView2 损坏：渲染进程异常、用户界面缓存损坏、安全软件拦截，都可能出现类似现象。

若日志明确指向图形渲染，可更新设备厂商提供的显卡驱动，并检查客户端是否提供“硬件加速”开关。只有当前版本的文档明确支持时，才使用对应开关或启动参数；不要把 Electron 的参数直接加给 Tauri 或 Flutter 程序。

第三步：关闭 TUN，分开检查服务与普通代理

服务模式通常用于让后台组件以所需权限运行，TUN 模式则通过虚拟网卡接管流量，两者不是同一个功能。客户端可以安装服务但不开启 TUN；普通系统代理通常也不需要一直以管理员身份运行整个界面。启动失败时，先把界面、内核、服务和 TUN 分开验证。

界面仍能打开时

  1. 先关闭 TUN 模式，保留普通代理测试环境。各客户端设置名称不同，以实际界面为准。
  2. 完全退出客户端后重新打开，观察是否能进入主界面、读取配置并显示内核日志。
  3. 如果普通模式正常，再在客户端自己的服务管理入口检查服务状态；需要安装或修复服务时，确认 Windows 权限提示中的程序来源。
  4. 服务恢复后单独开启 TUN，检查是否出现虚拟网卡创建、路由设置或权限错误。

卡在服务连接阶段时

按 Win + R，运行 services.msc。服务名称会随客户端变化，不要根据网上教程猜名称。打开对应服务的属性，核对可执行文件路径是否仍指向当前安装目录。把便携版文件夹移动到新位置后，旧服务可能仍引用原路径；卸载客户端后留下的服务也可能造成冲突。

优先使用当前客户端提供的服务修复或重新安装入口。不要直接运行来源不明的服务删除命令，也不要把旧客户端的服务程序复制到新客户端目录。若错误只在 TUN 开启时出现，还应记录同时运行的 VPN、虚拟机网络软件和其他 TUN 客户端；逐个退出后测试，不要直接重置全部网卡。

第四步：查清端口占用，不要只改 7890

日志中的 address already in use 或 bind 错误，通常说明监听失败。7890 常见于代理端口配置，9090 常见于控制接口示例，但它们不是所有客户端的固定值。应从实际生成的配置读取 mixed-port、port、socks-port 和 external-controller。

例如，配置使用 mixed-port: 7890，且控制接口地址为 127.0.0.1:9090，可以在 PowerShell 中检查这两个 TCP 监听端口：

Get-NetTCPConnection -State Listen -LocalPort 7890,9090 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess

输出中的 OwningProcess 是进程 ID。把它与「任务管理器」→「详细信息」中的 PID 对照，再查看进程路径。没有输出表示查询时没有找到这两个 TCP 监听，并不能排除其他端口或 UDP 监听问题。若日志报告的是 UDP 冲突，应针对实际端口使用 Get-NetUDPEndpoint 检查。

  • 旧客户端占用：从旧客户端托盘菜单正常退出，确认其后台服务是否也已停止。
  • 同一客户端重复启动：先结束已确认属于该客户端的残留实例，再启动一次。
  • 其他程序占用：确认用途后选择调整一方端口，不要结束身份不明的系统进程。

修改代理端口后，需要同步核对 Windows 系统代理地址；修改控制接口后，需要确保界面连接的地址与内核配置一致。控制接口若要求密钥，地址正确但认证不一致也会表现为“连接内核失败”。排查时保持控制接口仅监听本机，不要为了连接成功而随意开放到所有网卡。

第五步：隔离配置残留，保留可恢复的备份

覆盖安装通常只替换程序文件，不会清空用户数据。因此，升级后闪退、恢复旧配置后白屏，可能与残留设置或配置结构变化有关。正确做法是建立备份并测试新配置，而不是一上来删除整个目录。

如何找到数据目录

界面能打开时，优先使用客户端提供的配置目录、数据目录或日志目录入口。界面打不开时，在资源管理器地址栏分别输入 %APPDATA% 与 %LOCALAPPDATA%，根据客户端文档和目录中的日志确认归属。便携模式还可能把数据放在程序旁边。不同客户端、不同版本的目录名并不统一。

  1. 完全退出客户端，并停止已确认属于它的后台服务，避免备份时文件仍在写入。
  2. 复制已确认的数据目录到本地备份位置，保留订阅、覆写、规则、证书和日志。
  3. 在确认备份可读后，将原目录改名，例如在目录名后追加 .backup-20260821，不要立即删除。
  4. 重新启动，让客户端建立默认数据。先不恢复订阅和覆写，观察窗口与内核是否能稳定启动。
  5. 若恢复正常，只导入一份订阅，再逐项恢复自定义规则、覆写和 TUN 设置，每次变更后重新测试。

如果“全新数据正常、恢复某项设置后失败”，范围就缩小到了该项配置。YAML 缩进错误、引用了不存在的策略组、当前内核不支持的字段，都可能导致内核拒绝加载，但不一定让界面崩溃。结合日志区分解析失败和进程崩溃，再查阅 YAML 手册，不要把所有故障都归为订阅失效。

第六步：检查安全拦截，并做一次受控重装

如果界面启动后提示内核文件不存在，或者每次重装后同一个文件又消失，打开「Windows 安全中心」→「病毒和威胁防护」→「保护历史记录」，核对拦截时间、文件路径和检测名称。路径与出错时间必须对应，不能看到历史告警就认定当前问题由它造成。

先确认安装包来源、发布者和当前项目的系统要求。只有在核实文件可信、理解告警含义后，才考虑针对具体项目采取恢复操作；不建议关闭整体防护，也不建议把整个下载目录加入排除项。单位设备应交由管理员处理策略限制。

  • 从可信发布入口重新获取对应架构的完整安装包，避免只复制单个可执行文件。
  • 确认旧实例退出，并按客户端说明处理旧服务；保留上一节建立的数据备份。
  • 安装到稳定的本地路径，先使用默认数据启动，再恢复订阅。
  • 若只在某次升级后复现，记录升级前后完整版本号，按项目说明评估回退；不要让旧版本直接覆盖新版本的数据结构。

旧版 Clash for Windows 的 Electron 界面问题，与使用 mihomo 的新客户端服务问题并不等价。切换客户端时，也不要直接把整个旧数据目录复制过去。应分别迁移订阅、自定义规则和覆写内容，客户端选择可参考 客户端对比。

修复后的验收与问题反馈

能看到窗口只是第一步。按下面的顺序完成验证，才能确定问题已解决，而不是暂时绕过了报错。

  1. 重启验证：正常退出再打开，确认界面与内核都能启动，不依赖任务管理器反复结束进程。
  2. 普通代理验证：使用实际代理端口测试系统代理，观察连接日志和命中规则。节点延迟测试成功并不代表应用请求一定走了代理。
  3. TUN 验证：确有需要时再启用 TUN，检查服务、虚拟网卡和日志；没有需要时保持关闭也可正常使用普通代理。
  4. 退出验证：正常退出客户端，检查系统代理是否按预期恢复，避免下次开机浏览器连接到无人监听的端口。

仍然失败时，反馈应包含：Windows 版本与架构、客户端和内核版本、故障出现时间、复现步骤、是否启用服务与 TUN、错误前后少量日志，以及使用新数据目录后的测试结果。版本信息能帮助维护者对应代码变化，逐项测试结果则能排除重复建议。

后续配置可继续查看 订阅导入步骤与 连接验证方法。处理启动故障时，始终保持“一次只改一项”：先恢复界面，再恢复内核，最后恢复服务、TUN 和自定义配置。