Clash Verge 打开就闪退:日志位置、残留配置与端口占用的处理办法

针对启动即崩溃、托盘图标一闪而过等情况,讲清日志文件位置、损坏配置的清理方式、端口冲突与运行库缺失的排查。

先区分界面退出、内核失败与后台运行

“Clash Verge 打不开”可能对应三个不同故障层:桌面界面没有创建窗口、mihomo 内核启动失败、程序已在托盘运行但主窗口没有显示。端口占用通常先影响内核,不一定会让整个桌面进程退出。先确认进程状态,再决定处理配置还是修复运行环境。

本文以 Windows 上的 Clash Verge Rev 为主要排查对象。旧版 Clash Verge 与 Clash Verge Rev 并非同一维护分支,配置目录和菜单名称可能不同;不要仅凭桌面快捷方式名称判断版本。在能够打开窗口时,从「设置」→「关于」记录完整版本号,同时记录 Windows 版本、系统架构与最近一次修改。以下端口只是示例,实际值以本机配置为准。

可见现象先核对什么下一步
主窗口不见,托盘图标仍在后台进程与窗口状态从托盘重新打开窗口,避免连续启动多个实例
界面能开,内核提示启动失败内核日志、配置解析、监听端口先读首条错误,再处理配置或端口
进程出现后立即消失应用日志、Windows 应用程序事件检查运行时、权限及异常模块
窗口空白或一直加载界面运行时、前端与后台通信检查 WebView2 与应用日志

先恢复不依赖代理的网络路径

如果客户端退出后网页也打不开,先检查 Windows「设置」→「网络和 Internet」→「代理」→「手动设置代理」。确认代理确由该客户端设置、且对应本地监听已经停止后,关闭「使用代理服务器」。例如系统仍指向 127.0.0.1:7890,但没有程序监听该端口,遵循系统代理的应用就可能连接失败。

日志位置:先找到启动时刻的第一条错误

能够进入界面时,优先使用「设置」中的配置目录、日志目录入口;不同发行版的按钮名称可能略有变化。这比凭文件夹名称猜测更可靠。完全无法启动时,再从操作系统的数据目录定位。

Windows 常见数据目录

Clash Verge Rev 常见的用户配置根目录如下。按 Win + R,粘贴路径并回车;若不存在,打开 %APPDATA%,按文件夹修改时间查找实际安装分支。

%APPDATA%\io.github.clash-verge-rev.clash-verge-rev

该目录下通常可见 logs、profiles 以及若干 YAML 文件。日志子目录和文件名随版本调整,应按“刚才启动时间”排序查看;不要认定每个版本都有同名日志。旧版 Clash Verge 的数据目录可能使用 io.github.clash-verge.clash-verge,也可能因安装方式不同而变化。

macOS 的应用数据通常位于 ~/Library/Application Support/ 下,Linux 通常从 ~/.config/ 查起。具体目录仍应以客户端入口、应用标识和发行包说明为准,不要将 Windows 路径直接套用到其他平台。

按错误关键词归类,不追最后一行

先复现一次,再读取该次启动的第一条明确错误。后续的“无法连接内核”可能只是前面解析失败或端口冲突的结果。保留错误前后约 20 行,通常比只截一行更容易定位。

残留配置与损坏文件:备份后做最小启动

重装客户端后仍然闪退,常见原因是用户数据目录被保留。安装程序更新的是程序文件,不一定重置订阅索引、界面状态和覆写配置。处理原则是“隔离旧数据验证”,而不是直接删除全部文件。

完整备份,再隔离配置目录

  1. 通过托盘退出客户端。在任务管理器确认相关桌面进程已结束;若存在后台服务,还需按该客户端提供的方式停止服务。不要结束来源不明的系统进程。
  2. 将整个用户数据目录复制到独立备份位置。备份中可能含订阅地址与密钥,应限制访问权限。
  3. 将原数据目录重命名,例如在目录名后追加 .backup-20260915。保留原文件内容,便于恢复。
  4. 重新启动同一个客户端。通常会生成初始数据;先不导入订阅、不启用 TUN,只验证窗口和基础内核能否正常启动。

若全新数据可以启动,故障范围就收敛到旧配置或旧状态。若仍然退出,先保留新生成的日志,继续检查运行环境。不要马上把旧目录整体覆盖回来,否则会重新引入相同问题。

按订阅、覆写、TUN 的顺序恢复

先只恢复一份可信订阅,确认内核启动;再逐项恢复规则、配置合并与脚本,最后恢复 TUN 和服务设置。每完成一项就重启验证。订阅原文件能解析,不代表经过覆写后的最终配置仍然有效。

如需命令行复核,可对最终配置的副本执行内核配置测试。以下命令要求当前目录存在对应的 mihomo 可执行文件与 config.yaml;它测试配置,不会启动常驻代理。

.\mihomo.exe -t -f .\config.yaml

测试应尽量使用客户端实际调用的同版内核。含规则提供者或外部文件的配置还依赖工作目录和资源路径,因此命令行结果要与客户端日志一起看。不要把订阅原文件的测试结果,当作最终合并配置的测试结果。

端口占用:确认监听进程,再修改冲突项

常见冲突包括 HTTP/SOCKS 混合代理端口、控制接口端口,以及启用本地 DNS 后的 DNS 监听端口。下面用 7890 和 9090 演示查询;这不是所有 Clash Verge Rev 版本的默认设置。

Windows 查询 PID 与程序名称

在 PowerShell 中执行以下命令。第一条列出对应端口的 TCP 监听及其 PID,第二条在得到 PID 后查看程序身份;示例中的 4321 需要替换为实际查询结果。

Get-NetTCPConnection -State Listen -LocalPort 7890,9090 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id 4321 | Select-Object Id,ProcessName,Path

端口没有输出,只表示查询时没有匹配的 TCP 监听。DNS 或其他 UDP 冲突还需要检查 UDP,例如实际配置使用 1053 时:

Get-NetUDPEndpoint -LocalPort 1053 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess

若监听者属于另一个代理客户端,先正常退出该客户端及其后台服务。若属于当前客户端自己的内核,可能是重复实例或服务模式仍在运行;检查进程路径、启动时间和日志,不要见到 mihomo 就强制结束。权限不足时,查询结果中的程序路径可能为空。

修改代理端口后同步系统设置

确定必须并行运行时,可把其中一个客户端的混合端口从 7890 改为未被占用的 7897。修改应通过当前版本的设置入口或持久化覆写完成,避免只编辑下次启动会重新生成的文件。

端口变更后,重新开关一次该客户端的系统代理,并检查浏览器、命令行环境变量和其他应用中的手动代理地址。控制接口端口不能当作 HTTP 代理端口使用;把应用代理指向 9090,即使端口正在监听,也不代表能够正常代理流量。

运行库、权限与 TUN 服务的分层检查

界面在内核之前退出:检查 WebView2 与系统事件

Windows 版 Clash Verge Rev 的界面依赖 WebView2。若窗口空白、创建窗口即退出,且事件或日志指向 WebView2,可在 Windows「设置」→「应用」→「已安装的应用」检查 Microsoft Edge WebView2 Runtime。按微软官方安装器和当前客户端发行说明修复或安装,随后重新启动应用。

只有出现 VCRUNTIME140.dll、MSVCP140.dll 等明确缺失信息时,才进一步检查 Microsoft Visual C++ 2015–2022 Redistributable,并按报错程序的架构选择安装包。不要从 DLL 下载站单独复制文件,也不要把所有闪退都归因于同一个运行库。

普通启动成功、启用 TUN 才失败:检查服务层

TUN 模式涉及虚拟网卡、路由和较高权限;它与系统代理不是同一个开关。若关闭 TUN 后界面与内核都能正常运行,应将排查重点放到客户端服务、虚拟网卡初始化和其他 VPN 的路由竞争上,而不是继续清理订阅。

  1. 关闭 TUN,确认普通代理模式可以建立连接。
  2. 在客户端「设置」中核对服务模式状态,按当前版本提供的安装或修复入口处理。
  3. 暂时退出其他 VPN 或虚拟网卡接管工具,保留必要的企业网络软件设置。
  4. 重新启用 TUN,读取本次失败对应的首条服务或内核错误。

修复后的验收与复发记录

窗口能打开只是第一步。完成修复后,应验证内核、监听、配置恢复与退出后的网络状态。每次只恢复一个变量,才能知道故障究竟来自订阅、覆写、端口还是服务。

如果仍然复发,整理客户端完整版本号、内核版本、系统版本、安装方式、复现步骤和脱敏日志。明确写出“全新数据目录是否复现”“关闭 TUN 是否复现”“端口监听者是谁”,比笼统描述“打开就闪退”更有诊断价值。安装与配置流程可继续参考使用指南,概念区别可查阅术语表。

下载Clash平台与客户端选择