Shadowrocket 设置详解

01 / 配置来源

Config 与 Global Routing

先确定正在使用哪个 Config，再讨论某个 Settings 项是否有效。Shadowrocket 的实际连接结果不是单个开关决定的：Home 中选择的服务器提供连接参数，Config 承载规则及相关配置，Global Routing 决定采用哪种路由方式，系统网络提供基础连通条件。用户已有的订阅通常用于维护服务器条目，它和用于分流的配置文件不是同一回事。订阅更新成功，并不能据此认定规则或 DNS 已经同步改变。

先区分配置、代理与直连

Global Routing 的 Config、Proxy、Direct 分别对应配置、代理、直连三种姿态。Config 根据当前配置中的规则处理请求；Proxy 用于按代理姿态处理流量；Direct 用于按直连姿态处理流量。这里描述的是路由意图，不代表任意请求都必然成功，也不能据此推断系统中所有连接均由应用处理。排查时应记录当前姿态，避免在 Proxy 下修改规则，却误以为规则没有保存。

规则顺序比规则数量更重要

规则通常自上而下检查，先命中的条目决定后续策略。DOMAIN-SUFFIX 匹配域名本身及其子域名，GEOIP 按目标地址的地理数据库结果匹配，FINAL 接住此前没有命中的请求。把宽泛规则放在前面，可能使下面更具体的例外失去机会。编辑时先找到目标域名相关条目，再检查它上面的规则；不要只搜索文件最后是否存在一行看似正确的内容。

[General]
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

上例只用于解释结构，不是适合所有网络的完整配置。example.com 是示例域名；PROXY、DIRECT 是策略关键字，不能把它们当作服务器地址填写。域名规则先检查示例域名，GEOIP 再处理相应地址，FINAL 最后收尾。实际使用前必须确认已有服务器可用，并按自己的访问需求审阅每条规则。有关匹配范围的进一步说明见DOMAIN-SUFFIX、GEOIP 与 FINAL 的规则写法。

默认状态与建议基线

默认值应以当前安装后的显示及当前选中配置为准。导入配置、恢复数据或切换配置，都可能改变观察到的状态。日常建议在已理解规则内容后使用 Config；Proxy 与 Direct 可以用于对照排错，但不应在测试结束后忘记恢复原来的姿态。首次建立基线时，记录配置名称、选中服务器、Global Routing 和一条测试请求，之后才能判断变化来自哪里。

保存文件和使设置生效是两件需要分别核对的事。修改后先确认编辑内容确实保存，再确认该文件是当前启用的 Config，随后按应用界面提示处理连接状态。已经建立的连接可能继续使用原有路径，因此应重新发起测试请求，而不是只观察一个始终保持打开的页面。若结果仍不符，转到 Log 检查请求记录，不要立即重复导入相同内容。

出现“服务器可以测试，但某个域名失败”时，应先区分服务器可达与规则命中。检查实际请求的完整域名，确认是否存在子域名、跳转域名或不同地址族，再查看它命中的策略。若所有请求都失败，优先检查连接及服务器参数；若只有某一类请求失败，再缩小到规则和 DNS。需要重走首次连接步骤时，返回快速上手教程，不要通过同时重置全部设置掩盖原因。

02 / 名称解析

DNS 设置与解析路径

DNS 的作用是把域名转换为可连接的地址，它不等同于代理服务器，也不直接决定所有请求走哪条路线。排查 DNS 前先确认故障现象：域名无法解析、返回地址后连接失败、网页主文档成功但附加资源失败，是不同阶段的问题。只有第一类明显指向名称解析；其他情况还需要检查路由、服务器、目标服务和连接日志。不要把任何打不开的页面都归因于 DNS。

先检查当前 Config 的 DNS 内容

DNS 相关行为可能来自当前 Config，而不仅是 Settings 中某个入口。查阅时先打开当前配置，核对是否显式设置了解析服务器、域名映射或相关选项，再看应用界面所显示的状态。未显式填写不代表所有网络环境都会得到相同结果：系统提供的解析条件会随 Wi-Fi、蜂窝网络及网络接入状态变化。本文不规定一个适用于全部设备的固定 DNS 地址。

配置中的 dns-server = system 表示使用系统提供的 DNS，是理解配置来源时可采用的基线示例，不代表应用在所有情形下的出厂默认内容。若已有配置明确指定了解析方式，应先理解原有设计再修改。不要只把这一行粘贴进文件末尾；它属于相应的配置分节，还应避免重复定义造成阅读上的歧义。修改前保留完整副本，便于逐项恢复。

解析传输与请求路由分别判断

普通 DNS 与加密 DNS 的区别在于解析请求的传输方式，不能据此保证解析结果必定正确或访问必定成功。采用加密解析时，还需要先建立到解析服务的连接；若解析服务使用域名作为入口，其自身的地址发现也可能成为前置条件。配置过于复杂时容易形成排查循环：业务域名等待解析，而解析服务又依赖尚未就绪的路径。出现这种现象，应先恢复已验证的简单基线。

IPv4、IPv6 与缓存的边界

同一域名可能返回 IPv4 和 IPv6 地址。能够解析出某一类地址，不等于当前网络或选中服务器具备对应的可用路径。若请求总在某个地址族失败，应结合日志确认实际连接的地址，再检查网络条件。不要把关闭某个地址族写成普遍建议；它可能让一个测试暂时通过，却掩盖原先的路径问题，也可能影响其他已正常工作的请求。

缓存会让修改后的结果看起来没有变化，但缓存不只存在于 Shadowrocket。系统、浏览器、应用以及上游解析服务都可能保留结果，已建立的连接也未必重新解析。验证时可关闭原测试连接，再发起新的请求；若应用提供相关清理操作，应先了解清理范围。不要反复在多个位置清空数据，这既增加操作量，也会丢失用于比较的现场信息。

推荐取值与验证步骤

对没有特定解析需求的用户，建议先保留当前可用配置的 DNS 设置。需要调整时，只使用自己已确认用途与可达性的解析服务，并一次修改一项。依次记录原配置、目标域名、返回地址、命中策略和连接结果，再在相同网络下复测。若只比较网页加载快慢，而没有确认实际解析是否发生，就无法判断变化究竟来自 DNS、缓存还是目标服务。

应用内部自行完成的解析、保留的历史连接和不同的网络请求方式，会使诊断结果与某个业务应用的表现不完全一致。更可靠的方法是在同一网络、同一 Global Routing、同一服务器下，用同一目标连续比较。若 DNS 已返回合理地址而访问仍失败，应转到 Log 和 Proxy 端口章节继续定位，而不是不断替换解析地址。常见连接症状也可在问答页按现象查阅。

03 / 连接触发

On Demand 按需连接

On Demand 用于按条件触发 VPN 连接行为，不是规则分流的另一种写法。它回答“何时尝试建立连接”，Global Routing 和 Config 则回答“连接建立后如何处理请求”。因此，开启 On Demand 并不会自动修复错误的服务器参数，也不会替你选择合适的规则。设置前应先通过手动连接验证已有服务器可用，再考虑把这套已验证的连接交给条件触发。

默认状态以当前配置为准

不要凭其他设备的截图推断 On Demand 的默认状态。首次安装、恢复系统数据、重新添加 VPN 配置以及修改应用内条件，都可能影响当前观察结果。应在 Shadowrocket 中核对开关与条件，再在系统的 VPN 相关设置中确认对应配置。若设备同时保留多份 VPN 配置，还要先确认当前操作的确实是 Shadowrocket 所用配置，避免修改了另一条历史记录。

首次启用连接功能时，系统可能要求允许添加 VPN 配置。这是让系统登记连接配置的授权步骤，不是购买确认，也不代表服务器已经验证成功。应阅读系统弹窗，确认来源后再操作；若取消授权，应回到应用按界面引导重新发起。不要在没有理解影响范围的情况下删除其他系统配置，受管理设备还可能存在需要管理员处理的限制。

按网络条件设计，不按猜测叠加条件

如果当前界面提供 Wi-Fi、蜂窝网络或指定网络等条件，应逐项阅读其触发含义。识别某个 Wi-Fi 名称并不能证明该网络的全部属性，也不保证接入后立刻可以联网。公共网络可能先要求完成接入确认，网络名称也可能重复。建议先使用简单、可解释的条件，再根据实际需要增加例外，而不是一次建立很多相互覆盖的条件。

测试时至少观察三个阶段：接入网络后是否满足条件、系统是否尝试连接、连接后是否能够完成目标请求。只看到开关变为开启，无法证明最后一个阶段已经成功。记录切换前后的网络类型和时间，再观察应用状态与 Log；若触发成功但业务请求失败，应检查连接参数及路由，不应继续修改触发条件。这样可以避免两个层次的问题互相遮盖。

手动断开与再次触发

启用条件触发后，手动断开不一定意味着以后都保持断开。网络条件再次满足时，系统可能重新尝试连接。需要临时停止自动行为时，应先暂停 On Demand，再处理当前连接，并确认系统显示的状态。排查“刚断开又连接”的现象时，先检查条件是否仍然有效，而不是立即认定开关失灵。测试完成后再恢复需要的条件。

休眠、切网与异常恢复

设备休眠、Wi-Fi 与蜂窝网络切换，以及短暂失去网络，都可能导致现有连接中断或重建。On Demand 不能消除这些基础条件变化，也不应被描述为始终连接的保证。遇到切网后短时失败，先等待系统完成网络接入，再查看是否有重连记录；如果网络本身尚未恢复，反复切换应用开关通常只能产生更多失败记录。

推荐设置取决于使用需求。需要自动触发时，在手动基线稳定后启用最少必要条件；需要可控的排错环境时，暂时停用条件触发，确保一次测试只对应一次连接动作。不要把“全部开启”当作统一推荐。省电、后台状态和连接稳定性之间也不存在一个对所有设备都成立的固定取值，评估应建立在真实使用记录上。

当问题只发生在自动触发时，保留一次成功手动连接与一次失败自动连接的记录，比较网络条件、选中服务器和当前 Config。若两次条件一致但表现不同，再逐项检查系统配置与应用状态。需要完整重做首次授权和连接验证时，请按教程主线执行；不要为了测试 On Demand 同时更改 DNS、规则和协议类型。

04 / 可达性测试

Ping 与 Connectivity Test

Ping 和 Connectivity Test 提供的是特定测试条件下的结果，不是服务器质量的完整结论。测试能回答某个探测是否在规定时间内完成，却不能替代真实业务请求。看到较小的数值，不能直接认定所有页面都会更快；看到超时，也不能单独判定服务器配置失效。应先确认测试方式、测试目标及当前网络，再解释数值代表什么。

先认清测试测到了哪一段

不同测试方式覆盖的连接阶段不同。基础可达性探测、到指定端口的连接尝试，以及通过代理访问目标地址，其依赖条件并不相同。具体可选方式以当前应用界面为准，不应只根据“Ping”这个名称推断一定使用某一种协议。只有了解探测经过哪些阶段，才知道成功或失败能排除什么，不能排除什么。

例如，到服务器端口建立连接成功，并不证明后续认证、TLS 协商和目标访问也都成功；通过代理访问一个测试目标成功，也只证明该目标在当时可达。服务器可能允许一种探测而限制另一种，测试目标本身也可能暂时异常。因此，出现“测试通过但网页打不开”时，应进入 Log 观察真实请求，而不是只重复测速。

默认目标、超时与并发

默认测试目标、超时和并发设置应直接在当前设备读取，已有设置恢复后不一定与初始状态相同。没有明确问题时，建议保留应用当前的测试配置。需要更换目标时，应选择自己能够解释用途、且在当前网络条件下可验证的目标；不要使用带登录信息或私人令牌的地址作为测试入口，也不要把一项业务的访问结果当成全部业务的结论。

超时表示本次测试允许等待多久，而不是给连接分配更多带宽。设置过短可能把暂时波动判为失败，设置过长则会拖慢批量检查。并发过高也可能影响本来就有限的网络资源，让多个测试相互竞争。建议先用少量服务器、相同测试目标建立基线，再按需要调整；不要为追求更小数值反复切换所有参数。

延迟、吞吐与稳定性分别比较

延迟描述一次交互等待的时间，吞吐关注持续传输能力，稳定性则需要观察一段时间内的失败与波动。三者有关联，却不能相互替代。页面还包含 DNS、连接建立、加密协商、服务端处理和资源加载等阶段；一次探测只覆盖其中一部分。选中服务器时，应结合自己实际需要的访问任务，而不是只按列表中的某一个数字排序。

更有价值的比较是控制条件。保持同一设备、同一网络、同一目标与同一种测试方式，分别记录多次结果及失败情况。切换 Wi-Fi 和蜂窝网络之后，应把结果视为另一组数据，不直接与之前混算。测试期间若后台正在同步或传输大量内容，也应在记录里说明，否则无法判断波动来自服务器还是本地竞争。

失败时的分支检查

全部服务器同时失败时，先检查设备是否真正联网、网络是否仍待接入确认，以及测试目标是否可用。只有一个条目失败时，再核对该条目的地址、端口和协议参数。若已有订阅刚刚更新，应确认测试的是更新后的当前条目，而不是手动保留的旧副本。不同协议所需参数不同，不应为了通过测试把类型随意改成另一种。

建议在调整前后各做一组相同条件的测试，再用真实请求确认结果。若数值改善但业务问题没有变化，就不应把该调整当作修复。需要检查 Trojan 认证与 TLS 字段时，可阅读Password、SNI 与 Allow Insecure 参数说明。协议字段应以已有服务器信息为依据，测试失败不是降低证书验证要求的理由。

最后应保留一份可复现的记录：测试时间、网络类型、条目名称、方式、目标和结果。记录不需要暴露密码或订阅地址；用自己能辨认的代号即可。这样的信息比“有时快、有时慢”更有助于后续定位，也方便在更改设置后判断是否真的出现了可重复的改善。

05 / 请求证据

Log 与连接排查

Log 的用途是把连接现象拆成可检查的阶段，而不是看到一个错误词就立即更换全部设置。一次失败可能发生在解析、规则选择、服务器连接、认证、TLS 协商或目标响应阶段。先找到与实际操作对应的记录，再确认失败出现在哪一层，才能决定应该修改 DNS、Config 还是服务器参数。不同界面记录的详细程度可能不同，应以当前应用显示为准。

默认记录状态与开启范围

日志开关、记录级别和保存方式应在当前设备核对，不把某次安装的显示当作固定默认值。日常建议保留满足基本检查需要的状态；只有在复现问题时才提高详细程度，并在结束后恢复。更详细的记录会增加阅读量，也可能包含更多请求信息。开启记录不等于所有历史请求都能被补回，因此必须先安排好测试步骤，再发起目标操作。

一次有效复现应尽量短。先记下当前时间、网络类型、Global Routing、Config 与选中服务器，随后只访问一次目标，再立即查看相关记录。不要同时打开很多应用或重复刷新大量页面，这会让后台连接淹没目标请求。如果应用提供筛选或搜索，可按域名、时间或连接信息缩小范围，但不要仅凭一个模糊名称认定找到的就是同一次连接。

按连接阶段阅读，而非按词猜测

首先查看请求的域名或地址，再确认采用的策略和服务器。若命中了 DIRECT，而原本期望走 PROXY，应先回到 Config 检查规则顺序；这时改服务器密码没有意义。若策略符合预期，再看解析是否完成、是否尝试连接、后续是否有认证或握手错误。日志中缺少某阶段信息，也不能直接证明该阶段没有发生，可能只是当前记录粒度没有显示。

连接超时只是等待超过期限的结果，可能来自路径不通、端口不可达或远端未响应，并不自动证明是哪一方造成。认证错误应先核对已有服务器提供的凭据，注意复制时的空格与字段对应关系。TLS 相关错误则要检查服务器名称、证书及设备时间等条件；不要把开启 Allow Insecure 当作通用修复，它会改变证书校验边界。

Data 与 Log 不互相替代

Data 中的统计和 Log 中的请求细节服务于不同目的。统计可帮助观察某段时间的流量变化，但不能单独说明某个页面为什么失败；请求记录可帮助定位阶段，却不一定等于完整的业务流量账单。也不要把应用统计直接当作已有服务的计费依据，两者的统计口径、时间边界和计算方式可能不同。排错时应优先使用与问题对应的那类证据。

若前台页面失败而没有找到对应记录，先核对是否使用了预期的连接方式、是否仍在复用旧连接，以及日志是否在请求前开启。随后确认目标请求的实际域名，页面跳转或资源加载可能使用不同名称。不要仅因为搜索不到页面标题就断言请求没有经过应用；日志通常围绕网络连接信息组织，而不是围绕网页的可见标题。

导出、脱敏与回退

日志可能包含访问域名、IP 地址、网络名称和连接标识，导出前应检查内容。订阅地址、认证字段和其他能够复用的连接信息不应公开展示。即使只截取一小段，也要查看上下文是否包含敏感值；保留错误阶段与字段结构通常已经足够说明问题，不必附上完整配置。本文示例使用的 example.com 不能替代对真实记录的人工脱敏。

修复后必须重新执行原先失败的操作，并确认新记录中的路径与预期一致。若只看到错误消失，却换成了另一条策略或另一台服务器，应明确这属于条件改变，不能直接证明原问题已被解决。仍无法定位时，可按问答页的故障分类继续缩小范围；涉及域名拒绝策略时，参阅REJECT 的作用与边界，避免把主动拒绝误判为网络故障。

06 / 监听与远端

Proxy 端口与协议参数

端口必须先分清归属。Add Server 中的远端端口属于已有服务器的连接信息；本地 Proxy 相关设置中的监听端口属于设备上的代理入口；业务请求还会连接目标服务自己的端口。三者即使数值碰巧相同，也不是同一项设置。修改本地监听端口，不能修复远端服务端口填写错误；改远端端口，也不会让一个尚未开启的本地入口自动可用。

远端参数按已有服务器信息填写

服务器类型、地址、端口和认证字段必须成套核对。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard、HTTP 与 SOCKS5 的参数结构不同，不存在把同一套字段直接套用到所有协议的通用写法。应按用户已有的服务器说明选择类型，再逐项填写；不知道的字段不凭其他协议的经验猜测，也不因为某个类型看起来更熟悉就改变类型。

端口数值只说明连接目标的一部分，不能单独证明协议类型或 TLS 状态。即使两个服务使用同一常见端口，它们也可能要求完全不同的认证和传输方式。涉及 TLS 的配置，还应分别核对服务器地址与用于名称校验的字段，不能假定两者永远相同。具体字段解释可查阅Trojan 参数说明，而不是通过试填不同密码判断。

本地监听的默认值与调整建议

本地 Proxy 功能的可用入口、监听地址和端口，以当前应用界面提供的选项为准。本文不硬写一个固定默认端口，也不把其他设备的取值作为必须照抄的参数。没有明确的本地代理调用需求时，建议保留原设置，不为排查普通网页访问而额外开启监听。确实需要调整时，先记录原值，并确认使用该入口的应用也同步更新了地址和端口。

有效端口还需要与监听地址和协议类型一起理解。回环地址通常表示只供本机访问，局域网地址涉及网络中的其他设备；扩大监听范围会改变可访问边界。若界面提供局域网访问相关选项，只在明确了解用途时启用，并核对网络环境。不要仅为了让测试通过就扩大范围，也不要把系统 VPN 配置与局域网代理共享视为同一种机制。

端口冲突与连接方式不匹配

当调用方提示连接本地代理失败时，先确认 Shadowrocket 中相应入口实际处于可用状态，再核对监听地址、端口和协议。HTTP 代理入口与 SOCKS5 入口的使用方式不同，调用方必须匹配；向某个端口随意发送请求，不能验证所有协议。若怀疑端口被占用，应按当前界面的错误提示确认，而不是连续更换远端服务器。

修改监听端口后，旧的调用方设置不会自动理解新的取值。浏览器、测试工具或其他支持代理配置的应用，可能仍保留之前的连接地址。应先停止旧测试，再更新调用方，并重新建立连接。若同时保留了系统层连接和应用内单独代理设置，还要明确测试经过哪一条路径，避免重复配置使观察结果难以解释。

连接参数与安全校验分别处理

对于 VMess 与 VLESS，应依据已有服务器信息核对 UUID、传输及相关字段，而不是只比较名称；两者的参数使用存在差异。WireGuard 则需要按其自身的密钥、对端和地址信息理解，不能把它当作只有密码和端口的条目。相关概念见VMess 与 VLESS 的区别以及协议术语表。这些链接用于解释字段，不提供连接资源。

推荐的排查顺序是先验证设备联网，再核对远端信息，再检查协议认证与握手，最后才检查确实参与测试的本地监听入口。完成一次调整后，只用相同目标重新测试，并在 Log 中确认实际路径。如果已有订阅更新了端口或认证信息，先确认选中的条目是否已经更新，不要把旧手动副本与新订阅条目混用。没有证据时保留默认状态，比同时更改多处端口更容易定位问题。

07 / 状态入口

Widget 与系统状态

Widget 是查看状态或触发应用所提供操作的快捷入口，不是独立的连接引擎。它能够展示和执行哪些内容，取决于当前系统、应用提供的组件以及所选择的组件样式。不要根据其他设备上的布局推断自己一定有相同按钮，也不要把组件上的一次状态展示当成目标请求已经成功的证明。需要准确确认连接时，应回到 Home 并实际发起请求。

添加之前先建立应用内基线

建议先在 Shadowrocket 内完成服务器选择、Global Routing 确认及手动连接验证，再添加 Widget。组件无法替代首次导入，也不能补齐缺失的认证信息。首次使用相关操作时，如果系统要求进入应用完成授权，应按提示返回应用处理。反复点击组件不能绕过必须在前台完成的步骤，也可能让多次状态变化难以分辨。

添加位置和组件尺寸由系统提供的编辑界面决定。选中 Shadowrocket 后，检查当前可用样式的说明，再选择适合查看的内容。本文不规定一个固定默认尺寸或默认布局，因为这些会随设备及系统能力变化。组件添加后，先观察静态信息是否与 Home 一致，再测试它提供的操作；不要在尚未完成第一次同步展示时就判断组件已经失效。

刷新延迟不等于连接失败

组件展示受系统刷新机制影响，可能不会在每次连接变化后立刻更新。后台状态、节能条件和系统调度都可能影响观察时间。因此，组件显示与应用内状态短时不一致时，应先打开应用核对，再通过实际请求确认。删除并重新添加组件只是界面层面的处理方式，不应作为所有连接问题的第一步，也不能代替对真实连接日志的检查。

与 On Demand 的关系

如果 On Demand 正在生效，从 Widget 发起断开后，网络条件再次满足时可能出现新的连接尝试。这不是组件拥有另一套隐藏设置，而是条件触发仍在发挥作用。需要验证组件的单次操作时，先暂停 On Demand，再观察点击前后的 Home 和系统状态；测试结束后恢复原先条件。不要同时修改自动触发和组件布局，否则很难判断是哪一步改变了结果。

同样，切换了当前服务器或 Config 后，组件中显示的条目可能需要刷新才能反映变化。应先以应用内选择为准，再等待或按系统提供的正常方式刷新观察。若点击组件打开了应用，应在前台核对实际操作结果，而不是仅看系统页面是否关闭。快捷入口减少的是进入步骤，不减少连接验证所需的条件。

展示内容与隐私边界

Widget 可能放在他人能够看到的屏幕位置。若组件展示服务器名称或连接状态，命名时应避免包含私人账号、用途说明或可复用的连接信息。分享设备画面前，也应检查组件区域，而不只检查应用窗口。组件并非保管订阅凭据的替代方案，不应把完整订阅地址作为便于辨认的名称写进条目中。

日常推荐选择满足需要的最少展示内容，保留应用内可辨认但不敏感的名称。没有快捷操作需求时，不添加组件也不会影响已经配置好的手动连接。出现展示异常时，先记录应用内状态、系统状态与组件内容三者的差异，再检查系统是否仍保留该组件。只有问题局限于展示层，才进一步考虑重新添加，而不是重置网络配置。

需要区分三种常见现象：组件没有刷新，应优先核对展示；组件操作没有完成，应检查是否需要前台授权；连接确实建立但访问失败，应返回 DNS、Config 和 Log。按这个顺序处理，能够避免因为一个过时的展示状态反复断开正常连接。如果问题只发生在切网以后，结合On Demand 章节观察条件变化；首次连接仍未完成时，先回到教程页完成主线，再处理快捷入口。

08 / 数据恢复

iCloud 同步与设置回退

iCloud 相关功能用于应用支持范围内的数据同步或恢复，不等于所有设备上的全部状态都会完全一致。应先在当前界面确认可同步的对象、开关与操作说明，再决定是否启用。服务器条目、配置文件、系统 VPN 授权、当前网络和连接状态属于不同层次；即使某类数据已经同步，其他层次也可能仍需在目标设备上单独确认。

默认状态与系统前置条件

默认同步状态以当前应用和系统设置为准。使用前应确认设备登录的是预期的 Apple 账户，系统允许应用使用相关 iCloud 能力，并且当前网络能够完成同步。不要因为开关已经开启就认定数据已经上传完毕，也不要仅凭另一台设备暂时没有出现内容就立即重复导入。同步需要依赖系统状态，应用内记录和系统界面应结合查看。

应用获取与配置恢复是两件事。换机后应先通过 App Store 获取 Shadowrocket，再处理数据与首次连接授权；系统要求、设备兼容性和购买适用性以 App Store 页面标注为准。正版入口核对方法见正版三要素，已购恢复见换机与重新获取说明。本站不把同步能力写成跨设备购买适用性的依据，两者应分别核对。

先选基准设备，再处理多端修改

启用同步前，先确定哪台设备持有准备保留的完整配置，并保存可识别的副本。不要在两台设备上同时编辑同一份重要内容，然后假设系统一定按你的意图合并。若两端已经出现不同版本，应先比较文件和条目，再决定保留哪份；同步不是人工审阅的替代工具。对不清楚用途的重复记录，也不要在核对前批量删除。

建议使用清楚的名称区分日常配置、测试副本和回退副本，但不要在名称中写入密码或订阅令牌。恢复到新设备后，先核对条目数量、关键字段与 Config 内容，再选择当前使用的服务器和 Global Routing。即使名称相同，内部字段也可能不同；只看列表标题无法确认恢复完整，更无法证明服务器仍然有效。

同步、备份与订阅更新的区别

同步可能把修改传播到其他设备，因此不能简单等同于一个永远保留旧状态的备份。订阅更新则用于获取已有订阅提供的条目信息，不负责解释本地手动修改应该如何合并。需要长期保留的配置，应使用当前应用提供的导出或备份方式另存，并明确保管位置与访问权限；在删除任何云端或本地内容前，先确认副本确实可读。

新设备验证与敏感信息保管

恢复后应重新执行最小验证流程：确认设备联网，检查选中条目，核对 Config，按系统提示完成 VPN 配置授权，再发起一次真实请求。On Demand 应在手动基线正常后测试，Widget 应在应用内状态正常后检查。这样能把数据缺失、授权未完成与服务器失效分开，不至于因为一次连接失败就认定整个同步过程有误。

导出的配置可能包含服务器地址、密码、密钥或订阅令牌，应按连接凭据保管。发送诊断信息时只保留必要结构，不公开完整文件。本文不对具体同步对象的加密方式或保留期限作超出当前界面说明的承诺；需要了解数据处理边界时，应同时阅读隐私政策和系统提供的相关说明。删除前也要核对操作是否会影响其他设备。

需要回退时，先暂停持续产生变化的操作，再恢复已确认的副本，随后逐项复核 DNS、On Demand、测试设置和当前路由姿态。不要把“恢复全部默认”作为第一选择，因为它会丢失对故障来源的判断。完成后保留一份简短变更记录，写清修改项目、原值、新值和验证结果。下一次出现问题时，从最后一次可用状态出发，比重新试遍所有设置更容易得到明确结论。