配置实践 · Clash 技术博客

Clash Verge Rev 自动备份失效:重启后修复

Clash Verge Rev 重启后定时备份失效?先导出手动备份,升级应用至 v2.5.9,运行满间隔后以 ZIP 和 Scheduled 日志验证;WebDAV 或变更备份不算计划成功。

  • Clash Verge Rev
  • 定时备份
  • 本地备份
  • 重启
  • v2.5.9
本文目录

你已经开启定时备份,甚至保留了一些旧 ZIP,却发现重新打开 Clash Verge Rev 后,再也没有按间隔生成新文件。代理仍能使用、开关仍然亮着,都不能证明备份计划已经运行;先区分应用计时、手动备份与实际写入失败。

备份开关开着,为什么重启后一直没有新文件?

官方 issue #8331 的用户使用 Windows 11 与 Clash Verge Rev v2.5.8:设为每 1 小时备份,完整退出后重新启动,不改设置、保持设备唤醒超过 1 小时,仍没有自动归档,也没有对应 Backup 日志。

该用户改动设置后,再等待完整间隔才出现计划备份。这只是帮助识别问题的对照,不能把“每次启动后随便改一个设置”当成长期修复,也不需要为了排查反复改语言、代理或订阅。

本文依据这份 Windows 报告、共享备份代码和正式修复说明;没有把所有平台或所有旧版本都当成已实测受影响。v2.5.9 已正式修复本问题,单纯没有等满间隔或应用已经退出,应先排除正常计时条件。

三种备份要分开判断

看到的记录能说明什么不能说明什么
本地手动备份成功当前能创建一份本地归档重启后的定时计划已启动
文件名带 -auto-merge 或 -auto-script全局覆写或脚本变更触发了备份-auto-scheduled 的计划备份正常
WebDAV 上传成功本次服务器上传完成本地定时计划已运行或自动上传
新 -auto-scheduled.zip 与 Scheduled 成功日志这次定时任务确实创建了本地文件下次完整重启后仍一定正常

先手动备份,另存一份到应用目录之外

不要等下一次计划备份才保护当前配置。进入“设置 → Verge 高级设置 → 备份设置”,先在“本地备份”中点击“备份”,再打开“查看记录”,把刚生成的 ZIP 导出到应用数据目录之外。

确认导出的文件存在、能够打开,并检查 profiles.yaml、profiles/ 与自己的关键配置内容。ZIP 只是归档,不等于加密;订阅令牌、节点密码和本地覆写可能在里面,应保存在自己控制的受保护存储中。

如果手动备份也报错,先保存第一条错误并另外复制现有数据,查实际文件写入问题。不要把它直接归为重启后的计划缺陷,也不要清空应用目录、恢复旧 ZIP 或卸载程序来试探。

升级前留住这些内容

  • 一份能打开、已导出到应用目录之外的当前备份。
  • 客户端版本、备份开关、原备份频率和最后成功文件的时间。
  • 自己维护的外部文件、原始订阅地址与必要设置,分别安全保存。
  • 出现问题时的脱敏 Backup 错误;完整 ZIP 和订阅凭据不上传公开 issue。

修复在 v2.5.9 应用里,不是单独更新 Mihomo

官方 PR #8386 说明,旧实现先发送已保存的备份设置,再让计时任务订阅。没有接收者时,watch 通道的 send 不会保留新值;稍后启动的任务因此读到默认“未启用”,一直等待下一次设置变化。

修复把启动和刷新设置两处发送都改成 send_replace,让稍后启动的任务也能读到已保存的值。该修复已合并,并列入 2026 年 11 月 2 日发布的正式版 v2.5.9;不是只看到 issue 关闭或开发分支修改就认定已发布。

这是 Clash Verge Rev 应用的备份调度问题。只升级 Mihomo 内核、重新拉取订阅或重启内核,都不能代替更新应用。已经使用另有该修复证明的后续正式版时,不必为本文退回 v2.5.9。

定时备份由应用内的计时任务创建本地文件,不是操作系统中独立常驻的备份服务,也不是每天某个钟点执行的日历任务。完全退出应用期间,不要期待它继续生成文件或承诺重开后补齐漏掉的备份。

从官方发布页更新,保留现有配置

本文已核对的正式修复版本是 Clash Verge Rev v2.5.9。升级目标请使用正文参考资料中的官方 v2.5.9 Release,按自己的系统和芯片架构选择;本次维护没有同步本站托管安装包,旧 v2.5.8 镜像不能当作修复包。

按原安装方式完成应用更新

  1. 保存外部副本,再准备官方更新

    保留上一节导出的 ZIP、当前数据和外部文件。使用项目支持的正式更新方式,保持原有安装位置;不混入便携目录、开发版或来源不明的包。

  2. 在可以中断连接时正常退出并安装

    先保存工作,按客户端支持的方式停止系统代理或 TUN,再从托盘完整退出应用,按平台的正常安装流程更新。不要仅关闭窗口、手工替换内部内核或删除应用数据。

  3. 重开后确认应用版本和原配置

    在设置中查看完整应用版本,确认 v2.5.9 或有对应修复证据的后续正式版正在运行。核对 Profile、覆写、原代理模式,并恢复所需连接,不能只凭安装窗口消失判断完成。

如果官方安装包无法取得或安装报错,保留现有可用环境和错误,先处理对应的获取或安装问题。不要关闭签名检查或安全防护,也不要把网站上旧包的可下载状态当成这次更新成功。

重启后等满间隔,再查 ZIP 和日志

在“备份设置 → 自动备份”中核对“启用定时备份”和“备份频率”。固定 v2.5.9 代码的默认频率是 24 小时,允许 1至168 小时。为了观察可以临时选 1 小时,记下原值;保存后完整退出并重新打开一次。

从这次重新打开开始计时,保持应用运行、设备唤醒,期间不改设置、不重启,也不靠编辑全局覆写或脚本触发其他备份。等待超过一个完整间隔;没有刚启动就生成文件,不能据此判断失败。

应用重启或设置通知会重新开始等待完整间隔。频繁保存设置可能不断推后观察时间;这与备份开关明明开启、长时间不改设置仍不执行,需要分开判断。

到期后到“本地备份 → 查看记录”检查新文件,并核对日志中的 Auto backup created (Scheduled)。计划归档的文件名带 -auto-scheduled.zip;只看到 -auto-merge、-auto-script 或手动文件,不算这次验证完成。

确认重启后计划确实恢复

  • 实际运行的应用版本包含 #8386 修复,定时开关开启,频率已记录。
  • 完整退出并重开后,没有再改设置,连续运行超过一个完整间隔。
  • 出现时间对应的新 -auto-scheduled.zip 和 Scheduled 成功日志,归档能打开,配置内容符合当前状态。
  • 下一次正常重启后,按相同条件再检查一次;一次成功不代替重启后的验证。
  • 把临时频率恢复到原值或自己需要的频率,保留外部副本;保存后下一次等待会重新开始。

固定代码只保留最近 20 份带 -auto- 标记的自动归档,计划与全局覆写、脚本触发的文件共用这个数量,不是各保留 20 份。本地目录不是永久历史库,已确认可用的备份仍应单独导出。

本站没有在真实 Clash Verge Rev 客户端上等待一小时或执行恢复实验。以上是依据官方用户报告和固定源码制定的验收步骤;本站页面、翻译与构建检查通过,不能代替你设备上的计划备份验证。

仍不执行时,先分清手动备份能否创建

手动备份也失败

保留第一条写入错误和当前数据副本,检查错误指向的路径、权限或空间;不要持续切换定时开关掩盖真正的文件写入故障。

手动成功,计划仍无新文件

核对应用版本、开关、最后一次启动或保存设置的时间,以及是否连续运行满间隔。保存对应日志,不只反馈“开关开了没用”。

只有 WebDAV 上传失败

按服务器地址、认证和上传错误另查;本地 Scheduled 归档已经产生时,不能据此认定本题修复无效。

升级后应用或原配置不可用

停止继续修改,另存当前状态和首次错误,再按项目支持的方式使用升级前安全可用的程序与匹配外部副本恢复。

仅仅定时任务失败时,继续手动创建并导出备份,不要为测试计划而恢复覆盖当前配置。确实需要回退应用或恢复数据时,先完整退出,保留升级前后两份独立副本;不要让新旧程序争用唯一数据目录。

旧应用可能仍有本题缺陷,回退只是应急,不等于修好自动计划。恢复程序与数据后,核对原 Profile、覆写、代理模式和真实连接;手动备份仍要另存,计划是否恢复则按上一节重新等待验证。

向官方反馈时,提供系统、完整应用版本、原频率、启动与保存设置的真实时间、手动结果、计划文件名和第一条脱敏错误。不要上传整份 ZIP、订阅链接或凭据,也不要把其他平台没有执行过的验证写成已通过。

参考资料