01 · Subscribe：建立可更新的订阅记录
订阅的作用是把一个远端列表保存为可重复更新的入口，而不只是一次性添加几台服务器。导入成功后，应当同时检查订阅记录和它展开的服务器条目：前者保存地址与更新关系，后者用于选择连接。只看到列表变长，不能证明订阅关系正确；只保存了地址，也不能证明远端内容已经被成功读取。先分清这两层，后续才容易判断问题发生在更新阶段还是连接阶段。
导入前：辨认输入内容
已有订阅从你的服务商处获取。先确认它是供 Shadowrocket 使用的订阅地址，而不是账户管理页面、说明页面或单个服务器的分享链接。订阅地址通常属于个人凭据，即使外观看起来只是普通网页地址，也可能直接授予读取服务器列表的权限。不要把完整地址放进公开笔记、聊天群或问题截图；用于自己核对时，也应避免让屏幕录制和剪贴板同步暴露其中的访问参数。
导入前保留一份原始文本，检查开头、结尾和中间是否夹有空格、换行或中文标点。尤其要留意消息软件自动附加的句号，以及复制按钮之外同时选中的说明文字。不要自行删除查询参数，也不要把看不懂的字符替换成更熟悉的形式。地址里的大小写、路径与参数可能参与身份识别，整理显示名称与修改实际地址是两种完全不同的操作。
在 Add Server 中选择 Subscribe
在 Home 打开添加入口，进入 Add Server 后，将 Type 选择为 Subscribe，再填写完整地址，并用便于识别的备注保存。界面的具体排布可能随设备而不同，应以当前应用实际显示为准。第一次操作只添加一个订阅，保存后观察是否生成对应列表，再进行下一项；同时导入多个地址会让失败来源难以区分，也容易把重复记录误认为一次更新产生的新内容。
保存后，返回 Home 核对订阅名称、展开的条目以及预期服务器是否一致。不要把列表中的说明性条目直接当成可连接的服务器；如名称含有状态提示，应结合条目类型和详情判断。随后选择一条已确认参数完整的服务器进行连接验证。导入和连接是两个独立结果：前者依赖地址访问与内容解析，后者还依赖服务器可达性、认证和传输设置。
失败时：按访问、内容、结果分层检查
如果保存后没有条目，先检查地址是否完整，再确认当前网络能够访问订阅所在的主机。能在浏览器打开某个页面，并不代表它返回了可供导入的列表；登录页、提示页或访问错误都可能以网页形式返回。不要把这些页面的文字当成服务器内容继续手填。向服务商确认时，描述导入入口、错误文字和发生阶段即可，提供截图前先遮盖地址中的个人访问参数。
如果已有订阅更新失败，先保留旧记录，不要立即删除后重建。比较失败前后服务器是否仍在、选中项是否改变，以及是否只是某条记录不可用。若订阅地址发生更换，应先添加新记录并验证，再处理旧记录。这样可以保留回退路径，也能区分地址失效与服务器本身故障。需要重走最短连接流程时，可返回使用说明，不要在未定位原因前反复改动所有设置。
02 · Add Server：按协议核对手填字段
手动添加适合已经拿到单台服务器完整参数的情况。进入 Add Server 后，先确定 Type，再填写地址、端口和认证信息。不同协议的字段不是同一套参数换个名称：同样叫密码的内容，不能替代其他协议要求的 UUID、密钥或认证字符串。遇到缺失字段，应回到原始说明核对，不要凭名称相似推断，更不要从另一台能用的服务器复制认证内容。
先核对通用字段，再处理协议差异
服务器地址填写主机名或地址本身，不要把整段网页链接塞进地址栏；端口按照提供的信息单独填写。备注只影响识别，不参与连接认证，可以使用“用途、来源、传输特征”的组合，但不要把密码放入名称。地址看起来相同而端口不同，可能对应完全不同的服务。反过来，两条记录名称不同，也可能实际上使用同一组连接参数，因此查重必须查看详情。
认证字段应逐字核对，特别注意复制时混入空格、相似字符以及被消息软件截断的长字符串。填写密码时，不要因为界面以圆点显示就认为复制一定完整；有疑问应从自己的原始记录重新粘贴。UUID 也不应被当作普通备注重新排版。端口、认证与地址全部确认后，再检查 TLS 和传输层，避免一次修改太多项目而失去排错依据。
| Type | 重点核对 | 常见混淆 |
|---|---|---|
| Shadowsocks | 地址、端口、密码、加密方法 | 加密方法必须与服务器一致 |
| VMess / VLESS | UUID、传输方式、TLS 及相关参数 | 不能仅更改 Type 便完成协议转换 |
| Trojan | 密码、TLS、服务器名称 | 连接地址不一定等于 TLS 校验名称 |
| HTTP / SOCKS5 | 地址、端口、认证要求 | 是否需要认证以服务器设置为准 |
| WireGuard | 密钥、地址、对端及路由参数 | 密钥不能用普通密码替代 |
| Hysteria2 | 认证、TLS 与 UDP 可达性 | 本地网络限制可能影响连接 |
TLS 与传输层：名称相近不代表含义相同
连接地址负责找到服务器，TLS 的服务器名称用于握手与证书校验，HTTP 传输中的 Host 又可能用于应用层路由。这些值在某些配置里相同，但不能据此认定它们永远可以互换。如果服务信息指定了独立名称、路径或传输方式，应按字段分别填写。路径中的开头斜杠、大小写和查询部分也可能影响服务端识别，不宜为方便阅读而自行简写。
出现证书错误时，先查服务器名称、设备时间和服务端证书状态，不要把跳过校验当作常规解决办法。证书校验失败与密码错误的处理方向不同：前者通常要检查握手身份，后者才涉及认证内容。若当前网络连服务器端口都无法到达，继续切换认证字段不会改善结果。按网络、握手、认证、实际请求的顺序核对，比反复尝试不相关开关更容易保留有效信息。
保存后的验证与修改边界
保存前再看一遍 Type 与原始资料是否一致；保存后只选这条服务器测试，不要同时切换 Config 文件和本地网络。若刚添加的条目来自订阅，应先考虑通过订阅更新取得更正内容；直接修改订阅生成的字段，可能在后续更新中被覆盖。确需对照实验时，可独立保留一条手工记录，并在备注里写清它是临时核对项，避免以后把实验结果当成订阅原始参数。
手动填写不会自动补齐未知参数，也不会验证服务端是否接受这些组合。一次保存成功，只能说明应用接受了输入形式。连接失败时记录具体阶段和错误，再决定是否需要补充字段。关于 UUID、传输层与 TLS 的关系，可结合VMess 与 VLESS 参数说明阅读；如果只是辨认协议名称，则查阅术语手册即可，不必先调整整份配置。
03 · Scan QR Code 与剪贴板：减少复制误差
扫码和剪贴板只是输入方式，不决定输入内容属于订阅、服务器还是配置。一个二维码可以装入单个服务器链接，也可能只是普通网页地址；复制到剪贴板的文本同样如此。导入前先辨认来源和用途，导入后再检查生成的记录。看见成功提示不等于参数已经适合当前网络，也不能代替对地址、认证和传输设置的核对。
扫码前：确认二维码承载的内容
准备扫码时，先确认二维码来自你已有的服务器资料，并与对应说明保持一致。使用 Scan QR Code 时按系统提示授予相机访问权限；如果无法打开相机，先在系统设置中核对权限，再返回应用重试。二维码位于另一台设备上时，调整亮度和距离，保证四周边界完整。反光、裁边、过度压缩和模糊缩放都会影响识别，不应通过更改服务器参数来解决图像识别问题。
二维码在当前设备的图片中时，先查看当前应用入口是否提供从图片识别的选项；若未显示，不必寻找与当前界面不符的固定按钮。可以使用对应资料提供的文本链接，经剪贴板导入，并在保存后逐项复核。不要因为图片难以识别就把二维码上传到公共识别页面，二维码本身可能包含密码、密钥或完整订阅地址，公开图片与公开文字具有相近的泄露风险。
剪贴板导入：一次只保留一种内容
复制时尽量使用原始资料中的完整复制入口，避免手动拖选时遗漏开头或末尾。回到 Shadowrocket 后，使用当前界面提供的剪贴板导入入口，并按系统提示决定是否允许读取。若没有出现预期提示，先确认剪贴板里仍然是刚复制的内容：切换应用后再次复制其他文字、使用跨设备剪贴板或复制图片，都可能替换原来的文本。
批量文本尤其容易混入编号、项目符号和介绍段落。第一次建议只导入一条已确认的链接，确认字段正确后再处理余下内容。如果整段文本未被识别，先检查是否含有代码围栏、引号或消息引用符，而不是直接改写链接内部的符号。不同格式对换行的解释可能不同；无法确认时，应返回原始资料取得清晰的单条链接，不要把多行内容强行拼成一个地址。
导入后的三次核对
第一次核对记录类型：预期导入订阅，就应检查是否存在可更新的订阅记录；预期导入单台服务器，就检查是否出现对应服务器。第二次核对关键字段，至少确认 Type、地址与端口，随后查看认证和传输设置是否完整。第三次核对列表归属，确认条目没有混进另一组订阅或重复实验记录中。名称相同并不代表导入结果完全相同，名称不同也未必意味着新增了不同服务器。
如果重复扫码后出现多条记录，先保留其中已验证可用的一条，逐项对照其余记录再决定清理。不要在尚未验证时把原有记录全部删除。若扫码生成条目却不能连接，应转到字段与网络排查，而不是持续扫描同一个二维码。扫码识别、链接解析、连接建立是三个阶段，重复第一阶段通常无法修复第三阶段的问题。
权限也应按任务管理。相机用于扫码，剪贴板用于读取你主动复制的内容，它们与系统的 VPN 配置授权不是同一个权限。导入结束后若需要收紧权限，可以在系统设置中调整，之后再次使用相应入口时重新确认。首次连接与授权弹窗的顺序见使用说明；若已经得到记录但无法使用，应按连接排查步骤定位，不必反复进行权限重置。
05 · 更新策略：保留回退路径再改动
订阅更新是重新读取远端内容，并据此调整本地列表；它不是对每台服务器执行修复，也不保证正在使用的服务器继续保留。安排更新前，应先知道当前选中哪条记录、它属于哪个订阅，以及有没有依赖该名称的配置。把更新当作一次受控的数据变更，先核对结果再清理旧项，比在连接异常时连续刷新更容易定位问题。
手动更新适用于哪些情况
当服务信息明确发生变化、列表中缺少预期记录，或需要验证订阅是否仍可读取时，可以主动更新。更新前记录订阅名称和当前选中项，更新后查看列表是否有新增、删除或名称变化。如果应用提供自动更新相关设置，应依据实际入口选择，不要把某个固定时间间隔当成所有用户都适用的要求。更新频率还应考虑地址的使用规则和自己的使用习惯。
频繁更新并不等于连接更稳定。远端列表没有变化时，重复读取通常只得到相同内容；某台服务器端口不可达时，更新也未必改变它。先判断故障是否与列表过期有关，再决定是否更新。手工建立的服务器没有订阅关系，不能期待通过更新另一个订阅同步修正。若原始资料中的参数已经更换，应按资料对应的管理方式处理，而不是对所有列表重复操作。
更新失败：先读错误，再选访问路径
更新依赖当前访问订阅主机的网络路径。有时本地网络可以直达，有时正在使用的连接状态会影响访问结果。遇到失败，应先记录是否存在解析错误、连接超时、认证失败或内容无法识别，再检查相应环节。不要只凭“更新失败”四个字就切换全部路由设置；改变访问路径时也应一次只改一项，并在重试后确认结果，以便知道到底是哪一步产生了影响。
若地址可访问但返回登录提示、访问限制或空内容，问题不一定在应用解析。订阅地址中的个人访问参数可能已经改变，远端也可能暂时返回错误页面。此时应保留原地址的私密副本，并向自己的服务商核对状态。不要把错误页面保存成 Config 文件，也不要把页面中看似类似地址的文字拿来创建服务器。内容类型不正确时，继续改服务器端口没有作用。
处理覆盖、重命名与异常清空
订阅生成的记录应尽量保持与远端一致。对这类记录直接修改认证、传输或备注，可能在更新后被重新写入，也可能造成自己难以辨认的差异。需要长期保留的独立实验，宜建立明确标注的手工记录，并与原订阅分开。这样更新后的变化仍能追溯到远端内容，不会把本地临时改动误判为服务商下发的参数。
如果更新后列表明显减少或只剩说明文字，先停止进一步清理。检查原订阅是否仍在、当前选中项是否消失，以及更新结果是否符合服务信息。不要为了让列表看起来正常而立即删除整个订阅，这会同时失去地址和归属线索。若确需更换地址，先建立新记录，验证展开和连接结果，再决定旧记录的去留；旧凭据失效时，也应在自己的备份中同步标记。
将应用更新、订阅更新与 Config 更新分开理解。应用更新通过 App Store 进行；订阅更新读取服务器列表；Config 的变化影响规则及相关设置。三者发生时间可能接近，但不能据此认定其中一个会自动完成另外两个。排查时写清“更新了什么、更新前怎样、更新后怎样”，比笼统说“更新后不能用”更能帮助定位。应用获取与更新入口可参阅App Store 下载指南。
06 · 多订阅整理：先保留归属，再处理重名
多订阅管理的首要目标是让每条服务器都有清楚的来源，而不是让列表尽可能短。相同名称、相同地区说明或相近延迟，都不能证明两条记录重复。一个订阅中的多台服务器也可能共享地址但使用不同端口、认证或传输设置。清理前应先按订阅归属观察，再对照连接参数，避免误删仍承担不同用途的记录。
建立可持续使用的命名方法
订阅备注可采用稳定的内部标签，例如“日常”“备用”“测试”，再附上自己能识别的来源简称。名称应帮助区分用途，不应承载密码、完整订阅地址或私人身份信息。服务器名称通常来自远端，更新后可能变化，因此不要只依赖某段名称来记住重要记录。对经常使用的服务器，另记它所属的订阅和关键连接特征，迁移时会更容易核对。
不要为整齐而反复重命名订阅生成的全部条目。这样既可能被更新覆盖，也可能破坏自己依赖名称的配置关系。更可控的做法是先整理订阅层级，再保留原始服务器名称；需要测试时，用独立手工记录承载临时说明。名称中出现地区或线路字样，只能作为提供方的标注理解，不能据此认定服务器实际位置、性能或当前可用性。
查重应比较哪些信息
先比较 Type、地址和端口，再检查认证、TLS 名称、传输方式及相关参数。全部相同的记录可能只是重复导入，但仍需确认它们是否属于不同的更新关系。若两个订阅恰好包含同一台服务器，删除其中一个订阅可能同时失去该来源未来的变更信息。判断保留哪一个，应基于自己的管理需求，而不是只看当前列表是否重复。
处理重名时，不要先批量删除再凭印象重建。可以一次选择一个订阅，记录其条目特征，完成核对后再处理下一个。对于已经失效但仍需追踪原因的记录，先保留私密说明，再决定是否删除。列表中的状态说明也应单独辨认：它们可能用于传递账户或使用状态，不能一律按“连不通的服务器”处理，更不应据此推断所有实际服务器都不可用。
| 观察到的情况 | 先核对 | 再决定 |
|---|---|---|
| 名称完全相同 | 归属、Type、地址与端口 | 是否属于不同服务器 |
| 参数看起来相同 | 认证、传输与更新关系 | 是否需要保留两处来源 |
| 更新后出现重名 | 远端变化与旧手工记录 | 是否清理实验副本 |
| 某条测试失败 | 测试方式与网络条件 | 是否暂存而非删除 |
整理列表不等于改变路由
移动顺序、修改备注或删除重复项，主要改变管理方式；实际请求如何处理，还受到 Global Routing 和当前 Config 影响。某条服务器排在最前面，并不代表所有请求都会使用它。设置为 Config 时，命中 DIRECT 的请求仍按规则直连；选择 Proxy 时，也应确认当前选中的服务器就是准备使用的那条。整理完列表后，至少重新确认一次选中状态。
多订阅共存不意味着应用会自动在所有条目中挑选最优服务器。是否存在自动选择或切换行为，要看当前配置和实际使用的相关功能，不能从列表数量推断。为了获得可解释的结果，先用一条明确选中的服务器验证，再考虑更复杂的选择逻辑。不要把测试失败的条目不断复制到不同订阅中，这只会增加重复记录，不会改变服务器端状态。
每次整理完成后，做一个简短的收尾检查：订阅地址仍然保存、重要服务器可以识别、当前选中项正确、独立实验记录有清楚标签。若准备更换设备，再记录所需 Config 与更新关系。习惯上少量、分批整理比一次性大规模清空更容易恢复。名词含义不清时先查术语手册，涉及首次连接的疑问则查使用说明中的排查章节，不要用删除代替理解。
07 · Connectivity Test：理解延迟与排序结果
延迟测试适合初步比较服务器响应，不适合单独判断实际吞吐、长期稳定性或某个网站的访问结果。不同测试方式测量的阶段不同，有的侧重地址或端口可达性，有的包含更多请求过程。查看 Connectivity Test 的当前设置，先知道测量对象，再解释返回值。一个较小的数值不能证明认证正确，也不能保证后续传输能持续完成。
测试前固定条件，测试后保留上下文
比较多条服务器时，尽量使用相同本地网络、相同测试方式与接近的时间窗口。测试中途从 Wi-Fi 切到蜂窝网络，会让结果混入接入网络变化。设备后台任务、信号波动和网络拥塞也会影响结果。第一次测试可以先选少量候选服务器，重复观察后再扩大范围，避免把一次瞬时结果当作永久排名，更不要为了得到更低数字而不断更改无关设置。
批量测试会同时产生多个请求，本地网络或远端处理能力有限时，结果可能比单条测试更不稳定。如果同一台服务器单测正常、批量测试偶尔失败，应先缩小测试范围再复核。若所有记录同时失败，优先检查设备是否正常联网、测试目标是否适合当前环境以及测试方式是否受限，而不是立即认定全部服务器都失效。
区分超时、认证失败与实际请求异常
超时表示本次测试没有在规定等待范围内得到预期结果，但不直接说明失败原因。可能是地址解析、端口访问、传输握手或测试目标响应的问题。若出现明确认证错误，才应重点核对密码、UUID 或其他认证资料。若服务器能够建立连接而某个网站失败，则要进一步看规则命中、目标域名、DNS 和 TLS 等环节，不能继续只围绕延迟数字操作。
验证实际使用时，选择自己熟悉且允许访问的普通页面，分别观察页面能否完整打开、连续请求是否稳定，以及问题是否仅出现在某个目标。不要只看系统显示已连接就结束检查；系统状态主要说明本地连接机制已启用，不代表每个远端请求都成功。也不要只看一个页面缓存内容就认为网络正常，应结合新的请求与应用可见的连接信息判断。
排序用于筛选，不替代选择与验证
按延迟排序后，先确认排序作用于哪个列表，以及当前选中项有没有改变。排列位置变化不必然意味着连接对象改变；同样，最上方的条目也不必然适合所有请求。可以从响应稳定的少量候选中选一条进行实际验证，再保留一条备用记录。记录当时使用的网络条件，比把某个结果记成固定性能标签更有参考价值。
Global Routing 也会影响你如何解释访问结果。使用 Config 时，目标可能命中 DIRECT，因此页面正常并不能单独证明选中服务器可用。若要核对某条代理连接，应同时确认测试目标实际采用的策略。切换姿态只用于明确验证范围，测试结束后再恢复自己需要的配置，避免遗忘临时设置导致后续所有请求的处理方式发生变化。
速度慢与延迟高有联系，但并非同一个问题。小请求响应及时，仍可能在持续传输时受线路拥塞、丢包、服务器负载或本地网络影响。排查时先复核单条服务器，再比较不同时段和接入网络，最后检查协议与传输设置；每一步保留上一轮结果。更完整的分层方法见Shadowrocket 速度慢的四层排查。不要通过持续刷新订阅来代替这套验证过程。
08 · 删除与备份：明确恢复范围
删除前先确认对象是单条服务器、整个订阅，还是 Config 文件。这三类对象影响范围不同：删掉单条服务器可能只改变当前列表，删除订阅则可能连同其管理关系一起移除，删除 Config 则可能影响规则选择。具体关联行为以应用当前操作提示为准。不要在没有备份和验证的情况下连续删除多个层级，也不要把清空列表当作所有连接问题的通用处理步骤。
建立备份清单，而不是只保留一张截图
备份至少应覆盖自己需要恢复的订阅地址、独立手工服务器参数、正在使用的 Config 以及重要偏好设置的说明。截图可以帮助辨认界面，却常常看不到完整密码、密钥和长地址，不能替代原始资料。对订阅而言，保留可用地址有助于重新读取列表；对手工服务器而言，则需要确保认证和传输细节完整，否则只记住名称和端口仍无法恢复。
如果应用当前提供相应导出或备份入口，应先核对导出对象与包含范围，再保存到自己控制的私密位置。不要假定文件名写着备份就一定含有全部资料，也不要假定系统设备备份必然覆盖每个需要的项目。更可靠的做法是在不破坏现有可用环境的前提下检查文件内容或进行受控恢复验证，确认最重要的订阅关系和独立记录确实能够找回。
删除后的条目为何可能重新出现
订阅生成的服务器由远端列表管理，单独删除其中一条后，下一次更新可能再次生成相同记录。这并不一定是删除失败，而是更新重新同步了远端内容。若不再需要某个订阅，应先确认其地址已妥善保留，以及当前连接不再依赖它，再处理订阅记录本身。若只是不想临时使用某条服务器，切换选中项与删除记录的效果不同，不必为了停止使用而立刻清理。
删除前也应检查正在使用的 Config 是否依赖某些服务器名称或相关选择关系。移除一条记录后，原先的规则逻辑不一定自动得到等价替代。删除后重新核对 Global Routing、当前 Config 和选中服务器，再进行实际请求验证。若列表突然异常，先停止进一步操作，查看是否有本地备份或原始订阅可供恢复，避免在同一轮排查中把剩余线索也清除。
换机恢复：先少量验证，再补齐资料
在新的 iPhone 或 iPad 上，先通过 App Store 恢复应用，再检查需要的系统授权；系统要求与购买适用性以 App Store 页面标注为准。应用的已购恢复与订阅、服务器、Config 的恢复是不同任务，找回应用并不等于所有连接资料已经出现。具体获取步骤见已购恢复说明。准备迁移时不要先清空旧设备，应保留它作为字段核对和回退依据。
恢复资料时先导入一个订阅，确认展开结果；再恢复独立手工记录，最后选择需要的 Config 并核对 Global Routing。完成一轮实际连接后，再补齐其余订阅与偏好设置。这样的顺序有助于在出现错误时确定是哪个环节引入变化。如果一开始同时恢复全部资料、调整网络和改动规则，虽然操作较快，却很难判断失败究竟来自备份内容还是新设备环境。
恢复完成后检查选中项、订阅更新、测试方式及实际请求，再决定旧资料如何处理。若怀疑订阅地址或认证曾被公开，应从自己的服务商处取得更新后的信息，并同步修改备份；删除本地副本不能使已泄露的凭据失效。最后保留一份简洁的私密恢复说明，记录资料类别与恢复顺序即可，不要在公开笔记中保存敏感值。下一次需要快速重新连接时，按使用说明验证主线，本页继续承担字段和管理细节的查阅。