一、先确认退出的是窗口，还是代理内核
窗口消失，不一定就是程序崩溃。Clash 类客户端通常包含图形界面和代理内核两部分：前者负责按钮、配置列表和设置，后者负责实际接收连接、执行规则。mihomo 是部分客户端使用的代理内核，也常被称为 Clash Meta。两部分可以分别出问题，排查时先分清对象。
- 看系统托盘是否还有客户端图标。Windows 的图标可能藏在任务栏的折叠区域；如果图标仍在，先从托盘重新打开主窗口，检查是否启用了启动后最小化。
- 按 Ctrl + Shift + Esc 打开任务管理器，在「详细信息」中查看客户端及其内核进程。记录进程名，不要只凭图标判断。
- 如果窗口能打开，但显示内核未运行，优先查内核日志；如果图形界面进程也立即消失，优先查客户端日志与系统崩溃记录。
- 退出其他代理客户端，再启动一次出问题的客户端。两套程序同时启动，可能争用本地端口或虚拟网卡。
二、定位日志：保留启动前后的第一条错误
日志位置取决于客户端，不取决于“Clash”这个统称。安装目录、用户数据目录和内核工作目录可能是三个位置。不要从网上复制某个文件夹路径后，就认定自己的日志一定在那里。
窗口还能停留几秒时
优先使用客户端设置中的“打开日志目录”或“打开配置目录”入口；名称和层级随客户端变化。打开后复制整个日志目录，并记录启动时间，例如 09:42:10。随后重新启动一次，查看这个时间之后新增的日志，而不是反复阅读上一次的旧错误。
窗口完全打不开时
- 旧版 Clash for Windows：常见数据位置是
%USERPROFILE%\.config\clash，可检查其中是否存在logs。便携模式或迁移过目录时，以实际文件修改时间为准；其他客户端不要套用这个路径。 - 其他 Windows 客户端：在资源管理器地址栏分别输入
%APPDATA%和%LOCALAPPDATA%，按客户端名称或项目标识查找目录。只查看和备份，暂时不要删除。 - Windows 系统记录：按 Win + R，输入
eventvwr.msc，进入「Windows 日志」→「应用程序」，查找启动时刻的错误。也可运行perfmon /rel，在可靠性监视器中查看应用程序故障。 - macOS：打开「控制台」，查看崩溃报告；用户级报告常见于
~/Library/Logs/DiagnosticReports。若只有内核退出，仍应优先找客户端自己的内核日志。 - Linux：从终端启动实际的客户端可执行文件，保留终端输出；使用 systemd 用户服务时，再检查对应服务日志，不要假定所有发行版都使用同一个服务名。
日志先看第一条导致启动中断的错误，再看前后各 20 行。末尾的“连接被拒绝”可能只是内核已经退出的结果。故障模块指向图形运行时，也不能直接证明是显卡驱动问题，需要结合客户端日志判断。
| 日志线索 | 优先检查 | 下一步 |
|---|---|---|
address already in use | 监听端口被占用 | 查询占用进程，不急着重装 |
yaml、unmarshal | 配置结构或字段类型 | 测试实际加载的配置文件 |
no such file、not found | 内核或所需资源不存在 | 确认报错路径和安装内容 |
permission denied | 目录、执行权限或服务权限 | 检查当前账户与目录权限 |
access is denied | 权限、端口排除或安全拦截 | 结合完整错误判断，不能一律当成占用 |
三、端口占用：查清 7890 和 9090 的使用者
端口冲突通常影响内核启动，不一定让整个界面闪退。7890 常被用作本地代理端口，9090 常被用作控制接口端口，但它们都能修改。请以日志和当前配置为准；如果报错写的是 7897，就查询 7897。
在 Windows PowerShell 中执行下面的命令，查看示例端口的 TCP 监听者。没有输出只表示查询时没有对应监听，并不能排除进程刚刚退出。
Get-NetTCPConnection -State Listen -LocalPort 7890,9090 -ErrorAction SilentlyContinue |
Select-Object LocalAddress,LocalPort,OwningProcess假设输出中的进程编号是 4321，再查询进程身份。这里的 4321 是演示数值，执行时应换成查询到的编号。
Get-Process -Id 4321 | Select-Object Id,ProcessName,Path- 若占用者是另一套代理工具，从它的托盘菜单正常退出，避免直接终止未知系统进程。
- 若占用者是同一客户端的残留内核，先退出客户端及其后台服务，确认没有正在使用它的连接，再处理残留进程。
- 确实需要两套程序共存时，可以把其中一套的代理端口改为未占用的
7893，控制端口改为未占用的9093。同时更新应用手动填写的代理地址，不能只改配置而保留旧端口。
如果没有监听者，但 Windows 报端口访问被拒绝，可以用 netsh interface ipv4 show excludedportrange protocol=tcp 查看 TCP 排除端口范围。不要直接删除系统保留范围，先选择范围外的空闲端口。UDP 绑定错误则需另外检查 UDP 端点，不能仅凭 TCP 查询下结论。
四、配置回滚：先测 YAML，再找客户端合并层
回滚应恢复整份可用配置，而不是随机删字段。YAML 是用缩进表示层级的文本格式。混入制表符、把数字写成错误类型、引用不存在的策略组，都可能使配置加载失败。订阅能下载成功，也不代表下载内容一定适合当前内核。
按最近一次变更缩小范围
- 刚手动编辑过配置：复制故障文件留档，再恢复修改前的备份。
- 刚更新过订阅：保留更新后的文件；若客户端保存了历史快照，先回到此前能启动的快照。订阅内容也可能由服务端改变。
- 刚更换过内核：检查配置是否包含仅新内核支持的字段或协议。传统 Clash 与 mihomo 的支持范围不同，不能用“都是 YAML”判断兼容性。
- 刚启用覆写或脚本：覆写是客户端在原配置上追加或替换字段的过程。暂时停用新增的合并层，再测试原配置。
用当前内核进行配置测试
mihomo 的 -t 用于测试配置后退出，-f 指定配置文件，-d 指定工作目录。下面假设已把当前客户端配套的内核和待测配置放入 D:\ClashRecovery，文件名分别为 mihomo.exe 与 candidate.yaml；实际路径不同就相应调整。
Set-Location 'D:\ClashRecovery'
.\mihomo.exe -t -d 'D:\ClashRecovery' -f 'D:\ClashRecovery\candidate.yaml'工作目录可能还需要地理数据或规则资源。提示资源缺失时，应先补齐与当前配置匹配的资源，不能直接归因为缩进错误。测试通过也只说明该内核能加载这份配置，不保证节点可连接、远程规则可下载，更不保证图形界面一定正常。
五、内核缺失、架构不符与运行环境错误
只有日志明确指向文件或加载失败时，才处理程序文件。“内核未运行”也可能由配置错误造成，不等于内核文件丢了。先核对错误中的完整路径，再检查文件是否存在、是否被移动，以及当前用户是否有读取和执行权限。
核对安装包与设备架构
Windows 可在「设置」→「系统」→「系统信息」查看系统类型；Linux 可运行 uname -m。x64 与 ARM64 安装包应按设备和客户端支持情况选择。不要把另一款客户端的内核直接改名覆盖，因为启动参数、控制接口和配套资源可能不同。
按安全记录和依赖提示处理
- Windows 可打开「Windows 安全中心」→「病毒和威胁防护」→「保护历史记录」，确认是否有对应文件的隔离记录。先核实来源和检测详情，不要为了启动而全局关闭防护。
- 日志明确指出 WebView2 或其他运行时缺失时，按该客户端的系统要求修复对应依赖。并非每个 Clash 客户端都使用 WebView2，不必批量安装所有运行库。
- macOS 提示应用无法打开时，先确认应用适配当前系统版本，并查看「系统设置」→「隐私与安全性」中的具体说明，不要照抄关闭系统安全机制的命令。
- Linux 出现执行权限错误时，先用
ls -l查看目标文件权限；只有确认文件来源及路径后，再按项目安装说明调整权限。
如果普通模式可以启动，只有启用 TUN 才失败，应转向检查虚拟网卡、服务安装状态和权限。暂时关闭 TUN 进行对照，不要把“始终以管理员运行”当作所有闪退的通用修复。
六、安全重装：分开验证程序与用户数据
重装前保留数据，重装后不要立刻全部恢复。只覆盖安装文件，可能保留造成故障的用户设置；直接删除整个数据目录，又可能丢失本地规则和订阅记录。更稳妥的做法是备份、隔离、逐项恢复。
- 记录现场：保存客户端名称与版本、内核版本、操作系统版本、最后一次成功启动时间，以及刚做过的更新或配置变更。
- 备份数据：在程序和相关服务完全退出后，复制配置、订阅记录、本地规则、覆写脚本和日志。备份含有凭据，应放在受保护的本地目录。
- 隔离旧目录：确定实际用户数据目录后，将它重命名为带日期的备份目录，例如在原名称后添加
-backup-20261015。若仍被占用，先解决后台进程，不要强行删除。 - 重新安装：按客户端文档卸载程序；涉及服务模式时，按项目说明卸载对应服务。安装与设备架构匹配的稳定版本，不要跨项目混装程序文件。
- 先空白启动：确认新实例使用新的数据目录，在不恢复旧订阅、脚本和 TUN 设置的情况下打开窗口。有些客户端没有选中配置时不会启动内核，这与界面闪退是两回事。
- 逐项恢复：先导入一份已知可用配置，启动并查看日志；随后恢复本地规则、覆写、系统代理和 TUN。每次只改一项，便于定位触发条件。
如果空白数据也闪退，排查重点应转向系统兼容性、运行时、安装完整性或客户端自身缺陷。如果空白数据正常、恢复旧数据后复现，就保留新目录，分批恢复旧内容，不要把整个备份直接覆盖回去。
七、修复后的验证与求助信息
能看见窗口只是第一步，还要确认配置和连接恢复。保持客户端打开 2 分钟，查看内核是否反复重启；检查当前选中的配置、代理模式和策略组是否正确。规则模式会按规则选择连接方式，因此某个网站直连不一定表示代理失效。
- 确认实际监听端口与应用填写的代理端口一致，特别是排查中修改过 7890 的情况。
- 打开连接列表，访问一个有明确匹配规则的测试域名，查看命中的规则与策略组，不只看延迟数字。
- 需要 TUN 时最后再启用，并检查 DNS 解析、普通网页和日常应用。出现异常就回到上一个已验证状态。
- 退出客户端，再正常启动一次；确认配置选择和端口设置能保留，日志没有再次出现同一启动错误。
整个排查顺序可以保持简单：先确认退出对象，再读日志；有端口错误就查端口，有配置错误就回滚配置，有文件错误再处理安装。每一步保留可恢复的备份，通常比连续重装更容易找到真正的触发点。