Clash Verge Rev 配置丢失怎么办？Profile 恢复与备份

本文只处理一类明确现象：Clash Verge Rev v2.5.2 原本已有订阅、本地 Profile 或全局 Merge/Script，正常退出、关机或重启后再次打开，配置列表突然只剩少量项目，原来的覆写也可能恢复为空模板。

官方 issue #7577 记录了 macOS 启动时 32 个 Profile 文件被删除 30 个；issue #7804 记录了 Fedora 正常关机后的下一次启动删除 20 个文件中的 18 个，后续评论还出现 Windows 与 macOS 报告。这些记录都指向启动阶段的孤儿文件清理，而不是订阅服务同时清空了所有节点。

先打开应用日志，查找 Removed file、Profile 文件清理完成，以及一次启动中异常大的删除文件数。若磁盘中的 Profile 仍在、只是代理页空白，应先排查内核通信；若文件存在但报 Invalid YAML，先修格式或字段；若只有一个订阅更新失败而其他 Profile 仍在，也不要直接恢复整份应用备份。

恢复动作会把归档中的 config.yaml、verge.yaml、profiles.yaml 与 profiles 目录重新写入应用数据目录。先复制当前整个目录和 clash-verge-rev-backup 子目录到另一个位置。

哪怕当前目录看起来已经不完整，也要先保留副本。这样恢复选错备份或旧配置覆盖新改动时，还有原始现场可退。

普通安装通常把数据放在系统数据目录下的 io.github.clash-verge-rev.clash-verge-rev 文件夹；便携版则放在程序旁的 .config 目录。若不确定，以客户端设置中的应用目录入口为准，不要凭相似文件夹名称删除数据。

Clash Verge Rev v2.5.2 的本地备份位于应用数据目录中的 clash-verge-rev-backup。自动备份文件名可能带有 -auto-scheduled、-auto-merge 或 -auto-script。

issue #7804 的报告者就是从三天前的 auto-script ZIP 找回全局脚本。

官方 v2.5.2 备份实现会把 profiles 目录、config.yaml、verge.yaml、可选 DNS 配置和 profiles.yaml 放进同一个 ZIP。

不要只看到 ZIP 能打开就直接恢复：先复制一份，再检查归档同时存在 profiles.yaml 与 profiles/，并选择故障发生前、又尽量新的时间点。

保持系统代理和 TUN 关闭，打开设置中的“备份设置”，在“本地备份”下选择“查看记录”。找到故障前的备份，先使用导出按钮另存一份，再点击恢复并确认。官方界面在恢复完成后会重启应用。

如果 ZIP 已经移到其他位置，先使用“导入备份”把副本加入本地备份列表，再从记录中恢复。不要把 ZIP 直接解压到正在运行的应用目录；内置恢复会在写入后重新加载 config、profiles 与界面设置，手工覆盖则容易让磁盘文件和内存状态不一致。

没有可用 ZIP 时，不要编造 profiles.yaml 引用或随意改随机文件名。先从保存的订阅 URL 重新导入远程 Profile；本地手写配置则从故障前复制出的 profiles 文件中逐个辨认，在新建本地 Profile 后粘贴内容并让客户端重新生成索引关系。

全局 Merge.yaml 与 Script.js 若仍有旧副本，应先在离线副本中比较，再通过客户端的全局扩展编辑入口恢复。只有备份中没有旧内容时才重新编写；不要从公开截图反推其中可能含密钥或内部域名的完整规则。

如果订阅 URL 也丢失，应到原服务提供方重新获取或重置，而不是从浏览器历史、公开日志或他人的配置中拼接 token。恢复一个来源后就保存一次状态，避免一次性导入所有内容后无法定位哪一步出错。

应用重启后先不要立刻开启 TUN。核对 Profile 数量、名称、类型与当前选中项，再分别打开 Merge 和 Script，确认关键规则不是空模板。远程订阅应能手动更新，本地 Profile 应通过配置校验。

随后固定一条已知可用节点，仅开启系统代理完成一次真实 HTTPS 请求，并在连接记录中确认域名、规则和出站。最后完整退出并重新打开一次，再核对 Profile 数量与日志；只有第二次启动也没有异常删除，恢复才算稳定。

若恢复后应用无法启动、Profile 数量更少或新配置校验失败，先关闭应用，不要连续尝试多个 ZIP。把这次恢复后的应用数据目录另存一份，再用最初保存的现场副本恢复到修改前状态。

设备必须先保持 TUN 与系统代理关闭。回退后如果客户端仍不可用，可以暂时不启动它，保留日志、备份 ZIP 与目录副本，再在官方 issue 中提交脱敏的版本、系统、删除计数和首条错误。不要为修复配置而卸载虚拟网卡、重置整个系统网络或删除所有应用数据。

2026 年 9 月 2 日，维护者在 issue #7804 中确认提交 44f6f6e 已移除不可靠的清理逻辑并关闭问题。该提交标题为“preserve files until explicit deletion”，代码直接删除了启动时 cleanup_orphaned_files 的调用和整套自动删除实现。

截至 2026 年 9 月 3 日，官方 Releases 中最新稳定版仍是 2026 年 7 月 19 日发布的 v2.5.2，发布说明没有包含这项后续修复。因此不能把“issue 已关闭”写成“v2.5.2 已修复”，也不应仅为规避风险把日常设备切到开发构建。

稳妥做法是先完成备份和恢复，减少不必要的重复启动，等待官方发布明确包含 44f6f6e 的稳定版。新稳定版发布后仍要保留当前备份，核对 Release，再用完整退出、重启和真实连接做一次回归验证。

恢复完成后，在备份设置中开启定时本地备份，并保留“关键变更时自动备份”。v2.5.2 的实现会在计划时间以及全局 Merge/Script 变更后创建归档，自动归档最多保留 20 份。这个数量限制意味着本地目录不是永久历史库。

至少再把一份已验证 ZIP 导出到应用数据目录之外，或配置自己控制的 WebDAV。每次大改订阅覆写、迁移客户端或升级前手动创建并导出一份；恢复演练时只在有回退副本的前提下进行。