Shadowrocket 完整使用手册

正版获取与购买记录

先确认应用身份，再进行购买。Shadowrocket 是 Apple 平台上的付费商业客户端，主要操作场景为 iPhone 与 iPad，唯一获取入口是 App Store。Mac、Apple TV 与 Apple Vision 的兼容性也可在同一产品页查看，系统要求与是否通用购买以 App Store 页面标注为准。本手册后续步骤围绕 iPhone 与 iPad 展开，不把其他设备的页面布局当作相同操作说明。

核对名称、开发者与应用 ID

从正版核验页进入商店说明，依次核对应用名称 Shadowrocket、开发者 Shadow Launch Technology Limited、产品链接中的应用 ID 932747118。再将商店图标与本站页头的官方图标对照。名称相似不等于同一应用，搜索结果的位置、附加介绍或页面配色也不能替代身份核对，应以产品页实际列出的信息为依据。

商店页面同时承担价格、兼容性与更新记录的查询入口。购买前展开兼容性信息，确认当前设备能否安装；价格则查看当前店面与账户结算时显示的金额。不要把文章中的价格举例当作最终扣款依据，也不要仅凭设备属于某一产品系列就推断支持情况。同一型号在系统状态不同的情况下，商店呈现的可用操作可能不同。

区分客户端购买与连接服务

Shadowrocket 采用一次性买断方式，美区定价约为 2.99 美元，各店面按当地货币显示，实际金额以 App Store 页面为准。这里购买的是客户端使用资格。服务器地址、身份验证信息、服务可用时间与数据额度来自用户已有的服务配置，并不由客户端购买行为自动生成。安装完成但列表为空时，应继续导入已有配置，而不是重复购买应用。

购买前建议确认正在使用的 App Store 账户，并保留系统产生的购买记录。系统账户与商店购买账户在某些设备设置中可以分别管理，不能只看设备顶部显示的姓名就判断购买归属。后续换机、重新安装或查询付款时，重点是找到原购买记录，而不是依赖客户端内部的服务器名称、配置备注或连接状态来证明曾经购买。

安装、恢复与更新的边界

在商店完成购买并安装后，先打开一次应用，确认能够进入主要页面，再处理订阅和权限。若商店显示需要再次付费，先检查账户与购买记录是否一致，不要急于确认付款。同一购买账户下的再次获取，以及其他设备上的适用权益，都应结合商店页面和账户实际记录判断；家人共享是否适用也以页面标注及账户设置为准。

换机恢复要分成两件事：恢复应用购买资格，以及恢复应用内的数据。通过已购项目找回应用，不等于服务器、订阅链接与本地配置必然同时回来。准备更换设备时，应先确认是否有可用的配置备份，并保存自己已有服务的原始信息。仅记住一条服务器备注通常不足以重建连接，因为备注里不包含协议、端口和验证参数。

应用更新通过 App Store 管理。更新前，保存正在使用的配置和必要的连接参数；更新后，检查默认服务器、Global Routing 与当前启用的配置是否仍符合预期。若商店无法完成安装，先处理账户、付款、设备空间或系统兼容性等商店层面的问题。此阶段尚未涉及远端连接，修改 DNS 或规则不会解决购买与安装问题。

这一章的完成标准是：能够在商店核对同一产品、确认购买归属、正常打开应用，并清楚知道已有连接信息保存在哪里。不要以“图标已经出现在主屏幕”作为全部准备工作的终点。先把获取与数据恢复的边界分开，后续连接失败时才能准确判断是应用状态、参数问题，还是远端服务本身需要检查。

首次启动与 VPN 配置权限

首次打开后，先认识 Home 页，再开始连接。Home 集中了连接开关、Global Routing、Connectivity Test 与 SERVER 列表。不同设备和应用状态可能影响区块的呈现方式，应按英文名称识别功能，而不是照着固定坐标点击。详细界面说明可参阅首次打开与 Home 页说明，本章重点解释权限和连接状态的关系。

认识 Home 页的四个判断点

连接开关负责启动或停止当前连接；Not Connected 表示当前尚未建立相应连接状态，不代表应用购买失败。Global Routing 决定流量按配置规则处理、使用代理策略，还是采用直连方式。SERVER 列表保存可供选择的服务器项目，点开编辑某个项目和将它选为默认服务器是两种操作，需要分别确认。

Connectivity Test 用来检查列表中服务器的连通情况。测试结果可以帮助缩小问题范围，但不能代替完整的实际访问验证。初次进入时列表为空，测试自然无法提供有效的服务器结果；列表中出现内容，也不代表所有项目都可用。应先完成第三章的参数核对，再把测试结果作为参考，避免在缺少必要信息时反复切换开关。

还应区分“应用里显示的状态”和“系统里保留的配置”。系统可能保存此前添加的 VPN 配置，而应用当前并未连接；应用能够正常打开，也不意味着系统已经允许它建立连接。观察状态时，先看应用当前选中的项目和开关，再看系统的 VPN 状态，不要只凭状态栏某一个图标推断所有流量的具体去向。

理解添加 VPN 配置的系统提示

当应用请求建立所需的网络连接时，系统会要求确认添加 VPN 配置。它是 Apple 系统管理连接权限的流程，不是购买确认，也不是订阅登录。应先确认提示出现在自己主动操作 Shadowrocket 的过程中，再按系统说明允许，并完成设备要求的身份验证。确认前可以先保存手头操作，避免切换应用后忘记提示来自哪个步骤。

如果此前取消了授权，先回到应用确认是否仍可重新发起连接，再按当前系统提示操作。系统设置中的路径会随系统界面变化，可使用设置搜索查找 VPN，检查是否存在 Shadowrocket 对应的配置及当前状态。不要连续添加多个用途不明的配置，也不要为了重试而删除其他仍在使用的网络配置；先辨认归属再处理。

若设备由组织管理，网络配置可能受到管理策略限制。遇到不能确认、不能添加或开关立即恢复原状的情况，应先检查设备是否存在相应限制，并向设备管理方确认允许的设置。重复导入订阅并不会改变系统策略。排查时保留准确的系统提示文本，比凭印象描述“没有反应”更有助于定位这一类问题。

建立首次操作的基准状态

初次配置时，先保持手动连接，暂不启用 On Demand。只保留一条明确的操作链：准备服务器、选定默认项、检查路由方式、开启连接、验证访问。这样一旦状态变化，就能对应到最近的操作。若同时开启自动触发、修改配置和更新订阅，连接恢复或断开的原因就不容易辨认，也难以判断某次修改是否真正生效。

首次权限处理完后，记录应用是否能维持开启状态，以及系统是否显示相应连接。若开关不能维持，应优先检查权限、配置有效性与错误提示；若能够维持但访问失败，则进入连接验证流程。两种表现属于不同的排查分支。不要把“已允许权限”“开关已打开”“目标访问成功”合并成一个笼统的成功条件。

完成本章时，应能独立指出 Home 页上负责连接、路由、测试和服务器选择的区域，并知道系统权限是否已经确认。此时不要求所有目标都能访问，但必须清楚当前尚缺的是服务器信息、权限确认还是连接验证。如果只需要沿着最短路径完成操作，可回到使用教程；若要理解参数来源和导入边界，继续下一章。

服务器与订阅导入

导入前先确认自己拿到的是单个服务器信息、服务器分享内容、订阅链接，还是配置文件。它们解决的问题不同：服务器项目保存一次连接所需的参数；订阅用于更新一组服务器；配置文件主要组织路由及相关设置。把配置文件地址当作订阅输入，或把普通网页地址填进服务器地址字段，都可能出现解析失败或内容与预期不符的结果。

手动添加与协议参数核对

通过 Add Server 手动添加时，先选协议，再填写地址与端口，最后核对验证和传输参数。字段必须来自用户已有的服务信息，不应靠名称猜测。相同域名可以对应不同端口，相同端口也可能承载不同协议；参数看起来完整并不表示组合正确。保存后重新进入编辑页逐项复核，尤其注意复制时多出的空格、换行和全角符号。

表格只说明检查方向，不代表所有协议都要填写相同字段。若服务信息包含传输路径、主机名或 TLS 服务器名称，应按其各自用途填写，不要一律复制到地址栏。服务器地址用于确定连接端点，TLS 相关名称用于相应的身份校验；二者可能相同，也可能由服务配置明确指定为不同值，不能互相替代。

导入已有订阅并检查结果

已有订阅时，使用应用的添加入口选择 Subscribe，填入完整订阅地址并保存，随后执行相应更新操作。订阅链接通常包含访问凭据，复制时应保持完整，但不应发到公开聊天、截图或问题描述里。导入完成后回到 SERVER 列表，检查是否出现预期分组与项目；仅看到订阅名称，并不能证明服务器内容已经成功取得。

如果列表为空，先判断是更新动作尚未完成、请求失败，还是返回内容不能被识别。检查链接开头、末尾和查询参数是否完整，确认拿到的确实是订阅入口而非账户管理网页。再向原服务方核对订阅状态和支持的内容格式。不要连续重复添加同一地址，否则容易形成多个同名分组，让后续更新和删除更难判断。

更新订阅可能新增、移除或修改服务器项目，因此它不是单纯的刷新显示。更新前记下当前默认服务器所属分组，更新后重新检查选择是否仍然有效。若服务器改名，不要只按旧备注判断它已消失，应结合分组和服务方说明核对。关于空列表与解析错误的分支，可参阅订阅解析失败自查。

分享导入、二维码与配置文件

使用 Scan QR Code 导入时，先确认二维码来自自己已有服务的可信资料，并检查导入后呈现的协议、地址和备注。扫码只是减少手动录入，不会验证远端服务质量或保证参数仍然有效。若二维码显示在同一设备上，应使用应用当前提供的相应导入方式；不要为了识别二维码而把含凭据的图片转交到公开识别渠道。

导入分享内容后，应确认保存的是单个服务器还是订阅入口。单个项目通常不能据此推断未来会自动更新，而订阅下的项目可能在更新时发生变化。遇到导入后可编辑字段与原资料不一致，应先保留原资料，逐项检查协议支持和参数映射，不要立刻覆盖原本可用的服务器，以免丢失用于比较的基准。

配置文件导入后，还要在 Config 中确认当前启用的是哪一份。文件已经保存与文件已经启用是不同状态。导入含有规则的配置前，先阅读其策略引用、最终规则和 DNS 设置，检查是否依赖额外的规则资源。若配置引用了不存在的策略，不能仅凭文件能够打开就认为分流逻辑完整。下一章将说明这些规则如何与 Global Routing 配合。

本章完成标准是：列表中存在可辨认的服务器，来源类型清楚，关键参数能够与原始资料对应，订阅更新结果可以复核。最后单独选择默认服务器，不要停留在编辑完成的页面就认为已经选中。保留一份可用参数作为回退依据，再进入路由设置，能够把导入错误和分流错误分开处理。

三种路由方式与规则顺序

Global Routing 的三种方式分别是配置 Config、代理 Proxy、直连 Direct。它们改变连接采用的路由判断方式，不负责补全服务器密码，也不会修复远端服务故障。排查前先确认当前方式，尤其是在“服务器测试有结果，但某个应用访问不符合预期”时。此时问题可能来自规则选择了不同策略，而不是默认服务器失效。

先确定流量由谁决定

Config 适合按目标分别处理连接，但前提是当前配置内容明确。Proxy 可以用来观察代理路径的基本可用性，却不能被理解为所有特殊流量和系统行为都必然具有完全相同的表现。Direct 也不是“停止应用”的同义词。需要结束当前连接时，应使用连接开关；需要比较路由影响时，再切换 Global Routing。

按从上到下的顺序理解规则

规则通常按顺序检查，先命中的适用规则决定相应策略。具体条件放在前面，范围较大的条件放在后面，最后用 FINAL 处理未命中的连接。若把宽泛规则放得过早，后面的精确规则就可能没有机会匹配。排查时不要只搜索某个域名是否出现，还要阅读它前面的规则，以及这些规则实际指向的策略。

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

这是语法示例，不是适用于所有环境的完整配置。DOMAIN 针对指定域名，DOMAIN-SUFFIX 用于域名后缀匹配，DOMAIN-KEYWORD 按域名中的关键词匹配，IP-CIDR 针对地址网段。GEOIP 依赖相应地址数据，不能将其判断当成目标业务归属的绝对依据。FINAL 是末尾兜底，需要与用户预期的默认路径一致。

示例中，精确域名规则位于关键词规则之前，因此不能只看关键词中包含 example，就断言所有相关请求都会直连。类似地，域名规则与地址规则关注的信息不同；实际连接能够提供什么匹配信息，也会影响命中情况。不要把浏览器地址栏里看到的页面名称，直接当作该页面全部请求只涉及一个域名的证据。

区分规则、策略和当前配置

PROXY、DIRECT 与 REJECT 是规则里常见的策略关键字，作用不同。若规则引用了自定义策略名称，应检查相应定义确实存在，并确认策略最终使用哪条服务器。一个文件语法看起来正确，仍可能因为策略名称拼写不同而不符合预期。修改时保留大小写、分隔符与字段顺序，不要将英文逗号替换为中文逗号。

Config 中可能保存多份文件。编辑某一份后，先保存，再确认当前使用的确实是这份文件，最后按应用提示使连接使用新配置。仅修改文件名不会改变规则内容，远程配置更新也可能覆盖本地改动。对于需要长期保留的自定义规则，应明确其维护位置，并在更新前保留副本，而不是把所有修改都堆到来源不明的文件中。

遇到单个目标异常时，先临时比较 Proxy 与 Config 的结果。若代理路径正常而配置路径异常，重点检查规则和策略；若两者都异常，再回到服务器及远端条件。完成比较后恢复原本需要的方式，避免把临时排查状态当作长期配置。测试过程中每次只改变一个条件，记录变化，才能保留有用的因果关系。

最后，规则匹配不是一次设置后永远不变的结论。目标服务可能使用多个域名、不同地址和不同连接方式，配置更新也会改变顺序。应在实际使用场景中验证，而不是仅看某条示例规则存在就结束检查。涉及 DNS 与地址判断的情况，可结合第七章继续阅读；对常见现象的集中解释可查阅常见问题。

连接、验证与分层排查

连接成功要分层判断：基础网络可以使用、服务器参数有效、系统允许建立连接、当前路由符合预期、实际目标能够完成请求。任一层异常，都可能表现为“连不上”，但处理办法不同。先把现象描述清楚，例如开关无法维持、测试超时、只有一个目标失败，或切换网络后异常，再选择对应的检查路径。

建立一次可重复的连接流程

先确认当前 Wi-Fi 或蜂窝网络已经具备正常上网条件。若网络要求完成接入确认，应先完成该流程。然后回到 Home，在 SERVER 列表中选择准备验证的服务器，确认默认选择标记位于目标项目。不要把点击项目进入详情，误认为已经完成默认选择；也不要只看同名备注，因为不同分组里可能存在名称相同的服务器。

接着确认 Global Routing。初次验证可以先选择明确的代理路径，再开启连接，按提示处理系统权限。等状态稳定后执行 Connectivity Test，并在浏览器或实际需要使用的应用里发起一次新的请求。关于默认选择与首次测试的连续步骤，可参阅第一次连接与测试说明。

测试时尽量固定网络、服务器和目标，避免在一次操作中同时改变三者。页面可能存在缓存，应用也可能保留原先的连接，因此观察结果时应考虑是否真正产生了新请求。若只看已经加载过的页面，容易把缓存显示误判为网络成功。可以重新发起明确操作，并结合连接记录确认是否出现与目标相符的新活动。

区分测试结果与实际访问结果

Connectivity Test 的结果反映当前测试条件下的连通表现，不是远端所有业务的完整结论。测试有结果，但实际目标失败，可能涉及目标本身、DNS、规则或应用采用的连接方式；测试超时，也不能立即推断保存的每一个字段都错误。先比较其他已有服务器，再比较同一服务器在另一种基础网络下的表现，有助于缩小范围。

若连接开关立即关闭，优先查看应用提示和系统 VPN 状态，检查权限与配置是否有效。若开关维持开启但所有请求失败，先核对默认服务器、协议、端口及验证信息，再确认远端服务状态。若只有 Config 下失败，转查当前启用文件与规则策略。若只有单个应用异常，应检查该应用涉及的域名和请求，而不是马上重置全部配置。

还要区分短暂中断与稳定复现。锁屏恢复、网络切换或远端连接重建期间可能出现过渡状态，先等待当前动作结束，再进行新的测试。若异常能按相同步骤重复出现，记录发生条件；若只是偶发，不要立即修改多个底层参数。连续叠加改动可能暂时掩盖问题，却让原本可重复的条件消失，增加后续维护成本。

用最小改动定位故障层

当多条已有服务器都异常时，先检查共同条件：同一个基础网络、同一份配置、同一个 DNS 设置或同一项系统限制。若只有一条异常，则更应核对该项目的参数与远端状态。这样的分组判断比逐条乱改有效。比较时保留一条已确认可用的项目，作为控制条件，不要在未记录原值前覆盖它的验证参数。

发生 TLS 或身份验证相关错误时，核对设备时间、服务器名称要求与原始参数，不应通过随意关闭验证来代替检查。发生域名解析错误时，先判断是服务器域名无法解析，还是目标域名处理异常，这两种情况对应不同环节。发生超时时，则结合网络、端口和远端状态分析；相同错误词并不总是同一个原因。

需要寻求进一步帮助时，提供脱敏后的现象、协议类型、网络类型、Global Routing 方式与已完成的对照测试。不要公开完整订阅、密码、UUID、密钥或带查询参数的地址。错误提示可以保留与原因有关的部分，服务器身份信息则应遮蔽。若联系原服务方，说明哪条项目和何种网络下复现，通常比发送整套配置更明确。

本章结束时，应获得一个可复核的结论：基本连接可用，或故障已缩小到权限、参数、路由、解析、目标服务中的某一层。验证成功后再恢复需要的 Config 方式，检查典型目标是否符合预期。之后进入 Data，观察实际流量，而不是把一次测试数字当作全部连接质量的长期证明。

流量统计与连接观察

Data 用于观察应用提供的流量信息及相关连接活动，适合回答“是否产生了流量”“变化来自哪个操作”“统计范围是什么”等问题。它与服务方的账户结算记录并不是同一个计量系统。阅读任何数字前，先确认页面当前展示的时间范围、统计对象和单位，再讨论增长是否异常，避免将不同范围的数据直接相减。

先确认统计口径再比较

上传与下载分别描述数据传输方向，瞬时速率与累计数据量也不同。速率表示某个时间窗口内的传输速度，累计量表示相应范围内传输了多少数据。页面上的瞬时变化不能直接推算整月用量；同样，一段时间没有明显速率，也不能证明之前没有后台传输。应结合观察起止时间和操作行为理解结果。

客户端统计、系统蜂窝数据统计和服务方记录可能存在差异，因为计量边界、会话范围、更新时机及协议开销不一定相同。查看服务额度时，应以已有服务的账户记录和计量说明为准。若数字不一致，先核对是否在比较同一时间段、同一设备与同一连接范围，不要仅凭差额就认定某一端出错。

如果准备重置或清理统计，先保存当前需要的观察结果，并明确操作会影响哪些本地记录。重置客户端数字不会恢复远端账户额度，也不会改变已经发生的数据传输。不要为了让数字看起来归零而反复清理，这会破坏跨时段比较所需的基线。对于长期记录，应把时间、网络和使用场景一并记下。

用单一操作观察流量变化

需要验证某个操作是否产生预期流量时，先记录当前读数，暂时减少其他应用的活动，再执行一个范围明确的操作，例如重新加载一个页面。操作结束后回到 Data，比较相应记录的变化。如果同时播放媒体、同步照片和更新应用，就很难把总量增长归因于某个页面，单独的数字便失去排查价值。

后台同步、通知与应用自己的刷新都可能产生连接，因此用户没有主动点击，不等于设备完全没有网络活动。观察到持续增长时，应先检查系统和应用正在进行的任务，再分析具体连接记录。媒体缓存和预加载也可能使实际传输量大于屏幕上当前可见内容，这属于需要结合使用场景解释的现象。

想验证分流是否正确时，流量增长只能证明发生了传输，不能单独证明命中了预期规则。应结合具体目标、连接记录和路由策略核对。尤其在 Config 下，一次页面加载可能涉及多个域名，不同请求可以匹配不同策略。总量变化无法替代第四章的规则检查，更不能据此断言整个应用始终使用同一条路径。

阅读连接信息并保护记录

应用内的连接信息若提供目标、策略或错误等字段，应围绕一个具体请求阅读：先确定操作发生的时间，再定位对应目标，然后检查所用策略与结果。不要按列表第一行就推断它必然对应刚才的页面，因为后台请求可能同时出现。目标使用共享域名或地址时，也不能只凭名称片段确认它属于哪一个应用。

记录中可能包含访问域名、地址、时间和其他网络细节，导出或截图前应检查内容。分享问题时，只保留与故障相关的少量条目，遮蔽个人服务信息和访问凭据。若完整日志会暴露无关活动，先提取错误时间和必要字段；排查通常需要清晰上下文，而不是尽可能多的原始数据。

持续出现大量失败连接时，先看它们是否集中到同一目标、同一策略或同一时间点。相同目标反复重试，可能使记录迅速增长，但不意味着有同等规模的有效数据传输。应回到目标与路由层检查原因，不要仅根据记录条数判断线路负载。只有明确统计口径后，条目数量和数据量才有可比较的意义。

完成观察后，将临时测试与日常使用分开记录。长期维护只需保留关键异常、改动前后的结果及必要基线，不必持续收集所有细节。若 Data 显示活动正常而目标仍然异常，应继续检查响应是否成功、内容是否完整以及应用自身状态。数据有传输，只能说明链路中发生了活动，不能自动等同于业务请求完成。

常用设置与自动连接

Settings 的修改应建立在手动连接已经可用的基础上。先明确要解决的问题，再调整对应设置，并保留原值。应用设置、当前配置文件和系统网络设置可能分别影响同一连接，因此排查时要注明修改发生在哪一层。不要仅记录“换了 DNS”或“打开自动连接”，而应写清所改位置、原有状态及验证结果。

DNS：先理解解析发生在哪里

DNS 将域名转换为后续连接需要的地址信息。连接失败可能发生在解析之前、解析过程中或取得地址之后，因此修改 DNS 不能修复所有超时。先判断无法解析的是服务器域名还是访问目标，再检查当前配置中的相关设置。服务器地址本身不能解析时，连接端点尚未确定；目标解析异常时，则需结合当前路由和解析路径分析。

系统 DNS、自定义 DNS 与 DNS over HTTPS 的使用方式不同，选择时应考虑当前网络和解析服务是否可达。加密传输描述的是解析请求的一种传输方式，不意味着它必然适合每一种网络条件。更换解析设置后，要用相同目标和相同服务器比较结果，避免同时切换网络导致判断失真。详细原理见DNS 设置对照说明。

[General]
dns-server = system

这段示例展示在配置文件中使用系统 DNS 的设置位置，不是完整配置，也不是所有环境的统一答案。编辑时注意它属于 General 区段，不要放进 Rule 区段。若当前文件已经包含同名设置，应先阅读原值和相关项，再决定修改方式，避免重复定义造成理解困难。保存后确认启用文件，并按应用提示重新验证。

缓存会影响短时间内的对比：相同目标可能暂时继续使用已取得的结果，应用也可能复用现有连接。测试时应结合新请求和连接记录判断，而不是修改后立即看到旧页面就认定没有生效。若问题仅影响一个目标，先检查该目标记录和规则，不要直接把全部解析策略改成另一套复杂配置。

On Demand：先手动可用，再自动触发

On Demand 用于按配置的条件管理连接触发。它不是服务器健康修复功能，也不能替代第一次手动授权。启用前，先确认选定服务器可用、Config 行为正确，并阅读应用当前提供的条件选项。只添加自己能解释的条件，再分别验证符合和不符合条件时的状态，避免出现自动连接与预期不一致却找不到原因。

验证自动触发时，应记录当前网络、连接状态和触发动作。例如网络变化后，观察应用是否按设定进入预期状态，再检查实际访问。不要仅因开关重新开启就判断远端连接已经成功。若用户手动断开后又看到连接恢复，应先检查 On Demand 是否仍然启用，以及当前条件是否再次触发，而不是反复删除系统配置。

连接相关选项与修改纪律

协议中的 TLS、传输方式与其他参数，应按已有服务要求设置，不属于可随意调节的通用优化开关。若目标是解决兼容性问题，应先确认服务端支持范围；若目标是排查错误，应先保留原参数并记录错误变化。仅因为某项名字与网络有关就把它打开，可能改变原本成立的连接条件，使新问题与旧问题混在一起。

配置文件和界面设置出现相关项时，不要自行假设所有选项都采用同一优先级。先查看当前文件、应用说明及实际连接结果，明确生效来源。远程配置更新后，也要检查先前依赖的设置是否仍在。对于不理解用途的选项，保留已验证状态通常比批量修改更容易维护；需要变更时，先用副本做范围有限的验证。

每次修改遵循“原值、目的、结果、回退”四项记录即可。目的应具体，例如确认某个域名能否完成解析，而不是笼统地追求速度。结果应能复现，不能只凭一瞬间的页面加载感受。若变更没有改善，先恢复原值再尝试下一项。这样可以避免长期积累一组无人知道原因的设置，并为下一章的维护建立清楚基线。

备份、更新与日常维护

日常维护的目标是保留一套可解释、可恢复的工作状态，而不是不断增加配置数量。至少明确当前默认服务器、订阅来源、启用的 Config、Global Routing 方式与自动连接条件。遇到异常时，这些信息能帮助判断最近改变了什么；准备换机时，它们也构成恢复清单。只有一份应用截图，通常不足以还原完整状态。

分别备份服务器、订阅与配置

备份前先区分对象：服务器参数决定连接端点与验证方式，订阅链接用于重新取得服务器列表，配置文件保存分流及相关设置。某一种导出内容不一定包含其他全部数据，应实际检查备份里有什么。使用应用当前提供的导出或备份功能时，阅读操作说明，并确认备份是否包含敏感信息、是否依赖账户或其他恢复条件。

把备份保存在自己能够管理的受保护位置，避免以公开链接传播。订阅地址、密码、UUID 和密钥均应视为敏感信息。给备份加上便于辨认的说明，记录它对应哪套配置与使用场景，但不要在文件名中写完整凭据。若服务信息已经变更，旧备份可能不再适用，应保留必要的历史说明，防止恢复时误用。

换机前最好做一次恢复演练：确认能找到原购买记录，能定位已有订阅或服务器资料，也能读懂配置文件中的策略引用。演练不要求删除正在使用的数据，可以在副本上核对。重点是证明恢复所需资料确实存在，而不是仅凭“以前导出过”就认为已经准备完成。设备丢失后再寻找唯一保存在设备里的链接，往往会失去恢复依据。

更新后按固定顺序复核

更新分成应用更新、订阅更新和配置更新三种。应用更新由 App Store 管理；订阅更新可能改变服务器列表；配置更新可能改变规则、策略和解析设置。尽量不要在同一次排查中把三者一起更新，否则很难确定哪个变化影响结果。每完成一种更新，先验证基本连接和典型目标，再进行下一项维护操作。

订阅更新后，先检查默认服务器是否仍然存在，再看分组和项目变化。配置更新后，先核对启用文件、最终规则和自定义策略，再检查本地修改是否被保留。应用更新后，则复核权限状态、连接开关和自动触发条件。复核不必遍历每一个网站，但应覆盖日常确实依赖的几类目标，以及局域网等需要直连的使用场景。

发现问题时，先恢复最近一项已记录的变更。若订阅内容发生变化，应向原服务方核对状态，不要拿旧项目强行覆盖全部新列表；若配置规则变化导致异常，则用已保存副本比较差异。回退是为了恢复已知状态并定位原因，不代表旧内容可以无限期使用。对于远端已失效的服务器，客户端本地回退也无法让它重新可用。

整理配置并形成故障记录

定期清理重复订阅、用途不明的配置与失效项目，但删除前先确认它们是否仍被使用。尤其要检查同名文件和同名服务器，避免只凭名称删除当前有效项。可以用清晰备注区分测试与日常配置，记录来源和用途，而不是给每个副本添加难以辨认的序号。保留少量有明确意义的回退副本，比长期堆积所有历史文件更易管理。

故障记录只需要保留能支持判断的信息：发生条件、错误表现、默认服务器类别、路由方式、最近变更和对照测试结果。应去除订阅凭据与个人访问细节。若某次调整解决问题，再写明最终保留的设置，并清除不再需要的临时尝试，避免数周后只记得“改过很多地方”，却无法重建因果关系。

如果必须重新安装，先停止连接，检查 On Demand 状态，再确认数据保存完整，并通过 App Store 重新获取。安装后按本手册顺序恢复：处理权限、导入已有信息、选择默认服务器、启用配置、验证连接，最后恢复自动触发。不要一次导入全部历史文件后立即连接，否则重复项目与旧规则可能再次引入同样的问题。

至此，日常维护形成一个闭环：保留基准、一次变更、分层验证、记录结果、必要时回退。需要快速重走连接主线时使用使用教程；遇到常见购买或导入疑问时查阅常见问题；需要核对商店身份与已购恢复时返回正版下载与恢复说明。本页用于解释各阶段边界，实际参数始终以应用内选项与用户已有服务信息为准。