官方手册 / Settings 设置项参考
Shadowrocket
Settings 设置项与取值依据
按用途查阅 DNS、On Demand、Proxy、Ping、Log、Widget 与 iCloud 同步，先确认设置作用范围，再决定是否调整。
Shadowrocket 是只在 Apple 平台发行的付费客户端，唯一获取入口为 App Store。开发者为 Shadow Launch Technology Limited，应用 ID 为 932747118；设备兼容性与系统要求以 App Store 页面标注为准。购买前可阅读App Store 正版核对说明。
本页是系统查阅手册，不替代首次连接流程。尚未完成导入与授权时，先按入门指南走完主线；已经可以连接、需要理解某个选项时，再回到本页。下文均以用户已有自己的订阅或服务器信息为前提。客户端一次性买断 ≠ 线路套餐。
01 / 作用范围与默认状态
Settings 设置基线与调整顺序
区分应用设置、配置文件与服务器参数
Settings（设置）主要承载客户端的行为选项，但一次连接并不只受这里控制。Home（首页）中选中的服务器、Global Routing（全局路由）的姿态、Config（配置）中启用的文件，以及系统授予的 VPN 权限，共同决定请求如何处理。排查前应先辨认问题属于哪一层，否则容易在 DNS 中寻找认证错误的原因，或用切换服务器掩盖规则匹配问题。
服务器地址、端口、认证内容与协议传输参数属于连接资料，应与用户已有的信息逐项核对。规则顺序、目标策略及部分解析行为可能来自配置文件。Widget（小组件）和日志偏向操作与观察，不负责修复服务器资料。把这几类内容分别记录，能够看出修改是否真正触及故障原因，也方便在试验后只恢复相关部分。
本手册不把某个设备当前显示的开关状态写成所有安装环境的固定默认值。首次安装、恢复数据、导入配置和跨设备同步，可能形成不同的起始状态。默认值应在未主动修改的实际环境中核对；已有数据的设备应称为“当前值”。遇到界面未显示某项时，不要为了对照文章而创建不存在的入口或参数。
Global Routing 的三种姿态
| 姿态 | 主要用途 | 检查重点 |
|---|---|---|
| Config（配置） | 依据当前配置中的规则分流。 | 活动配置、规则顺序与策略指向。 |
| Proxy（代理） | 将适用流量交由所选代理处理。 | 服务器连接与目标请求是否成功。 |
| Direct（直连） | 将适用流量按直连方式处理。 | 当前网络本身的访问与解析情况。 |
三种姿态不是三档速度，也不改变远端服务的能力。日常需要规则分流时，以理解并维护好 Config 为前提；Proxy 和 Direct 可以用于短时对照，但测试结束应恢复原来的工作姿态。Direct 表示路由处理方式，不等于已经关闭系统 VPN。判断连接是否断开，应同时检查应用连接状态与系统中的 VPN 状态。
建立可以撤回的修改记录
- 记录当前网络类型、连接状态、服务器备注、Global Routing 姿态和活动配置名称；不要把订阅完整地址写入记录。
- 写下准备修改的设置项、当前值、修改理由和预期观察结果，再只调整这一项。
- 结束旧请求；需要重建连接的设置在断开后重新连接，再用相同目标进行验证。
- 若结果没有改善，恢复原值后继续下一项；不要把多个未经验证的调整永久叠加。
推荐取值首先服务于明确需求，而不是把开关全部打开。尚无特定解析需求时，保留已验证可用的 DNS 设置；尚未理解自动触发条件时，先手动连接；排查完成后，再将详细日志恢复到日常使用所需的程度。这些建议描述的是调整原则，不替代当前界面的实际默认状态，也不要求已经稳定工作的用户重新配置。
如果连首次系统授权都尚未完成，应先回到入门流程，而不是继续微调高级选项。若只有某个目标异常，可保留当前连接并从请求记录入手；若全部目标同时失败，则先检查基础网络与服务器连接。更多现象分类可参阅常见问题，再按对应章节继续查阅。
02 / 域名解析
DNS 设置与解析路径
解析成功与请求成功是两件事
DNS（域名系统）把域名转换为可连接的地址，但得到地址并不代表目标服务已经可用。一个请求可能依次经历本地解析、规则判断、代理连接和目标响应；不同配置下，解析与规则判断的先后及执行位置也可能不同。遇到页面打不开时，应先看失败发生在哪一环，不能因为更换 DNS 后偶尔恢复，就把所有问题归因于解析。
需要区分服务器域名与目标域名。前者用于建立到代理服务器的连接，若它无法解析，连接可能在到达代理之前就失败；后者是浏览器或其他应用请求的地址。两者可能走不同路径。记录错误时应说明“服务器地址解析失败”还是“连接后目标域名失败”，而不是笼统写成 DNS 不可用，这会直接影响后续排查方向。
核对当前 DNS 设置时，先确认活动 Config 是否也包含解析相关内容，再检查 Settings 中显示的选项。不要同时在多个入口加入不同解析地址后，凭界面上最后改动的一项判断实际行为。若无法确认覆盖关系，可以保存现有配置，在可撤回的副本中减少重复设置，并结合 Log（日志）观察新的请求。
默认值与推荐取值的判断依据
本手册不规定通用的公共解析地址，也不把某个地址当作所有网络的推荐答案。没有明确需要时，保留当前经过验证的解析方式；需要访问局域网名称时，先确认当前网络提供的解析能否识别这些名称。将所有解析交给外部解析器，可能使内部域名失去对应结果，因此“能解析公共域名”并不能证明适合整个使用场景。
若界面提供加密 DNS 方式，应核对其完整地址格式、证书验证和连通条件。加密描述的是解析传输的保护方式，不代表解析结果必然适合当前网络。解析器本身也需要可达；如果它的连接依赖尚未建立的代理，而代理服务器域名又依赖该解析器，便可能形成启动依赖问题。应先恢复可独立完成连接前解析的路径。
| 现象 | 优先核对 | 不宜直接推断 |
|---|---|---|
| 连接前就失败 | 服务器域名解析及基础网络。 | 不能直接认定目标网站故障。 |
| 只有内部名称失败 | 网络提供的解析与内部域名处理。 | 不能只比较公共域名结果。 |
| 切换网络后异常 | 新网络可达性、缓存及连接重建。 | 不能只看切换前的成功记录。 |
| 只有部分地址失败 | 地址族、规则路径与目标连通。 | 不能把全部解析都判为失败。 |
IPv6、缓存与重复验证
一个域名可能返回不同地址族的记录，也可能根据网络位置返回不同地址。IPv6 相关选项应以当前网络和服务器路径是否支持为依据，不宜仅因某一次访问失败便长期关闭。若相同域名在不同网络表现不同，应比较实际使用的地址族、规则策略和连接错误。解析记录存在，只说明获得了候选地址，不说明对应路径能够完成通信。
修改解析设置后，旧连接和缓存可能继续影响结果。先结束目标应用中的旧请求，必要时重新建立 Shadowrocket 连接，再发起新的访问；若当前界面提供清理相关缓存的操作，可在记录原状态后使用。不要把不断刷新同一页面当成独立测试，因为它可能复用既有连接，甚至只读取页面缓存而没有发出新的网络请求。
一个可重复的验证顺序是：确认基础网络可访问，核对服务器域名可以解析，建立连接，再访问固定目标并检查对应记录。之后只修改一个 DNS 相关选项，重建必要连接，再重复同样流程。前后记录应处于相同网络与相同路由姿态；若中途更换了网络，就应将它视为另一组测试，而不是直接比较。
排查完成后，把临时添加但未证实有效的解析项移除或恢复原值，并保留最终选择的理由。长期设置应能够解释其适用条件，例如保留内部域名解析、满足已知网络要求，或修复已经复现的依赖问题，而不是只记住某个地址“曾经有效”。
03 / 自动连接与系统权限
On Demand 的触发与停止
按需连接不是持续产生业务请求
On Demand（按需连接）用于让系统按照已配置的条件管理连接触发。它处理的是何时尝试连接，而不是为目标访问选择规则策略。开关开启后，仍需有效的服务器资料、可用的网络和相应系统权限；如果认证信息失效，自动触发只会再次遇到相同错误，不会自行更正服务器参数或补齐订阅内容。
阅读这一项时，应把应用内的设置、系统保存的 VPN 配置和当前连接状态分开。应用界面退出到后台，不一定代表系统连接已经结束；一次手动断开，也不一定意味着后续匹配条件不会再次触发连接。判断行为时，需要说明是在关闭自动触发前断开，还是关闭后仍然重新连接，这两类现象的排查顺序不同。
首次连接可能出现添加 VPN 配置的系统提示，这是 Apple 系统授权应用建立相关网络连接的流程。应先确认提示来自正在操作的 Shadowrocket，再依据系统要求完成验证。拒绝后，后续设置即使填写正确，也可能无法建立连接。可在系统“设置 › 通用 › VPN 与设备管理”核对相关条目，具体路径以设备实际显示为准。
先手动验证，再启用条件
- 暂不依赖自动触发，使用当前服务器与 Config 手动连接，并确认固定目标可访问。
- 进入 Settings 查找 On Demand，记录当前开关及已有条件；条件名称与可选范围以当前界面为准。
- 只启用需要的一组条件，断开后重新进入对应网络场景，观察系统是否按预期触发。
- 再进入不应触发的场景，检查是否保持预期状态；最后验证手动停止的完整流程。
推荐策略是从最少条件开始，而不是一次覆盖所有网络。若只是希望在特定网络条件下连接，应先确认当前界面是否提供相应条件，以及条件的匹配与例外关系。网络名称接近不代表同一网络，空白、大小写或重新命名也可能影响辨认。记录时应使用自己能够识别的备注，但不要公开家庭网络的完整识别信息。
不要将“自动连接已开启”写成“始终保持连接”。网络切换、系统调度、服务器不可达、设备休眠及授权变化都可能影响实际状态。需要判断是否工作时，应结合连接指示和真实请求，而不是只看 On Demand 开关。若设备长时间没有业务请求，观察不到新日志也不必然代表自动触发失效。
处理反复连接与网络切换
当连接在断开后反复恢复时，先关闭 On Demand，再执行手动断开，随后观察系统状态。若仍有异常，检查是否存在其他由自己配置的自动化行为或重复 VPN 条目，逐个辨认用途后再处理。不要一开始就删除全部网络配置，因为这会同时丢失其他必要信息，也使原本可复现的触发条件难以追踪。
在需要先通过网页完成登录的 Wi-Fi 网络中，应优先完成该网络的接入流程。若自动连接使登录页面难以打开，可暂时关闭 On Demand 并断开，再按网络要求完成验证。接入完成后恢复原有设置并重新测试。这个过程解决的是基础网络尚未具备访问条件，不应通过永久放宽证书验证或长期更改代理参数处理。
从 Wi-Fi 切换到蜂窝网络后，原连接可能需要重建。应观察新的连接记录，而不是沿用切换前的成功判断。若只在某一种网络下失败，分别手动测试并记录结果，再决定是否为该网络调整触发条件。自动连接的配置应建立在两种网络各自可工作的基础上，否则自动化只会把基础故障重复呈现出来。
授权被误删或拒绝后，可先确认应用仍从 App Store 正常安装，再回到连接操作检查系统是否重新请求授权。关于系统条目的辨认与恢复，参阅添加 VPN 配置提示说明。不要把系统配置删除与订阅删除混为一谈，两者管理的是不同层面的数据。
04 / 连接参数与本地监听
Proxy、协议与端口作用范围
远端服务器端口与本地端口
Proxy（代理）相关内容最容易混淆的是两类端口：服务器资料中的端口指向远端服务，本地监听端口则用于接收按相应方式接入的请求。二者即使碰巧数值相同，也没有必须保持一致的关系。修改本地端口不会修复远端认证失败，修改远端端口也不会让其他设备自动获得本地代理接入能力。
先查看正在编辑的是 Add Server（添加服务器）中的连接资料，还是 Settings 中当前设备提供的监听相关选项。远端端口必须与用户已有的服务器信息一致，不能根据“常用端口”猜测。若资料来自 Subscribe（订阅），还要确认后续更新是否会重写手动修改的字段；必要时保留单独备注，避免下一次更新后误以为设置自行失效。
本地端口只有在相应监听功能启用且接入方式匹配时才有意义。端口号相同并不能使 HTTP 与 SOCKS5 自动互通，调用方必须使用监听端实际支持的协议。普通的设备内使用并不意味着需要主动开放本地监听；没有明确接入需求时，保留当前已验证的状态，不为排查网页问题而扩大监听范围。
端口取值与访问边界
如果当前界面提供本地端口编辑，先记录原值与监听范围，再确认该端口未被其他服务占用。端口在有效范围内只是基本条件，是否能成功绑定还受系统权限与运行环境影响。因此本手册不指定一个适用于所有设备的默认端口，也不建议为了记忆方便，把多个不同服务配置成相同监听地址与端口组合。
| 字段所在层次 | 含义 | 取值依据 |
|---|---|---|
| 远端服务器端口 | 连接远端服务的目标端口。 | 已有服务器资料。 |
| 本地监听端口 | 接收对应代理协议请求的入口。 | 实际接入需要与可用端口。 |
| 监听地址或范围 | 哪些网络接口能够接入。 | 最小必要访问范围。 |
| 认证与传输字段 | 连接身份及传输约定。 | 服务端配置的对应参数。 |
若界面支持局域网接入，应先确认当前网络可信，以及接入方确实需要使用该能力。可供其他设备访问的监听，不能按“只在本机使用”理解；其他设备是否可达，还受网络隔离和系统限制影响。若提供访问认证，应按实际需求配置并保护凭据，使用结束后恢复最小必要范围，避免把临时测试变成长期开口。
不要用客户端监听端口替代路由器中的网络概念，也不要将绑定失败等同于服务器离线。出现绑定错误时，优先恢复原端口、停止重复监听或重启相关连接，再观察错误是否消失。只有成功建立本地入口后，才继续检查请求是否经过正确的服务器与规则路径，否则多个故障会叠在同一次测试里。
协议参数应按资料逐项对应
Shadowsocks、VMess、VLESS、Trojan、WireGuard 与 Hysteria2 是不同的协议或连接方式名称，不是可以随意替换的标签。服务器地址与端口相同，也不代表其他认证和传输字段能够复用。先确认协议类型，再核对当前界面显示的必需字段；不要为减少输入而把没有依据的值填入证书、服务器名称或传输相关选项。
当连接资料要求 TLS 时，应保持证书验证与服务器身份信息一致。地址用于连接到哪里，服务器名称可能参与身份验证，二者不一定具有同一种用途。遇到证书错误，应核对设备时间、已有资料中的名称和证书状态，不应把关闭验证当作长期推荐取值。能够建立加密连接与确认连接到预期服务器，是需要分别满足的条件。
UDP 相关能力也取决于协议、远端服务和当前网络，不能只根据一个开关推断所有请求都能传输。网页访问成功，不足以证明其他类型请求正常；反过来，某种业务失败也不代表整个代理不可用。应使用与故障业务相对应的验证方式，并结合 Log 区分本地接入失败、远端连接失败与目标响应失败。
05 / 测量对象与对照方法
Ping 与 Connectivity Test
先确认测试究竟测到哪一段
Ping（延迟测试）显示的是特定测试条件下的响应情况，不是线路质量的完整结论。界面中使用 Ping 这个名称，也不应直接推断底层一定采用某一种探测方法。若当前版本提供测试方式选择，应先读清其说明，确认测试针对服务器地址、连接建立过程还是某个目标请求，再解释结果代表什么。
Connectivity Test（连通性测试）与业务访问同样需要区分。某项测试成功，可能只证明测试目标能够响应；业务应用仍可能受 DNS、规则、认证、目标限制或连接复用影响。测试失败也可能因为探测方式在当前网络不适用，而服务器对实际业务仍可工作。因此应把测试结果作为证据之一，而不是唯一的可用性判定。
对延迟数字的比较，必须保持测量条件一致。相同服务器在不同网络、不同时间或不同测试目标下得到的结果不能直接排序。即使数值较低，也不代表持续传输、丢包表现或长连接稳定性更好。选择日常使用的连接时，应结合自己的真实访问场景，并优先关注可重复的成功与失败，而非一次测量的最小值。
测试目标、超时与并发的取值依据
若 Settings 提供测试目标或超时等选项，默认值应以当前界面显示为准。没有排查需求时，保留已验证可用的设置；需要更换目标时，选择自己有权访问、行为稳定且能确认响应含义的目标。不应为了得到漂亮结果，选用只在特定网络中可达、会频繁跳转或需要登录的地址，再把它当作所有访问的代表。
超时设得过短，可能把正常但响应较慢的连接判为失败；设得过长，则会延后故障发现。取值应服务于测试目的，而不是一律越小越好。若当前界面没有对应选项，就不必按其他资料寻找同名字段。调整后应先用已知能够工作的连接验证测试本身，再测试可疑连接，避免把错误的测量设置带入所有结果。
一次触发大量测试会增加瞬时连接与网络负担，结果也可能互相影响。管理多个已有订阅时，可先按分组缩小范围，再对需要比较的条目进行测试。不要在更新订阅、切换网络和重建连接的同时连续测量，因为这些动作同时改变了输入条件，很难分辨差异来自测试对象还是设备当时的状态。
一组可重复的测试记录
- 固定网络与 Global Routing 姿态，记录当前服务器备注和测试方式，不记录认证字段。
- 先访问一个已知可以使用的目标，确认设备基础网络与测试目标本身处于可用状态。
- 对同一条目间隔重复测试，观察是否稳定成功，而不是只保存最小的一次结果。
- 再使用真实业务发起新请求，核对 Log 中的策略与连接结果，最后恢复临时测试设置。
如果测试全部超时，先检查测试目标和基础网络，不要立即删除整个订阅。若只有单个条目失败，核对该条目的服务器信息及最近一次更新是否完整；若测试成功但业务失败，检查业务请求是否实际使用同一服务器，以及 Config 是否将目标分到了不同策略。这种分层方式能减少不必要的全局改动。
当测试只在 Wi-Fi 或蜂窝网络中的一种失败时，应为两种网络分别建立记录。不要把切换网络前保留的数值当作新网络结果，也不要根据旧排序直接判断当前最合适的条目。必要时等待基础网络稳定，再重建连接并重新测试；对频繁变动的环境，应优先分析失败模式，而不是维持一个静态排名。
看到空白、未测试或失败标记时，应按界面含义记录，不要自行换算成延迟数值。把“没有完成测量”与“测量得到较慢结果”分开，能够避免排序误读。若结果长期互相矛盾，可暂时停止批量测试，使用一个固定目标和单条连接，结合下一章的日志方法重新建立最小可复现场景。
06 / 观察证据与信息保护
Log 的读取与故障定位
用一条新请求建立时间线
Log（日志）的价值在于把操作与结果对应起来，而不是积累越多记录越好。开始排查前，先记下当前网络、Global Routing 姿态、活动 Config 和选中服务器，再发起一个新的目标请求。之后按时间顺序寻找相关记录，区分域名解析、规则匹配、连接建立与目标响应，避免把背景应用产生的请求误认为正在测试的访问。
若当前界面提供日志开关或详细程度选择，日常保留满足观察需要的级别；复现故障时，再临时增加必要细节。具体默认状态以设备当前显示为准，不应假定所有安装环境都持续记录同样内容。更详细的日志可能增加存储与处理负担，也可能包含更多访问相关信息，因此排查结束后应恢复日常所需状态。
没有新日志不必然说明客户端没有工作。目标应用可能复用既有连接、读取本地缓存，或者该流量不属于当前记录范围。先确认测试是否真正发出新请求，再检查连接状态和日志设置。反复切换多个开关只会改变观察条件；用一个固定目标、一次明确操作和一段短时间记录，更容易建立可靠的因果关系。
按失败层次阅读记录
| 观察层次 | 主要问题 | 下一步 |
|---|---|---|
| 解析 | 域名是否得到可用地址。 | 区分服务器域名与目标域名。 |
| 规则 | 请求匹配了哪条规则与策略。 | 检查活动配置和前序规则。 |
| 连接 | 是否建立到远端的连接。 | 核对服务器、认证与网络。 |
| 目标响应 | 连接后目标是否返回预期内容。 | 检查业务本身及响应含义。 |
若记录显示请求走了 DIRECT，而预期应使用 PROXY，应先查规则与活动配置，不必急着更换服务器。若确实走了预期策略但远端连接失败，再核对服务器资料。若连接已经建立，目标却返回业务错误，则应继续看响应本身。日志中的某个“成功”通常只描述一个阶段，不能直接等同于整个业务流程完成。
规则匹配要关注第一条实际生效的条件。后面存在一条看似正确的规则，并不能证明请求会到达它。还应留意目标是否通过不同子域名请求资源，或是否使用新的连接路径。页面主体能够打开而部分资源失败时，可分别寻找这些资源的记录，不应把页面中的所有请求都当作一个域名处理。
连接失败的描述也应保持具体。超时、认证不匹配与证书验证错误指向不同问题；不要把它们统一归为“速度慢”。核对设备时间、服务器地址、端口和协议参数后，再决定是否需要向自己的服务商确认资料状态。向外说明时，可以提供错误类别和出现条件，不必提供认证内容或完整订阅地址。
保存最小证据，避免扩大暴露范围
日志可能包含访问域名、目标地址、服务器备注及其他上下文。分享前先检查内容，只保留与故障有关的短片段，并移除订阅地址中的敏感部分、认证字段和个人网络标识。截图也需要检查状态栏、列表备注与相邻记录；遮住一个字段并不意味着整张图已经适合公开，应重新通读所有可见内容。
建议形成一段简洁说明：在什么网络下，使用何种路由姿态，对哪个目标发起什么操作，预期结果与实际结果分别是什么，恢复原设置后是否变化。这样的描述配合经过整理的错误片段，比完整导出长时间日志更容易复现。若无法确定哪些字段敏感，优先用文字概述错误类型，而不是直接发送原始文件。
排查结束后，保存最终有效的设置差异与恢复步骤，再按需要清理不再使用的本地记录。清理日志不会修复导致错误的设置，也不等于删除订阅；两者应分别处理。若同类问题再次出现，可以先对照上次的网络条件和失败层次，而不必从头尝试所有设置。
07 / 快捷操作与跨设备数据
Widget 与 iCloud 同步边界
Widget 是入口，不是独立连接配置
Widget（小组件）用于提供系统允许的快捷查看或操作入口，具体内容以设备可添加的组件为准。它通常依赖应用已经完成的设置，不能替代首次导入、VPN 授权与手动连接验证。添加组件前，应先在 Shadowrocket 内确认当前服务器和配置能够使用，再检查组件呈现的状态与应用内状态是否一致。
组件显示可能受到系统刷新安排影响，不应把尚未更新的画面当作即时连接证据。需要确认操作是否生效时，进入应用检查当前连接，并发起新的目标请求。若组件操作后没有预期变化，先核对应用是否需要完成授权、连接资料是否有效，以及系统是否允许相关行为，而不是立刻修改 DNS 或服务器参数。
推荐把组件用于已经熟悉的常用操作，而不是在未理解状态时连续点击。快速重复操作可能使连接处于正在建立或正在断开的过渡阶段，画面与实际状态暂时不一致。先等待一次操作完成，再执行下一次；若需要停止自动重连，仍应按 On Demand 章节的顺序处理，不能只依赖组件上的一次断开动作。
iCloud 同步不等于完整设备复制
Settings 中若提供 iCloud Sync（iCloud 同步）或相关入口，应先确认设备已按系统要求登录并允许应用使用 iCloud。可同步哪些数据、是否需要手动触发，以及是否存在独立的导入导出入口，均以当前界面说明为准。不要预设所有服务器、配置、开关、日志与系统权限都会自动同步，也不要把一次成功同步当作长期备份保证。
App Store 的购买账户与设备使用的 iCloud 账户属于不同用途。恢复购买解决的是应用获取资格，iCloud 同步解决的是受支持的数据传递，二者不能相互替代。换机时能够重新下载应用，不代表旧设备的所有连接资料已经存在；反过来，看到同步数据，也不代表已经完成当前设备所需的 VPN 授权。
启用前先保留可恢复的资料，并确认哪些内容只存在本机。若当前界面提供导出能力，应检查导出范围与文件内容，妥善保管其中可能包含的认证信息。备份应放在自己控制且能够恢复的位置，不应把完整资料放进公开文档。对同步默认状态的判断同样应基于当前设备，而不是用另一台设备的状态推断。
两台设备出现差异时的处理顺序
- 分别记录两台设备的活动 Config、服务器备注和最近一次手动修改，先不要同时编辑同一份数据。
- 核对系统中的 iCloud 使用条件与应用实际提供的同步范围，确认两端检查的是同一类资料。
- 确定哪一份是需要保留的内容，在可恢复的前提下再执行界面提供的同步或导入操作。
- 逐台验证列表、配置选择与真实连接，不以文件名称相同代替内容核对。
当两端都修改过同一内容时，不应假定最近打开应用的设备一定会覆盖另一端，也不应连续操作期待自动得到正确合并。先保存两份差异，再依据应用实际呈现的冲突处理方式选择保留内容。若界面没有说明合并规则，采用单一设备完成修改、其他设备验证结果的方式，通常比同时编辑更容易追踪。
同一配置在 iPhone 与 iPad 上呈现不同布局，并不代表数据不同。应比较具体字段与活动状态，而不是只看列表宽度或按钮位置。iPad 的购买恢复和布局说明可参阅iPad 购买与界面说明；共享购买、设备兼容性及系统要求以 App Store 页面标注为准，不从同步结果反推适用范围。
同步后若出现旧服务器或重复条目，先辨认它来自订阅更新、手动导入还是同步资料，再决定清理对象。删除前保留需要的备注与本地修改，避免把仍在使用的来源一起删除。组件只是提供操作入口，同步只是传递受支持的数据，最终仍要以本机活动配置和真实访问结果确认设置是否正确。
08 / 配置协作与恢复检查
Config、Subscribe 与设置恢复
更新服务器资料不等于更新全部设置
Subscribe（订阅）通常用于维护用户已有的服务器资料，Config（配置）用于承载规则及相关配置内容，Settings 则管理客户端提供的行为选项。更新订阅后看到了新条目，不等于当前活动规则也随之改变；编辑了一份配置，也不等于它已经被选中使用。每次变更后，都应核对列表内容、活动选择和实际请求三者是否一致。
多个订阅并存时，先用自己能够辨认的备注区分来源，再处理排序与重复条目。名称相同不一定代表参数相同，参数相近也不一定需要同时保留。不要仅根据显示名称批量删除，更不要把完整订阅地址放进备注以便区分。有关分组、重复条目与删除顺序，可继续阅读多个订阅链接管理说明。
在已有订阅条目上手动修改参数前，应确认后续更新是否会覆盖改动。若需要保留特殊调整，先记录差异，并使用当前界面支持的方式建立独立、可辨认的资料。一次更新后连接变化，优先对照服务器字段和选中条目，不必立即重置全部 Settings。只有证据表明故障来自客户端选项，才进入对应章节调整。
规则示例与匹配顺序
下面是 Shadowrocket .conf 中的规则片段，用于说明关键字、目标与策略的关系。它不是完整配置，也不包含服务器资料；应用到自己的配置前，必须确认对应策略能够按预期工作。示例主机仅使用 example.com，不代表应将任何真实业务统一照抄到相同路径。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX 根据域名后缀匹配，适合描述某个域及其子域；GEOIP 依据地址所属地区数据进行匹配，其结果受到地址与数据内容影响；FINAL 是前面没有匹配时的收尾处理。规则通常按顺序检查，因此更具体的需求应放在能够影响它的宽泛规则之前，收尾规则应放在末尾。
| 关键字 | 匹配依据 | 注意事项 |
|---|---|---|
| DOMAIN | 完整域名。 | 不等同于全部子域名。 |
| DOMAIN-SUFFIX | 域名后缀。 | 检查是否覆盖了过宽范围。 |
| IP-CIDR / IP-CIDR6 | 对应地址族的网段。 | 域名请求还可能涉及解析。 |
| FINAL | 此前未匹配的请求。 | 检查最终策略是否符合预期。 |
不要仅凭文本里存在正确规则就认定它已经生效。应确认当前 Global Routing 为 Config、活动文件确实包含该片段，再从 Log 查看新请求的匹配结果。若正在使用 Proxy 或 Direct 姿态，应先恢复正确测试条件。规则测试结束后，也要移除仅为实验添加的条目，避免临时匹配长期改变其他业务。
从最小恢复开始，而不是全部重置
故障出现后，先回想最后一项已经确认的修改。如果更换 DNS 后异常，恢复原解析设置并重建连接；如果编辑规则后异常，回到保存的配置副本；如果订阅更新后异常，核对更新内容与当前服务器。这样的恢复只改变一个层面，既容易验证，也能保留其他正常工作的设置，避免问题与资料损失同时发生。
若无法确认改动来源，可以建立最小检查链：基础网络可用、服务器资料完整、手动连接成功、固定目标可访问，再逐步恢复 Config、On Demand、Widget 与同步。每恢复一项就验证一次，不要在同一次操作中重新导入全部内容并开启所有功能。最小检查链的目的是定位依赖关系，不是要求日常长期使用简化配置。
完成恢复后，最后检查日常路由姿态、自动触发条件、日志详细程度与同步状态，并保存最终有效的差异记录。需要重新走完整操作时返回入门指南；需要按现象查找原因时阅读常见问题。本手册的使用终点不是某一组统一参数，而是每项设置都有明确用途、可验证结果与可执行的撤回步骤。