Clash Verge Rev
一次成功的升级，不只是“新窗口能打开”。原来的配置、订阅、规则与必要网络功能应该继续工作，并且在发现回归时有明确的恢复路径。最稳妥的顺序是：建立基线、保存可用快照、安装匹配版本、验证关键场景，最后决定是否保留新版本。
本文是面向 Windows、macOS 和 Linux 桌面用户的维护流程，不承诺跨越任意版本都能直接降级。官方发布说明中的迁移要求优先于通用建议；工作电脑或远程维护主机应先与管理员约定维护窗口，避免在唯一的远程连接上试错。
一、先分清需要恢复的三类东西
- 程序与运行组件：安装包、客户端版本、内核版本及相关运行环境。保存旧安装包并不等于保存了配置。
- 用户数据：订阅记录、本地配置、覆写或脚本、自定义规则及应用设置。重新下载同一份订阅不一定能找回本地修改。
- 系统状态：系统代理、TUN 或服务模式、DNS、自启动与必要权限。这些状态不一定包含在应用导出的文件里。
因此，“我有一个 YAML 文件”和“我能恢复整个工作环境”不是同一件事。先列出自己实际依赖的功能，再决定需要保留哪些数据和状态；没有使用的功能不必为了测试而开启。
二、升级前完成五项检查
- 记录当前正常工作的客户端版本、内核版本、系统版本和处理器架构。
- 在当前版本运行一次日常关键流程：订阅可读取、规则命中符合预期、所需应用能访问目标。
- 阅读目标版本发布说明，检查系统要求、已知问题、迁移提示和安全修复。
- 确认安装来源与既有管理方式。使用包管理器安装时，先了解它的升级、版本保留和降级机制，不要随意混用多个渠道。
- 准备可用备份与受信任的恢复安装包，安排不会影响重要工作的时间。
下载时明确区分 Windows x64/ARM64、macOS Apple Silicon/Intel，以及 Linux 的发行版包格式与架构。不要仅根据文件名里的“64”判断。有关当前平台要求，参见项目安装文档与本站下载页。
三、制作真正可用的离线快照
先从当前版本设置或官方说明确认正在使用的数据目录；如果界面提供打开配置目录入口，优先从该入口定位。不要根据网上另一种安装方式的固定路径猜测，也不要把程序安装目录误当作用户数据目录。
- 记录目录位置及需要恢复的设置。如使用应用内导出，先确认它究竟包含哪些内容。
- 正常退出应用，确认相关配置不再写入，再把需要保留的数据复制到单独的带日期目录。不要强行终止不相关系统服务。
- 打开备份副本中的几个关键文件，核对目录结构、文件数量及自己的自定义规则是否存在；如使用归档或加密容器，确认能够解锁和读取。
- 把恢复说明与版本记录放入备份，但不要将完整订阅 URL 或口令放进公开笔记。
备份可能包含节点凭据、订阅令牌、控制密钥或同步凭证。请限制访问权限，使用可信的加密存储，不要上传到公共 Git 仓库、论坛或未确认保护措施的网盘。仅能看到文件名不等于已经验证备份可恢复。
四、核对安装包来源，不绕过安全告警
从项目官方发布记录或可信管理渠道取得目标版本，核对发布者、版本、架构、包格式与文件大小。若官方提供校验值或可验证的签名，再按其说明核对；自己计算一个哈希只能描述手里的文件，不能独立证明来源可信。
Windows 的运行环境问题应先查项目 FAQ；macOS 出现安全提示时先核实来源与系统说明，不要把关闭系统安全检查当成安装步骤；Linux 应通过与现有发行版匹配的包管理流程处理依赖。不要执行来源不明的“一键修复脚本”。
五、安装后按固定清单验收
安装完成后先保留原备份，不要立即覆盖它，也不要同时刷新所有订阅和重写规则。确认实际运行的是目标版本，而非旧快捷方式指向的另一份安装。
- 启动与数据：应用可正常启动；本地配置、订阅记录和必要覆写仍在；日志没有持续加载或解析错误。
- 规则：分别验证一个应直连的目标和一个按自己配置应使用代理的目标，检查实际命中记录。
- 原应用：复测升级前记录的日常应用，而不只是内置延迟测试。
- 所需模式：只验证原本需要的系统代理、TUN 或服务模式，检查权限和日志；不需要的模式不必开启。
- 生命周期：关闭后重开客户端，再测试一次；在维护窗口内验证网络重连或休眠恢复。
- 退出恢复：正常退出并核对系统代理等设置是否符合预期，避免留下指向已停止监听端口的配置。
保留每项结果，而不是只写“升级成功”。浏览器、工作应用与网络重连全部通过后，再把新版本视为当前稳定基线。
六、什么时候回退，什么时候先排查
如果只有某个远端网站失败，先对照其他目标和网络状况；时间上的先后不能单独证明版本回归。若启动失败、配置持续解析错误，或同一配置与同一环境下关键功能稳定复现故障，则可以评估回退。
回退之前保存新版本的脱敏日志和当前数据副本。若旧版本存在已知安全问题，不应为了恢复便利而长期停留，应寻求修复版本或暂时采用不触发问题的受支持工作方式。
七、安全回退的顺序
- 停止继续修改新版本配置，记录故障与回退原因。
- 正常退出应用，保留升级后的数据副本，避免丢失升级后新增的内容。
- 检查发行说明和安装渠道是否允许降级。若格式已迁移，不能假设旧程序可以读取新数据。
- 使用可信旧安装包或相应包管理器流程；只有在支持的恢复方式下，恢复与旧版本匹配的升级前快照。
- 按上一节同一份验收清单复测，确认恢复而不是“看起来能打开”。
不要把旧备份和新配置目录随意叠加，也不要先删除整个数据目录再尝试。没有升级前备份时，不应保证无损回退；优先保留全部现有数据，寻求项目支持，必要时在受支持的独立环境验证最小配置。
八、保存一张不含秘密的维护记录
维护时间与时区：
原版本 / 目标版本 / 内核版本：
系统 / 架构 / 安装渠道：
备份位置与读取验证：
基线测试与升级后结果：
是否回退 / 原因 / 恢复结果：假设案例：升级后本地规则不见了，但订阅仍能更新。直接再次下载订阅并不能证明这些规则会回来；应先检查旧配置、覆写文件及导出覆盖范围，再决定如何恢复。这也是为什么备份要围绕真实工作环境，而不只是某一个配置文件。
版本更新完成后，保留至少一份已经验证可读的旧快照，直到新的基线经过你的关键使用场景。清理时按实际需要和隐私要求处理，不要把备份当成长期公开的配置资料库。
延伸阅读
参考资料
参考资料核对：2026-10-14。以下链接为项目及平台文档；本文为本站独立编辑指南。