本文目录
先确认是不是 GNOME 托盘菜单卡死
本文只处理 Linux 桌面在切换节点和代理组很多的订阅后立刻卡顿，且日志同时指向 GNOME Shell、Ubuntu AppIndicators、dbusMenu.js 或 GJS 垃圾回收的情况。只有 Clash Verge Rev 窗口变慢、节点超时或网页打不开，不属于同一问题。
Clash Verge Rev issue #7779 的报告环境是 Ubuntu 22.04.5、GNOME 42.9 与 X11，使用 347 个节点、14 个代理组且单组最多 349 个节点的订阅。普通订阅正常，切换到大型订阅约一秒后开始错误风暴和整桌面卡顿。
报告者把现象归因于托盘中生成的巨大代理组子菜单，并用同一系统、同一订阅做了 A/B 对照；禁用托盘代理组显示后不再复现。Issue 仍处于开放状态，这个解释是可重复的排查线索，不是维护者已经确认的普遍根因。
先按现象分流
| 现象 | 更可能的方向 | 下一步 |
|---|---|---|
| 切换大订阅后顶部栏、窗口切换和桌面一起卡顿 | GNOME Shell 或 AppIndicator 菜单负载 | 核对会话与系统日志 |
| 只有 Clash Verge Rev 窗口卡住 | 应用界面或 WebView | 不要直接套用本文结论 |
| 桌面正常，但网页和节点超时 | 节点、DNS、规则或 TUN | 按连接记录排查 |
| 未切换订阅也会周期性冻结 | 其他扩展、显卡或桌面问题 | 做关闭客户端的对照 |
先恢复桌面，避免再次打开巨大菜单
桌面仍能响应时，先不要点击托盘图标或反复切换 Profile。保存正在编辑的文件，从 Clash Verge Rev 主窗口关闭系统代理和 TUN，再正常退出客户端；确认系统直连可用后重启桌面会话或系统。
若 GNOME Shell 已基本无响应，但 Ctrl+Alt+F3 仍能进入文本终端，可登录后使用正常重启命令。强制断电可能损坏未写完的文件，只能作为键盘、终端和系统电源菜单都不可用时的最后选择。
sudo systemctl reboot重新进入桌面后
先保持系统直连
不要立即启用 TUN、系统代理或刚才的大型订阅，先确认桌面与基础网络稳定。
从主窗口打开设置
不要从托盘展开代理组菜单；直接打开 Clash Verge Rev 主窗口。
先改托盘显示模式
完成禁用设置后，才重新选择同一大型订阅做受控复测。
保留失败时间点
记下切换订阅和桌面开始卡顿的时间，后面只截取对应日志。
记录会话、版本与 AppIndicator 错误
先记录发行版、GNOME、会话类型和 Clash Verge Rev 版本，再导出故障前后几分钟的系统日志。X11 与 Wayland 的恢复方式不同，不能只写“Ubuntu 最新版”。
下面的查询只读取本次启动日志。若输出出现 ubuntu-appindicators、dbusMenu.js、JSAPI during、already disposed 或 PopupSubMenuMenuItem，并且时间紧跟订阅切换，才与 issue #7779 的模式接近。
日志可能含用户名、主机名、订阅或节点信息，公开前必须脱敏。只保留复现前后几分钟，不要上传完整系统日志。
printf 'session=%s\n' "$XDG_SESSION_TYPE"
gnome-shell --version
clash-verge --version 2>/dev/null || truejournalctl -b --no-pager | grep -E 'gnome-shell|ubuntu-appindicators|dbusMenu\.js|JSAPI during|already disposed|PopupSubMenuMenuItem'修改前基线
- 发行版、GNOME、X11 或 Wayland 会话类型已记录
- Clash Verge Rev 的实际版本与安装来源已记录
- 普通订阅不会触发同样卡顿
- 大型订阅的节点数、代理组数和最大组规模已记录
- 故障时间点与对应日志已保存并脱敏
- 系统代理和 TUN 关闭时桌面能够稳定运行
禁用托盘代理组菜单再切换订阅
在 Clash Verge Rev 主窗口进入“设置 → 界面设置”，把“托盘代理组显示模式”改为“禁用”。v2.5.2 的官方类型定义支持 default、inline 与 disable，中文设置资源也把这一项显示为默认、一级菜单和禁用。
这个改动只是不再把代理组和大量节点展开到系统托盘菜单；订阅、规则、节点和主窗口里的代理组仍然保留。之后从主窗口选择节点，不要为了确认设置而反复点击旧托盘子菜单。
若图形界面无法保存，可先从设置中的应用目录入口找到 verge.yaml，完整退出客户端并复制整个目录作为备份，再把 tray_proxy_groups_display_mode 明确设为 disable。不要猜测数据目录，也不要在应用运行时覆盖文件。
tray_proxy_groups_display_mode: disable用同一订阅完成四项验证
保持系统、客户端版本和订阅不变，只改变托盘代理组显示模式，然后从主窗口切换到原来会触发卡顿的大型订阅。这个单变量对照比同时删节点、换内核和关闭 TUN 更能说明问题。
切换后等待超过原来的触发时间，再打开主窗口的代理组完成一次节点选择和真实 HTTPS 请求。不要只看延迟数字；桌面响应、托盘结构、日志和真实连接都要通过。
验证清单
- 切换同一大型订阅后顶部栏、窗口切换和快捷键仍然响应
- 托盘菜单不再生成代理组与节点子菜单
- 日志没有新增成片的 dbusMenu.js、JSAPI during 或 already disposed 错误
- 主窗口仍能查看代理组并切换节点
- 真实 HTTPS 请求成功且 Connections 中能看到对应连接
- 完整退出并重新启动后禁用设置仍然生效
禁用后仍卡顿时重新分流
托盘子菜单已消失，但只有应用窗口无响应
检查 WebView、渲染和应用日志，不把它归因于 GNOME Shell 菜单。
关闭 Clash Verge Rev 后桌面仍周期性冻结
检查其他 GNOME 扩展、显卡与系统日志，本文规避不适用。
桌面正常，只有连接失败
转查节点、DNS、规则、系统代理或 TUN，不恢复巨大托盘菜单。
仍出现相同 AppIndicator/GJS 错误风暴
保留禁用设置，记录是否还有其他应用提供超大托盘菜单，并向项目提交完整对照。
不要先卸载 Ubuntu AppIndicators、删除大型订阅或重装整个桌面。它们会改变太多变量，也可能影响其他应用。先用关闭 Clash Verge Rev、普通订阅和禁用托盘代理组这三个对照，确认究竟是哪一步触发。
需要托盘切换时安全回退并提交证据
如果必须恢复托盘代理组菜单，先在主窗口切回已验证的小订阅，再把显示模式改回“默认”或“一级菜单”。不要在大型订阅仍生效时恢复菜单；若卡顿重现，立即回到 disable，并继续从主窗口选节点。
向官方反馈时，应提供发行版、GNOME 与会话类型、Clash Verge Rev 版本、订阅规模、触发时间、脱敏日志，以及 default 与 disable 的同条件结果。不要上传订阅链接、节点地址、认证信息或完整配置。
截至 2026 年 9 月 8 日，issue #7779 仍开放且没有关联的正式修复。报告使用的是 2.5.3 AutoBuild；官方最新稳定版仍是 v2.5.2。v2.5.2 已包含这个显示开关，但其发布说明没有宣称修复大型托盘菜单卡死，因此不能把设置存在写成问题已经解决。