01 · Subscribe 入口与首次导入
先区分订阅与单台服务器
Subscribe 保存的是一个可再次请求的数据入口；Add Server 保存的是一次手动填写的服务器记录。两者最后都可能在 Home 的列表中呈现服务器，但维护方式不同：订阅所包含的条目通常由订阅数据决定，手填条目则需要逐项修改。开始前先看你手上的资料是什么。如果是一条供客户端读取并定期更新的链接，按 Subscribe 路径处理；如果只有地址、端口、认证信息和协议参数，就按下一章的 Add Server 路径处理。不要因为两者最终都显示为列表项，就把服务器分享链接当成订阅地址填写。
在 Shadowrocket 的 Home 打开添加入口，选择用于添加订阅的 Subscribe 类型，然后把已有的完整链接填入对应的 URL 字段。不同界面状态下，添加入口的位置与字段排列可能略有差异；判断依据是类型确实选为 Subscribe，而不是仅看到一个可粘贴文本的输入框。保存后返回列表，等待客户端读取和解析。首次添加前可先复制原始链接到系统备忘录临时核对，检查开头、结尾有没有缺字符，也检查复制时是否把前后的空格和换行带进去了。
保存成功不等于解析成功
一次导入至少包含三个环节：保存 URL、通过网络取得响应、把响应转换为 Shadowrocket 可识别的服务器条目。列表里出现订阅名称，只能说明第一环节完成；名称存在而服务器为空，应继续核对后两环。先在同一网络条件下检查原始链接是否仍有效，再确认该链接返回的确实是适配客户端的订阅内容，而不是登录页、错误页或单条分享文本。不要凭空更改链接里的查询参数：参数可能是数据的一部分，删除一个字符就可能得到另一份响应。
如果添加后有条目但名称难以辨认，先给订阅入口起一个便于自己区分的名称，再考虑列表排序。名称只是本机的管理标记，不会修正服务器地址，也不能替代对服务端数据的检查。对于第一次使用的人，建议先只导入一条已掌握的订阅，确认能看见条目、能识别其归属、能按需要更新，再增加下一条。这样遇到解析失败时，排查对象明确，不必在多个来源和重复条目之间反复猜测。
订阅内容是会变化的远端数据，不应把当前显示的服务器数量当作永久状态。下次更新后，条目可能增加、消失或更名；如果某个地址只适合单独长期维护，先弄清它是否原本由订阅管理，再决定是否另建手填记录。也不要把应用购买与数据导入混作同一步：App Store 完成的是客户端获取，Subscribe 完成的是你已有数据的读取。需要先确认应用身份时，可按正版核验三要素检查开发者、图标与应用 ID。
02 · Add Server 手填字段
按资料原样选择协议
只有单台服务器资料时，在 Home 的添加入口选择 Add Server，再按已有资料指定的协议类型填写。协议选择不是给同一组数字换个标签：Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 和 Hysteria2 的字段结构、认证方式及传输要求各不相同。若资料没有写明协议，应先向资料提供方核对；仅凭端口或地址无法可靠推断。填写时保留资料原有的大小写、标点和特殊字符，尤其是密码、标识符、主机名及路径，不要为了看起来整齐而自行改写。
Address 指向服务器的域名或 IP，Port 是与该服务对应的端口；它们要作为一组核对。地址栏一般不需要附带网页路径，端口栏也不填写协议前缀。若资料给的是含完整结构的分享链接，优先判断能否按后文的链接方式导入，避免从编码文本中人工猜字段。手填完成后先保存，再返回记录查看是否被分配到预期的列表；保存动作只检查输入能否被记录，不代表服务端一定接受连接。
认证、TLS 与传输参数
认证字段随协议变化。Shadowsocks 需要对应的加密方法与密码；VMess、VLESS 常见标识符和传输选项；Trojan 以密码及 TLS 相关设置为重点；WireGuard 则按 Interface 与 Peer 的资料成组填写。TLS 场景下，SNI 所指的服务器名称与 Address 可能不同，不能随意互换。遇到 Allow Insecure 时，应理解它与证书验证有关，先核对证书名称、时间及输入信息，不应把改变验证行为作为排查连接失败的第一步。
| 资料类别 | 填写重点 | 常见核对点 |
|---|---|---|
| 地址与端口 | Address、Port 与协议类型 | 域名拼写、端口数字、资料是否仍有效 |
| 认证信息 | 密码、标识符或密钥 | 大小写、复制时混入的空白字符 |
| TLS 信息 | SNI、证书相关选项 | 名称与证书是否匹配 |
| 传输信息 | 路径、Host 等协议指定字段 | 前导斜线及约定的原始写法 |
字段较多时，推荐分两轮核对。第一轮只检查协议、地址、端口和认证信息是否与原始资料逐字一致；第二轮再检查 TLS、传输及额外选项。这样可以区分基础字段错误与进阶设置不匹配。不要连续改动多个字段后立刻测试，因为即便结果发生变化，也难以判断哪一项起作用。对需要密钥的配置，不要把完整资料贴进公开讨论区；排查时仅描述字段类型、报错位置与操作现象即可。
如果列表中同时存在订阅生成的记录和手填记录，优先标明手填记录的用途。以后订阅更新不会自动修复这条手填数据；服务端参数发生变化时，应回到该条记录重新编辑。反过来，也不要直接把手填时的经验套用到订阅生成的条目上：后者的字段可能在下一次更新时由订阅内容重新写入。关于 Trojan 各参数及 WireGuard 的成组资料，可分别查阅Trojan 字段说明和WireGuard 参数指南。
03 · Scan QR Code 与剪贴板导入
扫码前先确认码的内容
扫描二维码省去逐字段输入，但二维码只是文本的另一种承载方式。先弄清其中装的是单台服务器分享链接、订阅 URL，还是别的文本，再决定导入后应出现什么。如果资料明确以二维码提供，在添加入口选择 Scan QR Code，允许相机权限后让完整码面进入取景范围，待识别结果出现再核对协议与主要字段。码面模糊、被遮挡或与背景对比过低时，可以让资料提供方重新展示清晰的原码；不应依据二维码旁的说明自行拼接地址。
扫码后不要立即把新条目作为当前连接。先查看导入结果的类型、名称、Address 和 Port 是否符合预期；如果导入的是 Subscribe，应检查它是否成为一个可更新的订阅入口，而不是一条静态服务器。如果应用提示文本无法识别，问题也可能在二维码所含内容，而不只在相机权限。对于已经保存在本机的图片，可以先确认图片内容可读，再使用界面实际提供的识别入口；不要把浏览器中看到的缩略图当作完整原图处理。
从剪贴板读取时检查边界字符
剪贴板导入适合你已持有一条完整的分享文本。复制时应从协议前缀开始，一直到文本最后一个字符结束，不连带聊天记录中的引号、编号或解释文字。返回 Shadowrocket 后使用添加菜单中与剪贴板对应的导入操作，并检查预览内容。若系统出现读取剪贴板的许可提示，这是读取刚才复制内容所需的系统交互；应先确认自己确实发起了导入，再决定是否允许。粘贴后若出现空记录，先回到原始资料，核实剪贴板中存放的究竟是不是链接。
二维码和剪贴板只是输入通道，不会替你验证资料的真实性或时效性。重复扫描同一个码或重复粘贴同一条文本，可能在列表中留下难以辨认的重复记录；导入前先搜索现有名称，导入后再比较协议、地址、端口等字段。若文本包含认证资料，避免在共享设备的其他输入框里反复粘贴。完成操作后，可按自己的隐私习惯用普通文字覆盖剪贴板；但不要因此删掉唯一保存原始资料的位置。
碰到“扫码可识别、连接不可用”的情况，应把两阶段分开。识别成功说明客户端读到了文本，并不说明端口开放、认证正确或服务器可达；先检查导入后的字段，再使用后文的 Connectivity Test 辅助定位。若另一台设备同样需要这份资料，优先使用你自己保存的原始信息，不要从列表截图重新手敲隐去的字段。跨设备转移尤其需要确认订阅 URL 的完整性，部分界面可能只展示便于阅读的截断文本，不能把截断结果当作备份。
05 · Subscribe 更新策略与异常排查
区分手动更新和自动更新
订阅不是一次导入后永远不变的本地清单。手动更新是在你需要确认最新数据时主动发起读取；自动更新则按设置在适当时机尝试读取。选择哪种方式，应以你自己的使用频率和数据变化情况为准，而不是把间隔设得越短越好。频繁请求不会让原本错误的链接变正确，也不保证远端数据每次都变化。若正在排查，先做一次手动更新并记录前后的列表差异，比反复等待自动行为更容易判断问题所在。
建议把每次检查拆成“入口状态”和“条目状态”。入口状态包括 URL 是否完整、请求是否成功、是否能解析；条目状态包括更新后名称、数量与所需字段是否符合你已有的资料。若更新提示失败而旧条目仍留在 Home，不要据此判断新数据已取得：有些情形下，屏幕呈现的仍可能是先前保存的内容。先查看失败提示，再核对当前网络和原始 URL；不要因为旧条目仍可见就忽略更新结果。
列表变空、变少或重复
列表变空时，先停止连续重复点击更新。检查是否选择了正确的 Subscribe 记录，再核对链接的开头、查询部分和末尾；还要确认返回内容是可解析的数据，而非一段说明文字。列表变少未必是客户端删除错误，也可能是远端数据发生变化。可将当前结果与自己留存的上一次记录作对照，找出具体缺失的名称，再核对其原始资料。若更新后出现重复项，先确认是否导入了同一 URL 两次，或同时保留了手填记录与订阅记录。
需要修改订阅 URL 时，应明确是在编辑现有 Subscribe，还是新建另一条记录。编辑可保留原有的管理位置，但改动前要保存完整旧链接，以便发现粘贴错误时恢复；新建有利于并排验证两条不同的 URL，却可能造成重复列表。选择方式取决于你是否需要对照，不宜一边排查一边删掉唯一可工作的旧入口。更新失败也未必涉及协议字段：在取得数据之前，DNS、网络状态和 URL 响应都可能影响读取。
若只有某条订阅反复异常，而同一设备上其他订阅可更新，可优先检查该条 URL 和返回内容；若多条同时异常，先检查当前网络状态，再分别尝试一次手动更新，避免把共同的网络问题误写成多个链接问题。关于链接格式、编码和更新时机的逐项排查，参见订阅导入失败或节点为空。排查完成后再决定自动更新安排，并定期查看结果；自动设置不能代替对实际列表内容的核对。
06 · 多订阅与手填记录整理
让名称表达管理用途
当 Home 同时列出多个 Subscribe 和手填记录时，首先要解决“这条记录从哪里进入、该由谁更新”的问题。给订阅入口使用可区分的本地名称，例如按自己的用途或资料类别命名，不要仅靠服务器名称推断归属。服务器名称可能随更新改变；订阅入口名称则适合作为管理线索。对手填条目也可以使用便于辨认的备注，但不要把密码或完整订阅 URL 放进显示名称，以免在截图或屏幕共享时暴露。
整理的基本单位是入口，而不是列表中每一个看起来相似的名字。同一份订阅可能包含多条服务器；两份不同订阅也可能给出相似名称。判断重复时至少比较协议、Address、Port 以及关键传输参数，再确认各自属于哪个入口。只凭显示名相同就删除，有可能误删仍需要的独立记录。若两条看起来完全一致，可先保留其中一条进行测试，同时记录另一条的归属，确认重复原因后再处理。
建立可回溯的变更顺序
每次新增订阅后，先确认新入口可以读取，再整理旧入口；每次大范围清理前，先保存自己合法持有的原始链接与手填参数。这个顺序能降低误删后的重建成本。对于已经不再需要的条目，应区分“从列表中暂时不选用”和“删除入口”：前者便于以后继续核对，后者会失去在客户端内直接更新的路径。是否保留应依据实际资料状态，而不是仅看一次 Connectivity Test 的结果。
混合使用订阅和手填记录时，要特别注意改动归属。订阅生成的字段应优先回到订阅数据本身核对，因为下一次更新可能再次改变它；手填记录则直接在 Add Server 的编辑流程中维护。若要针对一条订阅内的服务器做临时对照，可以先记录原字段与变更目的，避免在更新后分不清是本地调整还是订阅数据变化。记录不必复杂：写清入口名称、操作前现象、改了哪一项以及操作后结果即可。
多订阅还会影响你对列表数量的判断。数量增加可能来自新增入口、某条订阅内容变化，或者重复导入；数量减少可能来自删除入口、更新结果变化，或显示范围改变。排查时按入口逐一查看，不要从总数直接推断原因。若当前只需使用其中一条记录，可先选中明确归属的服务器，再核对 Global Routing 当前为 Config、Proxy 还是 Direct，避免将路由姿态与服务器选择混为一谈。
当资料跨设备使用时，保持命名习惯一致有助于对照，但不意味着两台设备的本地列表会自动同步。分别检查每台设备上的 Subscribe 入口、手填条目与 Config 选择状态，尤其是在一台设备新添或删除资料之后。设备适用性和系统要求以 App Store 页面标注为准；本章讨论的是 iPhone、iPad 上的资料管理方法，不把列表排序当成跨设备备份。下一章将说明如何用测试结果辅助选择，而不是让排序代替来源管理。
07 · Connectivity Test、延迟与排序
测试结果回答什么问题
Connectivity Test 可用来观察当前网络条件下，客户端对服务器条目的连接测试是否完成。它不是服务质量的长期保证，也不能证明某个应用的所有请求都按预期规则处理。测试前先确认所测条目来自哪一个 Subscribe 或手填记录，并确认设备目前的网络状态；换一个网络环境再测，结果可能变化。一次成功或失败只对应当时的测试条件，不应直接用它判断订阅 URL 是否仍可更新，后者需要回到 Subscribe 检查。
延迟数字有助于对比，但比较前要确保测试条件尽量一致。不要把不同时段、不同网络下取得的结果混成一张固定排名；也不要只看较小的数字就忽视连接是否稳定。某条记录显示测试异常时，可先对同一条再做一次测试，再选另一条已知记录作对照。如果所有记录同时异常，应先排查设备网络和当前设置；如果仅某一条持续异常，再回到该条的 Address、Port、认证和传输参数核对。
排序服务于查找，不代替验证
按延迟排序适合在大量条目中迅速找到当前测试结果较靠前的记录，但排序之后仍应识别条目归属。服务器名称可能相近，测试结果又可能随网络变化，单凭排序位置很容易选错。建议先通过订阅入口名称或手填备注缩小范围，再看测试状态与延迟。对经常使用的记录，定期重新测试比保存一次排序截图更有参考价值；截图中的数字脱离测试时间与网络条件后，解释空间很有限。
如果服务器测试成功，实际请求仍不符合预期，可以将连接与路由分开排查。先核对 Home 中实际选中的服务器及连接状态，再看 Global Routing：Config 按当前 Config 的规则处理，Proxy 和 Direct 用于对照不同路由姿态。在 Config 下，某个目标可能命中 DIRECT，此时服务器测试成功并不能说明该目标正在经过所选服务器。需要进一步看规则时，可检查 DOMAIN-SUFFIX、GEOIP、IP-CIDR 等关键字与策略，确认请求落在哪条规则上。
| 观察到的现象 | 先核对 | 再检查 |
|---|---|---|
| 全部条目测试异常 | 设备网络与当前连接状态 | 分别检查订阅更新及设置 |
| 单条持续异常 | 该条资料归属与字段 | 认证、TLS 及传输参数 |
| 测试正常、请求结果不同 | 实际选中项与 Global Routing | Config 规则命中情况 |
排查过程尽量一次只改变一个条件：先固定服务器比较路由姿态，再固定路由姿态比较服务器，最后检查具体 Config。这样能够判断问题出在数据、连接还是规则。若连续切换多个项目，即使结果恢复，也无法知道原先是哪一步造成差异。进一步的问题可查疑难解答；若涉及 DNS 的解析路径，可看DNS 设置说明。测试与排序只是诊断工具，最终仍要结合实际请求和当前规则理解结果。
08 · 删除、迁移与资料备份
删除前确认对象与影响范围
清理列表时，先辨认将要删除的是单台手填服务器、订阅生成的条目，还是整个 Subscribe 入口。删除单条记录与删除入口的后果不同：移除入口后，你可能失去在当前设备上通过该 URL 更新整组条目的路径。即便只想清理一个暂时不可用的服务器，也应先查它是否属于订阅；如果属于，下一次更新可能再次写入，直接逐条删除未必达到整理目的。先处理资料归属，再决定是否需要删除。
建议把清理拆成检查、保存、执行和复核四步。检查时确认名称及关键字段，避免把相似条目认错；保存时留存自己已有的原始订阅 URL、手填参数和必要的 Config 文本；执行时一次只删除一类对象；复核时回到 Home，确认保留的入口仍能按预期更新、所选服务器仍存在。若你无法判断一条记录是否仍需要，先不要删除唯一的原始资料。列表整洁是管理目标，但不应以丢失可重建信息为代价。
备份的是可重建资料
备份不仅是保存一张列表截图。截图可能隐藏完整 URL、密码、密钥、路径及其他字段，也可能无法表明一条记录是手填还是由 Subscribe 生成。更可靠的整理方式是分别保存自己合法持有的订阅原始链接、手填服务器的完整参数，以及需要继续使用的 Config 内容，并注明各自用途。敏感资料应放在你能控制访问权限的位置；分享排查截图前，要检查屏幕上是否展示认证信息或含参数的 URL。
在另一台 iPhone 或 iPad 上重建时，先从 App Store 获取 Shadowrocket 并核对应用身份，再按资料类型分别恢复：订阅 URL 回到 Subscribe；单台服务器参数回到 Add Server；Config 内容按配置文件路径检查。恢复完不要只看条目数量，还要确认订阅可更新、手填参数无缺漏、Global Routing 与所需 Config 已选对。应用的已购恢复属于 App Store 购买记录问题，和服务器资料能否重建是两件事；前者可查已购恢复说明。
如果已不再使用某份资料，删除前还应检查是否在别处保留了与它相关的配置引用。例如 Config 规则可能仍指向某个策略名，删除对应资料后，规则文本本身不会因此变得正确。先核对引用关系，再清理不需要的条目。反过来，如果只是暂时切换服务器，也不必通过删除旧记录实现；保持来源清楚、保存原始资料，通常更便于以后对照连接结果和订阅变化。
至此，本手册覆盖了从导入到清理的完整管理链。首次配置只需遵循入门指南的主线；当出现列表为空、参数不匹配或规则结果难以理解时，再回到相应章节逐项检查。Shadowrocket 的获取入口是 App Store，开发者为 Shadow Launch Technology Limited，应用 ID 为 932747118；设备兼容性与系统要求以 App Store 页面标注为准。客户端一次性买断 ≠ 线路套餐，服务器资料始终应由你自行管理和核对。