TL;DR：Clash Verge 开机自启失效，不要第一步就重装。先确认系统层面的登录项是否存在，再区分「托盘应用没启动」和「Mihomo 核心没接管」。这两个问题看起来一样，修法完全不同。
我排这类问题时，会先问一个简单问题：登录桌面后，Clash Verge Rev 的窗口或托盘有没有出现？如果完全没出现，重点查启动项和系统权限；如果托盘出现但没有代理能力，重点查 Service Mode、核心日志、端口和 profile。
先分清三种启动
| 启动类型 | 依赖条件 | 典型问题 |
|---|---|---|
| 图形界面自启 | 用户登录会话 | 登录项没写入、被系统拦截 |
| Service Mode | 系统服务权限 | 服务未安装、权限不足、核心路径变了 |
| TUN/系统代理恢复 | 核心启动后执行 | 端口占用、配置解析失败、上次状态未保存 |
只打开客户端里的「开机启动」开关，不等于三件事都完成。尤其是 Windows 和 macOS，应用升级后路径变化，旧登录项还在，但指向的可执行文件已经不存在。
Windows：先看启动应用，再看服务
Windows 上先打开「任务管理器 → 启动应用」或系统设置里的启动应用列表，确认 Clash Verge Rev 处于启用状态。若列表里没有，回到 Verge 关闭开关再打开一次，让它重新写入。
如果托盘能出现，但开机后没有自动接管，再检查 Service Mode：
- 在 Verge 设置里查看 Service Mode 状态。
- 若显示未安装或异常，先卸载服务，再重新安装。
- 打开日志，确认 Mihomo core 是否启动成功。
- 检查 mixed-port、external-controller 等端口是否被其他进程占用。
不要一边改订阅、一边改服务。先用一份能手动启动的 profile 做测试，确认自启链路本身是通的。
macOS：登录项和后台项目分开看
macOS Ventura 之后，「登录项」和「允许在后台」经常让人混淆。Clash Verge Rev 作为图形应用，需要在登录项里出现；如果还启用了服务能力，还要允许相关后台项目运行。
排查顺序：
- 系统设置里确认登录项存在。
- 删除旧登录项，重新从 Verge 内部打开自启。
- 检查应用是否从 DMG 里直接运行过；应拖到 Applications 后再设置。
- 如果升级后失效，重新授权后台项目。
macOS 的另一个常见坑是权限继承。把应用从下载目录、外置盘或同步盘运行，再迁移到 Applications，登录项可能留下旧路径。删掉重建比反复点开关更快。
Linux：看桌面自启动和 systemd
Linux 桌面环境通常靠 ~/.config/autostart/ 下的 .desktop 文件启动图形界面。先确认文件存在，里面的 Exec= 路径能直接执行。
如果你用 systemd user service 管 Mihomo core，要分开验证：
systemctl --user status mihomo
systemctl --user enable mihomo图形界面自启失败，不代表 user service 失败；反过来也一样。日志里如果出现配置文件找不到，多半是工作目录、相对路径或权限问题，不是核心本身坏了。
登录后失效的四个细节
第一，profile 路径要稳定。把配置文件放在临时目录、下载目录或会被清理的同步目录，开机后很容易读不到。
第二，端口不能冲突。上次异常退出后，另一个代理客户端还占着端口，Verge 会启动界面，但核心无法监听。
第三，系统代理状态不等于核心状态。开机后系统代理被恢复了，核心没起来，会表现成全局网络异常。
第四，管理员权限不要常态化。每次都靠管理员权限启动，说明服务安装或配置目录权限有问题；应修服务，而不是长期右键运行。
如果你需要重新导入一份多端可用配置，可以用兼容 Clash / Singbox / V2Ray 的订阅，但排查开机自启时先用最小 profile，避免把配置问题和启动问题混在一起。
最小验收
修完后重启一次，不要只注销。登录桌面后检查三件事：托盘出现、核心日志无报错、系统代理或 TUN 状态符合预期。再打开一个普通网页和一个需要规则命中的目标，看日志里是否命中对应策略。只有这一步通过，才算自启链路真的恢复。