Shadowrocket
系统教程与配置查阅

01 / APP STORE

正版获取与购买范围

先确认产品身份，再进行购买与安装。Shadowrocket 是 Apple 平台的付费客户端，唯一获取入口是 App Store；搜索到相近名称时，不要仅凭中文别称判断。进入本站正版下载与核验页，按开发者、官方图标和应用 ID 三项逐一对照，确认后再继续购买流程。

核对产品页的三项信息

开发者应为 Shadow Launch Technology Limited，产品页地址中的应用 ID 应为 932747118。应用名称可以帮助定位，但名称不是单独的核验依据。打开详情页后再看开发者字段，比只看搜索结果摘要更可靠；如果信息不一致，应停止购买并重新进入正确产品页。

图标应与本站页头使用的官方图标一致：白底、蓝紫描边的图形。图标只能作为三项核对中的一项，不能替代开发者与应用 ID。保存商店链接时保留完整产品地址，日后从浏览器书签返回，也应再次检查地址与页面内容，避免把相近产品当成同一应用。

购买前阅读产品页的兼容性与购买说明。iPhone 与 iPad 是本手册的主要操作设备；Mac、Apple TV、Apple Vision 的兼容情况也可在同一商店页查阅。所有系统要求与购买适用范围以 App Store 页面标注为准，不根据其他设备的安装结果推断当前设备一定适用。

区分客户端费用与连接配置

Shadowrocket 采用一次性买断形式，美区定价约为 2.99 美元，实际金额以购买时 App Store 页面为准，各店面按当地货币显示。客户端费用支付给应用销售渠道；服务器是否有效、订阅何时到期、可使用哪些连接参数，属于你已有服务的范围，不能由购买应用这一步决定。

客户端一次性买断 ≠ 线路套餐。安装完成后没有可用服务器条目，并不表示购买失败，而是还没有导入自己的连接信息。先确认手头已有订阅地址或完整服务器参数，再进入第三章；如果暂时没有这些信息，可以先阅读界面和规则章节，不必反复重装应用。

购买账号与配置内容应分别理解。App Store 中的购买记录用于确认应用获取资格，应用里的服务器和规则则属于另外一组数据。换机后能重新取得客户端，不代表订阅、手工添加的条目与本地配置已经一起恢复；恢复购买和恢复配置需要分别检查，不能合并为一次验证。

安装完成后的起点

下载完成后，从设备主屏幕打开 Shadowrocket，先确认应用能正常进入，再考虑连接。第一次阅读本手册时，建议记下当前设备类型、所用网络、已有配置的来源与取得方式。这些信息不需要上传，只作为后续排查的基准；出现异常时，可以判断问题发生在安装、导入还是连接阶段。

如果商店显示已经购买但当前设备仍要求付费，先检查当前用于 App Store 购买的账号是否与原购买记录一致，再查看已购项目。不要把设备登录状态与商店购买状态视为同一个结论。商店付款、可用地区和购买记录的问题，应在 App Store 的实际提示范围内处理。

应用更新同样通过 App Store 完成。更新前保留重要配置，更新后先验证原来的常用连接，不要立即同时修改协议、规则与 DNS。商店里的更新说明用于了解功能变化；本手册不固定某个应用版本的界面位置，遇到选项排列差异时，以当前应用内名称及说明为准。

02 / PERMISSION

首次启动与 VPN 权限

首次启动应先完成界面识别，再在准备连接时处理系统授权。Shadowrocket 的连接依赖设备允许添加 VPN 配置；这一授权与服务器账号是否有效是不同环节。看到授权弹窗并完成确认，只说明系统允许应用建立对应连接，并不说明远端服务器、规则或 DNS 已经验证通过。

认识 Home、Config、Data 与 Settings

Home 主要用于查看服务器条目、选择连接对象和控制连接；Config 用于管理当前规则配置；Data 用于查看流量与请求相关信息；Settings 汇集常用行为设置。阅读时先记住各区域的职责，不必寻找与其他设备完全一致的按钮坐标，实际布局会受设备尺寸与应用界面调整影响。

连接前在 Home 确认是否已有自己的服务器条目。如果列表为空，先不要用连接开关反复尝试，因为开关本身不会生成服务器信息。进入添加或导入流程后，确认保存的条目可以重新打开查看，再返回 Home；这一步能够把“信息未保存”和“连接无法建立”两种问题分开。

Config 中看到配置名称，也不等于已经启用了其中的规则。先确认当前选择的配置文件，再检查 Global Routing 的状态。只有理解服务器选择、配置文件选择和分流姿态这三个独立因素，后面才能解释为什么同一台设备上的不同请求可能采用不同处理方式。

理解系统授权的实际含义

首次开启连接时，系统可能要求允许添加 VPN 配置，并通过设备认证确认操作。应阅读弹窗，确认它是在你主动启动 Shadowrocket 连接后出现，再按系统流程继续。授权是设备级设置变更，不需要把服务器密码填进系统认证步骤；服务器凭据只应放在对应连接字段中。

如果此前点了取消，回到应用重新发起连接，并检查系统是否再次提出授权。如果没有弹窗或开关立即回退，先查看系统设置中的 VPN 状态与相关提示。受管理设备可能有额外限制，遇到明确的管理策略提示时，不应通过反复删除配置来试探，应先确认设备是否允许此类连接。

授权之后仍需选择有效的服务器，并核对网络是否能访问服务器地址。系统显示连接状态，是本地连接流程的一部分；网页能否加载还受规则、服务器认证、域名解析与目标站点影响。因此，“已经授权”“状态已连接”“请求已成功”应作为三个检查点分别记录。

清理冲突而不是清空全部设置

如果设备上已有其他 VPN 配置，测试时先明确当前由哪一项接管连接。不要在多个相关开关之间来回切换后直接判断结果；先停止当前连接，确认系统状态回到预期，再启动 Shadowrocket。保留已有配置的名称与用途，避免在不清楚影响范围时删除工作、学校或设备管理所需的项目。

第一次验证期间先暂缓启用 On Demand。自动触发可能在你切换网络或访问域名时改变连接状态，让手动操作看起来没有生效。先用一次完整的手动连接与断开建立基准，确认服务器可用之后，再逐项加入自动连接条件，这样更容易看清每个设置带来的影响。

iPhone 与 iPad 的授权原理相同，但横屏、分屏与窗口宽度会改变内容排列。找不到某个选项时，先退出过窄的分屏视图，回到完整应用窗口再查找对应英文名称。不要因为界面位置变化就重新导入订阅；显示布局变化不会自动证明配置内容已经损坏。

删除系统中的 VPN 配置不等于删除应用内服务器，重新安装应用也不等于解决所有权限问题。只有当系统明确报告配置异常、并且你已保留可恢复数据时，才考虑重建相关项目。操作后重新走一遍授权与手动连接流程，不要沿用删除前的状态判断当前结果。

03 / SERVER & SUBSCRIBE

添加服务器与导入已有订阅

导入前先识别手头资料的类型。单条服务器信息描述一个连接对象，订阅地址通常用于获取和更新一组服务器，.conf 配置文件则主要承载规则与相关行为。三者可以配合使用，但不能把订阅地址直接当成服务器主机名，也不能认为导入规则文件后就一定已经具备有效的服务器。

Add Server：逐项核对协议参数

手动添加时，从 Home 进入 Add Server，先选择与你已有资料一致的协议，再填写服务器地址、端口与认证信息。协议选择决定需要哪些字段；不能只因为两个协议都要求密码，就把其中一套参数填进另一套表单。保存之前逐项对照原始资料，尤其留意复制时多出的空格或换行。

服务器地址字段应填写提供给你的主机名或 IP 地址，端口单独填写。不要把完整网页地址及其路径一起放进主机字段。显示名称只是帮助识别条目的备注，不会修复主机、端口或认证错误；为条目使用可辨认的名称，可以在后续切换与 Data 核对时减少选错对象的情况。

Shadowsocks 通常需要核对加密方法与密码；VMess、VLESS 常涉及 UUID 以及相应传输字段；Trojan 的认证和 TLS 信息要按原资料填写。Hysteria2、WireGuard 的参数结构又有所不同。未给出的字段不要凭名称猜测，更不要把一种协议的参数规律机械套用到所有连接类型。

Subscribe 与 Scan QR Code

已有订阅可通过应用提供的订阅导入入口添加，按实际界面选择 Subscribe 或相应类型，填入从你的服务商处取得的地址。订阅链接可能含有个人识别信息，应像密码一样保存。导入后检查得到的条目名称、数量变化与协议类型，但不要仅凭“出现了一组条目”就认定其中每个连接都有效。

订阅更新失败时，先区分地址格式错误与获取过程失败。检查复制是否完整、是否带入引号或换行，再确认订阅本身仍有效。错误若发生在获取阶段，可能尚未进入服务器连接测试；此时反复修改节点密码没有针对性，应先看更新提示并核对订阅地址的访问条件。

Scan QR Code 适合导入已经持有的连接资料，但扫码只是另一种输入方式，不会额外验证内容可信。扫描前确认二维码来源，扫描后查看生成条目的协议、地址与关键字段，再决定保存。涉及相机或照片访问时，只按当前操作需要处理系统权限，不必为导入一个条目开放无关数据。

订阅更新与 Config 的边界

订阅中的条目可能在更新后被替换、删除或重命名，因此不宜把订阅自动维护的字段当作长期手工备注区。确实需要保留一个修改过的测试条目时，先确认是否可以另存独立副本，并记录其来源。不要在没有备份的情况下直接覆盖常用订阅，避免更新后无法区分手工改动与远端变化。

Config 中的文件应单独检查是否选中，以及规则引用的策略是否存在。某个文件能够成功导入，只说明内容被接收，不代表每条规则都符合你的使用环境。对陌生配置先阅读 General 与 Rule，确认没有意外的处理策略，再决定启用；不理解的复杂段落可以暂时保留原状并查阅专门说明。

导入完成后先选定一个条目做连接验证，再考虑整理分组与更新频率。这样可以把输入错误与批量维护问题分离。协议字段可查阅支持协议与参数速览；配置结构可查阅.conf 分段说明，不要通过重复导入来代替核对。

04 / GLOBAL ROUTING

Global Routing 三姿态与规则顺序

Global Routing 决定当前采用哪种整体处理方式。配置姿态对应 Config，代理姿态对应 Proxy，直连姿态对应 Direct；界面操作时以这些英文名称为准。三姿态不是服务器协议，也不表示速度等级。先明确正在排查全局连接还是某条规则，再选择姿态，能够避免用错误的测试条件解释结果。

Config、Proxy 与 Direct 分别验证什么

Config 按当前选中的配置判断请求去向，适合日常需要分流的场景。它要求配置中的规则、策略以及所引用的服务器关系都成立。如果某个目标在 Config 下失败，先查看实际匹配的规则，而不是立即认定服务器不可用；该目标可能被规则送往 Direct，或被明确设为 REJECT。

Proxy 用于按代理方式处理流量，可作为简化规则因素的一种测试条件，但依然需要有效的服务器、正确的认证与可用网络。它不能修复 DNS、远端不可达或目标自身故障。测试时只改变这一项，观察同一目标是否变化；如果同时切换服务器，就失去了对分流姿态的单独比较。

Direct 用于按直连方式处理流量，不代表“断开应用”。测试直连时仍应留意系统连接状态与应用设置。某个目标在 Direct 下可访问，只能说明当前网络对该目标的访问成立，不能据此推断其他域名、其他端口或代理服务器也能访问，更不能直接给整份规则下结论。

Rule 从具体条件走到 FINAL

规则应按顺序阅读，先看更具体的域名与网段条件，再看较宽泛的匹配，最后检查 FINAL。靠前规则一旦决定处理方式，后面的相似规则通常就不会再改变该请求的结果。新增规则前先搜索已有条目，避免把例外放在宽泛规则之后，造成内容看似存在却一直没有命中的情况。

DOMAIN 对应完整域名匹配，DOMAIN-SUFFIX 对应域名后缀，DOMAIN-KEYWORD 依据域名中的关键词。三者的覆盖范围不同，使用关键词尤其需要谨慎，因为它可能匹配并非你预期的其他域名。规则里的域名通常不写网页路径，也不把整段页面地址直接复制进去。

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

这段内容只展示 Rule 的结构，不是一份适合所有设备直接启用的完整配置。第一行域名规则可能先于后面的网段或地区条件决定结果；局域网段规则用于说明 IP-CIDR 的写法。PROXY、DIRECT、REJECT 是策略关键字，而界面姿态 Proxy、Direct 使用不同大小写，不要混为字段名称。

域名规则与地址规则的边界

IP-CIDR 与 IP-CIDR6 分别面向相应地址范围，GEOIP 依赖地址分类数据；它们与域名规则所依据的信息不同。只有拿到目标地址后，相关地址条件才有判断基础。一个域名解析出多个地址，或网络环境改变解析结果时，实际命中也可能变化，因此排查时要同时记录域名与地址。

FINAL 处理前面未匹配的流量，应位于规则末尾。把 FINAL 提到前面会让后续规则失去预期作用。新增例外时，先确认它需要覆盖哪一条现有规则，再放到合适位置；不要仅为了“优先”就把所有新条目堆在顶部，否则长期维护时难以解释规则之间的关系。

修改后用一个具体目标验证，并在 Data 中核对策略，而不是只看页面是否打开。页面可能依赖多个域名，主文档成功不代表图片、登录与接口请求走向相同。需要查关键字时可进入概念速查；规则验证完成后恢复日常使用的姿态，避免把临时测试状态长期保留。

05 / CONNECTIVITY

连接、延迟测试与结果验证

连接验证要从本地网络开始，逐层确认服务器、协议、规则和目标访问。一次延迟测试返回数值，只说明该测试方式在当时获得了响应，并不能替代完整业务请求。先选定一个服务器、一种 Global Routing 姿态和一个固定测试目标，再进行比较，避免把多个变化叠加成难以解释的结果。

建立一个可重复的测试基准

首先确认当前 Wi-Fi 或蜂窝网络本身可用。如果网络需要完成登录页面或存在临时限制，先在断开 Shadowrocket 的状态下处理。网络基础访问尚未建立时，修改服务器协议没有意义。记录当前网络类型，再开始连接；测试过程中切换网络，应作为一次新的条件，而不是沿用之前的结论。

在 Home 确认选中的服务器正是准备测试的条目，检查是否仍属于有效订阅，并确认认证信息没有被最近更新替换。然后查看 Global Routing 与当前配置。服务器名称相似时，打开详情看地址更可靠；不要仅凭列表中的选中位置判断，因为导入或更新可能改变条目排列。

开启连接后观察应用提示与系统状态，再发起一个新的目标请求。浏览器已有页面可能来自缓存，页面停留在原地也不能证明新请求成功。可以重新加载固定目标，并在 Data 中找对应时间的记录，将操作时刻、请求结果和实际处理策略对应起来，形成可重复的验证过程。

区分 Connectivity Test 与真实访问

Connectivity Test 的测试方式与目标设置会影响结果，不同方法得到的延迟不应直接混排比较。有的检查偏向连接建立，有的检查还包含请求与响应过程。先确认当前采用的方式，再看结果是否稳定；单次数字更小，并不自动意味着所有网页或所有应用的完整访问都会更快。

测试超时也需要结合实际请求判断。服务器可能不响应某种探测，但仍能处理所需业务；反过来，能够响应探测也可能在认证或转发阶段失败。遇到两者不一致，保留测试方式名称与错误信息，再用同一服务器尝试真实访问，不要只根据列表中的一个结果删除全部条目。

如果所有条目同时失败，先怀疑共同条件，例如当前网络、订阅有效性、测试目标或设置变化；如果只有一个条目失败，再检查其协议、地址、端口与认证。共同失败和个别失败对应不同排查范围，按范围缩小问题，比随机更换加密方式或 DNS 更有依据。

按错误阶段缩小范围

域名解析失败应先检查解析路径，连接超时应检查服务器可达性，认证失败应核对凭据，证书相关错误应检查服务器名称、设备时间与原始 TLS 参数。错误文本可能来自不同阶段，应保留原文而不是统一记成“网络不好”。不要通过关闭证书校验来掩盖名称不匹配的问题。

当 Proxy 下可用而 Config 下失败时，把重点放在规则命中与所引用策略上；当两种姿态都失败时，再核对共有的服务器和解析条件。这种对照只能帮助缩小范围，不能直接证明原因。测试前后需要使用同一目标、同一网络与同一服务器，差异才有解释价值。

连接能建立但速度不稳定时，分别观察网络切换、目标响应、服务器状态与持续传输情况。大文件、实时通信和短网页的表现并不相同，不应拿一个场景替代所有场景。先复现最常见的失败动作，再按一次只改一项的原则测试，保留结果后决定是否继续调整。

完成验证后主动断开一次，再重新连接，确认结果可以重复。如果第一次成功只是旧会话仍在工作，重连可能暴露真实问题；如果重连稳定，再逐步恢复 On Demand 等自动行为。需要最短操作路径时可返回使用说明，本章则用于解释每个检查点为什么需要单独验证。

06 / DATA

Data 流量与请求记录

Data 用于观察经过当前连接处理的流量与请求线索，不应把其中的累计数字直接等同于服务账单。应用统计、系统统计与已有服务的计量可能采用不同范围和周期。阅读本章时先明确要回答的问题：是确认某个请求走向、寻找失败阶段，还是比较一段操作产生的数据变化。

把一次操作与一组记录对应起来

观察前记录当前时间、网络、服务器与 Global Routing，然后只执行一个可重复动作，例如重新加载某个固定页面。回到 Data 查看这一时间附近的新记录，不要在同时打开多个应用后再猜测对应关系。后台同步也可能产生流量，因此时间接近只能帮助定位，还需要结合域名或目标地址判断。

一个页面常包含主文档、图片、接口与其他资源请求，因此出现多个域名并不异常。先找与失败功能直接相关的请求：页面空白可能涉及主文档，登录失败可能涉及认证接口，图片缺失则应看资源域名。把这些请求分开核对，比只搜索页面地址然后断定整站状态更准确。

记录中可用的字段应以当前界面为准，重点关注目标、处理策略、命中规则、连接状态或错误。不同请求未必展示完全相同的信息，不能因为某一字段为空就断言应用没有处理。必要时重新发起请求，确认它是在当前连接与配置生效之后产生的，而不是残留的旧会话。

从规则结果回查配置

如果请求实际采用 DIRECT，先找是哪条规则作出的决定，再判断这是否符合预期。若采用 PROXY，则继续确认最终使用的服务器或策略对象。看到 REJECT 时应先回查明确拒绝的条件，而不是修改服务器密码；拒绝策略在连接远端之前就可能已经决定了请求结果。

域名信息与 IP 地址要一起理解。一个域名可能解析到多个地址，同一个地址也可能承载多个服务；只凭地址无法还原全部访问语义。某些连接记录未必拥有可用于域名匹配的信息，排查时应保留“当时可见什么”的边界，不要把后续查到的域名直接当成原请求一定携带的条件。

修改规则后，应产生新的连接再观察结果。已有连接可能继续沿用建立时的处理路径，因此“配置已经改了，但旧记录没变”不一定是保存失败。停止相关请求，必要时重连，再重复同一个动作；比较新旧记录的命中差异，才能判断修改是否真正影响了后续处理。

理解累计流量与数据保护

流量统计前先确认显示范围与起算条件，例如当前连接、某个时间段或应用保留的累计数据，具体以界面说明为准。没有统一统计窗口时，不要拿两次数字直接作结论。重连、清理记录或改变显示筛选，也可能改变观察范围，应在比较前把条件记录下来。

上传和下载反映传输方向，不等同于内容是否被用户主动观看。后台刷新、自动备份、页面预加载与重试都可能产生数据。发现异常增长时，先缩小到单一应用和短时间窗口，暂停其他明显传输，再观察变化；不要仅凭累计流量增加就认定某个服务器条目存在问题。

服务侧计量与本地显示不同，可能涉及协议开销、计量周期、统计范围及其他设备使用等因素。应先核对各自说明，而不是追求每个字节完全一致。本地 Data 更适合辅助定位连接行为，不能替代你已有服务对剩余用量、有效期或计量规则的说明。

请求记录可能暴露访问域名、地址、时间与个人活动线索。导出或截图前先筛选与问题有关的部分，隐藏订阅地址、认证字段和不相关访问内容。清理记录前保留需要复现的错误原文；清空之后再寻找旧问题通常更困难，维护时应在诊断完成后再做整理。

当 Data 与浏览器表现不一致时，先考虑缓存、旧连接与请求定位是否准确，再扩大排查范围。系统中其他活动也可能造成观察偏差，不能把每条记录都归给前台页面。通过固定动作、短观察窗口和重复测试建立对应关系，是读懂 Data 的基础。

07 / SETTINGS

Settings、DNS 与 On Demand

Settings 应在已有稳定连接的基础上逐项调整。先明确设置影响的是解析、触发条件还是连接行为，再记录原值和修改目的。界面选项会随设备与应用调整，具体名称和可用范围以实际显示为准；不需要为了追求选项齐全而开启所有功能，也不应把复杂配置当作连接成功的必要条件。

DNS：先确认解析路径

DNS 负责把域名解析为地址，规则分流负责决定请求如何处理，两者相互关联但不是同一件事。域名解析失败时，浏览器可能还没有进入正常连接阶段；此时单独切换代理服务器未必有效。先找出当前 DNS 设置来自应用、活动配置还是网络环境，再决定修改哪一处。

Config 的 General 与 Settings 中相关项目可能共同影响实际行为，覆盖关系应按当前应用说明核对。避免在多个位置填入不同值后只记住其中一个。修改前抄下原设置，并保留配置副本；测试时只变更一个来源，观察新请求的解析与访问结果，确认后再保留改动。

解析服务器并非地址越多越好。不同解析路径可能返回不同地址，也可能需要依赖当前网络或代理才能访问。排查时先确认你使用的解析服务在当前条件下可达，再考虑是否适合目标请求。不要把反复更换 DNS 当作通用修复，它不能纠正错误密码、服务器端口或拒绝规则。

域名结果可能被缓存，因此修改后旧地址仍短暂出现并不必然说明设置失效。使用新请求、重建相关连接，并观察实际解析线索。直接用 IP 访问网站也不是等价测试，因为 TLS 名称和站点路由仍可能依赖域名；测试方法改变后，应明确它只能验证其中一部分条件。

On Demand：从手动基准走向自动触发

On Demand 用于按条件触发连接相关行为，适合在手动连接已经稳定后设置。先写清希望在哪些网络条件下连接、哪些条件下不连接，再逐项建立规则。不要一开始就覆盖所有 Wi-Fi、蜂窝网络和域名条件，否则触发结果与手动开关互相影响时，很难确定是哪条条件起作用。

按 Wi-Fi 名称设置时，应核对实际网络名称，并留意相近名称、访客网络与设备自动切换。网络名称匹配只描述触发条件，不代表该网络一定具备相同的访问能力。测试时先保持其他条件不变，切换到目标网络后等待状态变化，再回到应用与系统状态中确认实际结果。

按蜂窝网络或域名触发时，同样需要验证触发时机和规则先后。请求是否产生、域名是否符合条件、系统是否允许当前连接，都会影响观察。自动连接不是服务器保活承诺；远端不可达时，触发本身成功也可能无法完成访问，应将“条件命中”和“业务可用”分开记录。

关闭 On Demand 后，仍应检查当前连接是否保持以及系统状态是否符合预期。自动触发规则的关闭与现有会话的结束是不同操作，不能只看开关就假定所有连接已经断开。更完整的条件组织方法可阅读On Demand 按需连接设置。

其他常用行为的调整边界

局域网访问异常时，先检查目标是否属于本地网段，以及当前规则如何处理它，再看相关设置。家用设备、打印服务或管理页面可能依赖本地发现，不应把所有流量都按同一种策略处理。修改网络相关选项后，使用明确的局域网目标验证，避免拿公共网页的成功来替代本地访问测试。

遇到 IPv6 相关现象时，先确认当前网络与目标实际采用的地址类型，再检查 IP-CIDR6 等规则覆盖。单纯关闭某种地址能力可能只是改变症状，并不能解释原因。保留原值，对比同一目标在不同条件下的结果，确认变化与问题相关后再决定是否长期采用。

不应为了完成基本连接而批量启用改写或证书相关能力。它们有独立用途和影响范围，需要逐项理解、明确授权并限定作用对象。普通服务器导入、Global Routing 与连接验证可先在较简单的配置下完成；当问题与这些额外能力无关时，暂时保持原状更利于诊断。

08 / MAINTENANCE

日常维护、换机与排错闭环

日常维护的目标是保持配置可理解、可恢复，而不是频繁重置。将应用购买记录、已有订阅资料、服务器条目、活动配置与个人改动分别保存，出现问题时就能只处理相关部分。维护动作完成后，应重新做一次连接验证，确保整理过程没有改变常用服务器、Global Routing 或规则去向。

更新前后保留可用基准

应用更新走 App Store，订阅更新则获取你已有订阅中的服务器资料，两者不要在诊断记录中混称为“更新”。如果应用更新、订阅刷新和规则修改同时进行，出现问题就难以确定来源。尽量分开操作，每一步后测试一个固定目标，确认稳定后再继续下一项。

更新订阅前保留需要的独立条目与备注，并确认活动服务器是否会受到条目替换影响。更新后检查名称变化、当前选择与连接结果，不要只看更新完成提示。若新条目失败而原独立条目仍可用，应优先比较协议字段与远端变化，而不是立即清空整个应用。

修改配置文件时保留一份已验证副本，并用能辨认用途的名称区分日常版与测试版。不要把唯一可用配置当作临时实验区。复杂改动可分成域名规则、网段规则与 General 设置几个阶段，每次只验证一个阶段；这样回退时可以恢复具体改动，而不必重新建立全部内容。

换机恢复需要分别检查三层

第一层是应用获取资格。在新设备的 App Store 中使用原购买账号检查已购项目，系统要求与购买适用范围以 App Store 页面标注为准。能够重新下载客户端，只完成了应用恢复；接下来仍需打开应用检查本地资料，不能把商店中的已购标记当作服务器配置已经迁移的证明。

第二层是服务器与订阅资料。根据你自己保存的地址或参数恢复，并重新确认有效性。订阅曾在旧设备可用，不代表地址现在仍然有效；手工条目也可能因复制缺失字段而失败。恢复后先选一个常用条目测试，再进行批量整理，不要在尚未连通时加入自动触发条件。

第三层是活动配置与个人设置。恢复规则文件后确认选中状态、Global Routing、DNS 与 On Demand，再检查首次连接的系统授权。旧设备的授权不会替代新设备上的确认。iPad 的购买恢复与布局细节可阅读iPad 已购恢复与使用要点。

用于迁移的配置可能包含服务器地址、订阅凭据或其他个人信息，应保存在自己能够控制的受保护位置。导出后先确认文件内容和恢复方式，不要为了测试备份而立即删除唯一工作副本。迁移成功并完成连接验证后，再按需要清理不再使用的临时副本。

用最小记录完成问题闭环

排错记录至少包括发生时间、设备类型、当前网络、服务器协议、Global Routing、活动配置以及错误原文。再补上最近一次成功条件与最近修改过的项目，通常就能划定范围。记录应隐藏密码、密钥、完整订阅地址与个人访问内容，只保留理解问题必需的结构。

遇到问题先复现，再定位层次：应用是否能打开、权限是否完成、资料是否导入、服务器是否可达、规则是否正确、目标是否正常。每个层次只回答自己的问题，避免用重装处理全部现象。只有当证据指向本地数据或安装状态时，才考虑相应恢复动作，并先保留可用资料。

修复之后要做反向确认。恢复日常姿态、重新连接、重复原失败动作，再检查 Data 中的规则与策略是否符合预期。如果只在临时测试姿态下成功，问题尚未闭环。确认稳定后才清理诊断记录，并写下最终改动，便于以后在相同现象出现时快速比较。

长期维护应删去已经确认不再使用的重复测试条目，而不是积累大量无法解释的配置。保留少量明确用途的基准，定期检查订阅有效性与购买记录的可恢复性即可。日常操作返回快速使用说明，术语疑问进入概念速查，购买与安装问题则回到正版下载页的已购恢复说明。