Shadowrocket 订阅手册

01 · Subscribe：建立可维护的订阅记录

先判断拿到的是入口还是服务器信息

开始前，先确定已有资料的用途。订阅地址是用于获取一组服务器记录的远程入口，通常采用 HTTPS 地址；单条分享链接则描述一个服务器的协议和参数。二者都可能以很长的字符串出现，长度不是判断依据。应以资料附带的说明为准，确认它明确用于 Subscribe，还是用于直接导入服务器。不要把账户管理网页地址当成订阅入口，也不要把单个服务器的域名直接填入订阅 URL。

在 Home 中通过右上角添加入口进入 Add Server，找到 Type 后选择 Subscribe。界面布局可能随应用调整，操作时以当前英文标签为准。将已有订阅地址完整填入 URL，并为这条记录设置便于识别的备注。备注宜说明用途和归属，例如“个人日常订阅”，不宜包含访问凭据。完成保存后回到 Home，检查是否出现对应订阅以及其中的服务器记录；若只保存了入口但尚未取得内容，再执行一次手动更新。

URL 前后的空格、换行以及被聊天软件替换的符号，都可能造成获取失败。粘贴后应特别检查问号后的参数是否完整、英文符号是否被替换，以及复制时是否混入了说明文字。地址内的查询参数可能承担访问授权作用，不应为了缩短显示长度而删除，也不要把它提交到公开的在线解码页面。核对时可以比较开头、结尾与参数名称，不必在共享屏幕上完整展示。

保存后核对集合与当前选择

订阅内容进入客户端后，先观察它是否归入预期分组，再查看服务器名称、协议类型与数量变化是否符合已有资料。名称只是备注，不能证明两条记录完全相同；同名记录可能使用不同端口或传输设置。首次导入时可以选取其中一条，打开详情核对基础字段，然后返回 Home 确认当前选中项。不要因为列表已经出现，就跳过连接所需的配置选择和系统授权。

Subscribe 的价值在于保留远程集合与本地列表之间的维护关系，而不是把所有记录变成互不相关的手填项目。后续更新可能增加、移除或替换集合内的服务器。若在订阅生成的条目上直接修改参数，下次更新后这些修改可能被远程内容覆盖。需要做临时诊断时，先记录原值；确有长期保留的自定义内容，应在应用允许的独立记录中管理，并明确它不再随原订阅自动维护。

导入失败时按层定位

如果保存时就被拒绝，应先检查 URL 字段和输入格式；如果保存成功但获取失败，重点检查入口可访问性、授权是否有效以及返回内容。远程服务返回登录页面、提示页面或空文本时，浏览器可能仍显示请求成功，但这些内容不等于可解析的服务器集合。不要仅凭“页面能打开”就认定客户端解析有问题。应先从已有资料确认该地址确实是订阅入口，再对照应用显示的错误信息。

排查时尽量只改变一个条件：先重新复制原始入口，再尝试更新；仍失败时比较当前 Wi-Fi 与蜂窝网络下的结果，并记录发生阶段。避免连续删除重建，因为这样会丢失分组和当前选择的上下文。若旧列表仍可使用，可以保留它并暂停重复操作，待确认远程内容后再更新。首次连接的完整顺序见入门指南；需要按错误现象继续检索时，可转到常见问题。

02 · Add Server：逐项核对手填字段

先选 Type，再填写通用字段

Add Server 适合将用户已有的一条完整服务器信息建立为独立记录。应先选择 Type，再填写对应字段，因为协议类型会决定后续需要哪些参数。不要先把所有内容填进默认表单，再随意切换协议；切换后有些字段可能不再适用，也有些必填项需要重新确认。若资料只有订阅地址，应回到 Subscribe 流程，不要从地址里猜测服务器参数。

Address 填写服务器域名或 IP 地址，Port 填写资料指定的端口。除非当前字段明确要求完整 URL，否则 Address 不应带上协议前缀、路径或端口。域名中的连字符和数字容易在复制时混淆，Port 也不能根据常见习惯自行补写。服务器名称或备注仅用于本地识别，可以按用途命名；它通常不参与服务器认证，修改备注并不能修复地址、密码或传输参数错误。

认证信息必须与所选协议一致。部分协议使用 Password，部分协议需要 UUID，也可能需要用户名、密钥或其他专用字段。空白字符会成为实际输入的一部分，尤其要注意从文档末尾复制出的换行。填写完成后先逐项对照原资料，再保存并测试；若信息不全，应补齐资料后再继续，而不是用其他协议的字段拼凑。手填的目标是准确还原已有信息，不是尝试所有选项直到偶然连接成功。

协议字段与传输字段分别核对

协议认证与传输方式是两层不同信息。同为 VLESS 或 VMess 的记录，可能使用不同的传输方式；即使 Address、Port 与 UUID 完全相同，缺少路径、Host 或 TLS 相关字段也可能连接失败。只有已有资料明确要求时才填写这些附加项，不能因为表单里出现某个输入框就随意补值。对照时先核对基础认证，再核对传输，最后检查证书相关设置，能减少来回修改产生的混乱。

TLS 的服务器名称用于证书校验等过程，它不必总与 Address 相同，但必须遵循服务器配置。遇到证书错误时，不应首先关闭校验来绕过问题；应核对域名、设备时间、证书有效性以及资料中的名称要求。某些错误看起来像“连不上”，实际发生在认证或握手阶段。保留准确的报错文字，比只描述连接开关有没有打开更有助于判断。

保存一条可复查的记录

保存前，建议按“地址与端口、认证、传输、TLS、备注”的固定顺序复查。保存后返回 Home 选择这条记录，观察当前选中状态，再进行测试。不要把成功保存等同于成功连接：表单校验只能判断部分格式，无法证明远程服务器正在接受请求。若导入与手填两种方式生成的结果不同，应打开详情逐字段比较，尤其关注默认值和未被分享链接携带的附加参数。

需要试验某个字段时，先复制记录或保存原值，再只修改一项，并记录修改后的现象。若多项一起变更，即使恢复连接也很难知道真正原因。对于由订阅维护的服务器，长期修正应先确认远程资料是否需要更新；本地改动可能在下次刷新时被替换。对 Hysteria2 的传输概念有疑问，可阅读Hysteria2 协议说明，但具体填写仍以用户已有服务器信息为准。

03 · Scan QR Code 与剪贴板：先预览再保存

扫码只改变输入方式，不改变核对责任

Scan QR Code 用于读取二维码承载的文本，再由应用判断是否能作为服务器或订阅信息处理。操作前先确认二维码来自用户已有资料，并判断它描述单条服务器还是一个订阅入口。二维码看起来相似，内部内容却可能完全不同；账户网页、普通文本与服务器分享链接都能生成二维码，因此“扫描成功”只表示读取到了内容，不表示已经获得有效配置。

在 Home 的扫描入口进入 Scan QR Code，按系统提示授予必要的相机权限，将完整二维码置于取景区域内。若应用随后展示详情或导入确认，应停下来核对 Type、Address、Port 与备注，不要立即连续确认。二维码被裁切、压缩或反光遮挡时，识别可能失败；先改善清晰度和取景距离，再尝试读取，而不是把识别失败当作服务器不可用。

若二维码保存在同一台设备上，可在当前应用确实提供相册读取入口时使用该入口；界面没有该能力时，不必反复寻找。更直接的办法是使用资料中对应的原始分享文本，通过剪贴板导入。不要把凭据图片上传到公共识别工具，也不要为了方便识别而在公开页面展示完整二维码。二维码中的内容通常与明文凭据具有相同的访问价值。

剪贴板导入要保留完整文本

复制时应只选择一条完整的分享链接或明确的一份订阅地址，不把标题、序号、引号、说明段落一起复制。回到 Shadowrocket 后，使用当前界面提供的剪贴板导入或添加提示；出现系统粘贴授权时，确认本次确实要读取刚复制的资料。若没有导入提示，可以进入添加流程查看是否提供对应入口，不要把整段编码内容直接粘贴到 Address 字段。

长链接可能在显示时自动换行，视觉换行不一定是实际换行。真正的问题通常是复制时截断、插入空格，或者只复制了链接的可见标题而没有复制底层内容。导入失败后，先回到原始资料重新复制一次，不要手动删除看不懂的编码段。若资料通过文档传递，应确认采用普通文本复制，避免智能标点将英文引号、加号或斜杠替换成其他字符。

一次导入多条内容时，先确认应用对当前格式的处理方式。多行分享文本与一个订阅返回的编码集合不是同一种东西，不能仅按“都有很多服务器”混用入口。建议先导入一条可核对的记录，确认字段正确后再处理剩余内容。导入结束后立即检查新记录的归属，避免它们与已有同名项目混在一起，导致下一次选择服务器时误用旧参数。

把识别、解析与连接分开验证

这一流程可以拆成三个检查点：第一，是否读到了完整文本；第二，是否解析成正确的记录；第三，记录是否能够建立预期连接。扫码没有反应通常属于第一步，提示不支持的内容多属于第二步，而记录已经出现但请求失败才进入第三步。按阶段排查可以避免反复扫码，却始终没有检查 Port 或 TLS 字段的情况。

解析成功后，打开新记录详情与已有资料对照。名称显示为乱码，可能只是备注编码问题，也可能提示链接被重复编码；需要继续检查认证和传输字段，不能只凭名称下结论。如果扫码导入与剪贴板导入得到相同记录，但两者都连接失败，重点应转向原始参数、服务器状态与本地网络，而不是继续更换输入方式。保留一条记录即可，重复导入不会增加连接成功的可能性。

操作完成后，可用普通文本覆盖剪贴板中的敏感内容，并按设备自身的隐私设置管理剪贴板访问。若导入过程中曾经共享屏幕或发送截图，应检查其中是否暴露完整二维码或授权参数。对误导入的记录，先确认不是当前正在使用的一条，再按本页删除与备份章节处理。首次连接还需要选择 Global Routing 并完成系统授权，这部分在入门指南中按顺序说明。

04 · 分享链接格式：区分记录、订阅与 Config

协议前缀决定如何解释后续文本

单条服务器分享链接通常带有协议前缀，例如 ss://、vmess://、vless:// 或 trojan://。这些前缀不是普通网页地址，而是告诉应用如何解释后面的服务器信息。不同协议的编码与参数约定并不相同；有的把多项字段放入编码后的内容，有的将认证、地址和查询参数分开表达。因此，不应通过替换前缀把一种协议链接改成另一种协议。

HTTPS 地址也不能仅凭外观判断用途。它可能是订阅入口、配置文件地址，也可能只是网页。导入前应先根据已有资料确认目标对象：服务器分享信息交给服务器导入流程，订阅入口交给 Subscribe，规则配置交给 Config。若把 Config 文本作为服务器列表解析，或者把服务器订阅当作配置文件载入，错误通常发生在内容解析阶段，而不是网络连接阶段。

分享链接中的井号后内容常用于备注，问号后内容常用于附加参数，但具体含义要遵循该格式约定。备注变更一般不会修复认证问题，查询参数却可能影响传输方式、路径或 TLS 行为。不要为了让链接简短而删除后半段，也不要把所有编码字符都替换成看起来更易读的字符。百分号编码、Base64 与普通文本混用时，错误地重复解码可能改变真实字段值。

理解 .conf 的职责边界

Shadowrocket 的 .conf 可以包含规则和其他配置设置。下面只展示一个 [Rule] 片段，域名用于说明语法，不是可用服务器信息，也不是可独立完成连接的完整配置。它表达的是请求应如何被处理，而不是服务器凭据从哪里获得。使用已有配置时，应先保留原文件，再确认这些规则与其他设置的关系，不能只复制三行就替换整份正在使用的配置。

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

DOMAIN-SUFFIX 用于按域名后缀匹配，GEOIP 按目标 IP 的地理分类匹配，FINAL 提供最终处理方式。规则通常按顺序检查，因此具体条件与兜底条件的位置会影响结果。PROXY 和 DIRECT 是规则中的处理关键字，不应替换成中文。这里的 example.com 只用于示意匹配对象，不代表需要将它填入任何服务器记录。

Global Routing 的 Config、Proxy、Direct 决定请求采取怎样的总体处理方式。在 Config 下，需要继续查看当前配置规则；在 Proxy 下，不能仅凭网页可访问就断言某条域名规则正确；在 Direct 下，也不能用结果证明代理服务器可用。订阅管理与规则配置需要分开核对：先确认当前记录，再确认路由姿态，最后看实际请求是否经过预期处理。

分享之前检查范围与敏感信息

导出一条服务器记录与导出一整份配置，涉及的信息范围不同。单条记录可能包含认证信息，配置文件可能包含自定义规则、DNS 设置、远程地址与其他个人化内容。发送之前先判断接收方究竟需要什么：排查字段名称可以提供脱敏截图，解释规则可以提供最小规则片段，不必把整个账户相关内容一并发出。即使备注看似普通，链接正文仍可能具有直接访问能力。

跨设备整理时，若采用应用提供的分享功能，应在接收设备上检查导入结果，而不是认为生成链接就已经完成迁移。有些补充设置可能依赖本地配置或订阅关系，单条分享记录未必携带全部上下文。尤其是从订阅条目分享出的一条独立记录，后续是否仍能跟随原订阅维护，应以导入后的实际分组和入口为准；不要把“参数相同”与“维护关系相同”混为一谈。

遇到格式不识别，优先保留原始文本并核对应用是否支持该种表达方式，不要将其粘贴到公共转换服务。可以从已有资料取得适合当前导入入口的表达形式，或在字段完整时改用 Add Server 手填。具体协议的扩展参数以当前应用界面及原始服务器信息为准；本手册不通过修改编码文本来猜测认证字段，也不提供从缺失资料还原凭据的做法。

05 · 更新策略：分清获取成功与内容变化

建立一次可核对的手动更新

订阅更新是重新请求入口，并将返回的服务器内容应用到对应集合。它不是对所有服务器逐个修复，也不能让已经失效的授权自行恢复。执行前先记下当前使用的订阅组和选中服务器，必要时记录正在使用的配置。这样即使列表顺序改变、名称调整或某条记录被移除，也能判断变化来源，而不是把更新后的不同显示误认为整个客户端设置丢失。

在 Home 找到目标订阅，使用当前界面提供的更新操作。不同界面布局可能将操作放在分组菜单、编辑入口或订阅管理区域，应以 Subscribe 对象为目标，而不是逐条编辑服务器。触发后等待这次请求结束，再查看反馈与列表变化；不要在请求尚未完成时反复点击。若有多个订阅，建议先更新一个已知集合，确认结果，再处理其余集合，便于定位具体哪个入口发生问题。

一次更新成功但条目没有变化，可能只是远程内容与本地一致；条目变多也不等于连接质量改善。应该分别判断“请求完成”“内容可解析”“变化符合预期”“当前选择仍有效”四件事。更新后打开常用记录详情，核对协议和关键参数是否变化，再执行一次测试。若当前选择被移除，应从新集合中重新选定，而不是仅看连接开关仍保持开启就认为旧选择继续有效。

自动更新与请求路径

需要自动维护时，可在 Settings 中查找订阅相关的自动更新选项，按当前界面说明设置，例如打开应用时更新。应先通过一次手动更新验证入口有效，再启用自动行为。自动更新只是改变触发时机，不能保证每次后台状态都能完成网络请求；设备网络、应用运行状态和系统调度都可能影响实际结果。重要变更后仍应回到订阅列表核对，而不是只依赖开关状态。

更新请求本身也需要网络路径。若入口只能在某种连接条件下访问，应根据现有配置理解它实际经过哪条路径，而不是立即将所有流量改为另一种 Global Routing。尤其在旧服务器已经不可用时，若更新请求仍依赖这条连接，就可能出现无法取得新列表的循环。排查时记录切换前后的路由姿态和网络环境，每次只改变一个条件，避免为了更新而永久改乱日常规则。

失败后保留现场，避免重复重建

出现更新错误时，先保留原订阅与旧记录，记录错误文本和当时网络环境。如果旧列表仍在，不必立刻删除；删除并不会改变远程入口的返回内容，反而会让原本可用的记录失去参考。应先确认授权参数是否完整、入口是否发生变更，再判断是否需要替换 URL。替换入口与新增第二个订阅的管理结果不同，操作前要明确是修正原集合还是建立独立集合。

如果更新后大量记录变化，先检查是否误用了另一个已有订阅入口，或是否在复制时取得了不同用途的地址。不要只根据备注判断，因为备注可以相同而 URL 完全不同。若远程内容本来就调整了服务器，旧记录是否还能继续使用取决于服务器实际状态；保留旧记录仅有助于比较，不意味着它仍有效。应以新资料核对，并避免将已经失效的旧记录重新混入长期维护的集合。

日常维护宜采用明确的节奏：需要时手动核对，自动更新作为辅助，发生异常时保留一次完整的失败信息。连续高频请求既不能修复格式，也容易让错误反馈混杂。更完整的操作入口与原因分支可参阅订阅手动更新与自动更新说明。若问题表现为解析成功但速度慢，应转向测试与排序，不要继续把它当作订阅格式问题处理。

06 · 多订阅整理：保持归属与规则可读

命名说明用途，不把名称当作身份

当用户已有多个订阅时，先为每个入口建立清晰的管理含义，再整理其下的服务器。订阅备注可以描述用途、设备或管理归属，例如“个人常用”“临时测试”，但不应包含完整授权参数。服务器名称可能由远程内容生成，更新时发生变化，因此不能把名称当成永不改变的标识。真正需要核对的是所属订阅、协议、地址与关键连接参数之间的对应关系。

整理前先列出当前有哪些订阅入口、哪些记录是手动添加、哪些记录由扫描或剪贴板产生。相同名字的服务器不一定重复，不同名字的记录也可能指向同一地址。不要只按名称批量删除。可以打开详情比较 Address、Port、Type 与传输参数，再判断是否确实多余；认证不同的记录应分别保留，除非已有资料确认其中一条不再使用。

如果相同订阅被导入多次，通常会形成重复的维护对象，而不是一个更完整的集合。保留哪一份应看当前选择、备注与配置引用关系，不是简单保留列表最上方的一份。删除前先在计划保留的集合里选择对应记录并验证，再处理重复项。这样即使同名项目很多，也能避免误删正在使用的唯一可用记录。整理操作应与更新操作分开进行，便于观察每次变化的原因。

订阅分组不等于路由策略

Home 中的订阅分组首先解决“这些服务器由哪个入口维护”的问题，Config 中的规则则解决“某个请求应如何处理”的问题。把服务器放入不同订阅，不会自动让不同网站分别使用它们。若配置还使用了策略组或特定名称引用，需要进一步核对配置实际如何选择服务器。单纯调整列表显示顺序，也不会自动修改规则中的匹配条件。

Global Routing 是检查这一关系的起点。选择 Config 时，应确认当前启用的是哪份配置，再查看相关规则和策略；选择 Proxy 时，测试关注的是代理处理路径；选择 Direct 时，结果反映的是直接连接。不要一边整理订阅，一边无记录地切换这些姿态，否则同一服务器前后测试结果可能来自不同的请求路径，整理结论也会失去可比性。

用小批量操作维护长期可读性

推荐按“确认归属、核对重复、统一备注、验证选择、清理多余”的顺序整理，每次只处理一个订阅。完成一组后返回 Home 检查列表，再继续下一组。如果应用提供筛选、折叠或排序操作，可以先利用显示层的整理减少干扰，不急于删除数据。隐藏或折叠只是改变可见范围，删除则改变持有内容，两者不能混用。任何批量操作前都应确认它作用于当前组还是全部记录。

长期保留的手填记录最好有单独的命名约定，明确它们不依赖 Subscribe 更新。例如在备注中说明用途，而不是写入容易过期的测试数字。需要暂时比较两条参数记录时，可在本地备注中说明“原始”与“测试”的关系，试验结束后及时清理。不要把临时调整长期留在订阅生成的条目中却不记录，因为下一次刷新可能覆盖它，也可能让日后排错的人误以为它来自远程原始资料。

完成整理后，应重新核对当前选中记录和 Config 的引用。特别是配置中存在按名称使用的内容时，重命名或删除可能影响后续选择，不能只看列表整齐就结束。对于名称会随更新变化的集合，更应避免在没有核对的情况下依赖固定显示文字。规则与姿态的进一步解释见代理模式；如果列表管理正常但某个网站处理方式不符，问题应转到规则检查，而不是继续调整订阅分组。

07 · Connectivity Test：测试、排序与实际请求

先确认测试测量的对象

Connectivity Test 的结果需要结合所选测试方式理解。不同方式可能检查服务器地址与端口的可达性，也可能通过代理完成指定请求；两者覆盖的环节并不相同。基础网络探测成功，不能自动证明协议认证、TLS 握手和目标网站访问都成功。测试前先在当前界面确认方法与相关设置，再解释显示结果，不要把任何一个数字都视为整个连接质量的完整结论。

测试条件应尽量稳定：使用同一设备、同一网络、同一测试方式，并避免同时更新订阅或进行大量传输。若在 Wi-Fi 下测一条、在蜂窝网络下测另一条，结果会混入本地网络差异。批量测试还可能带来并发影响，因此列表中的细小差距不一定有实际意义。应先找出明显失败或表现持续异常的记录，再对少量候选记录重复检查。

如果显示超时，应先判断它发生在哪种测试中。服务器端口不可达、协议认证失败、测试目标不可达，都可能表现为失败，但处理方向不同。不要在没有核对方法时直接删除所有超时记录。可以选择一条参数已核对的记录，分别观察基础连通性与实际请求，再比较错误信息；这样比连续更换测试目标更容易知道失败属于哪一层。

排序是观察工具，不是长期承诺

按测试结果排序可以帮助缩小候选范围，但排序反映的是当前条件下的一次观察。网络负载、目标站点、连接复用与测试时机都会影响结果，列表第一项不一定在所有请求中表现最好。不要把一次较低的延迟写进永久备注，也不要据此推断持续传输能力。需要长期使用时，更重要的是多次观察是否稳定，以及实际应用中的请求是否符合预期。

排序后仍应手动确认当前选中服务器。改变显示顺序不一定改变选择，批量测试完成也不意味着客户端自动采用了结果最好的记录。如果所用配置包含策略组或其他选择逻辑，还需要查看其实际行为。操作完成后返回 Home 检查当前记录，再发起一次实际请求；不要只凭排序位置判断某个服务器已经生效。

用实际请求形成验证闭环

测试通过后，选择一项用户实际需要的请求进行验证，并同时确认 Global Routing 与当前 Config。若普通浏览正常但某个应用异常，应检查目标域名、DNS、规则匹配和应用自身连接行为，而不是立即修改所有服务器参数。已有连接也可能继续使用原路径，切换服务器后应通过新请求观察变化，避免把旧连接的结果误认为新选择没有生效。

实际访问慢时，可按服务器、传输路径、本地网络与目标服务逐层比较。先在相同网络中更换一条已有记录，再在条件允许时对比 Wi-Fi 与蜂窝网络；每次都保留相同请求，避免同时更换目标。若只有域名相关请求失败，可继续核对 DNS 和规则；若所有连接都不稳定，先检查本地网络。具体分层方法见速度慢的分层排查说明。

求助记录宜包含协议类型、测试方式、失败阶段、当前 Global Routing 与网络环境，不包含 Password、UUID 或完整订阅地址。DNS 相关问题可对照DNS 设置说明，但不要为追求某次测试结果而同时更换解析、规则与服务器。一次测试只回答一个问题，才能让后续调整有依据；结果不一致时，重复少量可控测试比批量反复刷新更有价值。

08 · 删除与备份：先验证恢复，再清理记录

删除前确认对象与影响范围

删除单条手填记录、删除订阅入口和删除 Config，是三种不同操作。单条记录的删除通常影响该条服务器；订阅对象的删除可能连同其维护的集合一起移除；配置文件的删除则影响规则与相关设置。执行前必须阅读当前确认提示，弄清作用范围。不要因为几个对象显示在相邻位置，就认为它们可以通过同一种方式恢复，也不要把“退出编辑”误认为已经取消了删除。

删除正在使用的记录前，先选择另一条已验证的已有记录，并确认当前配置仍能按预期工作。若存在策略引用或固定名称关联，还要检查这些关联是否需要调整。订阅内的单条记录即使被本地删除，下次更新也可能重新出现，因为远程内容仍包含它；如果目标只是减少显示干扰，应优先查看应用提供的整理方式，而不是把删除当作永久过滤规则。

确认清理重复订阅时，先比较入口与归属，再备份需要保留的本地信息。两个分组名称一致不代表内容完全相同，两个 URL 看起来相似也可能带有不同授权参数。对于不再使用的旧入口，应先确认新入口已经完成更新和实际连接测试，再移除旧对象。清理过程中保留一份简短操作记录，说明删除的是哪个对象及其替代关系，能减少换机或恢复时的猜测。

备份内容分层保存

备份应覆盖四类信息：订阅入口与备注、独立服务器参数、正在使用的 Config，以及必要的本地设置。应用购买记录不能替代这些内容；从 App Store 重新取得 Shadowrocket，并不等于所有个人配置已经恢复。具体可导出的范围取决于当前应用提供的备份或导出功能，应查看实际包含项，不要仅凭文件名认定所有数据都在其中。

如果当前界面提供 Data 或相关备份入口，可以按界面说明导出，并检查导出结果是否包含需要的对象。若某些内容需要分别保存，就逐项处理：保留原始订阅资料、保存独立配置文件、记录手填字段与选择关系。不要把敏感参数放进公开笔记或随意共享的目录；备份文件应按访问凭据管理，存放在用户可控制且具备适当保护的位置。

备份时还应记录上下文，例如当前使用哪份 Config、Global Routing 选择、常用记录归属，以及是否启用了订阅自动更新或 On Demand。这些信息未必都由单条分享链接携带。On Demand 涉及按条件建立连接的行为，迁移后应重新核对条件和系统授权，不要在尚未验证服务器与规则时直接依赖它。备份不是只保存“能导入的文本”，还要保存足以理解它的管理关系。

恢复顺序与备份有效性

恢复时先确认 Shadowrocket 已从 App Store 正确取得，购买与重装说明见已购恢复。然后按“导入订阅与独立记录、恢复 Config、检查本地设置、选择当前记录、验证实际请求”的顺序操作。涉及订阅时，先检查已有备份内容，再决定何时更新；立即更新可能使列表发生变化，影响与旧设备的逐项比较。

备份文件能够被保存，不代表一定能够完整恢复。应在合适时机进行一次可控验证，检查应用能否读取文件、记录是否齐全、Config 是否存在，以及敏感字段是否保持完整。若在另一台自己的设备上验证，应避免覆盖该设备原有配置；先保留原状，再进行恢复。验证结束后比较关键字段和一项实际请求，而不是只看列表数量一致就宣布完成。

订阅入口或认证信息后来发生变更时，旧备份可能仍然保留旧值。应在重要变更完成且确认可用后更新备份，并清晰区分当前副本与历史副本。保存历史内容有助于比较，但不能保证旧服务器仍有效。如果曾暴露完整订阅或认证信息，仅删除本地记录不能撤销已经泄露的访问能力；应根据已有账户的管理方式处理相关凭据，再更新客户端与备份。

需要重新走一遍连接主线，可返回入门指南；需要按具体错误继续查找，可进入常见问题。日常管理不必频繁重建全部配置，保留清晰的入口、字段与操作记录，通常更容易判断下一次异常究竟发生在哪一层。