Clash 客户端启动闪退排查清单：端口占用、配置报错与权限问题逐项解决

先判断是界面退出，还是 Clash 内核启动失败

“双击后没有窗口”“窗口出现一秒后消失”“托盘图标存在但无法联网”看起来相似，实际对应三个不同层级。Clash 图形客户端通常由界面进程、Clash Meta（mihomo）内核、系统代理或 TUN 服务组成。界面进程退出属于客户端自身问题；界面仍在但内核反复停止，通常与配置、端口或内核文件有关；内核正常运行却无法访问网络，则应继续检查系统代理、DNS、规则和 TUN，而不是反复重装客户端。

排查前先暂时关闭“开机启动”和“静默启动”。如果客户端可以短暂进入界面，可按「设置」→「常规」关闭开机启动，再从「工具」或「日志」页面复制最近一次启动记录。不同客户端的菜单名称略有区别，常见入口包括「设置」→「日志」「工具」→「应用日志」以及「内核」→「运行日志」。重点记录退出时间前后的最后 20 至 50 行。

现象	优先检查	常见日志关键词
窗口出现后立即消失	应用权限、用户目录、界面运行库	permission denied、access denied、panic
界面正常，内核状态反复停止	端口、YAML、内核文件	bind、parse、unmarshal、config error
开启 TUN 后退出	服务权限、驱动、路由冲突	tun、service、route、operation not permitted
重启后提示已有实例	残留进程、锁文件	already running、lock、address in use

第一项：检查 7890、7891 与控制端口是否被占用

端口占用是最常见的内核启动失败原因之一。典型配置会使用 HTTP 端口 7890、SOCKS5 端口 7891，或者用 mixed-port: 7890 合并两种代理入口。外部控制器常见地址为 127.0.0.1:9090。这些数值不是强制标准，但同一台设备上的两个程序不能同时监听完全相同的地址与端口。

Windows 查询端口占用

先完全退出当前 Clash 客户端，再打开 PowerShell 或命令提示符，依次执行：

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

如果结果中出现 LISTENING，最右侧数字就是 PID。例如 127.0.0.1:7890 对应 PID 8420，可继续查询进程：

tasklist /FI "PID eq 8420"

确认它是旧的 Clash、mihomo、代理软件或调试服务后，优先从原程序的退出菜单正常关闭。只有确认进程不再承担其他任务时，才使用以下命令结束：

taskkill /PID 8420 /F

macOS 与 Linux 查询监听进程

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

Linux 还可以使用 ss：

ss -lntp | grep -E ':7890|:7891|:9090'

如果必须让两个客户端同时保留，可在其中一个客户端的「设置」→「网络」→「端口」修改监听值，例如将 mixed 端口改为 7897，控制端口改为 9097。修改后还要同步检查操作系统代理设置，避免系统仍指向旧的 127.0.0.1:7890。

第二项：隔离 YAML 配置错误与订阅异常

Clash Meta 会在启动阶段解析 YAML。缩进错误、字段类型不正确、同级键重复、规则格式错误，都可能让内核直接拒绝配置。日志中常见信息包括 yaml: line 42、cannot unmarshal、proxy group not found 和 invalid mode。此时重点是找到第一条配置错误，而不是追着后续连锁报错逐条处理。

用最小配置验证内核能否独立启动

先备份当前配置，再建立一份只提供本地监听和直连规则的测试配置：

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

proxies: []

proxy-groups: []

rules:
  - MATCH,DIRECT

这份配置不包含订阅节点，也不用于日常代理。它的作用是验证 YAML 解析、端口监听和内核进程能否完成启动。如果最小配置可以运行，问题基本位于原配置的 DNS、节点、策略组、规则或覆写内容；如果仍然退出，应继续检查内核文件、目录权限和残留服务。

逐段恢复，而不是一次粘回全部内容

先恢复 dns 块并重启内核，确认字段能被当前 mihomo 版本识别。
再恢复 proxies 或订阅提供者，检查节点协议参数与证书字段。
加入 proxy-groups，确认组内引用的节点名、提供者名和其他策略组真实存在。
最后恢复 rules，特别检查规则集名称、目标策略名和末尾的 MATCH 规则。

YAML 缩进只能表达层级，Tab 字符不应混入空格缩进。列表项的连字符后需要空格，例如 - MATCH,DIRECT。布尔值、数字和字符串也不能任意互换。某些包含冒号、井号或特殊字符的节点名应使用引号包住，否则井号后的内容会被当作注释。

proxy-groups:
  - name: "手动选择"
    type: select
    proxies:
      - DIRECT
      - "节点 A"

如果故障发生在订阅刷新之后，可在「配置」页面切换回上一次正常配置，再关闭自动更新进行对比。订阅下载成功只代表服务器返回了内容，不代表内容一定是可解析的 Clash 配置。返回登录页、HTML 错误页或被截断的 YAML 时，文件仍可能落盘，但内核会在载入阶段报错。

第三项：确认 mihomo 内核文件与架构匹配

图形客户端本身能够打开，不代表内核可执行文件一定可用。更新中断、文件被安全策略隔离、手动替换了错误架构，都会造成点击“启动内核”后立即停止。Windows 常见架构是 amd64 与 arm64；Apple 芯片 macOS 使用 arm64，Intel Mac 使用 amd64。Linux 还需要区分 amd64、arm64 等构建。

进入客户端的「设置」→「内核」或「内核管理」，先记录当前显示的内核名称与版本。例如日志若显示 mihomo v1.19.10 windows amd64，至少可以确认文件已经运行并输出版本；如果连版本信息都没有，且日志只出现“无法启动进程”或“文件不存在”，应检查文件路径与执行权限。

优先使用客户端内置的内核管理功能

先停止系统代理与 TUN，避免旧内核仍占用文件。
完全退出客户端，并在任务管理器或活动监视器确认 mihomo 进程已经消失。
重新打开客户端，通过「设置」→「内核」→「检查更新」或「重新下载」恢复与系统架构匹配的内核。
恢复后先载入最小配置，确认内核可以持续运行 30 秒以上，再切回日常配置。

手动复制内核时，不要只按文件名判断架构。错误架构在 Windows 上可能返回“此应用无法在你的电脑上运行”，在 Linux 上可能出现 Exec format error。macOS 若提示开发者或隔离属性相关阻止，应先确认文件来源与客户端版本，再从系统「隐私与安全性」页面查看实际拦截记录，而不是反复双击。

第四项：处理权限、TUN 服务与受保护目录

普通系统代理通常只需监听本机高位端口，而 TUN 模式需要创建虚拟网络接口、修改路由或调用系统服务，因此权限要求更高。一个典型现象是：关闭 TUN 时客户端稳定，打开 TUN 后内核立刻退出。这时应把 TUN 单独作为变量排查。

Windows：先区分应用权限与服务权限

右键客户端选择“以管理员身份运行”可以用于一次诊断，但不应把它当成所有问题的固定答案。若管理员启动后 TUN 正常，普通启动失败，应进入客户端「设置」→「TUN 模式」或「服务模式」，重新安装其系统服务，然后退出管理员会话，用普通方式再次测试。

同时检查应用是否放在需要额外写入权限的目录。客户端运行数据不应写入 C:\Program Files 下的只读位置，也不要直接在压缩包预览窗口中运行。将程序完整解压到用户可写目录后再启动，例如用户目录下专门的应用文件夹。

macOS 与 Linux：检查可执行权限和网络能力

Linux 手动部署的内核如果缺少执行位，会直接返回 Permission denied。可先查看权限：

ls -l ./mihomo
chmod u+x ./mihomo

这只解决文件执行权限，不等于自动获得创建 TUN 设备所需的能力。通过桌面客户端使用 TUN 时，应优先采用客户端提供的服务安装流程；通过 systemd 部署时，则检查服务单元的用户、网络能力、工作目录和配置路径。不要一边运行桌面客户端，一边启动另一个监听相同端口的 systemd 服务。

macOS 可在「系统设置」→「隐私与安全性」查看被阻止的系统扩展或应用记录，并在「系统设置」→「网络」检查是否残留重复的 VPN 配置。修改后完整退出客户端再启动，避免旧网络扩展状态继续影响测试。

第五项：清理残留进程、锁文件与重复启动项

客户端窗口消失后，mihomo 内核或系统服务可能仍在后台运行。再次启动时，新实例会遇到端口占用、数据库锁或“已有实例运行”的提示。Windows 在任务管理器的“详细信息”页检查客户端主进程、mihomo.exe 与旧版 clash.exe；macOS 使用活动监视器；Linux 可执行：

ps -ef | grep -E 'mihomo|clash'
systemctl --user status mihomo
systemctl status mihomo

如果同一程序同时配置了系统级服务、用户级服务和桌面开机启动，可能在登录时启动两到三次。保留一种启动方式即可。Windows 可检查「设置」→「应用」→「启动」以及任务管理器的“启动应用”；macOS 可检查「系统设置」→「通用」→「登录项」；Linux 则同时核对 systemd 服务和桌面环境的自动启动目录。

锁文件只能在确认所有相关进程已经退出后处理。不要在内核仍运行时删除数据库、缓存或运行目录。若客户端提供「重置运行状态」或「清理缓存」按钮，优先使用内置功能。若必须重建用户数据，先备份订阅地址、本地 YAML、规则覆写和应用设置，再将原目录改名保留，而不是直接永久删除。

第六项：按固定顺序完成一次可复现排查

闪退问题最容易被“同时改了五项设置”拖慢。下面这套顺序从低风险、易验证的项目开始，每一步都只改变一个变量：

完全退出客户端，确认没有残留的界面、mihomo 或 clash 进程。
检查 7890、7891、9090 等实际配置端口，关闭冲突进程或修改端口。
关闭 TUN、系统服务和开机启动，只保留普通 mixed-port。
载入最小 YAML，观察内核能否稳定运行至少 30 秒。
记录内核架构与版本，通过客户端内核管理入口重新部署一次。
逐段恢复 DNS、节点、策略组和规则，每次恢复后重启并查看日志。
最后重新开启系统代理，再测试 TUN 和开机启动。

每次测试都记录“操作、结果、最后一条错误日志”。例如：“端口从 7890 改为 7897，最小配置运行 60 秒正常；切回订阅后出现第 184 行解析错误”。这样的记录可以迅速把问题缩小到配置，而不是笼统地归因于客户端版本。

什么情况下应重装客户端

只有当界面进程本身无法打开、应用文件缺失、内置内核管理无法恢复，或用户数据目录在最小配置下仍持续报读写错误时，重装才是合理步骤。重装前先退出系统代理和 TUN 服务，备份必要配置，再卸载旧版本。安装后不要立即导入全部旧数据，先用默认设置启动一次，然后导入一份已确认可解析的配置。

什么情况下不需要重装

日志明确提示 address already in use：解决端口冲突即可。
日志给出 YAML 行号：修复配置结构或切回正常配置。
仅开启 TUN 后失败：处理服务权限、驱动或路由冲突。
订阅更新后开始退出：回退配置并检查订阅返回内容。
后台已有 mihomo 进程：停止重复实例并整理启动项。