Shadowrocket 完整使用手册 首次配置与日常维护

先核对应用，再确认购买

获取 Shadowrocket 应从App Store 正版核验页进入指定产品页面。不要只凭搜索结果里的名称判断应用身份：先看产品名是否为 Shadowrocket，再核对开发者 Shadow Launch Technology Limited、官方图标以及应用 ID 932747118。应用 ID 可在产品链接末尾的 id932747118 中识别。名称相近不代表同一产品，核对时应把这几项放在一起看，而不是只认某一种颜色或某个搜索排序。

进入商店后，阅读价格、兼容性与购买说明，再通过系统购买流程确认。Shadowrocket 主要用于 iPhone 与 iPad；Mac、Apple TV、Apple Vision 也可在同一产品页的兼容性栏查看适用情况。系统要求与购买适用范围均以 App Store 页面标注为准。不要把某台设备能打开产品页，直接理解为该设备当前系统一定满足运行要求；实际能否获取，应以商店对当前设备显示的结果为依据。

一次性买断买到的是什么

一次性买断指应用本身的购买方式，不等于持续提供连接资源。美区价格约为 2.99 美元，实际价格以商店页面为准，各店面按当地货币显示。支付前应确认当前用于商店购买的 Apple 账户，以及页面显示的金额。购买完成后，客户端仍需要用户已有的订阅或服务器参数；应用购买记录不能替代这些信息，也不能证明某个服务器当前可用。把两类费用和两类记录分开保存，后续换机与排错会更清楚。

服务器信息通常包括地址、端口、协议和认证参数；订阅则是用于取得服务器列表的地址。配置文件负责规则、部分连接设置与策略引用。这三者与 App Store 的已购记录承担不同职责：已购记录用于重新获取应用，订阅用于维护列表，配置文件用于决定连接如何处理。仅恢复应用，并不意味着原来的订阅、手工录入内容或本地修改会自动完整回到新设备，迁移前仍需核对数据来源与备份。

首次获取与已购恢复的顺序

首次购买后，等待商店完成获取，再从设备主屏幕打开应用。如果商店已经显示已购或重新下载标记，应先确认它对应的账户，不要立即重复购买。换机或重新获取时，使用原购买账户，在 App Store 的账户页面查找已购应用；入口名称可能随系统界面变化。若找不到，先查购买记录、隐藏项目及当前商店账户，再考虑地区或购买适用范围的影响。家庭共享能否适用，也应以商店说明和实际账户状态为准。

设备用于云端同步的账户与用于商店购买的账户可能并不相同，因此排查时要看商店账户，而不只是系统设置顶端显示的名称。账户信息属于个人资料，不应贴到公开评论或排错截图中。记录购买情况时，保留足以自己辨认的说明即可，不要记录账户密码。恢复过程遇到支付或账户限制，应沿商店提供的账户处理流程解决；修改 Shadowrocket 的规则、协议或 DNS，不会改变商店购买状态。

完成获取后的检查

打开应用后，先确认能够进入 Home、Config、Data、Settings 等主要页面，不急于更改高级选项。此时没有服务器列表，并不说明购买失败；它通常只是尚未导入用户自己的资料。接下来应按本手册顺序处理首次权限，再录入服务信息。应用更新通过 App Store 管理，更新记录与适用要求同样以商店页为准。关于换机恢复的具体入口，可继续查阅在已购项目中重新获取 Shadowrocket 的说明。

系统弹窗为什么出现

Shadowrocket 需要通过系统提供的网络扩展能力处理连接。首次启用相关连接功能时，系统可能提示添加 VPN 配置，并要求通过设备密码或设备支持的身份验证方式确认。这一步允许应用在系统中建立对应的网络配置，不是在购买新的服务，也不是向订阅地址提交付款。应先阅读弹窗中的应用名称与操作说明，确认是自己刚刚发起的操作，再作决定；不要把所有系统弹窗都当成同一种提示连续确认。

授权只是连接准备的一部分。即使系统已经允许添加配置，服务器地址错误、认证参数不匹配或服务不可用，仍然会导致访问失败。反过来，服务器列表已正确导入，也不能跳过系统要求的配置授权。首次使用时，把“资料已导入”“配置获准建立”“连接已启动”“目标访问成功”分成四个检查点，可以避免只看一个开关就判断整个流程已经完成。

拒绝授权后如何继续

如果此前取消了弹窗，先回到应用，检查当前连接状态，再由自己主动重新发起连接，并留意是否再次出现系统提示。不要连续快速点击开关，这容易让授权过程、启动过程与停止过程互相交错。系统没有再次提示时，可在设备设置中查找 VPN 相关配置，核对是否已有 Shadowrocket 对应条目。系统菜单名称可能随系统版本变化，判断重点是条目所属应用及状态，而不是死记某一级菜单的位置。

发现多个网络配置时，先确认各自用途。其他 VPN 连接或受管理的网络设置可能影响当前连接，排查应先停止自己能够控制的其他连接，再单独验证 Shadowrocket。单位或学校管理的设备可能有额外限制，这类限制应由设备管理方确认，不应通过随意删除管理内容来处理。删除本应用的系统配置也不应作为第一步；只有在了解影响、保存必要资料后，才考虑重新建立，并重新完成授权。

首次连接前整理环境

准备测试时，选择一种明确的网络环境，例如已完成认证的 Wi-Fi。部分公共网络必须先通过系统或浏览器完成接入认证；若连基础网络都尚未可用，客户端配置正确也无法建立远端连接。先暂时停止客户端连接，验证设备能够进行普通联网，再回到应用继续。首次验证期间不要同时切换 Wi-Fi、移动网络和多个服务器，否则失败后很难知道是哪一次变化产生了影响。

设备日期与时间也值得核对。使用 TLS 的连接需要校验证书有效期，设备时间明显偏差会使正常证书看起来不符合要求。应优先修正系统时间，而不是通过降低验证要求来掩盖现象。若系统弹出证书、设备管理或额外描述文件相关提示，不要因为正在配置客户端就认定都必须接受；普通服务器导入与配置规则，并不意味着应接受来源不明的系统级更改。

如何记录权限类故障

权限问题通常发生在连接启动前后，表现为授权未完成、配置无法建立或开关无法保持预期状态。记录时写下自己执行了什么操作、系统是否出现弹窗、确认后应用显示什么，不要只写“不能用”。如果开关能够启动，但只有某个目标访问失败，则应转到连接与规则章节继续分析，避免反复重建权限。故障记录越接近发生顺序，越容易区分系统层与服务层的问题。

这一阶段还应暂缓设置 On Demand。先通过手工开关完成一次可重复的连接与断开，再加入自动连接条件，才能判断后来的重新连接究竟来自手工操作还是自动条件。若每次断开后又自动连接，先检查是否启用了相关自动行为，而不是立即认为开关失灵。完成权限确认后，再进入下一章添加服务器或订阅；尚未准备好服务信息时，可以先阅读界面说明，不必为了继续操作而随意填写参数。

先辨认拿到的资料

导入前，先判断服务商给出的是订阅地址、单个服务器分享内容，还是完整配置文件。订阅地址通常用于取得一组服务器资料；单个分享内容只描述某个连接；配置文件还可能包含规则与其他设置。不能因为它们都是一段文本或一个地址，就放进同一个入口。先阅读资料来源处的用途说明，再选择 Home 中的添加入口或 Config 中的配置管理入口，能够减少“导入成功却没有得到预期内容”的情况。

服务器资料与订阅地址都可能包含认证信息，应按密码级别保管。复制时要保留完整内容，不要混入说明文字、空格、换行或中文标点。若通过 Scan QR Code 导入，同样需要确认二维码来自自己的可信资料来源；扫描结果不是天然可信的配置证明。不要把二维码上传到公开讨论区求助，也不要为了检查内容而把完整订阅地址粘贴进不明网站。排错时只需描述类型、错误提示与发生步骤。

手工添加服务器的核对方法

在 Add Server 中，先选择与服务信息一致的类型，再填写地址、端口和认证字段。协议选择决定了后续参数的含义；不同类型之间，密码、标识符、加密方法与传输选项不能互相代替。地址字段一般只填服务器地址，不要自行添加网页路径；端口应使用资料提供的数值。保存前逐项对照原始说明，尤其注意大小写、末尾字符和数字，不能凭“看起来差不多”判断一致。

如果资料还提供了 TLS、服务器名称、路径或其他传输参数，应按对应字段完整填写。服务器名称不一定等于连接地址，路径也不是可以随意补上的说明文字。无法确认某个字段时，应回到服务信息来源核实，而不是轮流尝试所有开关。手工添加适合参数完整、数量较少的情况；已有标准分享内容时，导入通常能减少抄写错误，但导入后仍应检查类型与关键字段是否符合预期。

订阅导入与首次更新

添加订阅时，在对应的 Subscribe 类型入口填入完整地址，保存后执行更新，观察是否出现服务器列表。名称可以用于自己辨认来源，但不要把名称当作连接参数。列表为空时，先判断是地址保存失败、请求失败，还是取得的内容不能解析；这三种情况的处理方向不同。能够在浏览器看到一个网页，也不代表该地址返回的是客户端可用的订阅内容，有时它实际上是账户登录页或错误说明页。

订阅导入成功后，选择其中一个服务器，再进入后续连接验证。此时不要立刻逐个编辑订阅生成的条目，因为下次更新可能覆盖相应变化。确需独立调整时，应先了解条目的来源与更新行为，保留原始订阅，并用清晰名称区分自己的副本。更新订阅主要用于刷新服务器资料，并不自动等同于更换当前 Config 中的规则文件；管理列表与管理分流规则是两项独立工作。

导入失败时保留原状

更新失败不必马上删除原有订阅。先保留已有列表，检查地址是否完整、服务账户是否仍有效，以及当前网络能否取得订阅内容。若此前正常、现在突然失败，应记录最后一次成功更新与最近的改动，再查看服务商提供的状态说明。连续重复请求通常不能修复格式问题，反而可能引入访问限制。可按订阅解析失败或列表为空的自查清单逐项定位，确认原因后再决定是否替换地址。

先确认模式，再解释规则

Global Routing 中的 Config、Proxy、Direct 决定了主要路由方式。Config 按当前配置文件中的规则分流；Proxy 将由客户端处理的连接统一交给所选服务器；Direct 则采用直连处理。这里的“统一”是路由模式含义，不应理解为对设备所有系统行为的绝对描述。系统保留行为、已有连接与其他网络设置仍可能影响观察结果，所以排错时应使用新发起的请求验证，而不是只看已经打开的页面。

Config 是配置模式的界面词，既出现在底部配置管理入口，也出现在 Global Routing 的选项中，两处作用不同。前者用于管理文件，后者用于选择是否按规则处理。文件已经导入，不代表当前模式一定是 Config；模式选了 Config，也不代表刚下载的文件已经生效。修改规则前，应分别确认这两处状态。许多“规则没有作用”的情况，实际上是当前仍处于 Proxy，或生效的不是刚编辑的文件。

一条规则由什么组成

常见规则由类型、匹配内容与策略组成，以英文逗号分隔。DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名后缀及相应子域，DOMAIN-KEYWORD 按域名中的关键字匹配；IP-CIDR 与 IP-CIDR6 分别表达相应地址范围，GEOIP 使用地理地址数据库判断。策略 PROXY、DIRECT、REJECT 分别表示交给代理、直连与拒绝。策略名需要与实际配置语义一致，不能用中文解释文字替代规则中的关键字。

[General]
bypass-system = true

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

以上是用于阅读的最小规则片段，不是适合所有网络环境的完整配置。示例域名只用于说明语法，不能当成验证服务器。局域网地址的直连规则用于展示地址范围匹配；GEOIP 的判断依赖数据库，也不能替代对具体目标的观察。实际采用前，应确认自己需要的服务、局域网资源与兜底策略，保留原配置副本，再在副本中逐项调整，不要直接覆盖唯一可用文件。

从上到下，第一条命中即停止

规则按从上到下的顺序检查，一旦命中，就采用该条策略，不再继续向下寻找所谓更精确的规则。因此，为个别域名设置的例外应放在可能覆盖它的宽泛规则之前。FINAL 是前面均未命中时的兜底，通常应放在最后。把 FINAL 提前会使后面的条目无法按预期参与判断。DOMAIN-KEYWORD 的范围也可能比直觉更宽，使用前应考虑是否会误匹配其他域名，能用明确后缀表达时不要随意扩大条件。

域名规则与地址规则观察的是不同信息。目标最初以域名出现，后续又需要解析成地址；某些规则判断可能涉及 DNS。不能因为目标最终连接到某个地址，就断定一定先命中了地址规则。分析时应结合实际请求记录、规则顺序与解析结果，而不是只查一次地址归属。涉及 IPv6 的环境还要考虑相应地址规则，不能只添加 IPv4 范围后就认为所有同类连接都已覆盖。

一次完整验证应包含什么

完成导入后，在 Home 选择一个自己已有的服务器，确认 Global Routing 的模式，再启动连接并完成必要授权。等状态稳定后，发起一个新的实际访问请求。完整验证至少包含四项：开关处于预期状态、服务器选择正确、目标能够返回内容、请求经过的策略符合预期。仅有系统 VPN 标记，最多说明相应网络配置正在工作，不能证明远端服务器认证成功，也不能证明每一个网站或应用都可以访问。

第一次测试应选择自己熟悉、能够判断正常结果的目标，不要同时开启大量页面。先验证一个普通请求，再验证确实需要代理处理的请求；如果涉及局域网资源，也单独验证。不同目标可能走不同策略，因此一个成功结果不能代表所有规则都正确。保留测试时的网络环境、服务器与模式记录，后续重复时使用同样条件，才有比较意义。不要在验证中途自动更新订阅或替换配置，避免测试条件被悄悄改变。

如何理解 Connectivity Test

Connectivity Test 可以辅助判断服务器或测试目标的可达情况，但结果受测试方式、测试地址和当时网络状态影响。测试成功不等于所有实际业务都正常，测试失败也不一定等于所有连接都不可用。应把它当作一个证据，与实际访问结果一起判断。若测试方法可以设置，先确认当前使用的是什么，再比较结果；不同测试方式下的耗时不应直接放在一起排序，更不应单凭一个数字推断长期稳定性。

出现测试通过但网页失败时，先看失败是否只发生在某个域名、某种请求或某个应用。目标服务自身、DNS、TLS、规则命中与远端访问限制都可能参与其中。如果所有目标都失败，再回到服务器地址、端口、认证参数和基础网络检查。若只有一个应用表现异常，可先彻底结束它的旧连接后重试，避免把旧会话或缓存当成新模式的结果；不要为了清理一个应用的连接而立即重置全部设备设置。

按层次缩小故障范围

第一层是基础网络：停止客户端连接后，设备是否能够正常联网，公共网络认证是否完成。第二层是服务器连接：在可控条件下使用 Proxy，验证所选服务器是否能够承载实际请求。第三层是配置分流：若 Proxy 正常而 Config 异常，应重点检查生效文件、规则顺序与相关解析设置。第四层是目标自身：若仅一个目标持续失败，而同类请求正常，应检查目标服务状态与具体错误，不要把所有问题都归因于客户端。

临时切换模式是定位工具，不是最终修复。测试结束后应恢复日常需要的模式，并再次验证。Proxy 与 Config 的结果不同，可能说明规则路径不同，也可能涉及 DNS 或已有连接，不能只凭这一个对比就断言某条规则写错。Direct 的对照同样应在允许直连的测试目标上进行。每次只改变一个因素，并记录改动前后结果，才能逐渐排除原因；同时更换服务器、模式和网络得到的成功，无法说明究竟修好了哪一项。

区分超时、解析与证书问题

超时表示在预期时间内没有得到所需响应，但本身不指出是哪个环节丢失了响应；应结合基础网络、端口与目标范围继续判断。解析失败首先指向域名解析路径，不应立刻更改认证密码。证书错误则需要检查设备时间、服务器名称与服务端证书情况。关闭验证会改变连接的信任条件，不能作为常规排错动作。先核对资料，再向自己的服务商确认服务端要求，比盲目调整多个高级选项更可靠。

如果故障只出现在网络切换后，记录切换方向以及重新建立连接能否恢复；如果只在休眠后出现，则比较唤醒后的首次请求和稍后请求。找到稳定复现条件后再调整相应设置，不要一开始就把系统行为、订阅格式与规则全部重做。初次连接仍不清楚操作顺序时，可回到快速上手说明重新完成一次最小流程；高级分析应建立在一个能够重复测试的基础配置之上。

统计反映的是哪一层流量

Data 用于观察客户端提供的流量与连接相关信息，具体可见项目以应用当前界面为准。阅读之前先看统计范围：是当前会话、某段累计记录，还是某个服务器的相关计数。不同范围不能直接比较。客户端观察到的数据，与系统移动网络统计、服务商账户用量和目标文件大小也不是同一个口径；计数不一致时，应先查范围与单位，而不是立即认为其中某一项错误。

一次页面访问会包含正文、图片、脚本、字体与后台请求，不能用地址栏里只有一个网址来估算连接数量。上传与下载也会同时发生：即使主要是在阅读内容，设备仍会发送请求与协议数据。页面刷新、预加载和应用后台同步都可能增加统计。若想了解一次操作产生的变化，应先记录操作前的计数，再执行一个明确动作，最后观察增量，而不是盯着一个不断增长的总数猜测来源。

客户端统计不等于服务商结算

服务商可能按自己的计费规则、统计周期和传输口径记录用量；客户端记录则取决于它能够观察到的连接范围。传输开销、重试与统计边界都可能造成差别。因此，Data 适合做本地观察和故障辅助，不应代替服务账户的结算依据。客户端买断不包含线路服务，应用中的流量记录也不会为用户增加服务额度。额度、有效期与账户限制，应回到用户自己的服务资料中确认。

用单次实验核对规则

准备检查某条规则时，先记下当前模式、配置文件与测试时间，然后只打开一个目标。若当前界面提供请求或连接详情，就按相近时间寻找对应记录，核对域名、地址与策略信息。一个页面可能请求多个不同域名，不能找到第一条记录后就结束判断。主页面成功而部分资源失败，可能是不同域名命中了不同策略；应把失败资源与相应规则对应起来，而不是给整个页面添加过宽的例外。

记录中没有出现预期内容，也需要谨慎解释。应用可能复用了已有连接，目标可能使用了缓存，或者当前显示范围并不包含该类记录。先发起一次可辨认的新请求，再确认筛选条件与记录范围。不要通过不断刷新页面制造大量重复条目，这会增加分析噪声。若要比较修改规则前后的结果，分别记下两个时间点，使用相同操作，并确保已经应用新配置，让比较真正对应同一个变量。

后台活动与隐私边界

停止主动浏览后，流量仍有变化并不罕见。系统同步、消息接收、媒体预加载和应用后台任务都可能继续联网。可以先暂停自己能够控制的下载与同步，再观察变化是否缩小；不要仅凭计数增长就推断异常。若某个应用重复失败并重试，流量也可能持续增加，这时应结合错误记录处理根因，而不是只把统计清零。清零仅改变观察起点，不会修复连接，也不会重置服务商记录。

请求记录可能暴露访问域名、时间、网络地址以及带认证信息的内容。导出或截图之前，应先检查是否包含订阅参数、完整访问路径或个人数据，保留与问题相关的最少片段。完成排错后，按自己的隐私需要清理不再需要的记录。不要为了得到更多信息而随意启用 HTTPS 解密；普通规则核对优先使用目标、时间和策略等元数据。关于底部入口之间的职责，可另查Home、Config、Data、Settings 界面词说明。

设置应从稳定基线开始

Settings 的作用是调整应用行为，不是把所有选项打开就能改善连接。首次使用应保留一个已经验证可用的基线：明确的服务器、固定的模式、可追溯的配置文件和可重复的测试目标。之后一次只修改一类设置，记录原值与修改目的。应用界面可能随实际版本变化，具体项目应以当前显示为准；如果没有看到某个教程中的选项，不要用名称相近的项目代替，更不要通过不明配置强行补齐。

有些设置改变下一次连接，有些影响当前请求，还有些只调整显示或更新行为。因此，保存之后应判断是否需要重新建立连接，并通过新请求确认结果。不能只因为页面上的开关改变，就认为网络已经采用了新条件。与配置文件有关的设置还可能来自文件本身，排错时应同时检查当前文件与应用设置，防止只改一个入口，却被另一处已有配置影响。

On Demand 先明确触发条件

On Demand 用于按设定条件自动建立连接。使用前先写清自己的目标，例如希望在什么网络环境中连接、在什么条件下保持断开，然后按应用实际提供的条件配置。它不是让服务器始终可用的功能，也不会修复认证失败。若手工连接尚未验证成功，先不要启用自动行为；否则每次失败重试与网络切换混在一起，很难判断是条件设置问题还是服务器问题。

启用后，应分别测试符合条件与不符合条件的场景，观察实际结果是否与预期一致。手工断开后又重新连接，可能是自动条件仍然成立，而不是断开操作没有生效。需要暂时停止时，应同时检查自动连接设置。离开原网络、返回原网络、设备休眠后唤醒，都属于值得单独验证的场景；条件中涉及网络名称时，也应考虑名称相同但实际环境不同的情况，避免把名称当成可信网络的唯一证明。

订阅更新设置的边界

如果当前界面提供打开应用时更新订阅的设置，可根据自己的使用频率决定是否启用。它能够帮助刷新服务器列表，但更新本身仍依赖网络可达与订阅地址有效。打开应用后更新失败，不等于已缓存的全部服务器立即失效；应分别测试列表刷新与已有连接。自动更新也不是持续监控服务商变更，不能保证每次都在最合适的时机获取到最新资料。

更改更新行为前，先了解订阅生成条目会如何处理。若自己改过名称、排序或连接字段，应确认下一次更新是否保留相应改动。重要调整应有独立记录，不能只存在于可能被刷新覆盖的条目中。遇到更新失败时，先保存可用状态再查原因，不要把“自动”理解为可以忽略失败提示。具体操作可配合订阅手动更新与打开时自动更新说明阅读，界面入口以实际应用为准。

DNS 与连接选项不要成组试错

DNS 参与把域名转换为地址，其请求路径与结果可能影响后续规则匹配和目标连接。更换解析设置前，应先确认当前问题确实与解析有关，例如同一域名持续解析失败，而基础网络与服务器连接已验证正常。不要把网上看到的一组解析地址直接叠加进去；来源、可达性与配置语义不明确时，增加地址只会增加变量。保留原设置，并用同一目标比较修改前后的结果。

与 TLS、传输、IPv6 或连接复用有关的选项，也应按实际服务要求调整。启用某项能力需要网络与服务端相应支持，并非选项越多越完整。出现连接问题时，优先回到服务参数核对，再考虑高级选项；不要通过关闭证书验证来换取表面上的连接成功。日志详细程度同样应按需使用：排错阶段收集足够信息即可，完成后恢复适合日常使用的状态，并妥善处理已导出的记录。

把三种更新分开管理

日常维护至少包含三件不同的事：通过 App Store 更新应用、更新订阅中的服务器列表，以及更新 Config 中的配置文件。应用更新改变客户端能力与行为；订阅更新改变服务资料；配置更新改变规则和相关设置。不要在同一次排错中同时进行这三项操作。若更新后出现异常，只有清楚知道变更了哪一层，才有条件比较前后差异，并向正确的信息来源核实。

更新前应确认当前连接是否承担重要任务，保存本地修改，并记录当前使用的配置名称。更新之后先检查列表与生效文件，再完成一次实际访问测试，不必立即调整其他设置。配置来源更新可能覆盖原内容，订阅更新也可能改变条目，因此重要例外规则与手工参数应另有可靠副本。应用更新记录以 App Store 页面为准，不应根据网上流传的编号猜测自己是否需要更新。

备份要覆盖内容，也要覆盖来源

备份时不只保存一份文件，还应知道它来自哪里、用于什么环境、自己改过哪些内容。可以用简短名称区分原始配置、测试副本与日常使用副本，并在私人记录中说明差异。导出文件后，检查它是否包含订阅地址、服务器认证字段或其他敏感信息，再决定存放位置。不要把备份当成普通文档公开分享；即使文件中大部分只是规则，一行含认证信息的地址也足以造成资料泄露。

备份是否有效，取决于能否恢复，而不只是有没有导出成功。准备迁移前，应确认文件可读、来源地址仍能取得、手工录入资料足够完整。保存到自己控制的安全位置，并保留清晰的恢复顺序：先获取应用，再完成权限，再恢复服务资料与配置，最后验证连接。若使用同步功能，也要核对实际同步范围；不要把看到相同文件名当成所有设置、记录与认证资料都已一致的证明。

换机后的最小恢复流程

在新设备上，先用原购买账户从 App Store 找回应用，系统要求与购买适用范围以 App Store 页面标注为准。进入应用后，不要立即复制所有高级选项；先恢复一个可用服务器或自己的订阅，选择明确的模式，并完成系统授权。最小流程成功后，再导入日常规则与自动连接条件。这样如果某一步出现异常，可以直接定位到最近恢复的内容，而不是面对一整套同时迁移后的未知状态。

旧设备上的连接成功，也不能保证新设备在不同网络中得到同样结果。应重新检查局域网地址、网络认证、设备时间与自动连接条件。确认新设备稳定后，再处理旧设备中不再需要的敏感资料；不要在迁移验证前先删除唯一副本。若购买恢复有疑问，可查已购恢复分区；价格与购买范围的常见问题见价格与买断说明，不要通过改动客户端规则来处理账户问题。

出现异常时先回退最近变更

维护中的故障应先问“上一次正常是什么条件”，再问“之后改了什么”。如果只修改过配置文件，先切回备份文件；如果只更新过订阅，先核对条目参数与选择状态；如果刚启用 On Demand，先暂停自动行为后手工测试。回退目的是恢复可比较的基线，不是要求长期使用旧设置。确认差异后，再针对具体项目处理，避免每遇到问题都删除所有配置并重新开始。

建议保留一份简短的私人维护记录，写清变更目的、修改项目与验证结果，不记录密码或完整订阅地址。问题长期不能复现时，也应如实写下发生条件尚不明确，而不是为了得到结论不断叠加规则。需要进一步查阅，可到博客说明列表按规则、订阅或购买主题阅读；只想重新跑一遍首次连接，则回到使用说明。系统手册的目标是让每次操作有依据、每次结果可解释，而不是把所有选项都配置一遍。