Clash Verge Rev 升级前，应该备份的不只是订阅链接，还包括本地覆盖配置、策略选择和当前可用环境。应用界面、代理内核和订阅内容都可能独立变化，升级后出现问题时，只有知道哪些层发生了变化，才能可靠回退。
先明确当前使用的是哪个项目
名称相近的客户端、旧项目和第三方打包版本可能有不同维护来源。应从 Clash Verge Rev 官方文档进入发布与说明页面，核对仓库和安装包来源。本文不把某个版本号永久称为最新版，也不假设未来版本继续采用当前菜单名称。
在升级记录中写下操作系统及架构、客户端版本、实际内核版本、安装方式和升级日期。如果官方提供校验信息，按官方方法核对下载文件。不要为了绕过错误，从陌生镜像下载安装包，之后又拿官方文档解释它的行为。
升级说明需要关注兼容性、权限、配置迁移和已知问题，而不只看新增功能。安全修复和破坏性变更影响不同：前者可能提高升级优先级，后者要求安排验证时间。是否马上升级，应根据自己的风险和使用场景决定，不能简单等同于追逐新版本。
备份的是可恢复状态
先确认官方支持的配置存储和备份方式，在客户端停止写入配置后再做一致性备份。不要凭文章猜测所有系统的目录位置相同。备份可能包含订阅令牌、节点认证和本地控制接口信息，应保存在自己控制的受保护位置，不能直接上传公开工单。
记录已启用的订阅、本地覆写和脚本。一个订阅文件并不一定包含界面保存的全部状态。尤其是自定义规则与全局扩展，要注明其作用范围、目标策略组和添加原因，避免迁移后看见规则存在却不知道是否生效。
也应保存一份脱敏的基线：正常访问任务、预期策略、关键日志和必要截图。这与备份文件用途不同，前者帮助判断是否退化，后者帮助恢复。只有备份没有验收标准，回退后仍可能不知道是否真正恢复到原状态。
把升级拆成两个阶段
先完成客户端升级并使用原有配置验证，再单独更新订阅或规则资源。这样可以区分程序变化和上游内容变化。升级流程可能自动更新部分资源，因此要实际查看记录，不要假设“我没点更新”就意味着所有数据都没变。
第一次启动先观察报错，再检查生效配置。不要一遇到问题就将规则模式换成全局，清空 DNS 并开启 TUN；这些操作会同时引入多个变量。对日志的正确脱敏方法见客户端日志指南。
示例场景中，升级后普通网页正常，但自己的办公域名走错策略。应检查本地扩展是否仍被应用、策略组名称是否改变、规则顺序是否保持，而不是马上认定内核连接性能下降。若节点根本无法建立连接，再调查握手参数和兼容性，两个问题不应混成一个结论。
回退要同时考虑配置格式
旧程序未必能读取被新程序迁移过的数据。回退之前保留新环境的故障记录，再依照官方说明恢复旧版本与对应备份，而不是只把一个旧可执行文件覆盖回去。不要让新旧程序同时写同一份配置目录。
如果回退后仍然失败，检查外部条件是否变化：订阅是否过期、节点是否维护、目标服务是否异常，以及系统权限是否已经改变。回退成功只是强化程序或配置变化相关的证据，仍不等于确认具体缺陷。
对有重要工作依赖的电脑，提前确定可接受的维护窗口和备用连接方式。备用方案应是事先验证过的正常方案，不是临时下载未知工具。不能为了回退方便无限期保留存在已知严重问题的软件，后续仍需关注官方修复和迁移建议。
用清单结束升级
检查启动、订阅读取、规则命中、DNS、局域网访问、系统代理或 TUN、退出后的设置恢复。选择自己实际使用的项目，不必为从未使用的特性制造大量测试。每项写下结果以及是否与基线一致。
本地覆盖层维护可继续阅读订阅与本地规则共存，当怀疑某项修改导致故障时，再采用单变量对照方法。把升级记录与这些配置说明放在一起，下次维护时就能看见来龙去脉，而不是依赖记忆。
升级结束后清理无效实验设置，保留必要备份和版本记录。若需要反馈问题，提供最小复现步骤、版本组合和脱敏错误，避免只写“升级不能用”。清晰的证据既能帮助维护者，也能帮助自己判断问题是否已经被下一次修复覆盖。
对自动启动功能也应单独验证。手动启动正常，并不能说明登录后服务启动顺序、权限和网络就绪时机都正常。可以在保存工作后重新登录系统，检查是否只有一个实例运行，并确认首次请求经过预期路径。若故障只在开机阶段出现，记录客户端开始运行、网络可用和错误发生的先后顺序，比反复重装更有定位价值。不要用延长随机等待时间来替代原因分析，除非已经明确知道所等待的资源是什么。
参考资料
- Clash Verge Rev 官方文档，核验日期：2026-10-15。备份与测试清单为编辑建议，具体迁移能力以对应版本说明为准。