Clash Verge Rev 配置管理教程：导入、更新与节点选择的顺序

配置管理出乱子，几乎都源于同一件事：分不清「新增一份配置」和「更新现有配置」。前者会让列表里多出一条内容相近的条目，后者才是把手上这份刷新到最新。等到列表里躺着四五份名字相似的配置时，「改了没生效」就成了必然。

这篇把配置管理拆成导入、更新、选择三步讲清顺序，再补上配置变多之后的整理办法，以及出现异常时的回退思路。

这三步之间是有先后关系的：导入决定了列表里有什么，更新决定了那份内容是不是最新的，选择决定了此刻生效的是哪一个。绝大多数「明明改了却没变化」，都是因为在错误的那一步上找原因。

一、先理清三件事的先后

官方快速开始的流程，落到日常管理上可以理解为“导入 → 更新 → 选择”的顺序。搞清楚这个顺序，能避免“先选了节点又重新导入导致选择被覆盖”这类反复。

导入是一切的起点。配置可能来自订阅链接或本地文件，取决于你手上的配置形式。请只导入你有权使用的配置——本文不提供也不推荐任何订阅或配置示例链接。导入后，配置会出现在 Profiles 列表中，作为后续更新与选择的基础。

当你的配置来源内容发生变化时，需要在客户端里更新对应的 Profile，把本地内容刷新为最新版本。更新和“重新导入一份新配置”是两件事：前者是刷新已有条目，后者会新增条目。理清这点，能避免列表里堆积多份内容相近、却又不确定哪份在生效的配置。

配置就绪后，进入 Proxies（代理）页选择代理组、具体节点以及模式。这里的选择由内核按配置执行。建议每次导入或更新配置后，都回到 Proxies 页确认当前选择是否仍是你想要的，因为配置变化可能影响可选项。若发现“改了没生效”，先检查是不是选择停留在旧条目上。

列表一旦超过三条，靠记忆就不够了。三个成本很低的习惯可以解决大部分混乱：给每份配置起一个能看懂的名字（用途 + 来源，而不是默认的一串字符）；只保留一份当前在用的，其余的要么删除要么明确标注为备用；每次更新后看一眼更新时间戳，确认刷新的是你以为的那一份。

如果同时用着多份订阅，还要注意别把它们混在同一个选择组里比较——不同订阅的节点命名习惯不同，混在一起会让你误以为某条线路「消失了」。

这套「先记录、再改动」的思路同样适用于订阅客户端，可参考怎样给订阅更新留回退路径。

同时用两家服务的人会遇到一个新问题：配置列表里有两份来源不同的订阅，节点命名、地区组合、分组方式都不一样。这时最忌讳的是把它们混着用——今天连这家、明天连那家，出问题时你无法判断是哪一份的问题。

更清晰的做法是给它们分工：一份作为日常主用，另一份只在主用不可用时启用。切换时明确记一句「今天起用备用」，而不是在两份之间随手来回跳。这样每一份的表现你都能观察到一段连续的时间，判断才有依据。

如果两份订阅是为了不同用途（比如一份日常、一份专门用于某类服务），那就更应该固定各自的适用范围，并在配置名称里写清楚，避免几周后自己都分不清哪份是干什么用的。

说明订阅内容本身发生了变化，而不是客户端出错。回到 Proxies 页重新选择即可，原来的选择在节点消失后不会自动迁移。

不会，但如果被删的正是当前生效的那份，需要重新选择一份并确认节点选择。

由配置本身定义，客户端只是把它呈现出来。因此不同订阅的分组方式差别很大，这也是不建议把多份订阅混在一起看的原因。

通常不会，更新失败一般保留原内容。但这正是更新前记下名称与时间戳的意义——你能立刻确认当前生效的到底是新的还是旧的。

通常只有一份是当前生效的。想要同时使用多个来源的节点，需要在配置层面合并，属于进阶用法，以客户端官方文档为准。