01 / APP STORE
App Store 正版获取与购买核对
先核对应用，再确认购买
Shadowrocket 是只在 Apple 平台发行的付费客户端，唯一获取入口是 App Store。开始之前先打开本站的App Store 正版核验页，核对应用名称、开发者和应用 ID，再进入商店完成购买。不要仅凭搜索结果中的名称判断应用身份；名称相近、图标相似，都不能替代产品页信息。商店中的介绍、兼容性、价格与购买确认界面，才是当前购买条件的依据。
正版核对需要同时检查三处：开发者为 Shadow Launch Technology Limited，应用 ID 为 932747118，图标与本站使用的官方图标一致。应用 ID 可以从产品页地址末尾的 id932747118 辨认。开发者名称应在商店产品页内查看，不以搜索摘要或其他页面的描述代替。完成这一步后，再查看当前登录的购买账号以及确认付款时显示的金额，避免把应用识别与账号核对混成一个步骤。
理解一次性买断的范围
客户端一次性买断 ≠ 线路套餐。购买 Shadowrocket 获得的是客户端的使用资格，连接仍需要用户已有的订阅或服务器信息。本手册只解释如何导入、配置和排查，不提供、不销售、不推荐节点或订阅。客户端负责读取参数、建立连接并执行分流规则；远端服务器是否可用、授权是否有效、连接容量如何，属于另一组条件，不能用“已经购买应用”来推断。
美区定价约为 2.99 美元，一次性付费；实际金额、货币和购买条件以 App Store 页面标注为准。商店地区不同，展示价格与可见性可能不同，付款前应以自己账号当前店面的确认界面为准。不要把订阅链接的有效期限与客户端购买混为一谈：前者描述远端访问授权，后者与应用购买记录相关。两者需要分别保存记录，也需要分别定位问题。
核对设备兼容性与商店地区
本手册以 iPhone、iPad 为主要操作设备。Mac、Apple TV、Apple Vision 也可在同一 App Store 产品页的兼容性栏核对，系统要求与购买适用范围一律以 App Store 页面标注为准。不能仅凭同一个 Apple ID 就假定所有设备和系统组合都满足条件。准备换设备时，先在目标设备上查看产品页是否显示兼容，再确认购买记录是否属于当前用于商店购买的账号。
搜索不到应用时，先区分“搜索没有结果”和“产品页提示当前店面不可用”。检查账号所属商店，重新打开正确的产品页，并保留提示文字；反复修改网络设置通常不能解决商店地区问题。账号的商店地区与设备语言不是同一设置，改变界面语言也不等于改变购买店面。具体核对方法见App Store 地区与商店可见性说明。
安装完成后的检查点
安装完成后，先确认能正常进入应用，再进行权限和连接配置。购买完成不代表订阅已经导入，也不代表系统已经建立连接；这些是随后独立完成的阶段。应用的更新由 App Store 管理，更新记录也应在商店中查阅。首次使用时不必急于调整大量设置，先保留初始状态，把商店获取、应用启动、服务器导入和实际连接分开验证，之后出现问题才能准确判断发生在哪一层。
02 / PERMISSIONS
首次启动与系统连接权限
区分应用开关与系统授权
首次启动后，先观察 Home 中是否已有服务器记录。空列表是尚未导入信息的正常状态，不能据此判断应用异常。Shadowrocket 建立系统级连接需要使用系统提供的 VPN 配置能力，首次尝试连接时可能出现添加 VPN 配置的系统确认。该确认用于允许应用在设备上建立网络通道，并不是远端服务器的登录窗口，也不意味着已经获得可用的服务器或订阅。
出现系统确认时，应核对提示关联的是当前正在使用的 Shadowrocket，再按设备要求完成确认或身份验证。系统密码、生物识别与服务器密码分属不同用途，不应互相填写。如果此前拒绝了授权，回到应用重新执行连接操作，观察系统是否再次提示；如需检查现有配置，可在系统设置中查找 VPN 相关项目，具体路径随系统界面变化，以设备实际显示为准。
权限失败时先看发生位置
如果应用开关立即退回，先查看是否存在未完成的系统确认、设备管理限制或其他正在建立的 VPN 连接。不能把这种现象直接归结为订阅失效，因为此时可能尚未开始访问远端服务器。受管理设备上的网络权限可能由管理策略决定，遇到限制应先确认设备政策。不要通过连续点击开关强行重试，先关闭当前连接请求，等待系统状态稳定，再记录具体提示。
如果系统配置已经存在，但应用仍提示授权问题，可先断开连接，查看系统中的对应配置是否仍归属于 Shadowrocket，并确认没有误选其他配置。修改或移除系统配置前，应保存自己的服务器和配置资料，理解移除后需要重新授权。删除整个应用不是权限排错的第一步，因为应用本地数据与系统配置的生命周期不同，贸然重装可能让原本简单的授权问题变成资料恢复问题。
按操作需要开放其他权限
使用 Scan QR Code 时，系统可能请求相机访问权限；只有实际采用扫码方式导入时才需要处理这一项。若此前拒绝相机访问，可在系统的应用权限设置中检查，而不是反复扫描。扫描相册中的图片与直接使用相机也可能对应不同的访问提示，应以当前操作所需为准。二维码往往含有完整连接参数，确认来源后再导入，不要为了排错把原始二维码公开发送。
粘贴订阅链接时，系统可能显示剪贴板相关提示。确认剪贴板中是自己准备导入的内容，避免复制了聊天文字、换行或多余标点。需要读取本地文件或云端文件时，先在系统文件选择界面中找到目标文件，再核对导入结果。权限只是允许访问相应资源，不能验证文件内容正确；授权成功后仍应检查服务器数量、名称和关键参数是否符合自己的预期。
首次使用建立清晰的基线
第一次配置建议在稳定的本地网络下进行，暂时不要同时启用复杂的 On Demand 条件或批量修改 DNS。先完成一个可辨认的服务器条目，再选择 Global Routing，最后尝试连接。这样可以把“无法导入”“无法建立系统连接”“连接后请求失败”分开处理。如果设备已有网络过滤或其他 VPN 配置，也应记录当前状态，并在测试期间明确只保留本次需要验证的连接条件。
授权完成后的检查重点不是系统是否出现某一个固定图标，而是应用连接状态、系统 VPN 状态与实际请求结果是否一致。不同设备对状态的显示方式可能不同，不能把状态栏没有常驻图标当成唯一失败依据。把此时的网络类型、所选服务器和授权结果记下来，下一章导入更多资料后仍可回到这组基线，判断变化来自新增数据还是系统层面的设置。
03 / SERVER & SUBSCRIBE
添加服务器与导入已有订阅
先判断手中的资料类型
开始导入前，先确认用户已有的资料是单个服务器参数、分享链接、二维码，还是能够返回多个服务器条目的订阅链接。这几种形式不能仅凭外观相似就互换：服务器地址描述连接目标，订阅地址用于获取条目集合，配置文件还可能包含规则与其他设置。若把订阅地址填写到服务器地址栏，即使输入完整也无法按预期工作。资料用途不明确时，应先核对原始说明，而不是试填每一个输入框。
使用 Add Server 手动添加时，先选择与已有资料一致的协议类型，再填写对应字段。地址通常只填主机名或 IP，端口单独填写，不把网页路径一并拼入地址。密码、UUID、加密方式以及其他选项应逐项对照，注意大小写、前后空格与输入法标点。给条目设置能区分用途的名称，避免多个名称相同的记录导致选择错误；名称用于辨认，不会修正错误的连接参数。
按协议核对必要参数
协议类型决定字段如何解释。同一个端口数字或同一段密码，不意味着可以在不同协议之间直接通用。Shadowsocks 需要匹配加密方式和密码；VMess、VLESS 的身份字段与传输条件需要一起核对；Trojan 的密码与 TLS 条件有关。HTTP、SOCKS5 的认证信息应按已有资料填写，不能沿用其他协议的字段含义。遇到 WireGuard、Hysteria2 等类型时，同样应以完整原始参数为依据，不凭名称猜测默认值。
导入 Subscribe 并检查结果
导入已有订阅时，在添加界面选择 Subscribe，填写完整订阅地址，保存后执行更新，检查是否生成预期的服务器记录。订阅地址中的查询参数通常属于访问凭据的一部分，不能随意删减、重新排序或替换。复制时尤其注意末尾字符是否丢失，聊天软件是否把链接截断，以及开头结尾是否夹入说明文字。导入成功后，应先选择其中一个条目测试，不要把列表出现视为全部条目都已通过验证。
订阅更新失败时，先区分地址无法访问、返回内容不被识别与远端授权失效。保留错误提示，核对完整链接，再比较当前网络下是否能够获取订阅内容。有些情况下原有服务器仍能连接，而订阅更新暂时失败，这说明更新请求与已有条目的连接不是同一过程。不要立即删除整个分组；先保留能工作的条目，再检查订阅获取条件，避免同时失去可用连接和排错依据。
扫码、更新与资料保护
通过 Scan QR Code 导入后，也要检查协议、地址、端口和认证字段；二维码识别成功只代表文本被读取，不代表文本完整或仍然有效。订阅更新可能改变条目名称、数量或顺序，因此不宜只靠列表位置记住常用服务器。若需要手工调整条目，先确认它是否会被下一次订阅更新覆盖，必要时保存独立副本并清楚命名，避免误把临时修改当作订阅源已经永久改变。
订阅链接、分享链接和二维码都可能包含访问授权，应按凭据对待。排错时可描述协议、错误类型与发生阶段，不公开完整密码、UUID 或订阅查询参数。导入完成的最低检查点是：列表中的条目来源清楚，关键参数能与原始资料对应，至少一个目标已被选中。接下来再配置 Global Routing；如果只需一次完整操作演示，可转到快速上手中的 Subscribe 导入说明。
04 / GLOBAL ROUTING
Global Routing 三姿态与规则顺序
先决定模式，再检查命中结果
Global Routing 决定请求按什么方式处理，界面中的三种姿态是 Config、Proxy、Direct，分别对应配置、代理、直连。Config 按当前配置规则选择策略；Proxy 将进入该处理范围的请求交给当前所选服务器；Direct 使用直接连接。三者是请求处理方式，不是三组服务器，也不会改变远端账号本身。排错时必须先记下当前姿态，否则同一条规则在不同模式下看起来可能像是没有生效。
日常使用 Config 时，应先确认当前启用的是哪份配置，而不是只确认 Config 列表里存在文件。保存文件、编辑文件和启用文件是不同动作。更改规则后，按应用提供的方式保存并应用，再发起新的测试请求；已有连接可能继续沿用先前状态。Proxy 可以帮助隔离部分规则问题，但测试结束后应恢复原本需要的姿态，避免将临时排错状态长期保留。
规则按顺序判断，最终规则负责兜底
常规规则按配置中的顺序依次判断，较具体的目标应放在较宽泛的规则之前。DOMAIN 用于完整域名，DOMAIN-SUFFIX 用于域名后缀及其子域名，DOMAIN-KEYWORD 按域名中的关键字判断。IP-CIDR、IP-CIDR6 处理地址范围，GEOIP 依据 IP 地理分类数据判断。规则类型决定匹配对象，最后的策略决定匹配后如何处理，不能把策略名称与匹配条件混为一谈。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY
上面的片段仅用于解释顺序，不是适合所有网络的完整配置。访问 api.example.com 时，第一条已匹配，后面的后缀规则不再决定该请求；其他属于 example.com 的目标可能由第二条处理。最后的 FINAL 表示前面都未匹配时采用的策略，应放在末尾。示例中的域名是教学用值，复制前需要明确自己真正要处理的目标，不能把示例当成已验证的业务规则。
理解策略、解析与规则边界
PROXY、DIRECT、REJECT 是常见的处理策略，规则中还可能引用配置里已定义的策略组。引用名称必须与实际定义一致；只写一个不存在的名称，不会自动创建策略组。需要拒绝某个目标时，应先缩小匹配范围，并确认该目标是否同时承载登录、验证或其他资源，避免宽泛规则影响正常功能。排错时优先使用具体域名，不急于扩大到关键字或整段地址范围。
域名规则与地址规则依赖的信息不同。请求携带域名时可以按域名判断，只有地址信息时则可能进入地址相关判断；某些规则还可能涉及额外解析。DNS 返回的地址、缓存与请求类型都会影响观察结果，所以不能只看目标名称就推断必然命中哪条规则。USER-AGENT 等条件也有适用范围，不能假定所有加密请求都能暴露相同的应用层字段。
配置越复杂，越需要保留一份可以恢复的基础文件。建议一次只增加一组规则，记录预期命中的目标和实际策略，再决定是否继续添加。出现异常时，先检查文件是否启用、规则顺序是否正确、策略名称是否有效，最后才考虑扩大修改范围。能够解释一条请求为何命中某条规则，比单纯积累大量规则更有助于维护。
05 / CONNECT & VERIFY
连接建立与分层验证
建立一次可重复的测试
连接前先固定三个条件：所选服务器、Global Routing 姿态和当前本地网络。确认服务器来自自己的有效资料，选择明确的姿态，再打开连接开关，处理尚未完成的系统授权。测试期间不要同时切换服务器、更新订阅和修改 DNS，否则即使请求恢复，也难以判断是哪一步产生作用。先用少量、可重复的请求建立基线，后续比较才能具有实际意义。
一次完整验证至少包含三个层次：系统连接是否建立，目标请求能否完成，实际处理策略是否符合预期。系统显示已连接，只能说明本地通道处于工作状态，不能证明远端服务器能够完成认证或访问目标。网页能打开，也不必然说明它经过了所选服务器；在 Config 下，它可能命中 DIRECT。因此验证结果要同时记录“能否访问”和“按什么策略处理”，不能只留下一个成功或失败结论。
Connectivity Test 的结果如何使用
Connectivity Test 可以帮助比较条目的基础连通情况，但应先明确所选测试方法。不同方法可能只检查连接建立、特定目标响应或部分协议阶段，结果不应直接等同于日常下载速度。一次测试出现超时，也可能与测试目标、网络瞬时变化或服务器对测试方式的处理有关。合理做法是在相同网络和相同测试条件下重复少量测试，再结合真实请求判断。
低延迟不代表较高吞吐量，能够建立连接也不代表所有业务请求都正常。若基础测试正常但某个页面失败，应继续看目标域名、规则、DNS 与相关资源，而不是立即否定整个服务器。反过来，如果多个独立目标都失败，且 Proxy 下同样无法完成请求，则更值得优先核对地址、端口、认证与远端状态。测试工具提供线索，不能替代对失败阶段的区分。
按失败现象选择下一步
遇到无法上网时，可先在断开状态下确认本地网络本身是否能够完成正常请求，再恢复同一个服务器进行对比。若本地网络需要网页认证，应先完成认证。测试 Proxy 与 Config 时，只改变模式这一项：Proxy 正常而 Config 异常，优先查规则、策略引用和配置是否启用；两者都异常，再查服务器与连接条件。这样的对照不能覆盖所有原因，但能显著缩小排查范围。
把“速度慢”与“连接失败”分开
速度问题应在连接已经可用的前提下分析。先固定测试内容和时间段，再区分远端服务器、本地网络、传输条件与目标服务本身的限制。大文件传输与短网页请求关注的指标不同，不能用一个很小请求的响应时间推断持续传输能力。比较时尽量避免其他设备或应用同时占用网络，也不要在测量过程中反复更换协议选项，以免失去可比性。
验证完成后，记录最终服务器、姿态、配置名称和网络类型，恢复日常需要的设置，并重新发起一次请求。若仍需深入排查，可阅读已连接却无法上网的逐项检查；持续速度不足则参考节点、线路、协议与本地网络的分层定位。记录应保留现象与条件，不包含完整访问凭据。
06 / DATA
Data 流量与请求记录的读法
先确认统计范围和时间窗口
Data 用于观察应用实际提供的流量与连接信息。阅读数字之前，先查看当前界面展示的是本次连接、某个时间范围还是累计数据，并确认是否存在重置操作。不同统计口径不能直接相减比较，重连后的变化也不一定等于所有历史记录被清空。应用界面的具体栏目以实际显示为准，不应根据其他设备上的截图推断自己必然拥有相同的统计视图或记录保留方式。
上行与下行描述传输方向，不等于上传文件与下载文件两类操作。打开网页同样需要发送请求，发送文件也会收到确认与响应。协议封装、重传、连接保活和名称解析都可能产生流量，所以界面统计与文件大小未必一致。要判断一项操作大致带来多少变化，可以在其他活动较少时记录操作前后数据，但应把结果视为近似观察，而不是精确的远端计费凭证。
客户端统计不替代远端账户记录
Shadowrocket 中的统计描述客户端能够观察到的活动，远端订阅的计费与额度可能采用不同口径。如果设备还有其他直接连接、多个设备共同使用同一远端账号，或统计时间不同，两边数字就更不能简单对齐。订阅中显示的剩余流量也可能来自远端返回的信息，更新频率与客户端实时计数不同。遇到差异时，先比较时间段和设备范围，再讨论数据是否异常。
观察某个应用是否走了预期策略，应结合请求目标与规则命中信息，而不是只看总流量增加。总量变化只能说明发生了网络活动，不能直接归因到某一个前台操作。系统后台同步、页面预加载和其他应用刷新都可能同时发生。为了减少干扰，可以先停止不必要的活动，再做一次短而明确的操作，记录对应时间，随后查看附近出现的请求与策略。
用请求信息定位规则与解析问题
如果当前界面提供连接或请求详情，可重点查看目标域名或地址、使用策略、关联服务器以及错误阶段。域名与地址不是同一类证据：前者有助于判断域名规则，后者有助于核对地址范围与解析结果。一个页面往往访问多个目标，主文档成功并不代表图片、登录验证和其他资源都采用同一路径。出现局部缺失时，应寻找失败的具体资源，而不是只添加页面主域名。
规则修改后，应新建请求再观察结果。浏览器已有连接、应用缓存与 DNS 缓存都可能让旧状态继续存在，使人误以为新规则没有生效。先结束当前测试操作，必要时关闭并重新发起相应请求，再检查新的记录。清理记录之前，先保存有价值的错误阶段和时间信息；如果直接清空再重试，而问题又暂时消失，就可能丢失唯一能解释故障的线索。
流量增加与后台活动的排查
发现后台流量持续增加时，先确认连接持续时间、设备上的同步任务和 On Demand 条件。常驻连接可能包含维护通信，但不能仅凭总量增长就判定某个设置有问题。将观察窗口缩短到一个容易复现的时段，比较屏幕使用、后台同步和网络切换是否与变化一致。耗电也不能只由流量数字解释，还与连接唤醒、无线网络状态及设备任务有关，应分开记录。
需要向他人描述问题时，优先提供经整理的时间、目标类型、策略与错误文字。请求记录可能含有访问习惯、完整地址、查询参数甚至认证资料，分享前应删去不相关内容。不要为了方便把所有记录和订阅一起发出。完成诊断后，把额外开启的详细记录恢复到日常需要的范围，既方便后续阅读，也减少不必要的信息积累。
07 / SETTINGS
Settings、DNS 与 On Demand 设置
先分清设置作用在哪一层
Settings 中的选项不都作用于同一个范围。有些属于应用行为，有些与当前连接有关，另一些由 Config 文件或具体服务器条目决定。修改之前先确认设置对象，并记下原值。若某个配置中已有相关内容，不能简单假定界面上的另一处设置一定会覆盖它；应查阅当前选项说明，再用实际请求验证。保持能够工作的基线，比一次开启许多看起来有用的选项更重要。
建议把设置分成三组处理：先完成连接所必需的项目，再调整按需连接和名称解析，最后才考虑与特定网络有关的高级选项。每次只修改一个逻辑相关组，保存后测试相同目标。若结果恶化，恢复该组原值，而不是再增加其他修改来补偿。对于尚不理解作用的开关，保留当前可用设置通常比猜测性调整更容易维护。
DNS 影响名称解析，不替代连接认证
DNS 的基本作用是把域名解析为请求所需的地址。解析失败、返回地址不符合预期或解析过程本身不可达，都可能表现为网页打不开，但这与服务器密码错误是不同阶段。排查时先观察失败发生在解析之前还是之后，再确定需要修改的层面。某个 IP 可以建立连接，不代表该服务所有域名请求都正常；许多服务还依赖名称、证书与多个资源域名，不能简单用地址访问代替完整测试。
选择或修改 DNS 时，需要同时考虑解析服务能否在当前连接条件下到达，以及配置如何安排解析请求。不要只替换地址而不检查访问路径，也不要把多个来源不明的地址不断叠加。测试应记录域名、返回结果与时间，并保持其他条件不变。启用加密解析也不等于所有请求都会采用同一出口，解析路径与业务请求策略仍需要分别验证，不能用一个设置推断整条连接链路。
On Demand 按条件触发连接
On Demand 用于按照设定条件决定何时建立或保持连接，不是自动修复远端服务器的功能。设置之前，先写清自己需要的行为：进入某个网络时是否连接、离开后是否保持、哪些场景应直接使用本地网络。具体可用条件以应用当前界面为准，条件之间的顺序与匹配范围需要逐项核对。网络名称相近并不代表条件相同，保存后必须在真实切换过程中验证。
出现关闭开关后又自动连接时，先检查 On Demand 是否仍在生效，而不是立即认为手动开关失灵。按需规则可能在新的网络请求或网络变化时重新触发连接。排错期间可以暂时停用相关条件，完成手动连接验证后，再逐项恢复。对于需要网页认证的网络，尤其要先完成本地认证，再确认按需条件是否适合，避免连接触发时机干扰最初的接入过程。
连接取舍与高级选项
按需连接与持续连接在使用体验、后台活动和网络切换恢复上有不同取舍，不存在适合所有设备的统一答案。频繁进入或离开触发条件，也可能带来额外的连接建立过程。判断耗电时，比较相似使用时长和网络环境，不只看某一次系统统计。需要更完整的对照思路，可阅读On Demand 与后台耗电的设置取舍，再按自己的实际使用方式决定。
涉及 IPv6、UDP、连接超时或其他网络参数时，应先确认症状与该选项确实相关。仅某个请求失败，不足以证明需要全局关闭某类能力；改变范围越大，越可能影响原本正常的请求。优先采用小范围测试，并保存修改前后的结果。设置完成后，至少验证一次重新连接和一次网络切换，确保不是只在当前尚未结束的连接中看起来正常。
08 / MAINTENANCE
日常维护、换机与故障记录
把应用、订阅与配置分开维护
日常维护应分别处理应用更新、订阅更新和 Config 文件修改。应用更新来自 App Store，订阅更新从用户已有的地址获取服务器条目，配置修改则改变规则与相关行为。三者发生变化时可能互相影响，但不是同一操作。为了方便定位，尽量不要在同一次测试前同时完成所有更新；先确认当前连接可用，记录状态，再分阶段操作，每一步结束后做一次简短验证。
订阅更新后，核对条目数量、常用服务器是否仍在、当前选中项是否发生变化。不要仅凭名称相同就认为参数没有改变，也不要因为列表顺序变化就误判条目丢失。若某个条目由订阅维护，手工修改可能被后续更新覆盖，应把临时测试与日常条目区分开。定期清理重复、失效且已确认不再需要的记录，但在故障尚未定位前，不宜批量删除资料。
保留可恢复的配置与资料
修改 Config 前保存一份可工作的副本，名称中写明用途即可，不必堆叠难以分辨的“最终”标记。备份不仅需要规则文本，还应明确哪些参数来自服务器条目、哪些由订阅更新提供。涉及密码、UUID 和完整订阅地址的资料应保存在受保护的位置，避免混入公开笔记。恢复时先看内容适用范围，不要把某台设备上的所有设置不加判断地应用到另一台设备。
换机前，分别检查应用购买账号、已有服务器资料和配置文件是否能够重新取得。恢复 App Store 购买与恢复应用内部资料不是同一件事：前者解决能否重新获取客户端，后者决定能否找回原来的连接条件。使用原购买账号在 App Store 的已购项目中查找 Shadowrocket，系统要求与购买适用范围以 App Store 页面标注为准。具体步骤见已购恢复说明。
重装前先建立最小排错记录
遇到故障时，先记录发生时间、设备网络类型、Global Routing 姿态、配置名称、服务器协议和错误阶段。说明是订阅无法更新、系统连接无法建立，还是连接后某个目标失败。把问题缩小到一个可重复操作，再做对照测试，比“全部重置后看看”更容易得到有用结论。记录中可用自定义代号指代服务器，避免暴露真实地址与认证字段。
重装不是常规的第一步。移除应用可能让本地资料、记录和已保存的调试线索无法继续使用，而远端认证错误、网络条件或规则逻辑问题未必因此改变。先尝试恢复最近一次可用配置、关闭临时新增的条件，并按连接章节的顺序检查。确实需要重装时，应先确认自己能够重新获取所有必要资料，再执行操作；不要把“商店中还能下载”当成“内部配置已经备份”。
形成可重复的维护流程
可以把每次维护压缩成固定的顺序：确认基线，保存资料，执行一项变更，测试代表性目标，检查实际策略，最后记录结果。代表性目标应覆盖自己真正需要的几类访问，而不是一次打开大量无关页面。正常结果也值得简短记录，因为下一次异常时，需要知道上一次成功使用了哪些条件。若测试临时切换到 Proxy，结束时记得恢复日常姿态，并确认 On Demand 条件符合原计划。
共享排错信息前，再检查截图、日志和复制文本中的敏感内容，尤其是订阅查询参数、认证字段与访问记录。对方通常需要的是错误阶段和复现条件，而非完整账户资料。更换设备后无法找到购买记录，可继续阅读换机或重装后的已购恢复方法；第一次重新配置时则返回快速上手教程，按单条主线建立可用连接，再逐项恢复个性化设置。