Shadowrocket 配置备份与换机迁移：iCloud 同步与导出配置文件步骤

一、区分配置文件、服务器记录与连接设置

配置备份不是把一个文件保存下来就完成全部迁移。Config 中的配置文件可以包含规则、DNS 设置和其他配置字段；Home 中的服务器、订阅来源，以及 Settings 中的应用设置，需要另外核对。具体文件包含什么，应打开文件查看，不能只凭文件名推断。

尤其要区分“规则仍在”和“已有服务仍可连接”。一份仅包含 [General] 与 [Rule] 的文件，不会因为被导入就自动补齐 Home 中的服务器凭据。反过来，服务器已恢复也不代表原来的自定义 Rule 已经生效。

二、换机前建立一份可恢复的备份

先在旧设备确认当前正常使用的配置，再备份，不要随手导出列表中名称相似的另一个文件。建议记录当前配置名称、Global Routing 选项、选中的服务器或策略组，以及 Settings → On Demand 的条件。记录用于恢复后对照，不等于应用数据已经被同步。

1. 打开 Config，确认当前使用的文件，进入查看内容；如果刚修改过规则，先保存，再返回核对。
2. 检查 Home 中需要保留的手动服务器和 Subscribe 来源。对手动记录，确认能从自己的资料重新取得地址、端口、密码或 UUID 等信息。
3. 记录 Global Routing 的当前选项。Config、Proxy、Direct、Scene 是不同处理方式，换机后的选项要单独检查。
4. 进入 Settings → On Demand，记录启用状态与已设置的连接条件；新设备首次验证时先使用手动连接，避免自动触发影响排查。
5. 保存一份独立配置副本，并在保存位置重新打开，确认能看到完整内容，而不是只有名称或一个无法访问的云端条目。

三、iCloud 同步：先检查权限，再验证云端文件

iCloud 同步适合在使用同一 iCloud 账号的设备之间访问配置文件，但不能把它理解为每项应用状态都已迁移。iCloud Drive 中有文件、Shadowrocket 能打开文件、Config 已选用文件，是三个分别需要确认的结果。

1. 在旧设备的系统设置中打开 Apple Account 的 iCloud 设置，确认 iCloud Drive 已开启；检查允许使用 iCloud 的应用列表中 Shadowrocket 的权限。系统列表分组与文字以当前设备显示为准。
2. 回到 Shadowrocket 的 Config，检查应用提供的 iCloud 文件位置或相关文件操作入口。入口名称以应用实际显示为准，不把“存储到本地”当作已经上传。
3. 如果通过系统文件选择器保存副本，明确选择 iCloud Drive 下自己的目录。只保存到本机位置的文件，不会因为登录了 iCloud 账号就自动成为云端副本。
4. 在新设备启用对应的 iCloud Drive 与应用权限，打开同一文件位置，等待文件可用。云端条目出现后，实际打开文件并检查规则末尾，不只查看列表名称。
5. 将可用文件导入或选用为当前配置，再核对 Home 的服务器记录。文件恢复与服务器恢复分别验收。

如果新设备没有看到文件，先区分账号、存储位置、权限和下载状态。两台设备使用不同 iCloud 账号，或者旧设备副本保存在本地目录，都不能靠反复打开 Config 解决。检查 iCloud 可用空间与网络状态后，再确认旧设备的文件是否确实保存在云端位置。

四、手动导出：保存文件，再检查导出结果

手动导出适合保留迁移前的配置快照，也适合在 iCloud 文件尚不可用时恢复。操作对象应是 Config 中的配置文件，而不是 Home 中单条服务器的分享链接。两者保存的信息范围不同，不能互相替代。

1. 在 Config 找到要保留的文件，打开该文件的操作菜单，使用应用提供的文件分享或导出操作；具体操作名称与位置以当前应用显示为准。
2. 在系统分享面板选择存储到“文件”，保存到自己可访问的目录。使用容易辨认的文件名，保留配置文件原有扩展名。
3. 从“文件”打开刚保存的副本，核对 [General]、[Rule] 和最后一条规则。若原配置有其他段，也逐项核对。
4. 把副本传到新设备可访问的位置。随后通过系统分享面板或 Config 的文件导入入口交给 Shadowrocket，检查导入后的内容。
5. 在 Config 中选用该文件，再进行连接测试。仅完成导入，不应直接判断原规则已经参与请求处理。

下面是用于检查规则段结构的最小示例，不是完整服务配置。它没有提供服务器地址或凭据，不能代替用户已有的服务资料。实际迁移应保留自己的原始文件，不要用示例覆盖正常使用的配置。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX 匹配域名后缀，IP-CIDR 匹配指定 IP 网段，GEOIP 按目标 IP 的地理归属参与判断，FINAL 负责兜底。规则从上到下匹配；文件看起来完整，仍要核对顺序、策略名称与当前模式。

五、新设备恢复：文件、服务与系统授权分开处理

新设备上的 Shadowrocket 应从 App Store 获取。应用是一次性买断的商业客户端，客户端买断 ≠ 线路套餐；购买或重新获取应用，不会自动生成用户自己的服务配置。iPhone、iPad 及其他兼容设备的系统要求均以 App Store 页面标注为准。

1. 完成首次打开后，先恢复 Config 文件，查看内容并选用；保留旧设备与独立备份，暂不删除原始资料。
2. 在 Home 恢复自己已有的服务器或 Subscribe。订阅地址属于访问凭据；本文中的 https://example.com/sub?token=xxxx 仅说明格式，不是可用服务。
3. 执行一次订阅更新，核对服务是否仍有效、记录是否齐全。更新取得的列表可能与旧设备不同，原先选择的记录需要重新确认。
4. 按系统提示允许添加 VPN 配置。即使配置文件已经恢复，新设备的系统连接授权仍应以本机实际提示为准。
5. 为了验证规则，检查 Global Routing 使用 Config。若先用 Proxy 验证已有服务是否能连接，完成后应返回 Config 再验证 Rule。

导入后若出现策略名称无法对应的情况，检查 Rule 中引用的名称是否在当前配置里存在。自定义策略组名称需要与引用一致；不要只改其中一处。订阅更新后服务器名称发生变化时，也要重新核对相关组的成员与选择状态。

六、迁移后核对规则、DNS 与 On Demand

验收时固定网络环境，每次只改一个变量。先确认所选服务器能用于建立连接，再检查 Rule 命中，最后恢复自动连接条件。否则同时修改 DNS、服务器和 On Demand，即使现象改善，也无法判断是哪一项起作用。

• 协议字段：保留原来的 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard 类型。服务器地址和端口相同，不代表不同协议的字段可以互换；密码、UUID、TLS 名称或密钥等以自己的服务资料为准。
• DNS 与外部资源：如果配置依赖远程规则资源或外部文件，还要验证这些资源能够取得。一个配置文本的副本，不能证明所有外部资源也已经保存到新设备。
• 请求记录：重新发起请求后，查看应用内对应记录的目标、规则与策略。出现 DIRECT 可能是规则的预期结果，不应直接当作连接故障。
• On Demand：手动连接通过后，切换到实际使用的 Wi-Fi 或蜂窝网络检查触发结果。网络条件与旧设备不一致时，原有条件需要重新核对。

七、配置恢复常见问题