Clash Verge Rev 核心崩溃：启动报错与日志定位

获取首个错误

打开应用日志，定位第一次出现的 error 或 panic，而不是最后一条“退出”。记录核心版本、系统版本与配置更新时间。

常见修复

1. 退出程序，备份配置目录后恢复为最小配置。
2. 检查 YAML 缩进、重复端口和未知字段；尤其注意粘贴时的全角冒号。
3. 让应用重新下载官方核心，确认安全软件没有隔离可执行文件。

仍然崩溃

用空白配置能启动而订阅配置不能，说明问题在配置内容；逐段恢复规则以定位。不要从不明来源下载“修复核心”。

别把“核心通信错误”等同于“核心崩溃”

Clash Verge Rev 的公开问题 #7477 报告过一种相反情况：核心实际已启动、端口在监听且流量可以转发，但前端仍显示 core communication error、代理列表为空。因此首要证据是进程、监听端口和日志的时间顺序，而不是 UI 文案。

Windows 可先执行下列只读检查（将端口替换为自己的 mixed-port）：

Get-Process | Where-Object { $_.ProcessName -match 'verge|mihomo' }
Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -eq 7890 }
Get-Content "$env:APPDATA\io.github.clash-verge-rev.clash-verge-rev\logs\*.log" -Tail 120

脱敏后的日志应保留版本、时间和错误类型，例如：

INFO  core launched pid=[pid]
INFO  mixed proxy listening at 127.0.0.1:[port]
ERROR frontend cannot reach core control channel

若监听存在且手动代理可工作，优先按“前端/服务模式控制通道”处理：更新到维护版本、退出服务模式后复测、提交可复现日志。若进程在首个配置解析错误后退出，才回到 YAML 字段与核心版本兼容性检查。

诊断范围

“Clash Verge Rev 核心崩溃：启动报错与日志定位”应先按可观察现象缩小范围：解决 Clash Verge Rev 打不开、核心反复退出、配置加载失败的基础检查流程。 记录发生时间、使用的客户端与系统版本、是否仅在某个网络或某个配置下发生。不要从单次测速、单个节点或一次重试直接推断根因，也不要在未备份配置时同时修改多个开关。

操作步骤

1. 保留错误提示的非敏感部分，并记下当前客户端、系统、网络类型和最近一次成功时间；订阅链接、账号、令牌和个人网络标识不得写入截图或工单。
2. 在受控条件下只改变一个变量，例如切换已知可用的网络、恢复一份已导出的配置，或暂时停用可能重复接管流量的另一个客户端；每次改动后回到同一个操作复测。
3. 将结果归为“现象消失、现象不变、出现新错误”之一。前两类分别保留变更前后记录；出现新错误时立即恢复上一步，而不是继续叠加 DNS、代理模式、内核或系统权限改动。

验证与回退

完成调整后，以原始失败动作连续复测，并确认目标功能恢复而不是只看到界面状态改变。若复测失败，回退到已导出的配置或原先已知可用的客户端状态，再依据记录选择下一项检查。任何无法解释的证书、权限、路由或账户提示都应停止扩大改动范围并转交产品或网络管理员。

来源与适用边界

本页的“证据与参考”只用于说明已公开的配置说明或个案范围；它不能证明你的网络、账号、节点或服务端当前处于同一状态。将日志中的令牌、订阅地址、账户资料和网络标识删除后再用于比对。