先区分界面退出、内核失败与后台运行
“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,也可能因安装方式不同而变化。
- 应用日志:查界面初始化、文件读写、服务通信与后台启动异常。
- 内核日志:查 YAML 解析、规则提供者加载、DNS 监听与端口绑定失败。
- 系统事件:若应用日志没有更新,按 Win + R 输入
eventvwr.msc,进入「Windows 日志」→「应用程序」,找同一时刻的错误,记录故障应用程序和故障模块名称。
macOS 的应用数据通常位于 ~/Library/Application Support/ 下,Linux 通常从 ~/.config/ 查起。具体目录仍应以客户端入口、应用标识和发行包说明为准,不要将 Windows 路径直接套用到其他平台。
按错误关键词归类,不追最后一行
先复现一次,再读取该次启动的第一条明确错误。后续的“无法连接内核”可能只是前面解析失败或端口冲突的结果。保留错误前后约 20 行,通常比只截一行更容易定位。
address already in use或bind:优先核对监听地址与端口。yaml、unmarshal、parse:优先核对配置语法、字段类型与合并结果。permission denied或Access is denied:检查具体被拒绝的文件、服务或设备操作。WebView2或系统事件中的运行时异常:进入界面运行环境排查,不要先改代理规则。
残留配置与损坏文件:备份后做最小启动
重装客户端后仍然闪退,常见原因是用户数据目录被保留。安装程序更新的是程序文件,不一定重置订阅索引、界面状态和覆写配置。处理原则是“隔离旧数据验证”,而不是直接删除全部文件。
完整备份,再隔离配置目录
- 通过托盘退出客户端。在任务管理器确认相关桌面进程已结束;若存在后台服务,还需按该客户端提供的方式停止服务。不要结束来源不明的系统进程。
- 将整个用户数据目录复制到独立备份位置。备份中可能含订阅地址与密钥,应限制访问权限。
- 将原数据目录重命名,例如在目录名后追加
.backup-20260915。保留原文件内容,便于恢复。 - 重新启动同一个客户端。通常会生成初始数据;先不导入订阅、不启用 TUN,只验证窗口和基础内核能否正常启动。
若全新数据可以启动,故障范围就收敛到旧配置或旧状态。若仍然退出,先保留新生成的日志,继续检查运行环境。不要马上把旧目录整体覆盖回来,否则会重新引入相同问题。
按订阅、覆写、TUN 的顺序恢复
先只恢复一份可信订阅,确认内核启动;再逐项恢复规则、配置合并与脚本,最后恢复 TUN 和服务设置。每完成一项就重启验证。订阅原文件能解析,不代表经过覆写后的最终配置仍然有效。
- YAML 缩进使用空格,不使用 Tab;检查列表项前的连字符和冒号后的空格。
- 留意端口字段误填文本、数组误写成字符串、策略组引用了不存在的节点或分组。
- 核对自定义规则末尾的策略组名称,确保与当前订阅完全一致。
- 迁移旧内核配置时,按当前 mihomo 支持情况检查字段;不能把旧版解析成功等同于当前版本兼容。
如需命令行复核,可对最终配置的副本执行内核配置测试。以下命令要求当前目录存在对应的 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 的路由竞争上,而不是继续清理订阅。
- 关闭 TUN,确认普通代理模式可以建立连接。
- 在客户端「设置」中核对服务模式状态,按当前版本提供的安装或修复入口处理。
- 暂时退出其他 VPN 或虚拟网卡接管工具,保留必要的企业网络软件设置。
- 重新启用 TUN,读取本次失败对应的首条服务或内核错误。
修复后的验收与复发记录
窗口能打开只是第一步。完成修复后,应验证内核、监听、配置恢复与退出后的网络状态。每次只恢复一个变量,才能知道故障究竟来自订阅、覆写、端口还是服务。
- 冷启动:正常退出后重新打开,确认窗口与托盘状态一致,日志没有重复启动错误。
- 配置加载:确认当前订阅、策略组和规则已加载,而不只是停留在初始空配置。
- 监听与请求:核对实际代理端口,再观察客户端连接记录中的目标、规则与策略组是否符合预期。
- TUN 单独验收:需要 TUN 时再启用,检查相关应用联网及 DNS 行为,不把“系统代理可用”当作 TUN 已通过验证。
- 退出恢复:退出后确认系统代理没有继续指向已关闭的本地端口。
如果仍然复发,整理客户端完整版本号、内核版本、系统版本、安装方式、复现步骤和脱敏日志。明确写出“全新数据目录是否复现”“关闭 TUN 是否复现”“端口监听者是谁”,比笼统描述“打开就闪退”更有诊断价值。安装与配置流程可继续参考使用指南,概念区别可查阅术语表。