Shadowrocket 完整使用手册

获取与正版核验：先确认应用，再准备连接资料

Shadowrocket 是 Apple 平台付费客户端，主要使用场景是 iPhone 与 iPad。唯一获取入口是 App Store；Mac、Apple TV 与 Apple Vision 的兼容情况也在同一产品页查看，系统要求与通用购买条件以 App Store 页面标注为准。本手册后续操作围绕 iPhone 与 iPad 展开，不把其他设备的界面布局直接套用到移动设备。购买前先确认目标设备能够打开对应商店页，再阅读兼容性与购买信息，避免把账户问题和连接配置问题混在一起处理。

核对开发者、图标与应用 ID

通过下载指南的正版核验说明进入核对流程。应用名称应为 Shadowrocket，开发者应为 Shadow Launch Technology Limited，应用 ID 为 932747118。图标应与本站页头使用的官方图标一致。名称只能作为第一步辨认依据，搜索列表里的相似名称不能替代开发者与应用 ID 的核对；应用 ID 可以从产品链接末尾的 id932747118 确认。遇到商店搜索结果不明确时，回到下载指南使用产品页入口，不要凭名称相近就继续购买。

进入详情页以后，还要区分产品事实和账户当前状态。价格按钮、重新下载图标、兼容性提示分别表达不同含义：价格涉及购买，重新下载涉及已有购买记录，兼容性涉及当前设备是否满足条件。某一项显示异常，不能推断其他两项也有问题。例如已有购买记录却暂时不能安装，应先看设备与账户提示，而不是反复寻找另一个同名产品。购买前可以记下开发者与应用 ID，换设备核对时仍使用同一组信息。

购买的是客户端，不是连接服务

Shadowrocket 采用一次性买断方式，美区定价约为 2.99 美元，各店面按当地货币显示，实际价格与购买条件以 App Store 页面标注为准。付款取得的是应用的使用资格，不会因此自动获得服务器地址、认证信息或订阅链接。客户端一次性买断 ≠ 线路套餐。订阅请从你的服务商处获取，并确认其适用于 Shadowrocket 的导入方式。尚未准备这些资料时，可以完成安装和阅读界面，但不应把空的服务器列表理解为购买失败。

设备与账户条件分别检查

iPhone 上先核对系统要求，再完成商店购买和安装。iPad 使用同一购买账户时，能否直接重新下载以及适用的购买范围，以 App Store 页面标注为准；不要因为两台设备界面排布不同，就重新创建一套未经核对的参数。店面可见性、付款方式与购买记录都由当前商店账户状态决定。如果产品页暂时不可用，先阅读系统提示，确认当前店面与账户是否支持该购买，再决定下一步，不要把反复切换设置当作通用解决方法。

换机或重装时，应先到 App Store 的账户与已购记录中查找 Shadowrocket，并核对当前用于购买项目的账户。应用下载回来以后，原来的服务器、订阅和配置是否随设备恢复，是另一个需要验证的问题。不要假定应用重新出现就意味着全部连接资料已经恢复。打开后分别检查服务器列表、当前配置和路由姿态，确认内容完整，再进行首次连接测试；具体购买恢复流程可查阅已购恢复说明。

正式进入下一章前，建议准备一份仅供自己查阅的资料清单：订阅来源、服务器协议、认证方式、配置来源，以及哪些设备需要设置。清单不必保存完整密码，可以只标注资料存放的位置。对不确定的参数保持空缺并向资料提供方核实，比猜测一个看似常见的值更可靠。后续任何导入、更新或排查，都应回到这份资料确认来源；应用能安装只说明获取阶段完成，并不证明连接资料有效。

首次启动与权限：理解 VPN 配置和 Home 入口

首次打开 Shadowrocket 时，先观察 Home，不急于打开连接开关。Home 是连接操作的主要入口，其中的连接状态、Global Routing、Connectivity Test 与 SERVER 列表分别负责状态显示、路由选择、连通性测试和服务器选择。它们不是同一件事：列表里有服务器不代表已选中，已选中不代表已经建立连接，系统显示 VPN 状态也不代表所有目标都能访问。先把这些状态分开理解，可以避免后续只盯着顶部开关判断成败。

允许添加 VPN 配置的含义

在首次尝试建立连接等需要创建系统配置的操作中，系统可能询问是否允许添加 VPN 配置。确认这是刚刚由 Shadowrocket 操作触发的提示后，再按系统要求授权；系统可能要求设备密码或其他身份验证。这个步骤让应用能够通过系统提供的网络扩展机制处理相关流量，并不是把某个服务器自动设为可信，也不是替你填写认证信息。授权后仍需要正确的服务器、路由与配置，才能完成实际通信。

如果此前拒绝了提示，可以回到应用重新执行连接操作，按系统再次出现的提示处理。若没有出现预期提示，应先查看系统设置中的 VPN 配置状态，确认配置是否已经存在，而不是连续重复点击开关。对于受管理的设备，组织策略可能限制配置创建或网络扩展使用；这类限制应由设备管理方确认。不要随意删除其他用途的系统配置，尤其是在工作或学习设备上，删除前需要明确其用途与恢复方式。

按 Home 的逻辑检查四处状态

1. 先看 SERVER，确认是否已有你准备使用的服务器，并检查选中标记。
2. 再看 Global Routing，确认当前是 Config、Proxy 还是 Direct。
3. 打开顶部连接开关，观察状态是否完成切换，而不是刚点下就离开应用。
4. 使用 Connectivity Test，并进一步验证一个明确的实际请求。

连接未建立时可能显示 Not Connected。这个状态只描述当前连接情况，不能单独说明失败原因。服务器列表为空、认证错误、系统配置尚未授权、网络不可用等情况，都需要沿各自的层次检查。相反，顶部状态已经切换，也只是说明连接机制进入工作状态；服务器能否转发、域名能否解析、规则是否选择预期策略，还需要另外验证。详细界面说明见首次打开与 Home 页区块说明。

其他权限按实际操作授权

采用 Scan QR Code 时，应用需要相机权限；如果拒绝，可在系统设置中检查对应权限，再返回扫描。只进行手动输入或链接导入时，不需要为了预备使用就先打开相机权限。通过文件选择器导入配置时，应确认选中的文件来源与内容；通过剪贴板读取信息时，应确认剪贴板里确实是刚刚复制的连接资料。权限提示只能解释应用准备访问哪类系统资源，不能替代对资料来源的判断。

首次运行建议一次只完成一个动作：先导入一条已知资料，再确认列表内容，最后连接。不要在权限提示尚未结束时同时切换网络、更新订阅和更改路由，否则出现异常后难以判断是哪一步触发。若系统提示需要重新授权，先记录当时的操作和提示文字，再查看已有 VPN 配置是否对应当前应用。仅因为一次连接未成功就删除应用，可能造成尚未备份的本地资料丢失，也会增加重新授权和重新导入的工作量。

这一阶段还应确认设备本身已经联网。打开一个原本可访问的页面，检查是否需要先完成当前网络的登录或确认流程。应用无法替未接入互联网的设备创造基础连接；遇到公共网络的登录页面，应先完成网络要求，再测试 Shadowrocket。若设备同时存在其他会接管网络的功能，先明确各自作用，并在可控条件下逐项比较。完成这些检查后，下一章的导入结果才有稳定的测试环境。

服务器与订阅：区分单条参数、Subscribe 和 Config

导入前先辨认手中的资料是什么。单条服务器信息描述一个连接端点，通常包含协议、地址、端口与认证字段；订阅链接用于获取并更新一组服务器；Config 配置文件主要承载规则与相关设置，可能引用策略名称。三种资料不能只凭链接外观互相替代。订阅从你的服务商处获取，遇到格式不明确时，应先确认该资料应进入哪个入口，再操作导入；不要把服务说明页面的地址直接当作订阅地址。

通过 Add Server 手动添加

进入 Add Server 后，先选择与已有资料一致的协议，再填写该协议要求的字段。地址只填写实际服务器域名或地址，端口按照资料提供值输入；认证可能使用 Password、UUID 或密钥，不能互换。注意输入法是否加入空格、全角标点或换行，复制后的首尾空白也要检查。显示名称可以帮助辨认服务器，但名称不是连接参数，改名称不会修复错误的地址、认证或传输设置。

同一协议也可能采用不同传输方式，因此“协议名称相同”只是必要条件之一。以需要 TLS 的连接为例，实际连接地址和证书验证名称可能不同，Host 与 SNI 也有各自含义；不要把所有域名字段都改成同一个值来试错。若资料没有说明某个字段，先保留默认或向提供方核实。协议的简要背景可参阅支持协议与参数概览，实际填写仍以你的服务器信息为依据。

通过 Subscribe 导入和更新

添加订阅时，在对应的 Subscribe 入口填写完整链接并保存，然后执行更新。链接中的路径与查询部分可能参与认证，漏掉一段就可能得到错误页面或空结果。不要为了让地址更短而删除参数，也不要把凭据贴到公开提问中。更新后返回 SERVER 检查是否生成了预期条目，再选中其中一条连接。订阅名称可以自行整理，但应保留足以识别来源的信息，方便后续确认哪一组内容需要更新。

订阅更新成功只说明本次内容被成功获取和解析，不保证每个服务器此刻都可用。更新失败也不一定是服务器全部失效，应分别检查当前基础网络、链接是否完整、认证是否仍有效，以及返回内容是否为正确格式。如果原来已有可用列表，先保留它，记录失败提示后再处理，不要先删除整个订阅组。部分订阅更新会增加、移除或重命名条目，更新之后还应重新确认当前选中的服务器是否仍然存在。

扫码、链接与配置文件的边界

Scan QR Code 适合导入可识别的连接资料，但二维码只是信息载体，不是有效性证明。扫描后先核对协议和地址，再保存；若结果只是普通网页，应返回资料来源确认正确二维码。通过剪贴板或文件导入也应遵循相同原则：导入完成后检查实际生成的对象，而不是只看是否出现成功提示。对于 Import from Cloud JSON 等特定入口，只在已有资料明确要求使用时操作，不把不匹配的文件反复交给不同入口尝试。

Config 与订阅的维护要分开进行。更新服务器列表通常不会自动替你设计所需规则；切换配置也不应被当作刷新订阅的替代动作。规则中若引用自定义策略名称，必须确认当前环境能够识别这些名称。先保留原始资料，再做本地调整，并记录修改的是单条服务器、订阅组还是配置文件。建立这种对象意识后，即使列表内容变化，也能准确判断应该重新导入、更新订阅，还是只修正当前配置。

Global Routing：Config、Proxy、Direct 与规则顺序

Global Routing 决定当前采用哪种整体路由姿态。配置对应 Config，代理对应 Proxy，直连对应 Direct；实际界面以英文原文显示。三者不是服务器协议，也不是连接速度等级。Config 依据当前配置中的规则选择处理策略；Proxy 将可由当前连接处理的请求交给所选代理策略；Direct 用于直接连接。开始排查前一定先确认这里，因为相同服务器在不同路由姿态下，实际请求可能走完全不同的处理路径。

先用姿态区分问题范围

若 Proxy 下同一请求可以完成，而 Config 下失败，优先检查规则命中与策略引用，而不是立即更换认证信息。若两者均失败，则继续检查基础网络、服务器与解析。Direct 的结果只是直接路径的对照，不能用来证明代理路径正常。测试结束后记得恢复实际需要的姿态，尤其不要在完成一次诊断后长期保留临时设置，否则之后看到的统计与访问行为可能和原有预期不同。

规则从上到下匹配，具体条件放在前面

规则的关键是条件、策略和顺序。通常按从上到下的顺序查找匹配项，先命中的规则决定处理方式；因此更具体的例外应放在宽泛条件前，FINAL 放在末尾作为兜底。DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名后缀，DOMAIN-KEYWORD 按域名中的关键词匹配；IP-CIDR 与 IP-CIDR6 分别用于地址段，GEOIP 依赖地址归属数据。不要只看关键字熟悉就复制，必须明确目标请求能否提供该规则所需的匹配信息。

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

这段示例先让一个完整域名直接连接，再让同一后缀下的其他匹配请求使用 PROXY；私有地址段采用 DIRECT，随后按 GEOIP 处理地址归属，最后由 FINAL 兜底。它只演示语法和顺序，不代表适合所有网络。尤其是 GEOIP 规则不能替代域名规则，也不能保证每次请求都已有可用地址信息。将示例用于实际配置前，需要检查已有规则、策略定义与本地网络需求，避免把示例当成整份配置覆盖原文件。

策略名称与界面姿态不要混淆

规则中的 PROXY、DIRECT、REJECT 是处理策略关键字，和 Global Routing 中的 Proxy、Direct 在概念层次上不同。配置还可能引用已定义的策略组或特定名称，拼写与引用必须一致。某一条规则语法正确，不代表其指向的策略一定存在；策略存在，也不代表内部所选服务器可用。因此检查配置时要沿着“命中哪条规则、该规则指向什么、该策略最终选择什么”逐层确认，而不是只读规则条件。

对复杂页面应考虑多个请求。一个页面可能同时访问页面域名、资源域名和接口域名，它们可能分别命中不同规则。页面能打开但部分内容缺失时，先确认失败请求的实际目标，再决定是否需要补充规则。DOMAIN-KEYWORD 过于宽泛时可能影响无关域名，优先采用能够准确描述目标范围的条件。每次只增加少量规则，并为本地例外留下一句用途说明，后续订阅或配置更新后才容易检查是否仍然需要。

配置导入后应明确选择当前使用的文件，编辑某份文件并不等于它已经生效。保存后检查配置是否可用，必要时重新建立连接以排除旧连接影响，再用相同目标复测。对于仍未结束的长连接，仅重新打开页面可能不足以观察新策略；应按测试应用的实际行为重新发起请求。把配置选择、规则顺序和请求生命周期一起考虑，才能正确解释“已经改了规则，结果却没变”的情况。

连接与验证：从选中服务器到定位失败层次

连接前先回到 Home，确认 SERVER 中确实选中了预期服务器，而不是只进入过该服务器的编辑页面。检查 Global Routing 是否符合本轮测试目的，再打开顶部开关。观察系统与应用状态变化，等待连接过程完成后才执行测试。第一次验证宜选择一条资料明确的服务器和一个固定目标，不要同时开启订阅更新、规则修改与多项测试。可重复的测试条件比一次偶然成功更有参考价值。

把连接成功分成三个层次

第一层是系统连接状态，说明网络扩展是否进入工作状态；第二层是服务器链路，说明当前端点是否能够建立所需通信；第三层是实际业务请求，涉及目标域名、解析、规则与目标服务本身。三个层次可能出现不同结果。例如系统状态正常而页面失败，并不矛盾；服务器端口能够响应，也不代表认证与后续转发都成功。排查时应记录具体失败发生在哪一层，避免用“连不上”概括所有现象。

Connectivity Test 可以作为快速检查入口，但测试结果依赖测试方式、目标和当前网络条件。某条测试的读数只代表当时的特定路径，不能直接当作日常访问质量排序。先运行测试，再打开一个确定的实际目标，观察页面或请求是否完整完成。若测试与实际表现不一致，应比较它们使用的目标、协议与策略，而不是把其中任意一项当作绝对结论。操作主线可参阅选中服务器与 Connectivity Test 验证。

按基础网络、端点、解析、规则检查

1. 确认设备基础网络可用，当前网络的登录或确认步骤已经完成。
2. 核对所选服务器的地址、端口、认证与必要传输参数。
3. 确认域名解析能够完成，区分地址不可达和名称解析失败。
4. 检查路由姿态、当前配置与失败请求的实际策略。
5. 最后检查目标服务本身的响应与账户条件。

出现超时，可以先比较另一条你已有且确认可用的服务器，再比较另一种可控网络。比较时保持目标与配置不变，才能判断差异来自哪里。如果换网络后同一端点恢复，应进一步检查原网络限制、接入状态或路径条件；如果所有网络上只有一个端点失败，则优先核对该端点资料和服务状态。不要在没有证据时同时修改端口、密码、TLS 和 DNS，否则即使恢复也无法知道真正原因。

出现认证或 TLS 相关提示，应回到原始资料逐字核对。认证失败通常不能靠增加规则解决；证书名称不匹配也不应通过随意放宽验证来掩盖。检查设备日期与时间是否准确，确认 SNI、连接域名与证书要求的关系，并向资料提供方核实预期参数。如果错误提示指向内容格式，则先修正导入资料，而不是继续测试同一错误条目。保留提示原文有助于区分认证、握手与目标响应阶段。

部分请求失败时检查请求本身

若只有一个页面或某项应用功能失败，先确认其他目标在相同条件下是否正常。然后关注失败目标是否使用额外域名、不同传输或持续连接。浏览器缓存、应用内缓存和旧连接都可能保留之前的结果，修改规则后应重新发起请求再比较。目标服务的登录状态、地区设置或账户条件也可能影响响应；这类结果不能一概归为客户端故障。只有把失败范围缩小，日志里的信息才容易解释。

需要借助记录时，只采集能够复现问题的一小段时间。先记下测试时间、目标、当前服务器与路由姿态，再执行一次请求，随后查看相关记录。分享前移除订阅链接、认证字段、完整密钥和与问题无关的访问内容。可以提供错误类型、协议名称与已做过的对照实验，但不要公开完整连接资料。常见的状态解释与处理分支可继续查阅FAQ。

验证通过后，至少重复一次同样的请求，并确认配置与服务器选择没有被更新动作改变。对必须长期使用的场景，还应观察网络切换后的行为，但不要把网络切换测试和首次连接混为一轮。形成一份简短基线：使用哪个网络、哪条服务器、什么姿态、哪个目标能够完成。下次异常时先复现这份基线，通常比从头重填所有参数更快，也更不容易破坏原来可用的设置。

Data 流量：读懂统计范围，再判断请求去向

Data 用于观察应用记录的流量，不是独立的网络质量结论。查看数字以前，先确认当前展示的是哪个统计范围、哪个对象以及哪段时间。按服务器观察，关注不同连接端点承担的流量；按应用观察，关注可归属到应用的通信。不同视图的归属方式和覆盖范围可能不同，不能因为两个位置的数值不相等，就推断统计错误。应先阅读当前视图标签，再把数据和刚刚进行的操作对应起来。

上行与下行分别说明什么

上行是从设备发出的数据，下行是设备接收的数据。打开页面通常以下行为主，但请求头、认证、确认与控制通信同样会产生上行；上传内容时则可能出现明显的上行增加。数值大小与所用业务有关，不能单凭某个方向增长缓慢判定故障。连接维持、重试和后台活动也可能产生流量，即使前台没有主动打开页面，统计仍可能变化。把测试窗口缩短，才更容易分辨目标操作带来的增量。

总量和速率也需要分开理解。累计总量表示所选统计区间内的数据量，瞬时或短期速率描述某段时间的传输变化。过去已经累积的总量不会因为当前连接停止就自动消失，因此不能用总量仍然存在来证明连接仍在工作。反过来，短暂没有可见速率也可能只是请求已经完成。观察一次完整操作时，应记录开始前和结束后的变化，而不是只截取某一个时刻的读数。

用增量验证，不用总量猜测

1. 确认当前服务器、Global Routing 与配置，暂停无关的大流量操作。
2. 记录目标统计项的当前值，明确是否属于本轮观察范围。
3. 只执行一次可重复的目标操作，等待其完成或出现明确错误。
4. 回到 Data 查看变化，再结合请求记录核对策略。

如果某条服务器的统计增加，可以说明有通信被计入该对象，但不一定全部来自刚刚打开的页面。后台同步、通知或其他应用活动都可能同时发生。若没有增长，也需要检查请求是否命中 DIRECT、是否使用旧连接、是否直接读取缓存，以及当前视图是否选对对象。Data 适合提供观察线索，确认具体规则命中仍应结合当前配置和相关请求记录，不能让统计承担它并不直接表达的含义。

按服务器与按应用交叉观察

按服务器视图适合确认更换端点后是否开始产生新的通信，也适合检查某个原本不再使用的条目是否仍有活动。按应用视图则适合观察某项应用操作是否伴随流量增长，但显示方式受当前系统与应用能够获取的信息影响。未能准确归属的内容不应强行算到某个应用头上。两种视图可以帮助缩小问题范围，却不应被当作严格相等的两张账单；聚合口径不同，直接相加或相减可能没有意义。

使用 Config 时，部分请求按照规则直接连接，部分请求使用 PROXY，因此服务器流量与设备整体用量通常不是同一个概念。当前服务商所显示的用量，还可能采用自己的计量口径、结算周期或流量处理规则。应用统计、系统网络统计和服务端统计即使同时记录，也可能因起止时间、协议开销与归属范围而不同。比较之前应先对齐时间和对象，不要只凭一次差值判断资料是否异常。

统计清理与长期观察

如果当前界面提供清理统计的操作，执行前先确认它影响的对象和范围。清理本地统计不等于重置服务商用量，也不等于删除服务器，更不会替代订阅更新。需要保留历史比较时，先记录相关结果，再开始新的测试周期。长期观察宜采用固定条件，例如同一类操作、相似网络与相同路由姿态；条件变化太大时，应分别记录，而不是把所有结果放进一个趋势解释。

当统计和体验不一致时，回到上一章的分层检查：有流量却页面失败，可能是认证后的目标请求、资源域名或响应内容出现问题；页面正常却目标服务器统计不变，可能命中直连或缓存。保留这些可能性，比立即清空统计或反复切换服务器更有帮助。更具体的视图解释见Data 页按服务器与按应用的读数说明，阅读时仍应以当前界面实际标签为准。

Settings 常用项：On Demand、DNS 与诊断边界

Settings 中的选项应围绕明确需求调整，而不是一次性开启所有开关。某些设置影响系统触发连接，某些设置影响解析或记录，另一些行为来自当前 Config。修改前先确定设置的作用范围：是只影响当前服务器、当前配置，还是影响应用整体行为。界面组织可能随应用调整，查找时以英文项目名称和实际说明为准；没有出现在当前界面的设置，不应根据其他设备的截图硬找相同位置。

On Demand：连接触发条件与规则分流不同

On Demand 用于按已设置的条件触发连接。它解决的是何时请求建立连接，而不是把某个域名交给哪个策略。规则分流仍由 Global Routing 与当前配置决定，两者可以配合，但不能互相替代。启用前应先确认手动连接已经稳定，否则自动触发只会把尚未解决的问题变得更难观察。需要自动行为时，先明确哪些网络条件应该触发、哪些条件应该保持断开，再逐项设置并测试。

测试 On Demand 时，应观察一次完整的网络变化过程。记录变化前的连接状态，触发预期条件，再查看系统是否发起连接以及实际请求是否成功。不要只看开关已经打开就认定条件配置正确。手动断开后又重新连接，可能来自已经设置的触发条件，并不必然意味着应用无法关闭。需要临时停止自动连接时，应先检查 On Demand 状态及条件，再手动断开，之后按原需求恢复。

On Demand
Global Routing
Config
Connectivity Test

这里列出的是核对项目名称，不是可导入配置。排查自动连接时先看 On Demand，排查请求去向时再看 Global Routing 与 Config，排查实际连通时使用 Connectivity Test 并发起业务请求。把不同设置分开记录，可以避免用修改规则的方式处理自动重连，或用关闭自动触发的方式处理某个域名的策略错误。每一项改动都应能回答一个明确问题。

DNS：先判断解析问题，再更改配置

DNS 负责把域名转换为后续连接需要的地址信息，其结果可能影响地址类规则与连接过程。域名访问失败而其他请求正常时，解析是检查方向之一，但不是唯一原因。先比较同一域名在当前配置下是否能得到结果，再结合连接错误判断下一步。不同配置可能已经包含解析相关设置，直接在多个位置同时修改容易造成覆盖关系不清。应先确认当前生效配置，记录已有设置，再进行单项对照。

不要把任意解析服务地址当作通用修复值。解析路径、服务器可达性、加密方式与规则需要共同考虑；某个值在一种网络下可用，不代表所有网络都适用。修改以后应重新发起请求，必要时排除旧解析结果与旧连接的影响，再比较同一目标。若结果没有改善，就恢复原设置并继续检查，不要把尝试过的值层层叠加。私有网络中的名称还可能依赖本地解析条件，调整时应保留这种需求。

记录、证书与按需启用的功能

诊断记录应按问题需要开启，采集到足够信息后再检查是否继续保留。详细记录可能包含访问域名、时间与连接信息，导出或发送之前先删除敏感内容。对于会改变加密流量处理方式的证书相关功能，应先理解信任范围、适用目标与恢复步骤。普通服务器连接和规则分流的入门流程，不需要为了“设置齐全”就先安装额外证书。只在明确的调试需求下操作，并确认相关应用和业务允许该方式。

涉及 UDP、IPv6 等行为时，也应先核对服务器协议和当前网络是否支持，而不是只调整客户端一端。某项业务依赖特定传输时，可以在保持其他条件不变的情况下测试对应能力；不支持的服务端能力不能通过任意开关补齐。IPv6 地址规则应使用相应类型，并与实际解析结果一起检查。若只在一种网络中出现问题，优先比较网络能力与路径差异，再决定是否需要调整配置。

完成设置后重新检查 Home：当前服务器是否正确、Global Routing 是否恢复预期、配置是否仍为目标文件。然后分别测试一次普通请求和需要特殊设置的请求。这样的收尾能发现“某个功能修好了，日常连接却被临时设置改变”的情况。长期稳定使用不依赖设置数量，而依赖每个启用项目都有明确用途、可验证结果和已知恢复方法；没有实际需求的项目可以维持原状态。

日常维护：更新、备份、换机与可重复排查

稳定使用以后，维护重点从“怎样连接”转为“怎样让变化可追踪”。应用更新、订阅更新、配置更新与服务器选择是不同操作，应分别记录。应用通过 App Store 更新；订阅更新获取服务器资料；配置更新改变规则或相关设置；选择服务器只改变当前使用对象。不要因为其中一项更新成功，就默认其他内容也已经同步。出现问题时先问最近改动了哪一层，通常能明显缩小排查范围。

更新前保留基线，更新后检查对象

订阅更新前，先确认当前链接来源与已有可用条目，必要时记下正在使用的服务器名称。更新后检查列表是否增加、移除或重命名，以及当前选中项是否还指向预期对象。若列表变化导致自定义策略引用失效，需要修正规则或策略关系，而不一定要重新导入整个应用的数据。有关订阅的认证、有效期或返回内容问题，应回到你的服务商核实；本手册只说明已有资料的导入与维护方式。

配置更新之前先保留可回退副本，并区分远程内容和本地修改。若在会被更新覆盖的配置内加入了个性化规则，应记录这些规则的用途和位置，更新后逐项核对是否仍存在。不要把旧配置的所有内容不加检查地粘回新文件，这可能恢复已经不适用的设置。更稳妥的方法是先验证更新后的基础行为，再按需求补回少量本地例外，每补一项就用固定目标复测。

备份要覆盖关系，不只保存一个文件

一份有用的备份说明应包含服务器或订阅的来源、当前配置名称、Global Routing 姿态、必要的本地规则以及重要设置。只保存某份配置文件，不一定包含全部认证资料；只保存订阅链接，也不一定包含本地编辑和系统权限状态。使用应用当前提供的导出或备份能力时，先确认实际包含哪些对象，再决定是否还需单独记录。备份文件可能包含敏感信息，应存放在自己控制且有访问保护的位置。

备份完成后应验证是否可读，而不是等换机后才发现文件缺失。验证可以从检查文件是否存在、格式是否正确、关键对象是否齐全开始；不需要为了验证而覆盖当前正在使用的环境。对于密钥、密码和完整订阅地址，不宜直接写入公开笔记或截图。需要记录排查过程时，用资料名称或存放位置代替完整凭据。若发现敏感链接曾经公开，应向资料提供方确认更换或撤销方式，再同步更新本地引用。

换机按获取、导入、权限、验证重走一次

新设备上先从 App Store 恢复 Shadowrocket，再确认备份或设备恢复带回了哪些内容。服务器列表、配置文件和系统 VPN 授权需要分别核对，不要假设旧设备的系统状态可以原样转移。导入资料后，先完成手动连接和固定目标验证，再恢复 On Demand 等自动行为。对于 iPhone 与 iPad 的差异，重点核对当前页面与选中对象，不按旧设备的屏幕位置机械点击；系统要求与购买范围仍以 App Store 页面标注为准。

旧设备暂时保留到新设备完成验证，有助于对照参数，但对照时注意避免误改两端资料。确认新设备可用后，再按个人需要处理旧设备中的认证、订阅与备份文件。重装应用不应成为一般故障的第一步，因为它可能清除本地配置并引入额外授权工作。只有已明确需要重建环境、且确认资料能够恢复时，才考虑这一操作；购买恢复问题可回到已购恢复章节核对。

建立最小排查记录

长期维护可以保留一份简短记录：发生时间、网络类型、目标请求、服务器、路由姿态、配置名称、错误原文，以及最后一次有效改动。记录不需要包含访问内容和认证信息，只要能够重现条件即可。每次异常先尝试已知基线，再比较最近变化；每次只改一项，明确成功标准，测试后恢复无效改动。这样积累下来的记录比“已经试过很多方法”更容易复用，也能减少下一次相同问题的重复工作。

需要快速重走连接流程时使用快速上手教程；需要查一个具体疑问时进入FAQ；需要核对购买与应用身份时返回App Store 下载指南。本页的章节顺序也可以作为维护清单：先确认应用与资料来源，再确认权限和导入，接着检查路由与验证，最后解释统计和设置。把这些层次保持清晰，日常调整就能围绕事实进行，而不是依赖反复重置与猜测。