本文目录
工作、日常和测试订阅放在同一个客户端里，最容易混淆的是“刚更新的配置”和“正在运行的配置”。切换前看清用途，更新后核对实际节点与规则，并给自己的覆写留一份可恢复备份，多份配置才不会越存越难管理。
远程订阅、本地 Profile 与覆写各负责什么？
到配置列表确认当前选中的是哪份 Profile，再查看覆写是否仍启用。切换 Profile 后，全局覆写可能继续生效；远程订阅能正常加载，也不能证明合并结果正确。
三类配置承担不同职责
| 类型 | 适合放什么 | 更新方式 | 最容易误会 |
|---|---|---|---|
| 远程 Profile | 服务方提供的节点、策略组和规则 | 按 URL 手动或定时拉取 | 更新成功就等于当前已经切换 |
| 本地 Profile | 固定测试、离线回退或自写完整配置 | 手动编辑与备份 | 会像订阅一样自动刷新 |
| Merge / Script / 覆写 | 少量长期自定义规则和字段 | 跟随客户端加载 | 只作用于某一份 Profile |
清楚命名，保留未经覆写的可用配置
把工作、日常、测试和备用订阅都叫 Profile 1、Profile 2，过一周就很难知道哪份可以删除。名称至少应包含来源或用途，再加一个容易识别的环境，例如“工作｜公司规则”“日常｜主订阅”“测试｜本地覆写”。不要把完整订阅域名、账号或 token 写进名称。
在开始自动更新前，选择当前最稳定的远程订阅，手动更新并直接加载，不启用额外 Merge 或 Script。固定一条可用节点，确认浏览器、常用应用、内部域名和 DNS 都正常。
保留这份不加覆写的 Profile，不要复制出很多名称相近的版本。以后某个覆写报 group not found 时，切回它就能确认原始订阅是否仍可用；如果它也失败，再检查下载、解析或服务端变化。
这份原始配置应满足
- 不依赖临时脚本或在线转换站
- 在 Windows 上，退出客户端后网络能恢复
- 订阅 URL 已安全备份
更新间隔按实际变化来设，不是越短越稳
订阅通常只有在节点、流量信息或规则变化时才需要拉取。过短的间隔会增加服务端请求、耗电和失败通知，也可能在你工作途中把当前配置替换成一份暂时错误的响应。日常订阅可以从较保守的周期开始，频繁变化的测试源再单独缩短。
在 Clash Verge Rev 的 Profile 详情或订阅设置中调整自动更新时，先确认单位和下次执行时间。不同版本或导入方式显示的选项可能不同，因此不要照搬别人截图里的数字。最重要的是保留手动更新入口，并能看到最后成功时间与失败原因。
- 日常主订阅
- 以稳定为主，按服务方更新频率设置，不需要几分钟拉一次。
- 工作配置
- 更新前考虑会议、远程连接和固定出口，避免工作中途切换。
- 测试订阅
- 可以更频繁，但不设为开机默认，也不覆盖已确认可用的主配置。
- 本地 Profile
- 手动修改并保留版本记录，再检查修改是否有效；不要把它当成按远程地址拉取的订阅。
更新结果正常后切换当前 Profile
“更新成功”只表示下载与解析没有立即报错，节点是否可用还需用实际请求确认。
如果更新后节点从几十个变成零、策略组突然消失，或正文其实是登录页，不要继续切换。保留上一份正在运行的配置，查看 HTTP 状态和解析日志。自动更新也应遵守同一原则：失败时继续使用最后一份可用缓存，而不是把错误响应当成新配置。
一次可控的更新
记下更新前状态
记录 Profile 名称、当前更新时间和关键策略组。
只更新这一份
先不点击“全部更新”，避免多个来源同时变化。
阅读结果
检查下载状态、解析错误、节点与策略组是否完整。
切换并固定节点
通过连接页验证常用域名的规则和出口。
保留回退
在真实任务完成前，不删除上一份可用配置。
切换 Profile 后，覆写为什么会出错？
全局 Merge 如果引用了“PROXY”“节点选择”等固定组名，切到另一家订阅后，这个组可能根本不存在，于是出现 proxy group not found。覆写内容应尽量少，并只引用各 Profile 都存在的字段和组名。
不同来源的组名和结构差异很大时，分别维护覆写，不要让同一份脚本处理所有订阅。
调整覆写后要查看最终生成的 YAML，核对 DNS、rules 和 proxy-groups 的实际内容，以及组名和规则引用是否与当前 Profile 匹配。这些内容可能被覆写替换，不能只看原始订阅。
停用所有覆写，确认原始订阅可以加载，然后逐个启用。这样比同时阅读多项错误更容易找出是哪一项导致失败。
更新成功，切换时报 group not found
常见原因：覆写引用了这份 Profile 不存在的组名
处理方法：停用覆写，对照最终配置中的实际组名。
不同 Profile 切换后 DNS 一直相同
常见原因：全局 Merge 覆盖了每份订阅的 dns
处理方法：确认这是有意设计，否则缩小覆写范围。
每次更新后手改内容消失
常见原因：直接编辑了远程订阅缓存
处理方法：把长期修改移到持久覆写或独立本地 Profile。
备份内容与恢复后的实际测试
能恢复多配置工作流的备份至少有四部分：远程订阅地址、自己维护的本地 YAML、Merge 或 Script 文件，以及客户端版本、端口和当前 Profile 等少量设置。订阅地址放进密码管理器；本地配置和覆写放进加密归档；版本与设置可单独记成一页说明。
不要只复制 Clash Verge Rev 的整个缓存目录。缓存里可能有过期订阅、运行状态和旧内核，直接覆盖新安装会把问题一起恢复。需要回退时，先导入一份最近验证过的本地快照，在不覆盖主 Profile 的情况下确认能加载。
备用配置最好来自独立且可信的来源。如果主配置和备用配置使用同一服务、经过同一组转换步骤，并在同一时间自动更新，来源出错时两份配置会一起失败，备用配置也就无法用于恢复。本地快照包含节点凭据，必须加密保存并设置保存期限。
一次可恢复的备份
- 密码管理器中保存远程订阅 URL
- 加密保存本地 YAML 与 Merge/Script
- 记录 Clash Verge Rev 和 Mihomo 版本
- 记录 mixed-port、当前 Profile 与必要开关
- 在测试 Profile 中做过一次恢复验证
启动客户端并确认当前 Profile，手动更新后完成一个真实任务，切到备用再切回，然后退出并检查系统代理恢复。重启后确认当前配置与自动更新计划仍正确。