Shadowrocket
完整使用手册

一、App Store 获取与正版核验

先确认应用身份，再完成购买。Shadowrocket 是 Apple 平台的付费商业应用，唯一获取入口是 App Store。需要进入商店前，先阅读正版核验说明，核对开发者、官方图标和应用 ID。仅凭搜索结果里的名称或相似图形不能完成判断；应打开产品详情页，把几项信息放在一起检查，确认后再由系统处理购买。

核对开发者、图标与应用 ID

开发者名称应为 Shadow Launch Technology Limited，应用 ID 为 932747118。应用 ID 可以从产品页地址中的 id932747118 辨认。图标应与本站使用的官方图标一致，即白底蓝紫描边图案。三项共同用于识别应用，不要把搜索排名、名称里的附加描述或图片上的宣传文字当作替代依据。确认对象后，再查看价格、兼容性和购买按钮。

App Store 页面提供的价格、兼容性、更新记录与购买说明，应作为对应事实的核对来源。正文不固定列出系统最低版本，因为设备要求可能随商店页面调整。iPhone 与 iPad 是本手册的主要操作对象；Mac、Apple TV 与 Apple Vision 的可用性也应查看同一产品页的兼容性栏，系统要求及通用购买适用性均以 App Store 页面标注为准。

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

一次性买断描述的是客户端的购买方式，不表示同时获得服务器、订阅链接或服务流量。完成购买后，仍需准备自己的服务器信息或从已有服务商处取得订阅。客户端能否打开、购买是否成功、服务器能否连接，是不同层面的检查项。例如，应用已经安装而列表为空，通常需要继续完成导入步骤，并不能据此判断购买失效。

价格应以购买确认界面的当地货币金额为准，美区参考价格为 2.99 美元，最终以 App Store 页面为准。账户地区、付款条件与商店显示由 Apple 的购买流程处理。遇到商店无法完成购买时，先检查系统给出的具体提示，不要反复修改 Shadowrocket 的网络参数；应用中的服务器设置无法修复商店账户或支付环节的问题。

已购获取、重装与设备迁移

曾经购买的用户，先确认当前 App Store 使用的是原购买账户，再在账户内的已购应用入口查找 Shadowrocket。若产品页仍显示价格，不应立即再次确认购买，应先核对账户、购买记录和商店提示。已购入口的名称与位置可能随系统变化，以设备当前显示为准；能否在其他设备获取，也应同时核对该设备兼容性和商店所列适用条件。

重新获取应用与恢复应用内资料不是同一步。商店确认的是应用购买资格，原来的订阅、配置文件、自定义规则和统计记录是否存在，还取决于设备迁移或备份恢复情况。删除应用前先保存必要资料，不能把“之后可从已购列表获取”理解成“之后会自动恢复所有配置”。家人共享是否适用，以产品页与 Apple 账户实际显示为准，不在配置导入步骤中推定。

应用更新同样通过 App Store 完成。更新前记录当前可工作的服务器与配置，更新后按本手册第五章重新验证即可。购买与获取的集中问答见已购恢复和价格与买断说明。本章解决的是应用身份及购买边界，后续章节才开始处理连接内容；把这两类问题分开，可避免在错误的环节反复尝试。

二、首次启动与系统权限

首次启动先辨认操作区域，不急于调整所有选项。Home 用于查看服务器、选择连接对象并操作连接开关；Config 用于配置文件管理；Data 用于查看流量与连接相关记录；Settings 用于调整应用设置。具体布局以设备当前界面为准。需要辨认英文词时，可配合界面英文词对照查阅，不要仅按图标形状推测入口。

VPN 配置授权发生在什么阶段

当应用准备建立连接时，系统可能要求允许添加 VPN 配置。这个弹窗是系统对网络扩展配置的授权，不是新增服务器，也不是购买第二项服务。确认弹窗来自当前正在使用的 Shadowrocket，再按系统要求完成验证。允许之后，仍需有可用的服务器参数和正确的运行方式，授权本身不能替代这些准备工作。

如果关闭了授权弹窗，回到应用检查连接开关状态，再次按正常连接流程操作。不要连续快速点击开关，以免分不清哪一次操作产生了提示。若系统显示配置管理限制或无法添加，应先检查设备的相关设置与管理状态；受管理设备的限制不一定能从应用内部解除。排错时应记录提示原文，而不是把所有授权失败都归为服务器问题。

按操作需要授予权限

使用 Scan QR Code 时，系统可能请求相机访问权限；只有计划通过相机扫描自己的连接资料时，才需要处理这一请求。拒绝相机权限不等于不能手动添加服务器，也不等于不能导入已有订阅。若稍后需要扫码，可到系统中找到应用的权限设置进行核对。拍摄画面中若同时出现多个二维码，应确认识别结果对应的是预期连接资料。

从剪贴板粘贴链接、从文件位置选择配置，或使用其他导入方式时，也可能遇到对应系统提示。处理原则是把权限与当前动作对应起来：正在粘贴时检查粘贴请求，正在选取文件时检查文件来源。无需为了“准备齐全”而提前开放与当前任务无关的权限。若导入没有发生，先确认是否取消了系统选择框，再检查内容格式。

系统连接状态与应用状态分开看

系统显示 VPN 已连接，只能说明相应网络配置处于连接状态，并不直接证明远端服务器、DNS 或目标网站都正常。相反，Home 中尚未选中有效服务器时，即使已经允许添加 VPN 配置，也不能完成预期代理连接。首次操作应按“资料已导入、对象已选中、模式已确认、开关已打开”的顺序检查，不以单个状态标记作最终结论。

设备上若还有其他正在使用网络扩展的应用或系统配置，应先确认当前实际工作的连接对象。不要在一次测试里同时切换多个网络工具和多项系统设置，否则容易把配置切换造成的中断误判为 Shadowrocket 参数错误。对不能确定用途的系统配置，不应直接删除；先查看名称、来源及设备管理要求，再决定是否需要停用或进一步咨询管理方。

建立首次使用的检查基线

首次启动阶段建议记录三件事：Home 是否正常显示、添加 VPN 配置是否成功、当前使用的是 Wi-Fi 还是蜂窝网络。记录不需要包含密码或完整订阅地址。这些基础信息能帮助后面判断故障发生在应用打开之前、系统授权阶段，还是远端连接阶段。若应用可以正常进入而网络请求失败，继续检查连接资料通常比反复重装更有价值。

权限处理完成后，如果服务器列表仍为空，进入下一章添加已有资料即可；如果列表已经恢复，也应重新确认选中对象和 Global Routing，而不是直接沿用对旧设备状态的记忆。设备迁移可能保留部分数据，但网络环境和系统授权需要在当前设备上实际核对。首次启动的目标是建立清晰起点，不是一次性完成全部高级设置。

三、已有服务器与 Subscribe 导入

导入之前先区分三种资料：单个服务器参数用于建立一条连接记录；订阅地址用于取得并更新一组服务器；配置文件用于描述 DNS、规则及其他运行设置。三者可能在同一个交付说明中出现，但用途不同。把订阅地址填进服务器地址栏，或把配置文件当成服务器密码，都无法得到正确结果。先确认资料类型，再选择对应入口。

Add Server 手动录入

通过 Add Server 添加时，先选择与已有资料一致的 Type，再填写地址、端口和认证字段。地址只填写要求的服务器主机名或地址，端口使用资料提供的数值，不要把整段链接连同协议前缀一起粘入普通地址字段。录入后逐项对照，特别检查复制时带入的首尾空格、中文标点以及字符大小写。保存成功只表示记录已建立，仍需后续连接验证。

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 以及 HTTP、SOCKS5 的字段并不完全相同。某种协议需要密码，不意味着另一种协议也应填入同样内容；出现 UUID、密钥、TLS 名称或传输路径时，应按对应字段填写。对于资料中没有解释的高级选项，先向原有服务商确认，而不是参考另一条不同协议记录照搬。

Subscribe 地址与分组更新

已有订阅应从自己的服务商处取得，并通过应用支持的订阅导入入口添加。若使用 Add Server 中的 Subscribe 类型，按界面填写订阅地址与便于辨认的名称。保存后执行更新，检查是否出现预期服务器。订阅下载成功与服务器可连接是两次独立检验：前者验证能否获取清单，后者还要验证清单内的具体连接资料。

订阅更新失败时，先核对地址是否完整、是否带入换行，以及当前网络是否可以取得该地址。若返回内容是登录页面、提示页或不受支持的数据，应用未必能形成服务器列表。已有服务到期、链接被替换或认证信息失效，也可能影响更新。应把应用显示的错误与服务商给出的订阅状态对照，不要仅因列表数量变化就连续删除重建。

扫码、链接与配置导入的边界

Scan QR Code 适合导入自己已有的二维码资料。完成识别后，仍应检查 Type、名称及关键参数是否符合预期；二维码只是内容载体，不会自动保证资料准确或有效。链接导入同理。含有访问凭据的二维码、完整订阅地址和分享链接都应当作敏感资料，不应出现在公开截图、评论或排错记录里。

Config 中的配置文件与 Subscribe 更新的服务器清单应分别管理。导入一个带有规则的文件后，需要确认是否已被选为当前使用的配置；更新订阅后，也需要确认默认服务器是否仍存在。部分资料可能同时包含服务器与设置，但不能仅凭文件扩展名或名称断定其作用，应检查应用实际识别出的内容。

导入完成后，回到 Home 明确选中一条服务器，检查左侧选择标记，而不只是打开过它的编辑页面。相似名称容易造成误选，可以给自建记录使用能说明用途的备注，但不要把密码写进备注。需要清理重复条目时，先核对来源分组；订阅生成的条目可能在下次更新时重新出现，日常维护应围绕订阅来源进行，而不只是逐条删除结果。

本章结束的判断标准是“资料已被正确识别，且可以明确指出当前选中的服务器”，不是“列表里已经有很多条目”。随后进入 Global Routing 选择与连接验证。对订阅更新中的异常，应先保留错误原文和发生步骤，再到第八章按维护顺序处理，避免把清单获取失败与单条服务器不可达混在一起。

四、Global Routing 与规则顺序

Global Routing 决定当前流量采用何种处理方式。配置、代理、直连三种姿态对应界面中的 Config、Proxy、Direct。日常使用规则分流通常选择 Config；Proxy 与 Direct 可用于明确场景或对照测试。这里的选择不等于更换服务器，也不等于选择了另一份配置文件，应分别核对模式、当前配置和所选连接对象。

三种姿态分别控制什么

三种姿态的说明还应结合应用的系统绕过设置、流量接管边界及具体配置理解，不能据此承诺设备上每一种系统通信都采用相同路径。排错时切到 Proxy，可以帮助区分是否与某条分流规则有关，但它不是所有失败的修复开关；切到 Direct，也不能证明 DNS、远端网站或当前接入网络一定正常。

按顺序阅读 .conf 文件

以下是用于解释语法的配置片段，不是适合所有网络环境的成品配置。[General] 放置通用设置，[Rule] 放置规则。规则通常自上而下匹配，先命中的条目决定处理方式。PROXY、DIRECT 与 REJECT 表示处理策略，不是服务器协议名称。修改前应保存原文件，并一次只调整一处。

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

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

在这个片段里，example.com 及符合后缀条件的子域名先由 DOMAIN-SUFFIX 处理，因此不会再落到后面的 DOMAIN-KEYWORD。其余含有对应关键字的域名，才可能命中下一行。IP-CIDR 用于地址段，GEOIP 按地址归属数据判断，FINAL 则作为前面均未命中时的最终处理。把更宽泛的规则放在前面，可能遮住后面原本想单独处理的目标。

域名规则与地址规则不能互换

DOMAIN 用于完整域名匹配，DOMAIN-SUFFIX 用于后缀范围，DOMAIN-KEYWORD 用于关键字范围。关键字范围往往比直觉更宽，新增时应检查是否会影响名称相近但用途不同的目标。IP-CIDR 与 IP-CIDR6 分别描述相应地址范围，不直接表达“某个网站”。同一服务可能使用多个域名和地址，因此单条规则命中不代表页面所有请求都采用同一路径。

GEOIP 依赖地址归属数据与实际解析结果，不能只根据网页显示的语言或企业所在地推定命中。DNS 解析可能影响后续地址类规则能够看到的目标地址，但 DNS 设置本身也不是一条分流规则。涉及 USER-AGENT 等条件时，应先核对当前应用支持范围和实际可获取的信息，不应把它当作所有加密请求都能稳定识别的依据。

规则修改后的验证方式

先确认当前 Global Routing 为 Config，再确认当前配置文件就是刚修改的文件。用一个明确目标发起请求，查看可用记录中的域名、命中规则与策略信息。若记录仍显示旧路径，检查应用是否需要重新载入配置或重建连接，同时注意目标应用可能复用了已有连接。不能只看页面是否打开，就认定新规则已生效；缓存内容也可能让页面看起来正常。

局域网访问异常时，核对实际地址段、相关绕过设置与规则顺序，而不是只查公共网站是否正常。与 DNS 相关的原理可继续阅读DNS 设置说明，简明概念见概念速查。本章的核心是沿着“模式、配置、规则、策略”逐层检查；只记住某个关键字，无法替代完整的路径判断。

五、连接、Connectivity Test 与排查

连接验证按三个层次进行：应用是否建立连接、所选服务器是否可用、实际目标请求是否按预期完成。Home 顶部开关、Connectivity Test 和真实访问各自提供不同信息，不能互相替代。开始前先确认当前网络可用，已有资料仍有效，并明确选中一条服务器；不要在测试途中同时更新订阅、修改 DNS 和更换配置。

按固定顺序建立一次连接

在 Home 选择目标服务器，确认左侧选择标记已落在该条目上，然后核对 Global Routing。打开连接开关，若出现系统 VPN 配置授权，按第二章完成处理。等待状态稳定后再开始测试。若列表中存在名称相同的条目，应结合分组和 Type 辨认，避免刚编辑一条记录，却实际连接了另一条旧记录。

执行 Connectivity Test 后，记录成功、失败或超时等实际结果，再发起一次真实访问。测试通常只反映其测试对象和测试方式对应的条件，不能保证所有目标服务都正常。若测试失败但实际访问可用，也要核对测试目标是否存在单独的可达性限制；反过来，测试成功而特定页面失败，则应继续检查该页面使用的域名、DNS 与规则。

延迟数字与真实访问的区别

延迟测试适合比较同一条件下的响应差异，不直接表示带宽、持续稳定性或某个内容服务的表现。测试时间、接入网络、目标和方法变化后，数字不能简单横向比较。一次较低的延迟也不证明认证、传输设置与长连接都正常。选择已有订阅内的服务器时，可结合延迟、地区与协议说明理解数字边界。

按现象缩小排查范围

所有目标都失败时，先检查基础网络，再检查所选服务器的地址、端口、认证与 TLS 参数。若当前网络连普通服务也不能访问，应先处理接入问题。若只有这一条服务器失败，可以在用户已有资料中选择另一条进行对照；另一条成功说明排查范围可以缩小，但仍不能仅凭这一次结果断定原服务器永久不可用。

只有部分目标失败时，记录具体目标和发生时间，比较相关请求命中了什么规则。网页通常包含主文档、图片、接口和认证等多个域名，其中一个域名路径不正确就可能造成局部异常。切换 Proxy 仅作为短时对照，测试后恢复原模式。若切换后恢复，应检查分流与解析，而不是直接删除整份配置。

网络切换与重建连接

从 Wi-Fi 切换到蜂窝网络后，旧连接可能需要重新建立。先等待设备网络稳定，再关闭并重新打开连接开关，随后重复同一测试。保持目标和服务器不变，才能判断差异是否来自接入网络。若同时换服务器、换配置和换网络，即使恢复，也无法知道真正起作用的是哪一个变量。

TLS 或认证相关错误，应逐项对照已有资料与设备时间。不要以关闭证书验证作为默认解决办法，这会改变连接校验条件，也可能掩盖域名或时间设置错误。无法判断的字段应向原有服务商确认。反馈时描述错误类别、协议、操作顺序和网络类型即可，完整密码、密钥与订阅地址不应放进公开记录。

验证结束时，应能说明当前网络、所选服务器、Global Routing、使用配置与实际测试结果。这个简短基线比一句“已连接但不能用”更有诊断价值。接下来查看 Data，目的是进一步解释刚才的请求，而不是用累计流量数值代替连接测试结论。

六、Data 流量统计与请求记录

Data 用于观察应用所记录的流量与连接信息。它能帮助回答“测试时有没有产生请求”“哪些目标出现异常”“路径是否符合规则预期”等问题，但不是服务商账户账单，也不代表设备所有网络活动的完整总量。先明确统计对象和时间范围，再解释数字；不要把两个范围不同的统计直接相减，进而推断客户端或服务存在问题。

先看统计范围，再看大小

查看流量时，核对界面是当前连接、某段统计周期还是累计记录，并检查上传与下载的区分。重新连接、重置统计、应用数据恢复以及所用设置，都可能影响观察到的范围，具体以当前界面说明为准。记录数字时应同时写下测量起点和结束时间，否则之后很难判断变化来自测试请求，还是期间的其他后台活动。

客户端与服务商的计量可能位于不同位置。协议封装、统计口径、连接重试、时间窗口和计量单位都可能带来差异。Data 中有流量，不等于服务商账户一定按相同数值计费；服务商显示的剩余量，也不能仅凭本地累计数值反推。涉及已有服务的额度和有效期时，应查看原服务商提供的账户信息。

用一次独立请求建立观察关系

排错时尽量减少同时操作：先记录当前状态，再打开一个明确目标，随后回到 Data 查看对应时段的变化。如果多个应用同时刷新，记录里可能包含与测试无关的请求。系统后台通信也会出现，因此看到陌生域名时不要立即断定它属于刚打开的页面。应结合时间、目标和重复测试结果判断关联。

若当前界面提供目标域名、地址、策略、命中规则或错误信息，逐项核对这些内容。目标域名回答访问的是谁，策略回答如何处理，错误信息提示失败阶段；三者应连起来阅读。某条请求命中 DIRECT 并不自动说明规则错误，只有它与既定需求不一致时，才需要回到当前配置查找匹配原因。

从记录回到规则与 DNS

看到目标使用了不符合预期的策略，先确认 Global Routing 是否为 Config，再确认配置文件与规则先后关系。若目标以地址形式出现，还应考虑 DNS 和应用本身的访问方式。不要把记录里的一次地址直接写成宽泛地址段规则；同一地址可能承载多个服务，随意扩大范围会影响原本正常的请求。

出现域名解析失败时，关注 DNS 相关条件；已经解析出地址但远端连接超时，则继续检查服务器、路由和目标可达性。两类问题可能相互影响，但处理顺序不同。记录中的错误只是诊断线索，需要与实际操作对应，不能脱离发生场景单独下结论。涉及解析设置时，可返回第七章核对，避免在 Data 中反复清空记录。

重置、留存与敏感信息

重置统计能为下一次对照提供清晰起点，但不会修复服务器、改变规则，也不会重置服务商的计量。重置之前先保存需要比较的数值与时间，避免丢失唯一的故障线索。若只是想观察一个短时测试，也可以记录测试前后差值，不必每次都清理所有历史数据。

公开分享记录前，检查其中是否包含完整目标地址、查询参数、订阅凭据、认证字段或个人访问内容。即使截图没有密码，也可能暴露带令牌的链接。更合适的反馈方式是摘录错误类别和必要字段，并隐藏无关身份信息。隐藏后的文字应保留字段关系，否则对方无法辨认这是 DNS 失败、认证失败还是远端超时。

长期观察时，选择固定的时间窗口和相同的测试方法更有意义。偶发峰值可能来自正常后台任务，不应仅因一次变化就重新导入全部订阅。若故障反复发生，保留精简的时间线：何时切换网络、何时更新配置、何时发生错误。这样的记录能连接使用动作与结果，也能为下一章的设置调整提供依据。

七、Settings、DNS 与 On Demand

Settings 的调整应服务于已经明确的需求，而不是把所有选项都改一遍。初次使用先保留可工作的基线，随后再处理 DNS、On Demand 或诊断相关设置。某些设置位于应用界面，另一些写在配置文件中，两者应结合当前选中配置理解。当前界面没有出现的选项，不应按照其他截图的位置盲找或填入近似名称。

系统 DNS 与自定义 DNS

DNS 负责把域名解析成用于后续连接的地址；分流规则负责决定请求如何处理。两者相关但不相同。使用 dns-server = system 表示在该项中采用系统 DNS 设置，是理解配置行为的起点之一，但并不保证每一种网络环境都得到相同结果。设备切换 Wi-Fi 与蜂窝网络后，系统提供的解析条件也可能改变。

[General]
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

需要采用自定义 DNS 或 DNS over HTTPS 时，先确认解析服务地址与当前网络的可达性，再核对应用支持的填写格式。解析服务本身也需要被访问，如果其连接条件不成立，改动可能让更多目标出现失败。不要把更换 DNS 理解成改变了服务器认证，也不要假定使用加密解析就会自动修复所有连接问题。

修改后使用相同目标进行验证，并考虑缓存影响。目标应用可能复用先前得到的地址或已有连接，短时间内看不出变化并不一定意味着设置未生效。先确认配置已载入，再按需要重建连接，避免连续替换多个解析设置。完整说明见系统 DNS、自定义 DNS 与 DNS over HTTPS。

On Demand 是触发条件，不是服务器修复

On Demand 用于按已配置条件触发连接，适合在手动连接已经稳定后再设置。网络类型、Wi-Fi 名称或域名条件应按当前界面的规则填写，并逐条验证。它改变的是何时建立连接，不会自动修正错误的密码、过期订阅或不可达服务器。手动连接都失败时，先解决连接本身，再讨论自动触发。

设置前写清预期，例如“在指定网络条件下触发”，然后检查是否存在范围重叠的条件。不要凭记忆猜测多条条件的优先关系，应以应用内说明和实际测试为准。测试时分别进入满足与不满足条件的环境，观察连接是否符合预期；只在一种网络里测试，无法确认条件是否过宽，也无法解释之后的误触发。

若手动关闭连接后又很快恢复，先检查 On Demand 是否仍处于启用状态，而不是认定开关失效。临时排错时可以暂停自动触发，再建立手动测试基线。需要长期调整条件时，可参考按 Wi-Fi、蜂窝网络与域名设置 On Demand，避免同时改变触发条件与服务器资料。

诊断开关与高级参数的边界

日志或诊断相关选项仅在需要时启用，并留意记录可能包含访问目标和连接信息。排错完成后，按实际需要恢复原设置。开启更多记录不表示连接会更稳定；它的价值是提供判断依据。系统时间、证书校验、传输参数等若参与连接，应按已有服务说明核对，不能把安全校验项当成通用速度调节项。

不熟悉的高级设置应先阅读应用内说明，记录原值，再做单项实验。若改动后异常，恢复原值并重复同一验证，不要继续叠加更多“可能有用”的选项。配置文件中的相似字段也需要核对是否影响当前运行状态，不能仅凭已编辑文件就断定应用已采用它。设置变动与配置选择最好一起记录。

如果需求只是首次连接，不必在 Settings 中完成所有高级配置。先回到第五章取得明确的可用结果，之后再按需求逐项扩展。对界面词与协议参数的解释可查概念速查；对三种运行姿态的集中说明可查代理模式。本章强调的不是某组固定参数，而是让每一次设置都有可验证的目的。

八、订阅更新、备份与日常维护

日常维护围绕三个目标进行：保持已有资料有效、保留可恢复的配置、让异常可以被定位。更新订阅、更新应用和修改规则是不同动作，最好不要在同一次排错中一起完成。连接正常时无需因为看到某个新选项就立即调整；确有变化时，先记录当前状态，再按明确顺序操作。

订阅更新前后分别检查

更新前确认订阅来源与分组，记录当前选中的服务器和正在使用的配置。更新后查看是否有错误提示、条目是否符合预期，以及原先选中的服务器是否仍存在。服务商可能调整名称、数量或参数，清单变化本身不等于客户端故障。若原条目被替换，需要重新选择可用对象，再进行一次实际连接验证。

更新失败不要立即删除原订阅。先核对网络、链接完整性、服务有效状态及返回内容是否仍是可识别的订阅数据。已有清单有时仍可用于当前连接，但这不能证明订阅地址仍有效。反过来，成功获取新清单也不能证明每条服务器均可用。把“获取清单”和“验证服务器”分开记录，才能向自己的服务商准确说明失败发生在哪一步。

备份应覆盖哪些资料

在应用当前支持的导出或备份范围内，保存必要的配置文件、自定义规则、订阅来源及手动添加资料。不要假定只导出规则就同时保留了所有服务器，也不要假定系统迁移必定恢复全部应用数据。备份后检查能否辨认文件内容和用途，并记录哪些资料仍需从原服务商重新取得。

备份可能含有密码、密钥、完整订阅地址或其他认证信息，应放在自己能够控制访问的存储位置。用于求助的副本需要单独去除敏感字段，不能直接公开原始备份。文件名可表达用途和个人备份时间，但不应把凭据写进名称。保存多个副本时，应标明哪一份已经验证可用，避免恢复时误选实验中的配置。

换机、重装与应用更新

换机时先完成 App Store 已购获取，再恢复资料，最后在新设备处理 VPN 配置授权与连接验证。购买资格、应用数据和系统授权各有自己的恢复流程，不能以其中一项完成推定其他项也完成。旧设备可暂时保留作为参数对照，但两台设备是否能同时使用同一已有服务，应遵守该服务的实际使用条件。

应用更新后若行为变化，先检查当前服务器、Global Routing 和配置文件，再查看应用内提示及 App Store 更新说明。不要以重装作为第一步，因为重装可能增加资料恢复工作，也会丢失有价值的排错线索。若最终需要重装，应先确认购买账户、可用备份与必要凭据都已准备妥当，再进行操作。

建立可恢复的排错顺序

先确认基础网络，再确认系统授权与连接状态，然后确认选中服务器、运行模式、当前配置、DNS 和规则。每一步只改一项，测试后决定保留还是恢复。对于间歇性问题，记录网络切换、设备休眠、订阅更新与故障发生的先后关系，比反复执行所有操作更有帮助。只有建立时间线，才能看出问题是否始终跟随某个条件。

需要反馈时，整理设备类型、当前网络类型、协议、运行姿态、错误原文与复现步骤。应用版本信息可以在自己的排错记录中按实际显示抄录，但不要把不确定的信息补成猜测。提供经过遮盖的关键字段即可，完整订阅链接、密码、密钥和个人访问记录不应随反馈一起公开。描述越能定位到具体步骤，越容易得到有效判断。

至此，一次完整使用流程应包含正版获取、授权、导入、模式选择、连接验证与维护记录。只需要重新走通操作时，返回快速上手教程；遇到购买与恢复问题，查看App Store 正版下载说明中的问答；需要解释术语时，使用概念速查。把问题放回对应阶段处理，比将所有异常都归结为“无法连接”更便于持续维护。