Clash Verge Rev 代理菜单空白内核通信失败排查

打开 Clash Verge Rev，首页弹出“内核通信错误”，切到代理页面一片空白，节点列表什么都看不到，但系统代理开关还亮着——浏览器也确实能通过代理上网。这种“能用但看不到”的状态最容易让人误判成节点或订阅出了问题。Clash Verge Rev 代理菜单空白的根源通常不在订阅本身，而在于 GUI 与 Mihomo 内核之间的 IPC 命名管道断了。Clash Verge Rev 只是一个 GUI 壳，真正处理流量的是一旁的 Mihomo 内核进程，两者之间靠一条 IPC 命名管道通信。界面能看到什么、能操作什么，全依赖这条管道通不通。管道断了，界面就变哑巴。

01. 先看日志，确认代理菜单空白是哪条管道断了

Clash Verge Rev 的 IPC 通信涉及两个层面：一是 GUI 与系统服务进程之间的通信（Windows 上叫 clash_verge_service），二是 GUI 与 Mihomo 内核之间的通信（命名管道 \\.\pipe\verge-mihomo）。不同层面的故障，日志给出的错误信息不一样。

打开左侧菜单的“日志”页面，把日志级别切到 debug，然后重启一次客户端。关注以下三组关键词：

第一组：IPC path not ready 或 Some issue with service IPC Path。 这是 GUI 连不上系统服务。日志里通常会跟上具体的系统错误码，比如 系统找不到指定的文件 (os error 2) 或 所有的管道范例都在使用中 (os error 231)。前者说明服务根本没启动或路径不匹配，后者说明管道被其他进程占用，服务进程在等一个永远等不到的连接。

第二组：Failed to connect to named pipe: \\.\pipe\verge-mihomo。 这说明系统服务没问题，但 GUI 连不上 Mihomo 内核。通常是内核进程没起来、启动太慢、或者启动后又崩了。

第三组：Mode Description Not Available 或代理模式显示异常。 这是 IPC 通了但数据读取不完整的表现，说明命名管道建立了连接，但内核的代理信息还没准备好就被 GUI 拉取了。

日志里报错的时间戳很重要。如果错误集中出现在启动后的前 1-2 秒内，基本可以判定是启动竞态；如果错误持续存在直到手动重启才恢复，则是服务注册或路径层面的问题。遇到 Clash Verge Rev 代理菜单空白时，先别急着换订阅，把日志里的错误码和路径看全，后面的排查方向就清晰了。

02. 启动竞态：内核还没准备好，GUI 已经去敲门了

Clash Verge Rev 的启动流程是：GUI 启动 → 拉起 Mihomo 内核（Sidecar 模式）或通知系统服务启动内核 → GUI 通过命名管道向内核查询版本、配置、代理列表和代理提供商信息。问题出在第三步——GUI 在拉起内核后立刻就去查询，如果此时 Mihomo 还在解析 YAML 配置文件、或者还没来得及创建命名管道，首次请求就会失败并抛出 os error 2。

这个竞态的典型特征是：开机自启时出现概率远高于手动启动。因为开机时系统资源紧张，内核解析配置的速度被拖慢，而 GUI 的启动流程不会等。部分代理页面的数据在这种状态下无法自动恢复，即使内核后续正常运行，代理组视图也会一直保持空白。

社区贡献者提交的修复方案（PR #7334）为 getVersion 查询增加了重试机制，并在 AppDataProvider 中引入了启动恢复循环——当核心数据缺失时自动重新拉取配置、代理和代理提供商信息。

如果你使用的版本尚未包含此修复，手动绕开竞态的方法是：关掉 TUN 模式，先以系统代理模式启动。系统代理模式下内核的初始化流程更轻，启动更快，命名管道能在 GUI 首次查询前就绪。等界面正常显示后，再切回 TUN 模式。另外，在设置中关闭“开机自启”，改为登录后手动启动，也能大幅降低触发概率。

03. 命名管道被占：os error 231 的处理

代理菜单空白如果伴随日志中的 所有的管道范例都在使用中 (os error 231)，说明命名管道确实创建了，但已经被占满了。Windows 命名管道有一个“最大实例数”的限制，如果前一个 Mihomo 进程异常退出但没有正确释放管道句柄，后续的 Mihomo 进程就无法创建新的管道实例，GUI 自然连不上。

处理方式很直接：彻底清理残留进程。从托盘图标右键退出 Clash Verge Rev，然后打开任务管理器（Ctrl + Shift + Esc），在“详细信息”标签页中找到所有名为 verge-mihomo.exe、clash-verge-service.exe 的进程，逐个结束。如果不确定是否清理干净，以管理员身份运行 PowerShell 执行：

Get-Process | Where-Object { $_.ProcessName -like "*mihomo*" -or $_.ProcessName -like "*clash-verge*" } | Stop-Process -Force

清理完后等待 3-5 秒让系统回收管道句柄，再重新启动 Clash Verge Rev。

如果每次重启都会出现 os error 231，检查是否有其他代理软件（v2rayN、Sing-box、Surge 等）在后台运行。多个代理工具同时尝试绑定相同的命名管道或端口时，管道实例会被抢占。

04. 服务模式安装不完整：IPC 路径不匹配

如果你在用 TUN 模式或服务模式，os error 2 的根源往往不在内核本身，而在系统服务。Clash Verge Rev 在 Windows 上注册的服务名为 clash_verge_service，GUI 通过一个固定路径的命名管道与服务通信。服务在安装时将管道路径写入注册表，如果后续升级了软件版本、或者安装目录发生了变动，旧的服务注册信息仍然指向老路径，GUI 就连不上了。代理菜单空白在这种场景下会持续存在，直到服务注册被重置。

Linux 上也有类似的问题。有用户报告从 v2.4.2 升级到 v2.4.3+ 后，clash-verge-service-ipc 将 socket 创建在 /tmp/clash-verge-service-ipc-test/service.sock，但 GUI 却去 /tmp/verge/clash-verge-service.sock 查找——两个路径不匹配，GUI 超时后误判服务未安装。

诊断方法（Windows，以管理员身份运行 PowerShell）：

Get-Service -Name clash_verge_service

如果服务状态显示 Stopped，或者直接报找不到服务，而日志里确实出现了 IPC path not ready 或 os error 2，就是服务残留问题。

修复步骤：彻底退出 Clash Verge Rev，到安装目录的 resources 文件夹中以管理员身份运行 uninstall-service.exe，清除旧的服务注册。重启电脑后，重新以管理员身份打开 Clash Verge Rev，在“设置”页面重新安装服务模式。Linux 用户可以先手动创建符号链接临时恢复（sudo mkdir -p /tmp/verge && sudo ln -sf /tmp/clash-verge-service-ipc-test/service.sock /tmp/verge/clash-verge-service.sock），但根因需要等待官方修复版本。

05. 防火墙拦截与代理页面空白的区分

Windows 防火墙在部分更新后会重新评估网络规则，把 verge-mihomo.exe 的入站连接标记为可疑并拦截。表现是：GUI 能启动，内核进程也在运行，但 IPC 通信被防火墙阻断，代理页面空白。

修复方式是打开 Windows 防火墙设置，在“允许应用通过防火墙”列表中找到 Clash Verge Rev 相关的条目，全部勾选“专用”和“公用”网络。如果列表中没有，手动添加 verge-mihomo.exe 和 clash-verge-service.exe 的完整路径。

还有一种情况容易被误判：订阅本身有问题。代理页面空白和订阅未激活是两个不同的现象。如果“订阅”页面中的配置文件卡片旁边没有绿色勾选标记，说明订阅未激活。双击卡片激活后，代理页面会自动刷新。如果卡片有绿色标记但代理页面仍然空白，才是内核通信层面的问题。排查到这里如果还没解决，可以参考 TUN 模式完全指南 中的服务模式与内核启动顺序说明，或者到 FAQ 页面 搜索更详细的错误关键词。