故障排查 预计阅读 12 分钟

Clash 启动闪退排查:配置文件报错、端口占用与权限问题

客户端双击无响应或秒退时,按配置文件语法、7890 端口被占用、TUN 驱动与系统权限、内核文件损坏四条线索依次排查,附各平台的检查方法与恢复办法。

Clash 客户端启动后立即退出，通常不是单一故障。图形界面、mihomo 或 Clash 内核、配置文件、监听端口和 TUN 组件会按顺序初始化，其中任意一步失败，都可能表现为窗口闪一下、托盘图标消失或进程几秒后结束。直接反复双击很难获得新信息，正确做法是先判断退出发生在哪一层。

先区分界面闪退、内核退出与后台残留

启动故障可以先按现象分成三类。第一类是窗口完全不出现，任务管理器或活动监视器里也没有进程，重点检查应用文件、执行权限和系统安全提示。第二类是界面出现后立即关闭，常见原因是配置载入失败或图形界面自身数据损坏。第三类是窗口消失但后台进程仍在，此时可能只是客户端最小化到托盘，或者旧进程占用了新实例需要使用的端口。

用 60 秒完成初步判断

  1. 关闭系统代理和 TUN 模式，避免排查期间网络流量继续进入失效端口。
  2. 打开任务管理器、活动监视器或系统监视器，结束名称中包含 Clash、mihomo 或对应客户端名称的残留进程。
  3. 再次启动客户端，观察进程持续时间。少于 2 秒退出，优先检查执行权限和应用文件；运行 2 至 10 秒后退出，优先检查配置与端口。
  4. 检查客户端数据目录中的日志。若界面能够短暂打开，可进入「设置」→「日志」或「设置」→「运行日志」，把日志级别暂时调整为 info。
  5. 如果图形界面没有留下日志，直接在终端运行内核并执行配置测试，让错误输出保留在窗口中。
启动现象 优先检查 典型信息
双击后完全无进程 文件完整性、执行权限、系统拦截 Permission denied、应用无法打开
运行数秒后退出 配置语法、订阅内容、端口占用 parse config、address already in use
普通模式可用，TUN 一开就退出 TUN 驱动、服务权限、路由接口 start tun failed、operation not permitted
窗口消失但网络仍可用 托盘区域、后台进程、单实例限制 进程仍监听 7890 或 9090

配置文件报错：先测试 YAML，再恢复最小配置

Clash 和 mihomo 在创建监听端口前会读取 YAML 配置。缩进错误、字段类型错误、规则格式不完整、代理组引用不存在节点，都可能让内核直接退出。订阅刚更新后开始闪退，或者手工修改配置后无法启动，应把配置检查放在第一位。

常见 YAML 错误

  • 使用 Tab 缩进。YAML 应使用空格，同一级字段保持相同缩进。
  • 冒号后缺少空格，例如把 mixed-port: 7890 写成 mixed-port:7890。
  • 规则缺少策略名，例如只写 DOMAIN-SUFFIX,example.com，没有最后的代理组。
  • proxy-groups 引用了不存在的节点或组名，特别是重命名节点后未同步修改组成员。
  • 从网页复制内容时混入全角标点，导致英文冒号、逗号或引号被替换。
  • 把 mihomo 专用字段交给较旧的 Clash 内核读取，内核无法识别当前配置结构。

在终端执行配置测试

mihomo 支持通过 -t 测试配置，通过 -f 指定文件。Windows 用户可在内核所在目录打开 PowerShell，macOS 与 Linux 用户在终端进入对应目录。以下命令只测试配置，不会长期启动代理服务：

# Windows PowerShell
& ".\mihomo.exe" -t -f ".\profiles\config.yaml"

# macOS 或 Linux
./mihomo -t -f ./profiles/config.yaml

# 使用旧版 Clash 内核时
./clash -t -f ./profiles/config.yaml

如果输出包含具体行号，先检查该行以及它上方 3 至 5 行。YAML 解析器经常在读到下一字段时才确认前一段结构有误，因此报错行不一定是问题真正开始的位置。若语法测试通过但客户端仍退出，再查看是否出现代理组为空、provider 下载失败或规则集路径不可读等运行期错误。

用最小配置判断问题范围

不要在原文件上连续试改。先复制原配置，再创建只包含端口、模式和空规则的临时配置。该配置可以验证内核能否完成基础启动：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies: []
proxy-groups: []
rules:
  - MATCH,DIRECT

最小配置可以启动，说明内核文件与基础权限大致正常，故障集中在原订阅或自定义段落。接下来按 dns、proxy-providers、rule-providers、tun 的顺序逐段恢复，每次只增加一段并重新测试。若最小配置也无法启动，则转向端口、权限和内核文件检查。

7890 端口被占用：找到进程，不要只改数字

mixed-port: 7890 表示 Clash 同时在 7890 接收 HTTP 与 SOCKS 代理连接。如果旧实例没有退出、另一款代理程序正在运行，或系统服务已经监听该端口，新内核会报告 address already in use、bind failed 或类似信息。部分图形客户端没有把错误显示出来，看上去就像启动闪退。

Windows 检查 7890

在 PowerShell 中运行以下命令。第一条返回占用端口的进程 ID，第二条根据该 ID 查看程序名称：

Get-NetTCPConnection -LocalPort 7890 -ErrorAction SilentlyContinue
Get-Process -Id 4321

把示例中的 4321 换成第一条命令显示的 OwningProcess 数值。也可以使用系统自带命令查看监听项：

netstat -ano | findstr :7890
tasklist /FI "PID eq 4321"

macOS 与 Linux 检查 7890

lsof -nP -iTCP:7890 -sTCP:LISTEN
ss -lntp | grep 7890

lsof 适用于 macOS 和多数 Linux 环境，ss 常见于 Linux。确认占用者是旧 Clash 或 mihomo 进程后，先从客户端正常退出；无法退出时再结束对应 PID。不要直接结束名称不明的系统服务，应先确认可执行文件路径和用途。

改用其他端口时同步三个位置

如果 7890 必须留给其他程序，可以把 Clash 的 mixed-port 改为 7893，但配置、客户端设置和系统代理必须一致：

  1. 在配置文件中设置 mixed-port: 7893。
  2. 进入「设置」→「参数设置」→「端口」，确认混合端口显示为 7893。
  3. 重新开启系统代理，检查 HTTP 与 SOCKS 地址是否指向 127.0.0.1:7893。

除 7890 外，还应检查 7891、7892 和 9090。旧配置常把 7891 用作 SOCKS 端口、7892 用作重定向端口、9090 用作外部控制接口。只要其中一个必需监听项冲突，内核同样可能终止。排查时以当前 YAML 中实际启用的端口为准。

TUN 模式启动失败：检查驱动、服务与管理员权限

普通系统代理只需要在本机监听端口，TUN 模式还要创建虚拟网络接口、修改路由和处理 DNS，因此权限要求更高。若关闭 TUN 后客户端能够稳定运行，一开启「设置」→「网络」→「TUN 模式」就退出，问题通常位于驱动、服务权限或残留虚拟网卡。

Windows：检查服务模式与 Wintun 接口

  • 先以管理员身份启动一次客户端，完成服务或虚拟网卡初始化。之后是否需要管理员权限取决于客户端采用的服务模式。
  • 进入「设备管理器」→「网络适配器」，检查是否存在带警告标记的 Wintun、Mihomo 或 Clash 虚拟接口。
  • 如果客户端提供「设置」→「服务模式」，先停止旧服务，再重新安装服务，避免界面版本与后台服务版本不一致。
  • 确认 Windows 的 Internet Connection Sharing 或其他虚拟网络软件没有持续重建冲突路由。

日志出现 Access is denied、operation requires elevation 时，说明当前进程缺少权限；出现 device already exists 时，应检查残留接口；出现 start tun failed 但没有更多信息时，可把日志级别改为 debug 后重试一次，再恢复为 info，避免长期生成大量日志。

macOS：确认网络扩展授权

macOS 客户端首次启用 TUN 时可能请求安装辅助服务或允许网络扩展。打开「系统设置」→「隐私与安全性」，检查底部是否有待确认的系统软件提示；再进入「系统设置」→「网络」→「VPN 与过滤器」，确认对应配置没有处于反复连接状态。升级客户端后若辅助服务版本未同步，应在客户端设置中重新安装服务，而不是手动复制旧的辅助程序。

Linux：检查 TUN 设备与能力

先确认系统存在 /dev/net/tun，再检查当前账户是否有创建接口和修改路由的权限：

ls -l /dev/net/tun
ip tuntap list
ip route
getcap ./mihomo

直接从终端运行时，缺少网络管理能力可能出现 operation not permitted。使用 systemd 服务时，还要检查服务单元的用户、能力限制与工作目录。不要同时运行桌面客户端 TUN 和另一个 mihomo systemd 服务，两者可能争用接口名称、DNS 端口或策略路由。

Android 与 iOS：重新建立 VPN 授权

移动端的 TUN 通常通过系统 VPN 接口实现。Android 上可进入「设置」→「网络和互联网」→「VPN」，移除失效的常驻连接后重新授权；同时检查是否已有其他 VPN 应用占用系统唯一的 VPN 通道。iOS 上可进入「设置」→「通用」→「VPN 与设备管理」查看配置状态。若应用一启动连接就被系统终止，还应检查系统电池优化和后台运行限制。

内核文件缺失或损坏：验证路径并重新安装对应版本

图形客户端通常不是代理内核本身。界面会在启动时调用 mihomo、Clash 或客户端随附的核心文件。如果内核被移动、升级中断、架构不匹配，界面可能找不到可执行文件，或者启动内核后立即收到异常退出状态。

先确认客户端实际调用的内核

  1. 打开客户端的「设置」→「内核」或「设置」→「版本信息」，记录内核名称、版本和文件路径。
  2. 检查路径指向的文件是否存在，文件大小是否明显为 0 KB。
  3. 在终端直接运行 mihomo -v 或 clash -v，确认能够输出版本信息。
  4. 核对系统架构。Windows 与 Linux 常见为 amd64 或 arm64，Apple 芯片 macOS 应选择 arm64 架构。
# Windows PowerShell
& ".\mihomo.exe" -v

# macOS 或 Linux
./mihomo -v
uname -m

如果版本命令也立即退出，先不要继续修改订阅。重新安装与操作系统、CPU 架构相符的客户端或内核，再用最小配置测试。Linux 下还要确认执行位是否存在；文件可以读取但没有执行权限时，终端会返回 Permission denied。

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

客户端更新后开始闪退，还应排除界面与内核接口不匹配。部分新版配置依赖 mihomo 的新字段，而旧内核无法读取；反过来，较旧图形界面也可能无法识别新版内核返回的数据。恢复时应优先安装同一发布包内配套的界面和内核，不要把多个来源、多个版本的文件混放在同一目录。

客户端数据损坏：保留配置后重建运行目录

配置测试通过、端口空闲、内核能够独立运行，但图形界面仍闪退时，问题可能位于窗口状态、数据库、缓存或客户端自身设置。此时可以重建应用数据，但必须先备份订阅地址、profiles 配置、自定义规则和脚本。

安全的重建顺序

  1. 彻底退出客户端，并确认后台没有 Clash 或 mihomo 进程。
  2. 复制配置目录到桌面备份，不要只保留当前 YAML；provider 文件和自定义规则也可能需要恢复。
  3. 将原数据目录重命名，而不是立即删除。例如在目录名后加上 -backup-20260722。
  4. 重新启动客户端，让程序生成干净的数据目录。
  5. 先导入一个已确认可用的配置，不要一次性复制全部旧缓存。
  6. 确认启动稳定后，再逐项恢复订阅和自定义规则。

Windows 应用数据通常位于用户的 AppData 子目录，macOS 常见于用户资料库的 Application Support，Linux 常见于 ~/.config。具体目录名由客户端决定。可通过客户端的「设置」→「配置目录」或日志中的 home directory、config directory 字段确认，不应根据其他客户端的目录名直接删除。

按平台执行完整恢复流程

Windows 恢复步骤

  1. 关闭「设置」→「网络和 Internet」→「代理」中的手动代理。
  2. 在任务管理器结束残留的客户端与 mihomo 进程。
  3. 用 PowerShell 检查 7890、7891、7892、9090 是否处于 LISTEN。
  4. 在终端执行内核版本命令和配置测试命令。
  5. 普通代理可以启动后，再检查服务模式和 TUN 虚拟接口。
  6. 仍失败时备份数据目录，重新安装客户端并只恢复一份已验证配置。

macOS 恢复步骤

  1. 在「系统设置」→「网络」中关闭失效的代理或 VPN 配置。
  2. 通过活动监视器结束残留进程，并用 lsof 检查监听端口。
  3. 从终端运行内核，分别验证版本和 YAML 配置。
  4. 检查「隐私与安全性」中的授权提示，以及「VPN 与过滤器」中的网络扩展。
  5. 若普通代理正常而 TUN 失败，在客户端内重新安装辅助服务。

Linux 恢复步骤

  1. 检查是否同时运行桌面客户端和 systemd 服务。
  2. 使用 ss -lntp 查看端口，使用 journalctl 查看服务退出原因。
  3. 确认内核架构、执行权限、工作目录与配置文件读取权限。
  4. 关闭 TUN 后测试 mixed-port，再检查 /dev/net/tun 和路由权限。
  5. 修复后只保留一种启动方式，避免两个实例重复加载同一配置。

修复后的验证清单

客户端不再闪退只代表进程能够运行，还需要确认代理链路、DNS 和规则行为都已恢复。建议按以下顺序验证，任何一步失败都先停在当前层，不要同时修改多个选项。

  • 客户端持续运行至少 5 分钟，日志中没有循环出现 error。
  • 7890 或自定义 mixed-port 处于监听状态，进程名称与当前内核一致。
  • 系统代理地址与 mixed-port 完全一致，例如 127.0.0.1:7890。
  • 切换到规则模式后，DIRECT、代理组和 MATCH 能按预期命中。
  • 订阅可以手动更新，更新后执行配置检查仍然通过。
  • 普通代理稳定后再启用 TUN，并观察虚拟接口、默认路由与 DNS 是否正常。
  • 重启操作系统后再测试一次，确认没有旧服务抢占 7890 或重复启动内核。

最有效的排查顺序是：先用终端保留错误信息，再测试配置，随后检查端口，最后处理 TUN 和应用数据。配置错误通常能通过行号定位；端口冲突能通过 PID 定位；TUN 故障可以通过关闭 TUN 隔离；内核问题则能通过版本命令和最小配置确认。每次只改变一个变量，才能知道哪项操作真正解决了启动闪退。

下载Clash 选择对应平台安装包