先区分窗口退出与内核退出

Clash 客户端打开后立即消失，不一定代表整个程序崩溃。桌面客户端通常包含图形界面、代理内核，以及可能独立运行的服务组件。窗口关闭后，托盘图标和内核进程可能仍然存在；也可能只有 mihomo 内核启动失败，界面本身还能显示。先确认退出的是哪一层，再选择修复方法。

观察到的现象优先检查判断依据
窗口消失，托盘仍在关闭窗口行为、重复启动从托盘打开主窗口，确认是否只是最小化到托盘
界面存在，提示内核启动失败配置、内核文件、监听端口查看内核日志末尾的首条明确错误
窗口与主进程同时退出系统崩溃报告、图形运行环境查找同一时间的应用程序错误或崩溃记录
启用 TUN 后才退出或报错服务组件、权限、虚拟网卡关闭 TUN 后是否能正常启动和连接

启动前记录四项信息

  • 客户端名称与完整版本号，能打开界面时从“关于”页面读取；否则查看安装包名称或程序文件属性。
  • 系统版本与架构，例如 Windows 11 x64、macOS arm64；不要只写“电脑端”。
  • 故障发生时间，精确到分钟，以及此前是否更新客户端、导入订阅或启用 TUN。
  • 退出前的完整提示，以及系统中是否仍有客户端、mihomo 或其服务进程。

获取启动日志与系统崩溃记录

不同 Clash 客户端的应用数据目录并不统一，不能把某一个客户端的日志路径当作全部客户端的标准。若界面尚能打开，先查“日志”页面，或在“设置”中寻找打开日志目录、应用目录的入口；入口名称随客户端版本变化。重点保存故障时间前后约一分钟的内容，而不是只截最后一行“启动失败”。

Windows：事件查看器与应用数据

  1. 按 Win + R，输入 eventvwr.msc。
  2. 进入“Windows 日志”→“应用程序”，找到故障时间附近的记录。应用崩溃常见事件来源为 Application Error，事件 ID 为 1000，但并非每次退出都会产生这条记录。
  3. 记录故障应用程序名称、故障模块、异常代码与程序路径。程序路径有助于确认启动的是新安装版本还是旧快捷方式。
  4. 在资源管理器分别输入 %APPDATA% 与 %LOCALAPPDATA%，按客户端名称或项目标识查找对应目录。日志可能位于应用子目录中的 logs，也可能由界面指定位置。

还可以运行 perfmon /rel 打开可靠性监视器，按日期查看应用失败记录。系统报告用于定位图形界面崩溃；内核日志则更适合判断 YAML、端口和资源加载问题，两者不能互相替代。

macOS：诊断报告与控制台

在 Finder 使用“前往”→“前往文件夹”，输入 ~/Library/Logs/DiagnosticReports/。查找与客户端进程名、故障时间匹配的 .ips 或 .crash 文件。应用自己的日志也可能位于 ~/Library/Logs/ 或 ~/Library/Application Support/ 下的专属目录。打开“控制台”可按进程名称筛选错误，重点保留异常类型与退出原因。

Linux：终端启动与用户日志

从终端执行实际安装的客户端命令，能看到双击启动时隐藏的标准错误输出。桌面启动命令可从对应 .desktop 文件的 Exec 字段确认。若程序或用户服务写入 journal，可检查最近十分钟的记录：

journalctl --user --since "10 minutes ago" --no-pager

应用数据常见于 ~/.config/、~/.local/share/ 或 ~/.local/state/ 的项目子目录，但具体位置由客户端决定。系统使用 systemd 且保留了崩溃信息时，可运行 coredumpctl list 查看记录；没有输出不代表程序一定没有崩溃。

配置语法错误：先验证实际加载文件

若日志出现 yaml、unmarshal 或配置解析行号，先检查刚导入或修改的 Profile。YAML 缩进使用空格，不使用 Tab；同级字段应保持一致。订阅下载成功也不等于配置有效：失效链接可能返回登录页面、错误文本或未经转换的节点列表。

检查缩进、类型与策略名称

  • mixed-port: 7890 是数值字段示例。全角冒号或错误层级会导致解析失败。
  • 列表项需要正确的 - 前缀。把 rules 写成普通字符串，可能出现类型转换错误。
  • 规则引用的策略名称应与配置中的代理或代理组一致。例如规则使用 Proxy，配置中却只有 PROXY，需要核对实际名称。
  • 检查重复字段以及新增的合并、覆写配置。原始订阅正确，合并后的运行配置仍可能出错。

使用 mihomo 的 Clash 客户端，可以在已确认内核来源和版本的前提下，对配置副本进行测试。下面假定终端当前目录已有 config.yaml，且 mihomo 可直接执行：

mihomo -v
mihomo -t -f ./config.yaml

如果内核不在 PATH 中，应使用客户端实际内核的完整路径，不要另外下载一个不同版本的内核代替验证。部分配置需要在指定工作目录下加载规则资源或数据库；此时可用 -d 指定已经确认的工作目录。测试输出要区分语法错误、策略引用错误与资源读取失败。

客户端可能根据 Profile、全局覆写和界面设置生成最终运行配置。因此，原始订阅测试通过后，还要检查实际加载文件是否包含错误。最有效的对照方法是恢复修改前的备份，保持客户端版本不变重新启动。不要为了测试而永久删掉订阅或规则。

内核文件缺失：核对安装与安全记录

出现 no such file or directory、找不到可执行文件或创建内核进程失败时，应检查日志指向的实际路径。更新中断、直接移动程序目录、只复制主程序，或安全软件隔离了某个组件，都可能造成安装不完整。图形界面文件存在，并不能证明内核和依赖组件齐全。

  1. 核对快捷方式目标和安装位置，确认没有从旧解压目录启动。
  2. 查看内核文件是否存在，并确认安装包架构与系统匹配。Linux 的 Exec format error 常提示可执行格式或架构不匹配。
  3. Windows 可打开“Windows 安全中心”→“病毒和威胁防护”→“保护历史记录”，核对是否有与故障时间对应的隔离事件。
  4. 从原项目的发布入口重新获取完整安装包，退出客户端后修复或重新安装。保留应用数据备份，不要将不同版本的零散文件混装。

若 Windows 报错涉及 WebView2Loader.dll 或运行时初始化，问题可能位于图形界面的运行环境，而不是 YAML。只有依赖 WebView2 的客户端才需要相应运行时；其他客户端不能照搬同一处理方式。应依据客户端发布说明修复依赖，不要从陌生网站单独下载 DLL 放入系统目录。

macOS 的系统安全拦截通常会给出明确提示，和无提示崩溃不同。先核对应用来源、系统兼容要求与诊断报告。不要把关闭 Gatekeeper 或批量移除应用安全属性当作常规第一步。

权限不足：分开检查目录与 TUN

permission denied 和 access is denied 表示操作被拒绝，但不等于“所有场景都要管理员运行”。普通配置读写与 TUN 虚拟网卡是两类权限问题：前者依赖文件所有者和目录权限，后者可能依赖提权服务、系统网络扩展或设备访问权限。

目录读写失败

先查看日志中的具体文件路径。若配置放在只读介质、受保护目录或同步盘中，客户端可能无法写入缓存和数据库。Linux 上曾用 sudo 启动图形客户端，可能导致应用数据被 root 拥有；应检查那个目录的所有者，而不是给整个用户目录递归开放权限。不要使用 chmod -R 777 作为修复方案。

TUN 或服务组件失败

  1. 恢复启用 TUN 前的设置，先确认图形界面和普通代理能正常运行。
  2. 按当前客户端文档安装或修复服务组件，再使用界面提供的 TUN 开关。
  3. 检查系统是否提示授权、网络扩展被阻止或服务无法启动，并保存对应错误。
  4. 每次仅启用一个需要接管系统路由的工具，避免多个虚拟网卡和路由管理程序同时介入。

残留进程与端口占用：先确认所有者

更新后旧内核仍在运行，可能占用新内核需要监听的端口。日志中的 address already in use 比“启动失败”更有定位价值。代理监听和外部控制接口是不同端口：7890、9090 只是常见配置示例，排查时以实际配置与报错中的端口为准。

查看端口对应进程

Windows 在命令提示符运行以下命令，查看最后一列 PID，再到“任务管理器”→“详细信息”核对进程名称和可执行文件路径：

netstat -ano | findstr ":7890"
netstat -ano | findstr ":9090"

输出也可能包含远端地址匹配项，需要确认本地地址、端口和监听状态。macOS 可查询 TCP 监听进程：

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

Linux 可查看监听套接字；进程信息受权限限制，普通用户不一定能看到其他用户的进程：

ss -lntp 'sport = :7890'
ss -lntp 'sport = :9090'
  1. 优先从托盘退出旧客户端；独立服务则按其安装方式停止，不要仅关闭窗口。
  2. 再次查询端口，确认监听已经消失，再启动目标客户端。
  3. 若占用者是另一项必要服务，可调整目标客户端端口，同时更新系统代理和相关应用设置。
  4. 仅在确认进程归属后结束进程。不要按“名字像代理”批量终止系统或网络组件。

端口占用通常会导致内核启动失败，不一定让图形界面直接崩溃。如果释放端口后窗口仍立刻退出，应返回系统崩溃报告继续查，而不是反复更换端口。

备份后重置：分层恢复配置

当日志不足以定位，或旧设置与新版本存在兼容问题时，可以用干净应用数据做对照测试。重新安装不一定会重置配置，因为应用数据往往独立于安装目录。重置前必须先确认当前客户端使用哪个目录，避免误操作其他客户端的数据。

  1. 停止程序。退出托盘中的客户端，并确认内核或服务不再写入数据。
  2. 完整备份。复制应用数据目录，保留本地 YAML、订阅信息、覆写规则和界面设置。备份含敏感信息，应留在受控的本地位置。
  3. 隔离旧数据。将已确认的应用数据目录改名，例如在原目录名后添加 .backup-20260917，不要直接删除。
  4. 启动默认状态。确认客户端能否创建新目录并保持运行。此时先不恢复自动连接、TUN 或全部订阅。
  5. 逐项恢复。先导入一份确认有效的配置，再恢复覆写规则，最后恢复 TUN 和服务设置。每一步都重新观察日志。

如果某一步恢复后问题重新出现，就有了可重复的定位条件。若全新数据下仍崩溃，配置因素的优先级下降，应检查客户端版本、运行时依赖与系统兼容性。回退版本时也应使用独立备份，避免旧版本直接读取新版本迁移后的数据库。

修复验证与反馈信息

窗口能打开只是第一项验证。还要确认内核持续运行、配置加载成功、监听端口与预期一致。使用系统代理时，检查浏览器请求是否经过该端口；使用 TUN 时，再检查路由和 DNS 行为。节点超时属于连接层问题，不应仅凭超时结果认定客户端仍在启动崩溃。

  • 完整退出并重新启动一次，确认修复并非依赖残留进程。
  • 保存修复前后的日志，记录修改的是配置、安装文件、权限还是服务状态。
  • 反馈问题时附客户端与内核版本、系统架构、复现步骤，以及脱敏后的关键错误。
  • 若报告包含故障模块或异常代码，原样保留；不要只写“打不开”或仅发送窗口截图。

排查顺序可以归纳为：确认退出层级，取得日志，按错误处理配置、文件、权限与端口，最后用备份后的重置做对照。需要重新选择安装包时，可查看客户端下载页；配置导入与系统代理步骤见使用文档，TUN 与 DNS 参数见配置进阶。