要准确判断Shadowrocket订阅更新后分组和策略是否保留，最可靠的操作是先进入订阅管理页面确认当前待更新的订阅标注为“节点”还是“配置”类型，若为纯节点订阅则放心执行刷新且所有本地策略组和路由规则完整保留，若为远程配置订阅则必须在更新前进入配置页面手动导出完整备份文件并保存到云盘中，刷新完成后仔细对比策略组变化并根据备份内容快速恢复被覆盖的自定义设置。对于节点引用失效的情况，进入策略组编辑页面重新勾选新导入的节点列表即可恢复正常调度，同时建议将核心分流规则从托管配置中分离出来保存为本地独立规则集文件，配合关闭订阅自动更新改为定期手动刷新的习惯，从根本上规避远程强制覆盖带来的配置损失风险。
订阅类型对配置保留的决定性影响
节点订阅与配置订阅的本质区分
Shadowrocket中的订阅分为“节点订阅”和“配置订阅”两种截然不同的类型，前者仅提供服务器列表数据而后者包含了完整的策略组结构、路由规则和DNS设置。当用户添加的是纯节点订阅时，应用会将该订阅提供的服务器节点与本地配置文件中的策略组进行松耦合关联，更新操作仅作用于节点列表层面而不会触及策略组的定义。配置订阅则是一份完整的远程配置文件，刷新时会将服务端推送的整套策略组、规则集和节点引用全部替换本地现有内容，因此是否会丢失分组完全取决于订阅添加时的类型选择。
订阅管理页面中的类型标识识别
用户在订阅管理列表中可以通过每个条目右侧的标签或图标来判断其类型，通常节点订阅显示为服务器图标而配置订阅显示为文档图标，两者在刷新时的行为逻辑完全不同。若订阅条目下方标注了“包含策略组”或“远程配置”等字样，则代表该订阅属于托管配置类型，每次更新都会强制覆盖本地策略组的全部定义。正确识别订阅类型是判断分组和策略能否在更新后保留的第一步，如果用户无法确定当前订阅的类型，建议点击订阅条目进入详情页查看其关联的数据结构描述。
本地配置文件与订阅数据的存储分离
Shadowrocket的架构设计将本地配置文件与订阅源数据存储在不同位置，纯节点订阅仅将节点列表以引用形式挂载到本地配置的策略组中，而配置订阅则直接将远程数据写入本地配置文件的全部字段。当执行更新操作时，应用会根据订阅类型决定写入数据的范围和覆盖逻辑，节点订阅仅更新服务器列表而不触碰策略组定义，配置订阅则完全重写本地配置文件。理解这种存储分离机制能够帮助用户在订阅更新前准确预判哪些配置会被保留、哪些会被覆盖。
纯节点订阅更新后的保留范围
策略组结构完整保留的运行机制
当用户更新纯节点订阅时，本地配置文件中的策略组名称、嵌套层级、策略组类型（如select、url-test、fallback）以及每个策略组下的节点选择逻辑均保持不变。应用在更新过程中仅将远程拉取的新节点列表与本地数据库同步，同时更新每个节点的延迟测试结果和可用性状态，但不会对策略组框架进行任何增删改操作。这意味着用户自定义的“流媒体专用组”、“游戏加速组”等分组结构在订阅刷新后依然完整存在，无需重新创建或调整。
策略组内节点引用的动态映射逻辑
虽然策略组的结构被完整保留，但组内实际引用的节点对象会随着订阅更新而发生变化，因为服务商可能在新版本中重命名节点、删除老旧节点或增加全新服务器。策略组中通过名称匹配引用节点的机制在节点名称发生变更时会导致映射失效，表现为策略组下拉列表中原本选中的节点变成红色或显示为未选择状态。用户需要在更新后进入策略组编辑页面，重新勾选需要纳入该组的新节点列表，这一操作虽然需要手动完成但策略组本身的框架并未消失。
路由规则与DNS配置的持久化存储
纯节点订阅更新不会触及Shadowrocket的“配置”页面中的路由规则列表和DNS设置，这些规则文件是作为独立配置项存储的，与订阅源没有任何直接的数据依赖关系。用户为国内网站配置的直连规则、为特定应用配置的代理规则以及自定义的DNS服务器地址在订阅刷新前后始终保持一致，无需因为节点列表的更新而重新编写规则。这种独立的存储方式确保了网络策略的连续性，让用户可以在更换节点服务商时无需重建整个规则体系。
远程配置订阅更新时的覆盖风险
托管配置刷新完全替换本地设置的机制
当用户使用的是远程托管配置订阅时，每次刷新操作都会从服务端下载一份完整的配置文件，该文件包含了服务商预设的全部策略组、规则集、节点引用以及全局设置。Shadowrocket在更新成功后会使用这份远程文件直接替换设备上的本地配置文件，意味着用户之前对策略组名称、分组内节点、自定义规则甚至DNS偏好所做的所有本地化修改都将被永久覆盖。这种强制替换机制是托管配置的工作方式，并非应用本身的Bug，用户在选择此类订阅时就必须接受这一行为逻辑。
本地自定义修改被覆盖的触发条件
所有在应用“配置”页面中对策略组进行的重命名、添加新策略组、修改策略组类型等操作，在远程配置订阅更新后都会因本地配置被整体替换而丢失。唯一的例外是当远程服务器返回的配置文件解析失败或网络请求超时时，Shadowrocket会保留本地缓存配置以防止应用完全不可用，但这种保留属于异常情况下的降级保护而非正常更新流程。用户如果长期依赖托管配置且需要自定义策略，应当在每次更新前将本地策略组导出备份并在更新后重新应用。
服务商配置更新的版本兼容性问题
服务商推送的托管配置新版本可能改变策略组的命名规范、调整策略组的嵌套结构或引入全新的路由规则集，这些变化在刷新后不仅会覆盖用户的本地修改，还可能因为策略组名称变更导致用户依赖特定分组名称编写的脚本或自动化工具失效。部分高级用户会利用策略组名称作为外部调用的标识符，服务商对配置结构的频繁调整会破坏这种依赖关系。在刷新托管配置前，用户应仔细查看服务商的更新公告，确认新版配置是否包含破坏性变更。
本地手动修改在托管订阅下的失效逻辑
本地编辑与远程推送的优先级判定
Shadowrocket在处理远程配置订阅时，将远程文件的优先级设定为高于本地手动编辑内容，这意味着无论用户在应用界面中对配置做出了多少修改，刷新操作完成后所有字段都会被远程数据彻底覆盖。应用不会在更新前提示用户存在未保存的本地修改，也不会提供合并选项，而是直接执行强制替换操作。这种设计逻辑与代码版本管理中的“强制推送”类似，本地变更在没有提交到远程仓库的情况下会被下一次拉取操作清零。
本地规则集文件不被覆盖的例外情况
对于用户通过“配置-规则集”功能单独添加的本地规则集文件（如自定义的.list或.conf文件），这些文件存储在应用的独立目录中，并不属于远程配置订阅的一部分，因此不会被托管配置的刷新操作所影响或删除。用户可以将自己编写的核心分流规则保存在独立的本地规则集文件中，然后在托管配置的策略组中通过“引用”方式关联这些文件，这样即使托管配置被整体替换，只需要在更新后重新添加对本地规则集的引用即可快速恢复核心功能。这种分离存储策略是规避远程覆盖风险的有效手段。
更新前后对比策略组的应对方案
在执行远程配置订阅更新之前，用户可以进入当前配置的策略组页面逐项截图或记录每个策略组的节点分配情况和自定义参数，更新完成后对照记录手动恢复所有关键设置。虽然这种人工恢复方式较为耗时，但至少保留了完整的恢复参照，避免了更新后完全依靠记忆重建策略组的盲目性。对于策略组数量较多的高级用户，建议使用配置导出功能在更新前生成完整的本地备份文件，更新后如果发现策略组被过度修改，可以立即导入备份文件快速回退到更新前的配置状态。
更新后策略组节点映射的变化规律
节点名称变更引发的引用关系断裂
即使策略组框架在纯节点订阅更新后得以保留，组内通过名称引用的节点如果在新版本中被服务商重命名（例如从“US-01”改为“美国-主节点”），原有的引用关系会因为名称不匹配而失效。失效的节点在策略组下拉列表中通常显示为灰色不可选状态或带有警告图标，用户虽然可以看到策略组依然存在但其中包含的节点列表已经变为空。解决这一问题的唯一方法是在更新后手动进入策略组编辑界面，从新导入的节点列表中重新勾选正确的节点填充到各个策略组中。
策略组类型与节点组件的独立性
策略组的类型（如select手动选择、url-test自动延迟测速、fallback故障转移）属于策略组的固有属性，完全不受订阅更新中节点列表变化的影响，用户无需在每次更新后重新设定策略组的调度逻辑。url-test组中预设的延迟测试间隔和测试目标URL等参数同样保存在本地配置文件中，与订阅源数据无关，更新后这些参数会继续保持原有的配置值。策略组的独立属性确保了即使节点列表发生频繁变动，调度策略的核心行为依然保持稳定和可预期。
多订阅合并场景下的映射维护策略
当用户同时使用多个订阅源并将不同来源的节点混合到同一个策略组中时，某个订阅的更新仅会影响该订阅提供的节点集合同步情况，不会影响其他订阅节点在策略组中的引用关系。但如果被更新的订阅中的节点名称发生了全局变更，策略组中指向这些节点的旧名称引用将全部失效，即使其他订阅的节点依然有效，策略组的整体可用性也会因为部分引用断裂而下降。在多订阅环境下，建议为不同订阅分别建立独立的策略组，避免跨订阅节点混合引用带来的维护复杂性。
规避覆盖风险的备份与分离管理策略
配置文件独立备份的操作规范
在进行任何类型的订阅更新之前，用户应当养成先进入Shadowrocket的“配置”页面点击“导出”按钮生成当前完整配置备份文件的习惯，备份文件以.conf或.json格式存储并包含所有策略组、规则集和节点引用信息。将备份文件通过隔空投送发送到其他设备或保存到iCloud云盘后，即使订阅更新导致配置被完全破坏，用户也可以通过“导入”功能在几秒钟内完整恢复到更新前的状态。建议在每次修改策略组或添加重要规则后立即执行一次手动导出备份，将备份文件命名为包含日期和版本信息的格式便于追溯。
节点订阅与配置文件的分离管理架构
最彻底的策略是将节点订阅与配置文件完全解耦，即仅使用纯节点订阅来获取服务器列表，而将所有策略组、分流规则和DNS设置保存在本地独立配置文件中。在这种架构下，无论订阅如何更新都只会影响节点列表本身，本地配置文件的策略组结构永远不会被任何外部数据覆盖或篡改。当新节点导入后，用户只需在现有的策略组中调整节点勾选即可完成适配，整个规则体系和分组框架可以长期保持稳定不变。
关闭自动更新转向手动更新策略
为了降低因疏忽导致的配置意外覆盖风险，用户可以在订阅管理页面中将每个订阅的“自动更新”开关关闭，改为每周或每月手动执行一次刷新操作。手动更新意味着用户可以在有充足时间和心理准备的情况下执行刷新，提前完成配置备份并确认服务商的更新公告，最大程度地避免因自动更新在不可控时间触发而导致正在使用的策略组被突然覆盖。对于纯节点订阅而言，手动更新的频率也可以适当降低，因为节点列表本身并不需要每天同步。
常见问题FAQ
订阅更新后我之前设置的策略组全都消失了，是什么原因？
最可能的原因是您使用的是远程托管配置文件订阅而非纯节点订阅，远程文件在更新时推送了全新的配置结构并强制覆盖了本地所有策略组定义。请检查订阅管理页面中该条目的类型标识，如果是配置订阅则无法保留本地分组，建议改用纯节点订阅或更新前导出备份。
更新后策略组还在，但里面的节点选不中或者显示红色，怎么办？
服务商在更新订阅时重命名了节点或删除了旧节点，导致策略组中通过旧名称引用的节点对象已不存在。进入策略组编辑页面，清空失效的节点引用，重新从新导入的节点列表中勾选正确的节点即可恢复策略组的正常调度功能。
不想让订阅更新覆盖我的分组，该怎么操作？
将订阅链接添加为纯节点类型而非配置类型，刷新时仅更新节点列表而不触碰本地策略组。如果当前订阅已经是配置类型，可以删除该配置订阅后单独添加节点订阅，或者每次更新前导出配置备份并在更新后导入回退。
订阅更新后路由规则如绕开大陆的直连策略会丢失吗？
如果该规则存储在本地配置文件的规则列表中而非由订阅托管配置下发，则不会因订阅更新而丢失。若路由规则属于远程配置订阅的一部分，则每次刷新都会被新版本覆盖。建议将核心直连规则保存为独立的本地规则集文件，与订阅数据分离以确保持久保留。