订阅更新后自定义设置丢了，应该改哪一层

代理订阅更新后，自定义设置消失，先确认改动写在订阅原文、扩展配置，还是实际运行配置中。需要长期保留的定制，应放到客户端提供的独立扩展或适用的内核覆写层，并核对更新后的生效结果；直接改下载文件，可能在再次获取订阅时被替换。

把远端内容与本地定制分开

订阅通常由服务方提供节点或配置，更新的目的是获取其新内容。自己的规则偏好与节点参数调整，则属于另一项工作。混在同一文件里修改，会让“远端变了什么”和“自己改了什么”难以区分。

Clash Verge Rev 扩展文档将定制分为配置与脚本，也分为全局扩展和订阅扩展。前者用于多数订阅共同需要的改动，后者用于某份订阅的特殊处理。先确定范围，再选择位置，比把所有设置都塞进全局层更容易维护。

该文档说明，扩展配置的列表和普通值会整体替换，部分嵌套对象则按子字段合并。因此，在扩展里写入一份短的规则列表，不能当然认为它会自动追加到原列表末尾。

修改前应看清字段的处理方式。若需求只是补充少量条目，应使用文档支持的相应编辑方式，而不是随手复制一个不完整列表覆盖原内容。应用设置接管的字段还可能在处理链末尾被写回，扩展里的值不一定是最后结果。

Mihomo 的 provider 文档把更新间隔与节点加载时的 override 分别定义；后者可给节点名加前后缀，或调整文档支持的节点字段。这是针对节点供应内容的处理，不等同于修改整份客户端配置。

例如，统一给某组节点加名称前缀，可以考虑节点覆写；处理一份订阅的规则关系，则应查看客户端扩展能力。两种机制的位置和作用范围不同，不能照着相同字段名就互相替代。

先备份自己的定制片段，并记录客户端与内核版本。每次只改一小项，再更新订阅、重新加载，检查最终配置是否包含预期内容，同时观察实际规则匹配或节点名称。

如果某项改动消失，依次检查扩展是否启用、是否作用于当前订阅、后续处理是否替换了它，以及应用设置是否接管该字段。不要只看编辑器里的文本就认为已生效。

远端节点改名或删除后，本地引用也应重新核对。独立保存定制能减少重复编辑，却不能保证旧规则永远适配新的订阅内容。