Clash 客户端启动闪退怎么办：从运行环境到配置恢复的排查步骤

先分清：窗口闪退、后台运行与内核退出

搜索“Clash 打不开”时，首先要确认消失的是窗口，还是整个进程。Clash 系客户端负责界面、订阅导入和配置管理，Clash 或 Clash Meta（mihomo）内核负责代理连接、规则匹配及 DNS 处理。界面可以正常显示而内核无法启动；内核也可能仍在运行，只是界面窗口已经关闭。两种情况需要收集的日志和修复位置不同。

启动一次后观察约 10 秒，检查系统托盘、活动监视器或任务管理器。不要连续双击程序：已有实例、后台服务和新的启动请求混在一起，会让端口占用与退出时间难以判断。

操作前备份：保留配置、日志与版本信息

直接卸载可能保留损坏的用户数据，也可能删除尚未导出的订阅与覆写；“重装后还是闪退”不能据此证明安装包有问题。先记下客户端完整名称及版本、内核版本、系统版本与架构，并标明故障出现在更新客户端、更新订阅还是修改配置之后。客户端版本与内核版本是两项不同的信息，不能只写“最新版”。

备份应包含哪些内容

• 原始配置与订阅：保存本地 YAML、订阅记录和仍能正常工作的旧配置。订阅 URL 通常包含访问凭据，应按密码保存。
• 覆写与合并逻辑：单独保存规则追加、配置合并片段和脚本。订阅原文正确，不代表最终生成的运行配置正确。
• 客户端设置：记录系统代理、TUN、服务模式、本地监听端口和控制接口设置，必要时截图。
• 故障日志：保留启动前后约 1 分钟的记录，既要看内核日志，也要看界面进程的错误。

如果界面能打开，优先使用客户端提供的打开配置目录、打开日志目录或导出功能；不同客户端菜单命名并不统一。若完全无法启动，再按该客户端文档确认数据目录。Windows 的 %APPDATA% 与 %LOCALAPPDATA%、macOS 的 ~/Library/Application Support/ 都只是可能的上级位置，不要把整个目录删除，也不要把安装目录直接当作用户数据目录。

复制前正常退出客户端，确认相关进程不再写入文件；使用服务模式时，还需通过客户端支持的服务管理入口停止对应服务。不要凭进程名模糊匹配后批量结束任务。准备分享日志时，另做脱敏副本，遮盖订阅令牌、节点密码、控制接口密钥、私人域名和用户名。

运行环境检查：系统架构、依赖与完整解压

按设备架构选包，不按文件名猜测

Windows 11 可在「设置」→「系统」→「系统信息」查看“系统类型”；Intel 或 AMD 的常见桌面设备通常选择 x64，ARM 设备则应核对项目是否提供 ARM64 包。macOS 在苹果菜单「关于本机」查看“芯片”或“处理器”，区分 Apple Silicon 与 Intel。Linux 可用 uname -m 查看架构，常见输出 x86_64 与 aarch64 分别对应 x64 与 ARM64。

处理器架构匹配还不够，系统最低版本、Linux 的运行库版本和桌面环境也可能有要求。若提示 Exec format error，优先检查可执行文件架构；若明确提示 GLIBC_… not found，应核对发行版与程序构建要求，不要手工替换系统核心运行库。Android 安装包则需按设备支持的 ABI 选择，旧设备不能仅凭“64 位处理器”认定能运行任意 ARM64 应用。

依赖必须与具体客户端实现对应

• Windows WebView 界面：依赖 WebView2 的客户端如果提示运行时缺失或初始化失败，应按项目文档修复对应运行时。Electron 客户端不是同一套依赖，不能把安装 WebView2 当作通用解法。
• DLL 缺失：只有错误或项目说明明确指向 Visual C++ 运行库等组件时，才修复对应架构的运行库；不要下载来历不明的单个 DLL 填进系统目录。
• 便携包：先完整解压到当前用户可读写的本地目录，再从解压目录启动。直接在压缩包预览中运行，可能丢失内核、资源或相邻文件。
• 系统拦截：查看 Windows「Windows 安全中心」→「病毒和威胁防护」→「保护历史记录」，或 macOS「系统设置」→「隐私与安全性」中的相关提示，确认被拦截的具体文件和原因，不要关闭整套系统防护。

Windows 上可通过 Win + R 输入 eventvwr.msc，在「Windows 日志」→「应用程序」查找启动时刻附近的错误，记录故障应用程序、故障模块与异常代码。这里的模块信息有助于区分界面渲染异常和内核退出，但单个模块名不足以直接确定根因。

权限与端口检查：先关闭 TUN 缩小范围

如果客户端在启用 TUN 或安装服务后才出问题，先在界面里关闭 TUN，再退出并启动一次。TUN 用于在网络层接管流量，通常涉及系统授权、服务或虚拟网卡；系统代理主要为遵循系统代理设置的应用提供代理入口，两者不是同一个开关。普通界面启动与仅监听本地高位端口通常不需要持续使用管理员权限。

若关闭 TUN 后能启动，应继续检查客户端服务状态、系统 VPN 授权以及其他 VPN 或虚拟网卡软件的冲突。Windows 服务模式应按当前客户端文档修复服务；Android 的 VPN 授权或另一应用占用 VPN 槽位，应与应用界面崩溃分开处理。不要直接删除所有虚拟网卡，也不要对整个数据目录授予所有用户写入权限。

以本地端口 7890 为例检查监听冲突

日志出现 address already in use 或 Windows 的 Only one usage of each socket address 时，先找出具体冲突地址与端口。下面命令仅适用于配置确实使用 7890 的情况；若错误指向控制接口或 DNS 端口，应改查日志中的端口。

# Windows PowerShell：查找监听 7890 的进程
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS：查找 TCP 监听进程
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：查看 TCP 监听列表及进程信息
ss -ltnp

根据输出的进程标识确认占用者；Linux 普通用户可能看不到其他用户的完整进程信息。若占用者是另一个代理客户端，先正常退出它；若是当前客户端遗留的服务，应通过对应管理入口处理。确需更换端口时，要同步修改浏览器或系统代理入口，否则即使内核恢复，应用仍会连接旧端口。

配置检查：验证内核实际读取的 YAML

界面能打开但内核反复退出时，应从日志中寻找第一条具体错误，而不是只看最后的“启动失败”。常见原因包括 YAML 缩进错误、规则指向不存在的策略组、内核不支持节点类型，以及资源文件不存在。Clash 与 mihomo 的字段支持范围不同，某个客户端能导入订阅，不表示它所调用的内核能执行其中全部字段。

先检查合并结果，再检查订阅原文

1. 确认当前选中的配置文件，并从日志或客户端功能中找到实际运行配置。
2. 检查是否启用了覆写、脚本、规则追加或代理集合；暂时停用最近新增的处理步骤。
3. 检查 YAML 是否用空格缩进；核对策略组名称、规则目标与代理引用是否完全一致。
4. 区分订阅下载失败与配置解析失败：返回登录页或错误页面的 URL，不能作为 YAML 交给内核解析。

使用 mihomo 且能够运行其独立可执行文件时，可以先进行配置测试。以下命令假定当前目录内有名为 mihomo 的可执行文件及 diagnostic.yaml；Windows 假定文件名为 mihomo.exe。实际名称应以所用客户端附带的文件为准，不要为了测试而随意替换客户端内核。

# macOS / Linux
./mihomo -v
./mihomo -t -f ./diagnostic.yaml

# Windows PowerShell
.\mihomo.exe -v
.\mihomo.exe -t -f .\diagnostic.yaml

-v 用于记录内核版本，-t 用于测试配置。配置涉及相对路径、代理集合或规则集合时，还应按内核帮助说明使用 -d 指定对应工作目录，否则可能因资源位置不同产生额外错误。测试通过只说明该测试环境下配置检查通过，不能保证端口可绑定、TUN 有权限或远端节点可连接。

用最小直连配置隔离订阅问题

下面是用于 mihomo 的诊断示例，不含代理节点，不提供代理出口。仅在已备份、关闭系统代理与 TUN、确认 7890 未被占用的前提下，作为单独测试文件使用。不要把它覆盖到订阅原文件上；客户端自动添加的覆写也应暂时停用。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

若最小配置可启动，而原配置不能，下一步逐项恢复代理节点、策略组、规则、DNS 与覆写，找到首次失败的变化。若最小配置依然报相同的依赖、权限或端口错误，应回到运行环境层检查。不要用切换 Fake-IP、改 DNS 服务器等网络参数去修复界面进程崩溃。

配置恢复：隔离旧数据，不直接清空

当运行环境已核对、日志指向本地设置读取失败，或更新后只有旧用户数据会触发异常时，可以进行数据目录隔离测试。它的目的在于判断故障是否随旧数据出现，不是要求永久丢弃原配置。

1. 完成备份并退出：停止客户端及其对应服务，确认没有残留进程继续写入。
2. 确认正确目录：按当前客户端文档定位数据目录。如果支持独立配置目录或便携模式，优先使用项目提供的隔离方式。
3. 保留原目录：将已确认的数据目录改名，备份名可使用 client-data.backup-20260819，不要删除。
4. 用默认设置启动：允许客户端生成新的用户数据，先不开 TUN、不导入订阅、不恢复全部设置。
5. 逐层恢复：先导入已知有效的配置，检查内核启动，再恢复必要规则与覆写，最后启用系统代理或 TUN。

如果空白数据目录仍然闪退，旧配置大概率不是唯一原因；应回看系统崩溃日志和版本兼容条件。如果恢复某一项后再次失败，保留这一前后差异，比完整重装更便于定位。需要还原旧目录时，先退出程序，再保留本轮新目录并恢复原名，避免把两套数据库或缓存直接混合。

恢复后验证与故障反馈清单

窗口重新出现只是第一步。先观察界面和内核是否稳定运行，再确认本地监听端口，最后才测试代理流量。下面以监听 127.0.0.1:7890 的 HTTP 混合端口为例，选择有权访问且当前网络可达的 HTTPS 地址进行验证；示例地址的可达性仍受当地网络影响。

# macOS / Linux
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

# Windows：明确调用 curl.exe
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

这里的 10 秒连接超时与 20 秒总超时是诊断上限，不是延迟成绩。只看到 200 Connection established 不能认定目标请求已成功，还应检查后续 TLS 与 HTTP 结果。如果仍使用前面的最小配置，流量会直连；验证真实代理出口时，要恢复有效节点及对应规则，并在连接记录中确认命中的策略。

提交反馈时保留可复现信息

• 客户端名称、完整版本号、内核 -v 输出，以及系统版本与架构。
• 安装包类型、是否使用便携模式或服务模式、TUN 是否开启。
• 复现顺序，例如“默认启动正常 → 导入配置正常 → 启用覆写后内核退出”。
• 故障发生时间、首条具体错误、退出码，以及脱敏后的相邻日志。
• 默认数据目录测试、最小配置测试和端口检查分别得到什么结果。

若问题只在一次客户端更新后出现，应带着上述证据向相应项目反馈。选择其他客户端前，可先阅读客户端选型指南确认平台与内核支持范围；配置层的问题可对照配置大全逐项检查。能够复现并隔离到某一步，比反复重装更容易形成可验证的修复结论。