01 / Subscribe
Subscribe 入口与订阅首次导入
先分清订阅、服务器与 Config
订阅是一处可重复获取服务器列表的地址，服务器条目是实际建立连接时使用的一组参数，Config 则负责规则、DNS 等配置。三者可以配合使用，但不是同一种文件。添加订阅后出现多个服务器，不代表已经替换当前 Config；导入 Config 后规则发生变化，也不代表订阅地址已保存。开始前先确认拿到的是哪一类内容，能够避免把配置地址放进服务器字段，或把单条分享链接误当成订阅。
订阅链接通常带有访问凭据，完整地址应视为敏感信息。复制时使用原始文本，不要把网页标题、说明文字、引号或换行一起选中。通过聊天记录转发的地址可能经过截断，看到省略显示时不能据此手动补齐。若无法确认完整性，应重新取得原始链接，而不是反复尝试猜测参数。订阅地址从你的服务商处获取，后续步骤均以已有地址为前提。
在 Add Server 中选择 Subscribe
进入 Home，打开添加入口，在 Add Server 的 Type 中选择 Subscribe，再把完整地址填入 URL。为订阅设置便于辨认的名称，名称只用于本地管理，不改变远端内容。保存后检查 Home 中是否出现对应订阅分组和服务器列表；如果只看到分组而没有可选条目，先查看本次获取是否完成，再判断返回内容能否被解析。不要通过连续新建相同订阅来代替检查。
首次导入应先保留现有服务器和配置。已有可用连接时，记录当前选中项和 Global Routing 状态，再添加新订阅。成功保存后，选择一条新导入的服务器进行单独验证，确认连接和网页访问符合预期后再整理旧数据。这样即使新地址返回异常，也可以回到原来的条目，不必同时排查导入、规则和设备网络三种变化。
按结果定位导入问题
保存失败、获取失败和列表为空需要分别处理。保存失败时检查 URL 字段是否完整、是否混入空格；获取失败时检查设备当前网络，以及地址是否仍然有效；获取完成但没有条目时，重点确认服务器返回的内容类型。一个能在浏览器中显示说明页面的地址，不一定就是客户端需要的订阅地址。遇到登录页面或错误说明，应核对地址用途，而不是把页面正文继续粘贴到 URL。
不要只凭条目数量判断导入正确。订阅可能包含不同协议、不同用途或名称相近的条目；部分条目可能因参数不受支持而不能使用。先抽查名称、协议类型、服务器地址和端口是否与已有信息一致，再做实际连接。若所有条目都出现同一种错误，优先检查共同来源与导入格式；若只有一个失败，再检查该条目的参数和远端状态。
订阅导入成功只是建立了本地列表，不代表账户状态、远端服务和实际访问都已经验证。请区分“地址可以获取”“条目可以解析”“服务器可以连接”“目标网站可以访问”四个结果。向服务商反馈时按这四层描述现象，并隐藏链接中的凭据，比只说“订阅不能用”更容易明确问题所在。
02 / Add Server
Add Server 手填字段与协议核对
先确定 Type，再填写共同字段
手动添加适合你已经持有完整服务器参数、需要核对某个条目或保留独立测试副本的情况。进入 Add Server 后先选择 Type，再填写服务器地址、端口和认证信息。协议类型决定后续字段的含义，不能先按一种协议填完再随意切换类型。切换后应重新检查全部选项，尤其是认证方式、传输层和 TLS 设置，避免界面保留的旧值干扰新条目。
服务器地址填写主机名或 IP，不把网页路径和查询参数一起填入。端口只填写对应数值，不附带冒号或协议前缀。名称用于辨认，不参与认证；名称里写了某种协议或传输方式，并不会自动启用该功能。如果拿到的信息只有名称、地址和端口，却缺少所选协议要求的认证字段，应先补齐原始参数，而不是复制另一条服务器的密码尝试。
协议字段不是可以互换的备注
| Type | 重点核对 | 常见混淆 |
|---|---|---|
| Shadowsocks | 加密方法、密码 | 加密方法必须与远端一致 |
| VMess / VLESS | UUID、传输设置、TLS | 不能只凭 UUID 推断其余字段 |
| Trojan | 密码、TLS、服务器名称 | 连接地址不一定等于 TLS 服务器名称 |
| HTTP / SOCKS5 | 认证要求、用户名与密码 | 是否启用认证由远端要求决定 |
| WireGuard | 密钥、地址、Peer 与路由参数 | 不是填写普通密码的连接方式 |
| Hysteria2 | 认证、TLS 及远端指定参数 | 不照搬其他协议的传输设置 |
Shadowsocks 的加密方法与密码共同参与认证，只改其中一项可能仍然失败。VMess 与 VLESS 即使都使用 UUID，也不是同一种协议，不能通过替换名称完成转换。Trojan 的认证信息同样不能由其他协议的字段推算。以服务商给出的完整参数为依据，字段未提供时先确认是否有默认要求，不凭网上另一份示例补出一套看似完整的配置。
启用 TLS 时，要区分“连接到哪里”和“校验哪个名称”。连接地址用于寻找远端，服务器名称用于相应的 TLS 握手与证书校验；两者可能相同，也可能按实际部署分别填写。遇到证书错误，应先核对名称、设备时间和远端证书状态，不把关闭校验当作通用修复。传输层中的 Host、路径等参数也应逐项对应，大小写、斜杠和编码均可能影响结果。
保存后的检查与修改边界
保存后重新打开条目，检查 Type、地址、端口、认证和传输选项是否都保留下来，再发起测试。建议一次只改一类参数，并记录修改前的状态。例如先纠正端口再测试，随后再检查 TLS，而不是同时替换所有字段。若多个项目一并改变，即使恢复连接也无法知道实际原因，下一次出现同样故障仍需从头判断。
从订阅生成的条目与手动条目的维护方式不同。对订阅条目直接改名或修改参数，下一次更新时可能被重新生成的内容覆盖。如果需要长期保留本地调整，应在界面允许的情况下创建独立副本，并明确标记为手动管理。副本不会自动跟随订阅更新，远端更换参数后需要自行核对，这一点应在命名和备份记录中写清楚。
WireGuard 等类型包含多组相互关联的参数，缺少完整资料时不宜用通用示例拼接。密钥和认证字段不要出现在故障截图、公开笔记或分享名称中。讨论字段问题时，只说明字段名称、是否填写及错误现象；需要比对原值时，通过你与服务商已有的可信渠道完成，不向公共页面提交完整连接信息。
03 / Scan QR Code
扫码与剪贴板导入的检查顺序
二维码只是文本的另一种载体
Scan QR Code 读取的是二维码编码的文本，并不会自动判断内容是否适合当前用途。二维码可能包含单条服务器分享链接、订阅地址，也可能只是普通网页地址。扫描前确认它来自你已有的服务器资料；扫描后先查看进入的是服务器编辑页、订阅编辑页，还是其他提示。不要因为图案能被识别，就默认其中一定包含完整的连接参数。
使用相机扫描时，按系统提示授予所需权限，把二维码完整放入取景范围，避免边缘裁切、强烈反光或屏幕闪烁。先调整距离和清晰度，不反复切换不同设置。若从图片读取，则使用原始清晰图片，聊天工具压缩过的小图可能使密集编码无法识别。能够查看图片不代表二维码仍然具有足够的可读细节。
识别之后仍需检查保存结果
扫码成功后，检查 Type、服务器地址、端口和名称是否合理，再保存并回到 Home 确认条目实际出现。如果二维码表达的是订阅，检查是否形成对应分组，而不是只生成一条名称相同的服务器。二维码本身不会持续更新；真正能够更新的是其内部保存的订阅地址。含有固定服务器参数的二维码，之后远端变更不会自动反映到本地。
相同二维码重复扫描可能产生重复条目。第一次没有立即看到结果时，先返回列表查看、展开相关分组并检查排序位置，再决定是否重试。不要把“新条目不在列表顶部”误判为保存失败。若列表已经有同名服务器，进一步对照地址、端口和协议，名称相同可能是重复，也可能是两个独立条目，需要结合参数确认。
剪贴板导入保留原始结构
从已有资料复制分享链接后，回到客户端，使用实际界面提供的剪贴板导入入口；系统出现粘贴访问提示时，根据本次操作决定是否允许。若客户端没有识别到内容，先确认复制的是完整链接，而不是网页上可见的标题或被缩短的显示文字。不要在包含凭据的链接中间手动插入空格，也不要通过重新排版来提高可读性。
一次复制多条链接时，应保留原来的逐行边界。编号、项目符号、中文说明和代码围栏可能被一并复制，导致部分内容无法识别。稳妥的方法是先导入一条确认格式，再按界面支持的方式处理其余内容。部分导入成功时，记录成功与失败的范围，不把整份文本反复导入，以免成功的条目被重复添加。
扫码失败与导入失败的排查方向不同。前者先看权限、清晰度和图案完整性，后者先看识别出的文本种类与参数完整性。若同一链接通过复制可以导入，而二维码读取失败，问题更可能在载体质量；若两种方式都解析失败，则应回到原始资料核对链接格式。更换载体不会修复其中已经缺失的字符。
减少凭据在载体之间扩散
二维码图片和剪贴板文本都可能包含完整认证信息，不能把它们当作普通说明截图。不要为了展示操作步骤，把真实二维码放进公开相册或论坛；导入结束后，可用不含敏感信息的普通文本替换剪贴板内容，并按自己的资料保管习惯处理图片。清理一个位置不代表其他设备的同步副本也已经消失，应检查实际使用的同步范围。
如果导入入口没有出现，先核对当前处于 Home 还是其他页面，再查看设备上的添加菜单，而不是套用别处截图中的固定按钮位置。无法识别的内容应保留原始副本以便核对，但不要连续修改编码后碰运气。需要第一次完整连接流程时，回到快速上手教程继续；扫码只是录入手段，后续仍需选择服务器、检查姿态并验证访问。
05 / Update
订阅更新策略与失败处理
更新是重新获取，不是逐项修补
订阅更新会再次请求已保存的地址，并按返回内容刷新对应服务器列表。它不是只检查当前选中的一条服务器，也不等于更新应用本身。远端可以调整名称、参数、顺序和条目数量，因此更新后列表变化是可能的。应用更新通过 App Store 管理；订阅列表更新发生在客户端内，两种操作解决的问题不同，不应混为一谈。
在界面提供的订阅操作菜单中执行更新前，先确认作用对象是某一订阅还是全部订阅。若正在排查单个来源，优先只更新该订阅，保留其他分组作为对照。记录更新时间、更新前后条目是否变化以及出现的错误提示，这些是本次操作的观察信息，不需要公开完整地址。更新完成后还应检查当前选中项是否仍然存在。
手动刷新与自动更新如何分工
手动刷新适合首次导入、远端通知变更、列表明显陈旧或需要确认故障的情况。自动更新适合已经验证稳定、需要跟随远端列表变化的订阅；具体开关和间隔以应用实际提供为准。间隔不是越短越好，频繁获取既不能修复无效地址，也可能增加远端请求压力。没有明确变更时，不需要靠连续刷新保持连接。
设备锁屏、系统后台调度、当前网络和应用运行状态都可能影响自动更新的实际执行时机。设置了更新间隔，不代表设备会在每个时刻精确完成请求。发现列表没有变化时，先查看是否真的执行过获取，再判断远端是否返回新内容。必要时前台手动更新一次，观察明确结果，不仅凭自动更新开关处于开启状态下结论。
按请求、响应与解析分层排查
请求无法完成时，先检查设备网络是否正常，再确认地址是否完整和仍然有效。不要先删除现有可用条目，也不要反复更改 DNS、Global Routing 和订阅地址。保留当前配置，逐项改变一个条件并记录结果。某个网络下失败、另一个网络下成功，可以帮助缩小范围，但仍需结合错误提示判断，不直接推断远端已失效。
如果出现明确的 HTTP 状态错误，应记录状态与发生时间。认证相关响应通常需要核对地址中的凭据和账户权限；请求过于频繁时应停止密集重试；远端服务错误则需要由相应服务端进一步检查。状态码只能说明一层结果，不能单独证明本地服务器参数错误。反馈时隐藏查询参数中的敏感部分，保留足够的错误上下文。
请求成功但解析失败时，检查返回内容是否变成登录页面、维护说明或空响应。能够打开地址不代表响应就是服务器列表；名称保留但条目清空，也不代表所有服务器同时故障。如果地址在有效期或授权范围上发生变化，应以服务商给出的最新资料核对，不通过复制旧页面正文或修改编码来绕过格式问题。
更新后的验收与本地修改
更新成功后，至少检查选中项、协议类型和一项实际访问。正在使用的服务器若被远端移除，应明确选择替代条目，不假设应用会按原名称找到同一对象。存在本地改名或参数修正时，要检查这些改动是否被覆盖；需要长期保留的调整应放在清楚标记的手动副本中，并接受它不会跟随订阅自动变化这一维护边界。
单次失败不需要立即重建所有订阅。保留已有可用列表，在合理间隔后重试，并核对服务商给出的状态信息。若只有订阅获取失败而现有服务器仍可连接，可以分别记录这两个结果；若列表更新正常但连接失败，则转向延迟与连接验证检查。把获取与使用分开描述，可以避免在错误层面不断重复操作。
06 / Groups
多订阅分组、命名与重复条目整理
按维护来源分组，再按用途辨认
多订阅管理首先解决“这条服务器由谁更新”的问题，而不是先追求列表短。保留每个订阅独立的分组，名称可使用自己的用途标记或资料名称，不把访问凭据写进名称。手动添加的条目与订阅生成的条目也应能够区分。这样遇到参数变化时，可以准确选择更新某个订阅，或编辑某个独立条目，不误改整组数据。
命名应表达稳定信息，例如日常使用、临时核对、手动副本；不要把一次测试的数值写进长期名称，因为网络结果会变化。远端提供的服务器名称可能在更新时被恢复，如果需要本地说明，优先使用实际界面支持的备注方式，或把说明放进自己的管理记录。不要依赖订阅内的手动排序作为唯一的用途标识。
判断重复不能只比较名称
两个条目名称相同，可能使用不同地址、端口、认证或传输设置；两个名称不同的条目，也可能实际上指向同一连接参数。清理前先对照 Type、地址、端口、认证方式以及 TLS 和传输选项。含有不同认证信息的条目即使连接到同一主机，也可能对应不同权限，不能因为地址相同就认定其中一个可以删除。
重复的常见来源包括反复扫码、同一分享链接多次粘贴、相同订阅被重复添加，以及为了测试建立的手动副本。先辨认重复来自导入操作还是远端列表，再选择处理方式。本地反复添加造成的重复可以整理；远端订阅本身包含的相似条目，下一次更新可能重新出现，此时逐条删除并不能形成稳定的长期结果。
排序服务于当前任务
整理时先保留分组边界，再在当前范围内查看名称或测试结果。按延迟排序适合当次比较，按名称排序适合寻找固定条目，手动顺序适合自己维护的小规模列表。每次改变排序后检查当前选中项，不要只记住“列表第一条”。远端更新或筛选条件变化后，同一位置可能已经对应另一台服务器。
当列表很多时，可以先只检查当前正在使用的订阅，其余分组保持原样。每次完成一组的命名、核对与验证后再处理下一组，避免批量整理导致所有线索同时变化。如果界面支持搜索或折叠分组，用它缩小查看范围；这些操作通常只是改变显示，不等同于删除。确认操作作用范围后再执行涉及内容移除的动作。
给本地记录建立最小账目
建议记录订阅显示名称、是否自动更新、是否存在手动副本、最近一次实际核对的结果。记录中不必重复保存完整认证信息，只需帮助自己知道去哪里查原始资料。若确实需要保存原始地址，应放在受控的个人资料中，并与普通操作记录分开。名称、更新时间和测试数值都不能替代原始恢复资料。
整理前确认 Config 是否按服务器名称或策略组引用了相关对象。删除或改名可能让原有引用不再符合预期，尤其是手动维护的策略选择。订阅分组与配置中的策略组不是同一个概念：前者用于管理来源，后者用于决定连接策略。把服务器放进某个订阅分组，并不自动让某条规则开始使用它，仍需检查当前配置。
批量删除前，先保留一份可恢复资料，并选少量已确认的重复项做一次试操作。返回 Home 检查其余条目和当前选择，再决定是否扩大清理范围。如果无法从界面确认一项操作会影响单条还是整组，就先取消。整理的目标是减少歧义，不是把所有订阅合并成无法追溯来源的一长列服务器。
关于多个已有订阅的具体整理顺序，可阅读多个订阅的分组、排序与重复条目清理。完成整理后保留一条明确的日常使用路径，以及一份可查到原始资料的记录，比依赖固定的列表位置更适合后续更新和换机恢复。
07 / Connectivity Test
延迟测试、排序与实际连接验证
先明确测试测量的对象
Connectivity Test 用于观察所选测试方式下的响应情况。不同测试方式覆盖的阶段不同，有的主要反映到服务器的连接过程，有的还涉及指定测试目标的请求。结果应结合当前设置解释，不能把一个数值直接等同于所有网站的打开速度。测试目标、设备网络和测试时刻不同，结果也不宜放在一起直接比较。
测试前先确认设备本身可以正常联网，并检查当前连接姿态和所选服务器。要比较多条服务器时，尽量使用相同网络、相同测试方式与相同目标，在较接近的时间完成。不要一边切换网络一边比较数值，也不要把 Wi-Fi 下的一次结果与另一网络下的结果混排后得出稳定性结论。测试条件越一致，比较才越有意义。
数值、超时与波动分别说明什么
较小的数值说明这次测试响应较快，不保证大文件传输、长连接或特定应用都更好。超时只说明在本次条件和等待范围内没有完成测试，可能涉及服务器、测试目标、解析或网络路径。若只有少量条目失败，可以对照成功条目排查；若全部失败，应先检查共同条件，不急于逐个重填所有服务器参数。
单次异常应复测，但不需要持续高频测试。网络短暂拥塞、设备切换连接或远端负载都可能造成波动。可在条件稳定后再次测试，观察结果是否持续一致。对于日常使用，稳定完成实际请求通常比某一次最低数值更有参考价值。测试结果应作为选择依据之一，而不是自动排除其他条目的唯一标准。
按层验证真实访问
选择服务器后打开连接开关，按系统提示处理 VPN 配置授权，再使用一个自己熟悉的普通网页或应用验证。系统显示连接已建立，只代表设备上的相应连接状态，不保证远端认证、规则命中和目标响应全部正常。应分别观察客户端连接状态、错误提示和实际请求结果，不把开关保持开启当作连接已经完全可用的证明。
在 Global Routing 为 Config 时，测试目标可能按规则走 DIRECT，因此“网页可以打开”也不一定证明所选服务器正在承载该请求。检查当前配置的相关规则和可用的连接记录，确认目标命中的策略。需要临时改变姿态进行对照时，先记住原值，完成测试后恢复；不要为排查一个问题而长期遗忘原来的分流设置。
如果延迟测试正常但网页打不开，继续区分域名解析、服务器认证、规则走向和目标站点响应。先用相同服务器测试不同普通目标，再对照设备网络，逐步缩小范围。DNS 故障需要检查解析设置，不是持续刷新订阅。相关检查可参阅延迟正常但网页打不开的 DNS 排查，避免同时重建订阅和覆盖 Config。
排序后的选择仍需人工确认
按测试结果排序只改变查看顺序，不必然改变实际使用的服务器。排序完成后确认选中标记对应哪一条，再建立连接。更新订阅、切换分组或重新测试都可能改变列表位置，不能靠“第一条”或“第三条”描述固定服务器。记录问题时使用经过脱敏的名称和类型，比使用位置更容易复现。
只有某个应用失败时，先查看该应用相关规则、域名和连接记录，避免把局部问题归因于整个订阅。只有某个服务器失败时，再检查其参数和远端状态。对照测试每次只改变一个条件，并保留时间、测试方式、错误类别和结果。这样的记录可以区分持续故障与短暂波动，也能减少反复修改已验证正确设置的次数。
08 / Backup & Restore
删除、备份与新设备恢复顺序
先确认删除对象和影响范围
删除单条服务器、删除订阅分组和删除 Config 是不同操作。删除单条订阅条目后，它可能在下次更新时重新出现；删除订阅后，本地可能失去用于后续获取列表的地址；删除 Config 则影响规则和相关配置。执行前查看确认提示，明确对象和范围。不要把清空列表当作处理连接问题的第一步，也不要在缺少原始资料时批量删除。
从客户端移除订阅通常只是改变本地保存内容，并不等于注销远端访问权限。若真实地址或认证资料已经泄露，应通过服务商提供的管理方式撤销或更换相应凭据，再更新本地记录。只删除一张二维码图片、一个服务器条目或某份导出文件，不能使已经被别人取得的凭据失效，处理泄露与整理列表需要分开进行。
备份要覆盖不同层的数据
可恢复资料至少应区分订阅原始地址、手动服务器参数和当前 Config。订阅可重新获取当时远端提供的列表，但未必能找回你之前手动修改的名称和参数；配置文件可保留规则，但不一定包含全部服务器或订阅记录。导出某一类内容后，先检查它实际覆盖什么，不仅凭文件名称判断备份已经完整。
通过应用实际提供的导出或分享入口保存资料时，注意接收位置和访问权限。包含凭据的导出文件应放在自己控制的受保护存储中，不作为普通附件长期散落在聊天记录。备份名称可以记录设备和用途，不写完整密码。完成后确认文件能够读取、内容类型正确，并保留与之配套的恢复说明，避免只剩一个无法辨认的文件。
换机先恢复应用，再恢复资料
新 iPhone 或 iPad 上先通过 App Store 获取 Shadowrocket。已购项目、账号和购买适用范围的检查见已购恢复说明，系统要求以 App Store 页面标注为准。恢复购买只处理应用获取，不会自动补齐所有本地服务器参数。应用能够打开后，再按自己的备份内容恢复订阅、手动条目和 Config，而不是假设它们必然一起出现。
如果使用应用提供的 iCloud 相关同步功能，应先在两台设备上核对实际同步范围和完成状态。系统账号已登录，不代表每一类应用数据都已同步；看到 Config 也不能推断所有手动服务器已经恢复。旧设备保留到新设备验证完成，在确认来源与内容一致前不要同时手动导入和反复触发同步，以免产生重复或难以辨认的副本。
建议先在新设备恢复已有订阅并获取列表，再恢复需要单独维护的手动条目，随后导入并选择 Config，最后检查 Global Routing。若配置引用了具体名称或策略组，核对这些对象是否实际存在。建立连接后验证普通访问，再检查重要应用的规则走向。恢复的验收标准是可用且符合原有设置，不只是列表看起来与旧设备相似。
验证完成后再清理旧资料
迁移后先保留旧设备和原始备份作为对照。确认新设备可以更新订阅、使用手动条目并正确应用配置，再决定如何处理旧资料。若旧设备仍需使用，清理前先理解同步删除的影响，避免在一台设备上的整理传播到其他设备。不要在迁移过程中同时重命名所有对象、替换规则和更换订阅地址，否则难以定位差异来源。
定期复核备份是否仍能对应当前实际设置，尤其是在更换订阅地址、手动调整认证或修改 Config 之后。无需为每次测试保留大量重复副本，但应保留一份明确可恢复的基线和必要的变更记录。旧凭据失效后，相关备份也要纳入清理范围，防止下一次恢复时误用陈旧参数，再把历史问题重新带回设备。
更完整的设备迁移步骤可参阅换机迁移配置与新设备恢复。需要重新走一次连接主线时，返回快速上手教程；需要复核购买入口时，查阅正版三要素核验。管理流程最终应形成闭环：资料来源明确、更新对象明确、实际使用经过验证，并且保留能够恢复的个人备份。