Shadowrocket 完整使用手册

一、App Store 获取与购买核验

先确认买到正确的应用，再准备连接资料。Shadowrocket 是 Apple 平台的闭源商业应用，唯一获取入口是 App Store。应用购买解决的是客户端使用资格，用户已有订阅或服务器的使用条件则需单独核对。把这两件事分开，可以避免安装后没有服务器可选时误以为购买失效，也能区分账户购买问题与网络连接问题。

核对产品页的三个信息

从本站正版核验说明进入产品页，依次核对名称 Shadowrocket、开发者 Shadow Launch Technology Limited，以及产品页地址中的应用 ID 932747118。同时对照本站页头使用的官方应用图标。搜索结果中的名称相近并不能代替这些核验；应在同一个产品页上完成检查，再查看购买按钮、兼容性与应用说明。

商店页面中的图标、开发者和应用 ID 是辨认产品的依据，不能只凭搜索排序或名称里的中文别称判断。若打开页面后看到的开发者不一致，先返回核验步骤，不要把随后出现的权限或购买流程当作同一应用继续操作。核验时也应区分应用名称与开发者名称，两者不是同一个字段。

价格、设备与购买范围

Shadowrocket 采用一次性买断方式，美区定价约为 2.99 美元，实际金额、货币与税费以 App Store 页面显示为准。购买前确认用于 App Store 的 Apple 账户及所在店面，完成购买后保留系统提供的购买记录。价格不是连接质量指标，也不能据此推断某个服务器的有效期、可用流量或可连接地区。

本手册以 iPhone / iPad 为主。Mac、Apple TV 与 Apple Vision 也可在同一产品页的兼容性栏核对；系统要求及购买适用范围一律以 App Store 页面标注为准。不要把某台设备已经安装成功，直接推断为另一台设备必然适用。准备在第二台设备使用前，应分别检查设备系统、账户购买记录与该页的兼容性信息。

安装、已购恢复与更新

完成购买后由 App Store 安装应用。重新安装或更换设备时，先用原购买账户查看已购项目，再按商店提供的操作恢复。如果页面仍显示购买金额，应先核对当前用于商店的账户、购买记录和产品是否一致，而不是立即重复付款。设备上用于其他系统服务的账户与用于商店购买的账户可能不同，应以实际购买记录为准。

应用恢复和连接配置恢复是两件事。商店能帮助找回已购应用，但服务器地址、订阅内容、当前选中的配置文件与本地规则，应按原来的保存方式单独检查。不要假设重新安装后就能恢复先前所有连接资料。家人共享是否适用也只按 App Store 页面及账户实际显示判断，不能仅凭其他应用的购买经验类推。

更新同样通过 App Store 处理。计划更新前，记录当前使用的服务器、Global Routing 状态和 Config 文件名称；重要的本地修改先备份。更新后先验证原有连接，再调整设置，这样出现差异时能够判断是资料变化、网络变化还是本次操作造成。商店中的更新记录用于了解变动，本文不固定列出应用版本号。

进入下一章前，确认应用可以正常打开，并已准备好自己的服务器资料或订阅。只有购买记录、设备兼容性和应用安装三项都明确后，才进入权限与导入流程。关于账户恢复、购买价格和设备入口的集中问答，可继续查阅已购恢复与价格说明。

二、首次启动与 VPN 配置权限

首次启动应先熟悉页面，再处理系统授权。Home 主要用于查看已有服务器、选择连接对象和控制连接；Config 用于管理配置文件；Data 用于观察流量与请求；Settings 用于调整应用行为。不同设备或应用更新后的布局可能有所调整，应按英文项目名称寻找，不要仅凭按钮在旧图中的位置操作。首次连接的目标是建立可验证的基础状态，而不是一次开启所有设置。

系统 VPN 授权代表什么

Shadowrocket 在建立连接时需要使用系统 VPN 配置机制。首次触发相关操作，系统可能要求允许添加 VPN 配置，并通过设备的认证方式确认。这是允许客户端在系统网络路径中工作，不等于已经验证服务器正确，也不等于远端服务已经登录成功。应用安装、系统授权与服务器认证属于不同阶段，排查时应分别判断。

授权前看清提示来自系统，并确认当前打开的是已经核验的 Shadowrocket。接受授权后，返回应用继续检查连接状态。如果先前取消了提示，可以再次发起连接，根据系统当前提示处理；不要为绕过一次取消而反复删除应用。必要时到系统 Settings 的 VPN 相关位置检查现有配置，菜单层级以设备当前系统显示为准。

建立首次连接前的基础状态

先在未连接状态下确认设备本身能够访问常用网站，排除 Wi-Fi 尚未完成认证、蜂窝数据未启用或网络临时断开的情况。若设备连基础网页都无法打开，应先处理当前网络。客户端依赖现有网络建立到服务器的连接，系统出现 VPN 标记并不会替代基础网络接入，也不会自动完成公共 Wi-Fi 的登录流程。

随后查看 Home 是否已有你认识的服务器条目。空白列表只表示还没有完成资料添加，并不表示安装失败。已有条目也要核对是否来自自己的记录，尤其是在恢复设备或导入旧备份之后。先选择一个资料完整、用途明确的条目作为测试对象，暂时不要让多个不确定的设置同时参与首次连接。

第一次测试建议先明确 On Demand 的当前状态。若已启用按需连接，它可能根据网络条件再次发起连接，使手动断开后的状态难以理解。为了获得清晰的测试过程，可以先记录其原有设置，再暂时关闭自动触发条件。测试结束后恢复所需条件，而不是在没有记录的情况下改变所有自动化设置。

其他权限按用途处理

使用 Scan QR Code 时，系统可能请求相机权限；仅通过手动输入或已有链接导入时，相机权限不是建立连接的前提。涉及访问本地设备的操作时，还应留意系统是否给出相关网络权限提示。处理权限时应把提示与刚刚发起的动作对应起来，不要把与本次操作无关的权限变化当作修复连接的通用步骤。

VPN 配置授权也不等于安装证书。普通服务器连接不应被笼统解释为必须额外启用 HTTPS 解密。若某份配置涉及证书、重写或其他高级处理，应先理解其用途与适用范围，再单独评估。不要因为网页打不开就直接增加证书信任，也不要把关闭证书校验作为首次连接的常规操作，这会改变原本的安全边界。

如果连接开关刚打开便关闭，先分辨是否仍有未完成的系统提示，再检查配置是否完整；如果开关保持开启但网页没有响应，则转到连接验证章节。记录异常发生在授权前、授权后还是请求目标时，可以缩小排查范围。连续快速切换开关会打乱时间线，建议每次操作后等待状态稳定，再执行下一项检查。

本章完成的标准是：应用身份已经核验、基础网络可用、系统权限提示得到明确处理、自动连接条件处于已知状态。随后才进入服务器或订阅导入。只想沿最短流程完成操作，可回到使用说明继续；需要核对导入字段与配置关系，则直接阅读下一章。

三、添加已有服务器与订阅

先区分服务器条目、订阅与配置文件。服务器条目描述如何连接某个远端；订阅用于批量获取和更新条目；Config 文件主要描述流量处理方式及相关参数。三者可以配合使用，但不能互相替代。看到列表里出现服务器，不代表已经启用了预期的分流规则；导入一份规则文件，也不代表其中必然包含可使用的服务器。

Add Server 与手动字段

在 Home 进入 Add Server，先选与已有资料一致的协议类型，再逐项填写。协议选错时，其他字段即使看起来相似，也未必能够建立连接。地址应填资料中的主机名或 IP，端口按原值输入；地址字段通常不应混入网页路径或说明文字。不要把管理网页地址直接当作服务器地址，也不要从名称中的数字猜测端口。

认证字段随协议不同而变化。填写密码、UUID、加密方式或密钥时，应使用原始资料，不要根据其他条目的写法补全。复制后检查首尾空格与换行，但不要擅自改变大小写或删掉特殊字符。备注只用于辨认，不会修复地址、认证或传输参数。对于来源资料缺失的必填字段，应先核对资料，而不是反复试填常见值。

涉及 TLS 时，连接地址、证书验证名称与传输中的 Host 或路径可能分别承担不同作用，应按已有配置逐一对应。它们有时相同，但不能因此认定始终可以互换。尤其在导入成功却握手失败时，应先检查这些字段是否完整，而不是直接放宽验证条件。界面出现某个高级选项，并不表示所有协议都需要修改它。

Subscribe 与批量更新

已有订阅可按应用中的 Subscribe 相关入口添加，并将自己的订阅地址完整粘贴。订阅地址往往包含访问凭据，应当作私密资料保存，不要公开截图或粘贴到公开笔记。导入前核对是否带入了空格、换行或中文标点；订阅地址与服务器地址用途不同，不能把整段订阅内容随意填进单个服务器的地址栏。

更新订阅本质上是重新获取条目资料，不是延长已有服务的使用期限。更新成功后，要再次检查当前选中的服务器是否仍存在、名称是否变化、手动编辑是否被新内容覆盖。若更新失败，原有条目可能仍保留，但保留不代表参数仍有效。应区分获取失败、内容无法解析与服务器本身无法连接，三种问题的处理方向不同。

订阅为空时，先核对地址是否完整，再确认当前网络是否可以访问该订阅端点，并查看应用给出的提示。不要因为结果为空就立即删除全部旧记录；先保存必要信息，以免失去可对照的基线。如果同一地址在另一网络下结果不同，应把问题记录为订阅获取路径差异，而不是直接认定所有服务器都失效。

扫码导入与导入后验收

通过 Scan QR Code 导入时，二维码可能承载单个服务器，也可能承载其他配置资料，应以解析结果为准。导入前确认内容来自自己的记录；导入后打开条目核对协议、地址、端口与认证字段。Import from Cloud JSON 等入口也应匹配其要求的资料格式，不能仅凭文件名称或扩展名推断内容一定适用。

导入后的验收顺序是先看数量和名称是否符合预期，再检查至少一个准备使用的条目，然后明确选择它并进行连接验证。名称里的地区描述不等于实际路径保证，延迟测试结果也不等于业务访问成功。关于已有条目的挑选，可参阅延迟测试与服务器选择笔记。

若需要保留手动修改，先记录修改项，再决定后续是否继续由订阅覆盖。不要在多个同名副本之间来回测试而不记录选中对象，否则容易把某一条成功的结果误归因于另一条。完成本章后，应能明确说出当前使用的是哪个条目、其资料来自哪里，以及下一次更新会影响哪些内容。

四、Global Routing 与规则匹配

Global Routing 决定流量采用哪一种总体处理方式。中文可概括为配置、代理、直连，对应界面词分别是 Config、Proxy、Direct。先选对姿态，再讨论具体规则；否则在 Proxy 状态下修改规则，却期待分流结果变化，容易得到错误结论。服务器条目负责连接方式，Global Routing 负责总体路由选择，两者需要同时明确。

Config、Proxy、Direct 的分工

三种姿态用于对照路径，而不是三个不同的服务器。切换后应重新发起测试请求，必要时关闭旧页面再打开，因为已经建立的连接不一定按新选择重新建立。Direct 也不等同于关闭应用连接开关，系统隧道与请求处理方式是两个层次；需要比较完全未连接的基础网络时，应单独记录开关状态。

使用 Config 前，先到 Config 确认当前启用的文件名称与内容。列表里存在某份文件，不代表它就是正在使用的文件；编辑了一个副本，也不意味着运行中的配置已同步改变。保存并按界面要求启用后，再通过新请求验证。文件名称相近时，建议保留清晰备注，避免在多个副本之间误判修改是否生效。

规则按顺序匹配，FINAL 负责兜底

[Rule] 段中的规则从上到下检查，命中后采用对应策略。因此范围较小的例外通常放在范围较大的规则之前，兜底行放在末尾。DOMAIN 用于特定域名，DOMAIN-SUFFIX 用于域名及其子域范围，DOMAIN-KEYWORD 范围更宽，使用前应考虑是否会匹配到并非预期的域名。

[General]
bypass-system = true
skip-proxy = 192.168.0.0/16, 10.0.0.0/8, localhost
dns-server = system

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

以上是用于阅读语法的示例，不是适用于所有人的完整配置。PROXY 表示代理处理，DIRECT 表示直连，REJECT 表示拒绝。示例中的域名仅用于说明匹配方式，不能用它验证实际服务。FINAL,PROXY 兜底前面没有命中的流量，应先确认这符合自己的预期，再采用相应策略。

IP-CIDR 与 IP-CIDR6 针对地址网段，GEOIP 根据地址归属数据判断，它们与直接匹配域名不是同一种依据。域名请求可能涉及解析过程，no-resolve 用于避免仅为该条地址规则触发域名解析；不要把它理解为关闭整个应用的 DNS。归属数据也不能代替对某次实际请求的观察。

先做最小修改，再观察命中

排查某个目标时，先在现有配置副本中添加范围明确的规则，并将其放在可能覆盖它的宽泛规则之前。每次只调整一个条件，保存后发起新请求，查看实际目标与策略。不要一边更换服务器、一边改 DNS、一边调整规则顺序；否则即使恢复，也无法确认是哪项变化起了作用，下一次问题会更难复现。

局域网相关设置也需要结合实际网段理解。示例只列出部分私有地址范围，不代表设备所在网络一定使用这些地址；应从自己的网络信息核对。发现某个本地服务仍无法访问时，还要检查发现机制、设备权限和当前网络隔离情况，不能只凭一条直连规则推断所有本地通信都会恢复。

只有在 Config 状态、正确文件已启用且新请求确实命中时，才能评价某条规则的效果。需要更细的排列示例，可继续阅读规则优先级与 FINAL 兜底；关键字含义可在术语表交叉查阅。

五、连接建立与分层验证

连接验证应分层进行：基础网络可用、客户端连接保持、服务器链路可用、目标请求按预期处理。任何一个图标或单个测试数字，都不能覆盖这四个层次。开始测试前记录当前网络、选中服务器、Global Routing 与 Config 文件，随后只改变一个变量。这样才能把“刚才可以、现在不行”转成能够重复验证的具体条件。

按顺序完成一次基线测试

先在未连接状态打开一个平时可访问的页面，确认设备本身联网。随后选择已经核对过的服务器，设置明确的 Global Routing，再打开 Home 的连接开关。等待状态稳定，处理仍未完成的系统提示。若连接立即停止，应先看本次操作产生的提示或日志，而不是继续刷新网页；此时问题可能还没有进入目标访问阶段。

连接保持后，用新的页面请求测试一到两个用途明确的目标。优先使用自己平时访问且便于判断结果的页面，不要同时启动大批下载或多个视频应用。先确认页面能否完整加载，再观察图片、登录或其他业务动作。页面标题显示出来只证明部分资源成功，不能据此认定整条业务链路全部正常。

测试 Config 时应留意目标实际命中的策略；测试 Proxy 时，应明确是在观察代理路径；测试 Direct 时，应把结果视为当前网络直连的对照。某个目标在直连状态成功而在代理状态失败，说明两条路径表现不同，但仍需继续区分服务器、认证、解析与目标限制，不能只凭这一现象立即断定某个配置字段有误。

Connectivity Test 的含义与局限

Connectivity Test 或相关延迟测试通常用于观察某种探测方式下的可达性与耗时，具体测试方法和目标以应用当前设置为准。测试返回数字不等于所有业务可用，超时也不必然表示全部连接都失败。应先了解探测目标，再把数字与真实页面访问结合判断，不要把不同测试方法得到的结果放在同一标准下排序。

延迟较低只反映特定测试过程的往返或响应特征，不直接代表持续传输速度、连接稳定性或视频加载表现。已有服务器之间的选择，应结合测试时间、网络环境、实际业务和协议资料。避免只因一次数字变化就频繁切换，这会中断已有会话，也会让后续记录混入不同服务器的结果。

按异常位置缩小范围

出现解析异常时，不要立刻把所有 DNS 项改成陌生地址。先确认域名是否正确、基础网络是否需要认证，以及失败记录究竟停在哪一步。直接访问某个 IP 也不是域名访问的等价替代，因为 TLS、虚拟主机或内容分发可能依赖域名。用 IP 访问失败，并不足以反推出该域名的解析一定有问题。

认证或 TLS 异常应回到原始服务器资料，检查密码、UUID、证书名称、传输参数与设备时间。时间明显不准可能影响证书验证。不要用关闭校验来掩盖资料错误，也不要把所有握手失败都归为网络速度问题。若订阅刚更新，尤其要确认当前条目是否仍是先前测试的那一个。

网络切换后出现问题，可分别在 Wi-Fi 与蜂窝网络中做同样的一组短测试，并记录切换前后结果。某一网络下失败而另一网络正常，提示基础路径可能存在差异，但还应保持服务器和配置不变才能比较。公共网络若要求先登录，应先完成网络认证，再重新发起客户端连接，避免把认证页面问题混入服务器排查。

一次合格的验证记录应说明测试时间、网络类型、条目备注、姿态、目标与可见错误，并隐去凭据。如果仍无法定位，保留最近一次最清晰的失败样本，再进入 Data 查看对应请求。不要先清空记录再尝试回忆，也不要把包含完整订阅地址、密码或密钥的日志直接公开。

六、Data 流量与请求观察

Data 用于把“页面有问题”细化为具体请求与流量变化。它能帮助观察应用处理到的网络活动，但不能自动解释所有业务失败原因。阅读记录时应区分请求目标、采用策略、连接状态与传输统计；不同视图显示的字段可能不同，以当前应用实际呈现为准。先带着一个问题进入 Data，比漫无目的地浏览大量记录更有效。

用一个动作定位一组请求

开始观察前，关闭不必要的后台访问或暂停大流量任务，记下当前时间，再对目标应用执行一次明确操作，例如打开某个页面。随后查看该时间附近新增的请求。不要一边刷新多个应用一边判断哪条记录对应故障；一项业务往往已经会产生多个域名请求，额外背景活动会进一步增加辨认难度。

如果记录很多，按目标域名、发生时间或应用提供的筛选方式缩小范围。先找与问题直接相关的请求，再看它前后的活动。网页地址栏的主域名可能只负责入口，图片、脚本、登录和接口可能使用不同目标。主页面成功而某个功能失败时，应继续观察该功能触发后的新增请求，而不是只检查第一次打开页面的记录。

把规则命中与流量方向分开看

在可见记录中核对目标采用的是 PROXY、DIRECT 还是 REJECT，并与自己的规则预期比较。若目标被 REJECT，先检查是否由过宽的关键字或已有规则造成；若走 DIRECT 却预期代理，先确认当前姿态与启用文件。不要直接把所有拒绝规则删除，应先用范围明确的例外验证，再决定是否调整原规则的匹配范围。

同一个页面可能同时出现多种策略，这是分流的正常结果之一。某些资源直连、某些资源代理，不自动构成配置冲突；关键在于这些选择是否符合你的意图，以及业务是否正常。相反，如果所有请求都走同一路径，也不一定是规则失效，可能是当前姿态、规则范围或兜底策略本来就作出了相同选择。

看到有上传或下载字节，只能说明相应范围内发生了数据交换，不能直接认定目标业务成功。认证失败页面、重试请求和错误响应同样会产生流量。判断登录、文件传输或媒体播放是否完成，应同时看业务界面结果与相关请求。记录中连接已经结束，也可能只是一次正常短连接，不应只凭结束状态判断故障。

理解统计口径与计费边界

Data 中的累计值、某个会话的数值与服务商账户中的计量可能采用不同口径。直连流量是否纳入某个视图、统计从何时开始、是否包含协议开销，都需要结合该视图的实际定义理解。不要把客户端显示的总量直接当作已有订阅剩余额度，也不要根据一个累计数字反推远端账单一定有误。

需要观察某项任务的流量变化时，先记录开始值、结束值和测试持续时间，并尽量减少其他网络活动。若使用了清理或重置功能，先确认会影响哪些记录。删除历史记录并不会修复服务器认证、改变规则命中或恢复远端使用额度；它主要改变的是本地观察材料，因此排错期间应先保留有价值的样本。

从记录回到可验证的修改

假设页面里的图片失败，而主页面正常，先定位图片对应的目标，查看是否被拒绝或采用了不同策略。随后在配置副本里只改这一个目标的处理方式，再重试同一动作。若恢复，说明这项路径变化与结果有关；接下来仍要检查规则是否过宽、是否影响其他目标，而不是把临时测试配置直接当作最终方案。

如果记录提示请求已走预期代理，但业务仍失败，则继续检查远端连通性、TLS 和目标响应，避免反复改动已经正确的规则。若完全找不到对应请求，要先确认观察时间、筛选条件和当前连接状态。应用缓存可能让某次动作没有重新发出请求，应触发一个新的操作，而不是立刻认定客户端没有处理该应用的流量。

导出或分享诊断信息前，应移除订阅地址中的访问凭据、服务器认证字段、密钥以及不必要的私人访问域名。最有用的反馈通常是一小段时间范围、一个明确目标、预期策略和实际错误，而不是全部历史。保留必要上下文，同时减少敏感信息，能够让后续排查更集中，也方便日后与恢复后的结果对比。

七、Settings、DNS 与 On Demand

Settings 中的选项应围绕具体需求调整。先明确要解决的是自动连接、解析、测试还是记录保留，再修改对应项目。选项越多并不表示连接越稳定；互相叠加的自动化和配置覆盖反而会增加判断难度。开始调整前保存当前可用状态，尤其要记录哪些值来自 Config、哪些值来自应用设置，以及哪些只是当前会话的临时选择。

On Demand 的触发与手动开关

On Demand 用于按设定条件触发连接或断开，不负责提供服务器，也不修复失效的认证资料。按需条件可能涉及 Wi-Fi、蜂窝网络或域名，实际可选项以当前界面为准。设置之前先让手动连接稳定工作，否则自动化只会把同一个失败过程重复触发，增加耗电与观察噪声，却不能解决底层连接问题。

设置 Wi-Fi 条件时，应核对名称与预期动作，特别注意同名网络、网络切换和暂时失去连接的情形。蜂窝条件则需要考虑设备从 Wi-Fi 切出时是否符合预期。域名条件描述的是触发条件，不应与 Config 中决定请求走向的规则混为一谈；一个负责何时建立连接，另一个负责连接后如何处理流量。

完成设置后分别测试符合条件与不符合条件的场景，并观察手动断开后的行为。如果关闭后很快再次连接，先检查 On Demand 是否重新触发，而不是认定开关失灵。测试时每次只保留一组容易理解的条件，确认结果后再增加复杂度。更详细的条件讨论见On Demand 按需连接笔记。

DNS 与配置作用范围

DNS 负责将域名解析为地址，但解析成功并不保证地址可达，地址可达也不代表业务认证成功。遇到域名访问异常时，先分清解析阶段与后续连接阶段。不要把所有访问问题都归到 DNS，更不要在没有记录原值的情况下连续替换多组解析设置；这样会让相同目标的缓存、地址与路径同时改变。

配置示例中的 dns-server = system 表示使用相应的系统解析设置。实际使用何种方式，应结合已有配置、网络条件及信任范围决定。应用设置与 Config 文件中若都存在相关选项，需要核对当前生效来源，不能仅看到某处显示一个值，就假定所有请求都采用该值。修改后应等待状态稳定并发起新请求验证。

DNS 解析过程与路由判断可能相互关联，例如地址规则需要地址信息，而域名规则可以直接对域名作出判断。若解析结果随网络变化，最终路径也可能发生变化。定位问题时尽量保留同一服务器、同一配置与同一目标，再对照一项解析设置。不要同时增加地址规则和更换解析方式，否则难以分清各自影响。

连接测试、日志与安全边界

Connectivity Test 的目标和方法若可调整，应记录修改前后的值。不同方法返回的耗时不能直接比较，也不能为了获得更小数字而选择与实际需求无关的目标。日常测试只需帮助判断已有条目是否值得进一步验证，最终仍以真实业务表现为准。测试过于频繁也会增加网络请求，不需要把每次轻微波动都视为故障。

日志相关设置应服务于一段明确的排查过程。需要详细记录时先开启适当级别，复现问题后保存必要片段，再恢复日常设置。持续保留大量记录会增加管理负担，也会积累更多私人网络信息。分享前先脱敏，并确认导出内容是否包含服务器认证、订阅访问凭据或不必要的访问历史。

涉及 TLS 校验、证书、重写或其他高级处理的选项，应单独阅读其说明。普通连接不应依赖随意降低验证要求来维持可用；若只有改变验证边界才能连接，应返回检查服务器资料、证书名称和时间设置。对于不理解用途的选项，保留当前明确可用的值，比照着另一份配置逐项开启更利于稳定维护。

设置验收应覆盖首次连接、手动断开、网络切换与设备重新使用后的状态。特别是 On Demand，不能只在当前 Wi-Fi 测试一次就视为完成。确认行为稳定后保存一份简洁的设置记录，注明用途而非仅列数值；下次排查时，便能判断该选项为什么存在，以及是否仍适合当前环境。

八、配置备份、更新与日常维护

维护的目标是保留可用基线，并让每次变化都有记录。客户端更新、订阅更新、规则修改、设备换网和账户恢复属于不同事件，应尽量分开处理。一次完成多个变化后即使出现问题，也很难找出原因。日常不需要频繁重置全部设置；先保存信息、缩小范围、进行小幅验证，通常更容易恢复并理解问题。

建立一份可回退的基线

连接正常时，记录当前选中的服务器备注、Global Routing、Config 文件名称、关键设置以及最近一次验证方式。对本地修改的配置保存副本，并使用能区分用途的名称。备份不仅是复制文件，还要确认恢复时知道应该启用哪份内容。包含凭据的资料应存放在受控位置，不要为了方便对照而放进公开笔记。

配置备份、订阅地址与服务器凭据应分别理解。恢复配置文件可能只恢复规则，不一定恢复全部服务器；保留订阅地址也不意味着远端内容永远不变。若使用应用提供的导出或同步能力，应先核对实际包含哪些项目，再在第二台设备验收。不能仅因为导入没有报错，就认定原设备的全部状态已经完整迁移。

订阅和规则分开更新

更新订阅前，记录当前使用条目及必要的本地修改；更新后检查条目是否被删除、替换或重新命名，再进行短测试。若订阅内容发生变化，应优先按新资料核对，而不是把旧字段强行填回。对于需要长期手动保留的内容，应明确其独立维护方式，避免每次更新后都在不知情的情况下被覆盖。

规则文件更新则应关注匹配范围、顺序、兜底策略与新增的高级处理。外部获得的配置不能只因名称熟悉就直接启用，应先阅读与自己需求相关的部分。特别是最终策略、拒绝规则、DNS 与证书相关内容，可能明显改变行为。保留原文件，在副本中验证后再决定是否替换，出现问题时能够及时回退。

如果更新后只有某个目标失败，先比较该目标对应的规则与记录，不要立即撤销全部服务器更新。反过来，如果多个目标都在认证阶段失败，应优先核对服务器资料，而不是逐个为网站添加例外。维护时把故障分类为资料、路径、规则或业务响应，能够避免越来越多临时修补堆积到同一份配置里。

换机、重装与 iPad 迁移

更换设备时，先通过原购买账户在 App Store 找回应用，再恢复自己的资料。系统要求与购买适用范围以 App Store 页面标注为准。首次打开仍要检查 VPN 配置授权、当前服务器和启用文件，不要因为购买已经恢复就跳过连接验收。系统备份可能保留部分状态，但应以新设备实际显示与测试结果为准。

从 iPhone 迁移到 iPad 时，操作区域可能因横屏、分屏或更宽布局发生变化，应按 Home、Config、Data、Settings 等名称定位。先验证单个已有服务器，再逐步恢复规则和按需条件。两台设备的网络与使用场景可能不同，不需要为了界面看起来一致而强制采用所有相同设置。可补充阅读iPad 已购恢复与布局说明。

保留故障样本，避免连续重置

连接突然异常时，先记录最后一次正常使用与首次失败之间发生了什么：是否更新订阅、切换网络、改动规则或调整系统设置。保留当前错误提示和最近请求，再尝试恢复到已知基线。重置全部内容会同时移除线索与可用设置，只有在明确知道备份可恢复、且较小范围排查不足时，才考虑更大范围的整理。

长期未使用的条目可以在确认不再需要后清理，但先区分手动条目与订阅管理内容，避免下次更新又出现同名副本。规则也应定期检查重复、过宽匹配和已经没有用途的例外。清理时每次处理一类问题，完成后验证常用目标；不要把删除数量当作维护效果，真正的标准是行为更明确、恢复更容易。

向他人描述问题时，给出设备类型、当前网络、操作步骤、Global Routing、目标与错误类别即可，并对服务器、订阅和日志脱敏。需要确认字段含义可查术语表；需要重新走一遍首次连接可查快速使用说明；关于新手常见的操作混淆，可读新手十问。

完成维护后，再用固定的一组短测试确认常用页面、必要的本地访问和网络切换行为，并更新基线记录。未来出现差异时，先对照这一份记录，而不是从头猜测所有参数。手册各章可以独立查阅，但操作顺序仍建议保持获取、权限、资料、路由、验证与观察的层次，让每一步都有清楚的输入和结果。