要确保Shadowrocket配置文件更新后之前设置的分流规则能够完整保留，最可靠的操作策略是首先明确当前正在使用的订阅类型，将纯节点订阅与远程配置订阅区分对待，对于配置订阅则主动将自定义规则从主配置文件中剥离出来存入独立的本地规则集文件并通过RULE-SET指令引用，使其不受订阅更新的覆盖影响。在进行任何大规模修改前应导出完整配置备份并保存至iCloud云盘，同时养成每次订阅刷新后进入策略组页面检查节点引用状态的习惯，若发现节点名称变更则立即重新勾选以保持调度功能。当手动编辑订阅配置并希望永久保留时，应先执行“另存为”将其转化为本地独立配置文件再行修改，彻底切断与远程更新的关联，并定期清理冗余订阅和配置以避免混淆，确保每次配置更新后都能通过配置摘要和实时日志快速验证规则的完整性。
配置文件更新的类型差异与规则保留的关联性
本地手动编辑的配置文件重载规则完全保留
当用户通过Shadowrocket的“编辑纯文本”功能或外部文本编辑器修改了本地配置文件并保存后，执行配置重载操作时，所有修改过的分流规则、策略组定义和DNS设置都会被完整保留，因为这种更新本质上是用户主动对同一文件内容的修订而非替换。重载过程仅将文件系统中的最新内容重新加载至引擎的内存中，不会对文件本身进行任何增删操作，因此用户手动添加的每一条DOMAIN-SUFFIX规则、每一个自定义策略组以及每一处GEOIP调整都在重载后完好无损地继续发挥作用。这种类型的更新是配置文件管理中最安全可控的变更方式，用户无需担心任何自定义配置的丢失，可以放心反复修改和重载来调试分流效果。
远程配置订阅更新带来的完整内容覆盖
当用户使用的是通过订阅链接添加的远程配置文件（即配置订阅而非节点订阅）时，每次执行订阅更新操作都会从服务端拉取一份完整的配置文件，该文件包含了服务商预设的全部分流规则、策略组结构和节点引用信息，并在更新成功后用这份远程文件直接替换设备上的本地配置文件。在这种更新模式下，用户之前对本配置文件的任何手动修改（包括添加的直连规则、自定义策略组和调整的规则顺序）都会被远程推送的新文件完全覆盖而永久丢失，因为订阅更新采取的是整体替换而非增量合并的策略。用户必须清楚地认识到，配置订阅的便利性是以放弃本地修改权为代价的，任何自定义内容都应在远程配置更新前单独备份或迁移至独立的本地规则集文件中引用，才能避免被覆盖的命运。
节点订阅更新仅刷新服务器列表不影响规则
当用户添加的是纯节点订阅（即在订阅管理页面中标示为“节点”类型的订阅源）而非完整配置订阅时，刷新操作仅会更新该订阅提供的服务器节点列表，对配置文件中的分流规则、策略组结构和DNS设置完全不产生任何影响。这类更新只涉及节点的新增、删除或参数调整（如端口变更、加密方式更新），而用户配置文件中所有的DOMAIN-SUFFIX规则、GEOIP规则、策略组定义以及自定义的直连条目均保持在更新前的完整状态，不会因节点数量的增减而发生任何变化。这种节点与规则分离的架构设计使得用户可以自由切换和更新节点资源，同时保持自己精心构建的规则体系始终稳定不变，是实现灵活分流与节点管理的最佳实践。
本地自定义规则与订阅配置的存储隔离机制
本地配置文件与远程订阅数据的独立存储路径
Shadowrocket在应用内部为手动创建的本地配置文件和通过订阅下载的远程配置文件分别维护了独立的存储区域，当用户从零开始编写一个全新的配置文件并保存时，该文件以用户指定的名称存储在应用的本地配置目录中，与任何订阅源没有关联关系。而远程配置订阅则在首次添加时创建了一个指向服务端URL的引用条目，每次更新时直接从该URL拉取数据并覆盖存储在本地缓存中的对应文件副本，两者之间的数据流是单向且不可逆的。这种隔离机制意味着手动配置永远不会被订阅更新波及，但同时也意味着一旦用户主动加载了订阅配置并进行了修改，这些修改将在下次订阅刷新时被覆盖，除非用户将该修改保存为一份独立的本地配置副本。
通过本地规则集文件引用实现自定义规则的永续保留
为了在享受远程配置订阅便利性的同时保留自己的分流规则修改，用户可以在Shadowrocket中创建独立的本地规则集文件（扩展名为.list或.conf），将自定义的直连规则、广告拦截规则或特定域名代理规则写入该文件，然后在主配置文件中通过“RULE-SET”指令引用这些本地文件。当远程配置订阅更新并覆盖主配置文件时，主文件中的RULE-SET引用仍然指向这些独立存储的本地规则集文件，而这些文件本身并不属于订阅更新范围，因此其内容在订阅刷新后依然完整保留。这种架构设计让用户将“框架性规则”交给订阅管理，将“个性化规则”由本地文件固守，实现了订阅便利性与自定义灵活性的完美平衡。
策略组中手动勾选的节点引用与订阅节点的解耦
在策略组编辑页面中，用户从所有节点列表中手动勾选的节点（无论这些节点来自哪个订阅源）会在策略组配置中保存为节点名称的引用列表，这些引用与节点订阅的源数据是解耦的。即使某个订阅刷新后其中的节点名称发生了变更或节点被删除，策略组中旧名称的引用会显示为失效或灰色状态，但策略组本身的框架和已勾选的节点列表并不会被清空或重置。用户只需在订阅刷新后进入策略组编辑页面，重新勾选更新后的正确节点名称即可恢复完整的调度功能，而不需要重新创建整个策略组结构。
手动编辑被订阅覆盖的典型场景与防范措施
直接修改订阅配置后执行更新导致丢失的实例
当用户通过“编辑纯文本”功能打开了一个来自远程订阅的配置文件，在其中添加了几条自用的直连规则或调整了策略组的排列顺序并保存后，如果后续执行了该订阅的更新操作，所有手动添加的内容都会被服务端推送的新配置覆盖。这种覆盖不会给出任何警告提示，因为Shadowrocket的订阅更新逻辑默认认为远程配置是权威版本，本地修改被视为临时调试而不做合并保护。用户在这种情况下丢失的修改往往需要重新录入，但如果未能及时意识到被覆盖的原因，可能会反复编辑-更新-丢失的循环而困惑不解。
误将节点订阅当作配置订阅进行编辑的风险
某些用户会在订阅管理页面中添加了一个节点订阅链接，但在配置列表中看到该订阅生成了一组节点后，误以为这些节点是当前配置文件的一部分而直接进入编辑模式对配置文件进行修改。当后续刷新该节点订阅时，修改的其实是当前加载的本地配置文件而非订阅本身，因此这些修改实际上不会被节点订阅刷新覆盖，因为节点订阅不触碰配置文件。但如果用户同时添加了配置订阅和节点订阅，并在编辑模式下修改了配置订阅中的内容，则下次配置订阅刷新时修改就会丢失，这种混淆需要用户准确区分自己使用的订阅类型。
利用“另存为”备份防止覆盖的有效策略
在修改任何来自订阅的配置文件之前，用户应首先进入配置管理页面点击“另存为”或“复制”功能，将当前配置保存为一个全新的本地配置副本并赋予新的名称。此后对这个副本进行的所有修改都与原始订阅源无关，即使原始订阅不断更新也不会影响这个独立副本的内容。用户可以将这个副本设为默认加载配置，既享受了订阅节点更新的实时性（通过在该副本中引用订阅的节点组），又保持了自己对分流规则的完全控制权。
更新后规则仍存在但引用的节点可能失效的情况
规则框架完整保留但节点名称变更导致引用断裂
当配置文件更新后（无论是节点订阅刷新还是配置订阅更新），原本在策略组中通过名称引用的节点如果因服务商重命名（例如“US-01”改为“美国节点1”）而发生了变化，策略组中的这些引用会因名称不匹配而失效。此时策略组本身依然存在于配置文件中，其结构、类型和所有其他设置都完好无损，但下拉列表中的节点选项会显示为红色或无法选中。用户只需要重新进入策略组编辑页面，从更新后的节点列表中重新勾选对应的新节点即可恢复策略组的完整调度能力。
GEOIP规则因订阅IP库更新而产生的匹配变化
某些配置订阅在更新时会附带更新GEOIP规则所依赖的IP地理数据库，这可能导致原先直连的国内IP段在新数据库中重新分类，使得某些域名的分流行为发生细微变化。但这些变化并非规则本身的丢失，而是规则所依赖的数据源发生了变更，用户之前手动添加的DOMAIN-SUFFIX精确规则因优先级高于GEOIP规则而不受影响。只有当用户完全依赖GEOIP批量规则且订阅更新引入了新的IP分类逻辑时，才会感知到分流结果的改变，但规则条目本身并未减少或消失。
自定义策略组的类型和顺序在更新中的保留情况
对于配置订阅更新，由于是整个配置文件的完全替换，用户之前对策略组名称的修改、新增的策略组以及对策略组顺序的调整都会被远程配置的原始设置所覆盖。这意味着即使用户在更新前手动将策略组类型从select改为url-test，更新后也会恢复为服务商预设的类型。用户如果想要保留这些修改，必须将该配置文件转化为本地独立配置而非依赖订阅更新，或者在更新后重新应用修改。
备份配置与版本管理的最佳实践
每次重大修改前导出完整配置文件
用户在进行大规模规则调整或策略组重构之前，应进入配置页面点击“导出”按钮将当前完整的配置保存为.conf文件，并存储到iCloud云盘或通过隔空投送传输至其他设备作为备份。导出的文件包含了该配置中所有的分流规则、策略组定义、节点引用和DNS设置，是恢复配置的唯一完整数据源。建议在文件名中加入日期和版本描述（如“config_20260827_before_update.conf”），以便在后续需要回退时能够清晰识别应导入哪个文件。
定期清理冗余订阅并整理本地规则集
随着时间推移，用户可能添加了多个订阅源并在不同配置文件间反复切换，导致本地存储了若干已不再使用的配置副本和规则集文件。定期进入配置管理页面删除过时的订阅条目和冗余的本地配置备份，可以减少因误加载旧配置而产生的混淆，同时使当前主用配置的维护更为清晰。在清理之前应确认每个待删除的配置确实不再需要，或已将其中的关键规则迁移至新的配置文件中。
利用iCloud同步功能实现跨设备配置一致
在Shadowrocket的“设置”中开启iCloud同步后，所有本地配置文件和规则集会通过iCloud自动同步到同一Apple ID登录的其他iOS设备上，当一台设备上的配置被修改后，另一台设备在打开应用时会自动拉取最新版本。这种同步机制在配置更新后能够确保所有设备上的分流规则保持统一，但前提是同步的配置均为本地独立配置而非依赖订阅的动态配置。如果用户在多设备上都订阅了同一远程配置，则同步功能不会合并各设备的手动修改，因为订阅更新会覆盖本地差异。
更新后验证规则完整性的系统化方法
通过配置摘要页面快速查看规则总数
在Shadowrocket的配置页面顶部，应用会显示当前加载的配置文件的规则总数、策略组数量和节点数量，用户在更新前后对比这些数字即可快速判断是否有大量规则被意外删除或新增。如果更新后规则总数锐减且与预期不符，则说明订阅更新可能替换了配置，此时应立即停止使用该配置并导入之前备份的版本。如果规则总数保持不变但分流行为异常，则问题更可能出在节点引用或具体规则的优先级排序上，而非规则的丢失。
使用实时日志验证关键域名的分流结果
在配置更新后，用户应打开实时日志并访问几个在分流中具有代表性意义的关键域名（如一个国内网站、一个境外代理网站和一个广告域名），观察日志中每个请求匹配到的具体规则行数和最终执行的策略动作。如果日志显示这些域名的匹配结果与更新前完全一致，则说明配置文件更新未破坏核心分流逻辑；如果发现某个域名匹配到了错误的策略，则需要进入规则列表检查该域名对应的规则是否因更新而改变了顺序或动作，并手动修正。
通过策略组下拉菜单验证节点引用状态
在配置更新后，用户应依次点击每个策略组并查看其节点下拉列表，确认所有节点名称均显示为正常的可选状态而非灰色失效状态。如果发现某个策略组中的节点全部变为红色或无法选中，则说明该策略组引用的节点在本次更新中被重命名或删除，需要重新勾选当前可用的节点。这个检查应在每次订阅刷新后常态化执行，因为服务商调整节点命名是常见操作，及早发现并修复能够避免在实际访问时因策略组无可用节点而导致的代理失败。
常见问题FAQ
我手动编辑了订阅配置的规则，刷新后不见了，还能找回吗？
不能。订阅刷新采用完整替换机制，手动编辑的内容在刷新时被覆盖且无历史版本存储。唯一的恢复途径是在编辑前导出了配置备份，否则只能重新手动添加。建议以后修改前先“另存为”本地独立配置。
节点订阅更新会影响我写的分流规则吗？
不会。节点订阅仅更新服务器节点列表，配置文件中所有的分流规则、策略组结构和DNS设置均保持原样，不会因节点更新而发生任何变化。
配置订阅更新后，我之前在策略组里选好的节点还在吗？
如果节点名称未变，则策略组中的引用依然有效。但如果服务商在更新时重命名了节点（如将“US-01”改为“美国1”），则旧名称引用失效，策略组虽然还在但需要重新勾选对应的新节点。
如何区分我使用的是节点订阅还是配置订阅？
在订阅管理页面中，每条订阅条目右侧会显示类型标识，节点订阅显示为服务器图标，配置订阅显示为文档图标。若不确定，可以点击条目查看其详情，配置订阅通常会包含规则列表和策略组信息，而节点订阅仅包含节点列表。