Shadowrocket
订阅与服务器管理

01 Subscribe：建立可更新的订阅

先分清订阅、服务器条目与 Config

订阅是一个返回服务器资料的远程地址，服务器条目是解析后显示在本地的连接记录，Config 则负责规则与相关连接设置。三者有关联，但不能互相替代。导入订阅后看到一组服务器，只能说明资料已经进入客户端，不能证明当前规则已将请求交给该组服务器，也不能证明远端账号仍有使用权限。开始前先确认手中的内容究竟是订阅地址、单条分享链接，还是配置文件地址。

本章以你已经持有自己的订阅为前提。准备时应保留完整链接，以及服务商提供的格式说明；如果另有账号状态页面，可先核对订阅是否仍有效。不要根据链接里包含的单个英文单词判断用途，有些订阅路径没有明显后缀。订阅地址通常携带访问凭据，应按密码资料保管。下列地址仅为教学示例，不能用于实际连接，也不代表可用服务。

https://example.com/sub?token=xxxx

在 Add Server 中保存 Subscribe

1. 从 Home 进入添加入口，打开 Add Server，在 Type 中选择 Subscribe。
2. 将完整订阅地址填入 URL，为 Remarks 填写便于辨认的名称，再保存。具体可见字段以当前应用界面为准。
3. 等待首次获取结束，返回列表检查是否出现归属于该订阅的服务器条目。需要再次获取时，使用该订阅对应的更新操作。

名称建议表达用途，例如“个人订阅·日常”，不必在名称里重复完整链接。保存前检查地址开头、问号后的查询参数和结尾是否完整，尤其注意从聊天消息复制时混入的空格、换行或中文标点。二维码、浏览器页面标题和订阅地址不是同一个对象；把展示页面的网址填入 URL，可能只会取回网页正文，而不是服务器数据。

首次获取后的验收顺序

先核对分组名称，再抽查一条服务器的 Type、Address 和 Port，确认返回内容与自己的资料相符。订阅条目数量可能随远端维护改变，不能把“数量更多”作为导入正确的判断标准。若名称显示正常但列表为空，应区分请求失败、返回空内容和内容格式无法解析。此时先保留原订阅，记录错误提示，不要通过连续删除和重建覆盖现场。

首次请求失败不一定是链接失效，也可能是当前网络无法访问订阅地址、远端临时不可用，或返回了登录页面。若已有可用记录，先保持其状态；若完全没有服务器，可在当前网络与另一可信网络下各验证一次，避免反复切换多个设置后失去比较基准。相关分支见订阅解析失败或节点为空的自查说明。

完成本章后，应能够指出订阅父项、它所管理的服务器和当前选中的连接条目。若只看见独立服务器而没有可更新的订阅关系，可能导入的是单条分享链接。不要仅凭显示名称推断它会自动更新；下一次维护前，先确认该条目是否确实属于 Subscribe。

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

按协议选择表单，不按名称猜参数

手填适用于已经掌握完整服务器参数的情况。进入 Add Server 后，应先选择 Type，再填写该协议需要的字段。不同 Type 的认证方式、传输选项和加密设置不相同，切换类型后不要假定原字段仍保持原来的含义。服务器名称只是标签，即使名称包含 Trojan 或其他协议词，也不能替代资料中明确给出的协议类型。

Address 一般填写主机名或 IP 地址，Port 填写服务端监听端口。若主机名与端口由资料分开给出，不要把协议前缀、网页路径或查询参数一并放入 Address。对于 IPv6，应按当前字段的输入要求处理地址，不要自行把分享链接中的方括号与端口写法搬进所有表单。端口应与服务端一致，不能因常见示例使用某个端口就直接套用。

认证、TLS 与传输层分别检查

Shadowsocks 的密码与加密方法需要配套；VMess、VLESS 常见 UUID 认证；Trojan 使用相应的密码认证。WireGuard 的密钥、地址及对端配置又是另一组结构，不能把它当作只需地址和密码的表单。Hysteria2 也应按自己的服务端资料填写认证与传输参数。本页列出的是核对路径，不表示每种协议的所有选项都能互换。

TLS 相关字段应按资料保留。SNI 用于 TLS 握手中的服务器名称，连接目标 Address 与证书所对应的名称可能不同，因此不能看到两个域名就认定重复。证书错误应优先检查域名、设备时间、服务器证书与传输设置，不要把跳过证书验证当成通用修复。这样做可能掩盖真正的地址或证书问题，也会改变连接的验证边界。

使用 WebSocket 等传输时，Host 和 Path 可能影响服务端路由。Path 的斜杠、大小写和查询参数都可能有意义，不能凭外观简化；Host 也不必与 Address 完全相同。对于未提供的字段，保留适当默认值比随意补入其他示例参数更合理。只有资料明确要求时才修改，并把每一次修改与对应结果记在一起。

保存后进行单变量验证

首次保存建议使用容易辨认的 Remarks，并把手填条目与订阅条目区分开。先确认能够保存和选中，再做一次测试及实际访问。如果失败，每次只调整一组有依据的参数，例如先纠正端口，再检查认证，最后检查传输。一次同时改动 Type、TLS、Path 和 DNS，即使偶然恢复，也无法说明究竟是哪项产生作用。

如果相同服务器的分享链接能够导入，而手填条目不能使用，可以并排核对字段，但不要公开完整凭据。重点比较认证字符、TLS 状态、SNI 和传输参数，而不是只比较名称。资料不完整时应向自己的服务商确认缺失字段；客户端无法从一个主机名推导出正确密码、UUID 或服务端监听方式。

手填条目通常不会随原订阅更新而自动修正。若它原本是从订阅记录复制后调整的，应在备注中标明“手动”，并保留修改原因。远端更换端口或凭据时，要分别复核手填副本，避免列表里仍存在旧参数却因名称相同而被误选。

03 Scan QR Code 与剪贴板导入

先识别载荷，再选择导入方式

二维码与剪贴板只是承载文本的方式，并不决定文本的用途。一张二维码可能包含单个服务器分享链接，也可能包含 Subscribe 地址或普通网页地址。扫描成功只说明二维码内容被识别，不能证明其中的服务器参数完整、订阅有效或数据可信。导入前应清楚它对应的是你已有的哪一份资料，导入后仍需检查最终进入了哪个分组。

使用 Scan QR Code 时，把二维码完整放入取景范围，避免边缘被裁掉、屏幕反光或图像过度压缩。首次使用相机功能，系统可能请求相机访问权限；应在主动扫码时按需要授权。若二维码已经保存在设备上，是否支持直接从图像读取以及入口位置，以当前界面为准。不要为了解码方便把含凭据的图像提交到外部识别页面。

扫码后的检查不能省略

1. 确认识别结果属于预期资料，尤其核对是单个服务器还是订阅。
2. 如出现编辑或确认页面，检查 Type、Address、Port 和 Remarks，再保存。
3. 返回 Home 找到新增记录，检查所属分组，随后才进行测试和选择。

摄像头对焦失败与服务器无法连接是不同层级的问题。前者应调整光线、距离、图像清晰度，后者才进入参数和网络排查。若扫码后提示内容不支持，先核对载荷格式，不要反复重新拍摄同一张清晰二维码。服务商提供的二维码有时只指向一个展示页面，应使用其中明确给出的客户端资料，而不是把网页跳转误认为节点导入。

剪贴板只复制一份完整资料

从自己的资料中复制链接时，尽量使用专门的复制操作，避免连同说明文字、引号和句末标点一起选中。回到 Shadowrocket 后，通过当前界面提供的剪贴板导入方式处理；若系统询问是否允许粘贴，确认是刚才主动复制的内容后再继续。不要在还未核实剪贴板内容时连续确认多个弹窗，以免导入上一次复制的旧记录。

多行资料应先确认应用支持相应的批量格式。把数条不同协议链接、说明段落和订阅地址混成一段，不一定能被当作预期的集合处理。稳妥做法是先用单条记录验证流程，再处理明确支持的批量内容。如果只成功导入其中一部分，应逐条比较原始文本，而不是把全部内容再次粘贴，造成可用条目重复出现。

遇到截断时，重点检查链接末尾的名称部分与查询参数是否还在。有些编辑器会把长行视觉换行，这不一定代表实际插入换行；另一些传递方式则确实改变了原文。可以在设备本地查看文本边界，但不必把完整凭据复制到多个笔记或共享文档。需要比对时优先比较字符位置和字段是否存在，而不是到处保存副本。

若同一份资料已经通过 Subscribe 导入，再扫码导入单条记录，通常会形成另一份独立记录，而不是自动并回订阅。它可能不会随订阅更新。导入前先检查列表中是否已有该条目；导入后若只是临时验证，应给副本加明确备注，测试完成后按备份与删除章节处理。

最后把“资料导入成功”和“系统连接已建立”分开确认。新增列表记录不等于已经打开连接开关，系统 VPN 配置授权也不是相机或粘贴权限。只有在主动建立连接时才处理相关系统授权，再通过实际访问验证结果，避免把几个不同权限步骤混成一次导入失败。

04 分享链接：格式、编码与配置边界

链接前缀决定解析方向

服务器分享链接通常以协议相关的 URI 前缀开头，例如 ss://、vmess://、vless:// 或 trojan://。前缀之后可能直接排列认证、地址和参数，也可能是经过编码的结构化内容。因此，不同协议的链接不能用同一套拆分方法处理。尤其不能只替换前缀，就期待把一种协议转换成另一种协议。

以下内容用于观察字段位置，密码与域名都是教学假值，不能用于实际连接。Trojan 示例中的认证信息在地址前，问号后是参数，井号后是备注。VLESS 示例使用示例 UUID。真正使用时应保留自己的完整原文，并确认服务端要求的传输参数；链接结构看起来完整，并不等于服务器确实接受其中的设置。

trojan://[email protected]:443?security=tls&sni=example.com#example-trojan

vless://[email protected]:443?encryption=none&security=tls&type=tcp&sni=example.com#example-vless

不要反复解码或手工拼接

URI 中的某些字符具有分隔意义，认证或名称里的特殊字符可能需要百分号编码。编码后出现的百分号序列不是可以随意删除的杂字符；重复解码也可能把原本属于字段内容的字符变成新的分隔符。若链接由服务商提供，优先使用原始复制内容，不要为了让它“看起来更短”而删去参数、补空格或改写大小写。

VMess 等分享形式可能包含 Base64 编码内容，但 Base64 不是保密措施，只是编码方式。知道一串字符能被解码，并不代表应该把结果粘贴到公开页面。还原后得到的认证资料仍然属于敏感信息。对于无法解析的内容，应先核对前缀、完整性和格式支持情况，再检查字段，而不是连续套用多个编码转换操作。

备注往往位于链接末尾，通常不承担认证作用，但不能据此认为末尾都可删除。井号之前的查询参数可能控制 TLS、SNI、传输类型或路径，删去后可能仍能导入，却无法按原来的方式连接。如果导入后的表单与预期不一致，应比较原始链接和应用解析后的字段，重点检查这些参数有没有被截断或忽略。

服务器分享与 .conf 不是同一层资料

单条分享链接主要描述一条服务器连接；Shadowrocket 的 .conf 可承载规则等配置。下面是规则章节的教学片段，展示按顺序匹配的基本结构，并非完整连接资料。复制该片段不会生成服务器，也不会替代订阅。使用前还要确认所需策略在自己的配置与连接环境中具有正确含义。

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

DOMAIN-SUFFIX 匹配域名后缀，GEOIP 依据目标 IP 的归属信息参与判断，FINAL 处理此前未命中的请求。规则从上到下匹配，前面的宽泛规则可能让后面的细分规则没有机会生效。排查服务器时如果把请求交给 DIRECT，就不能用该次访问结果证明代理服务器是否正常；这也是导入与分流需要分开核对的原因。

对分享链接最可靠的验收不是“能够粘贴”，而是导入后得到的协议、认证和传输字段与原资料相符。字段缺失时，应确认分享格式是否确实包含它、当前解析是否支持它，再决定是否按资料手工补齐。不要在不理解字段作用时借用另一条服务器的参数，否则会把原本可复现的问题改成新的混合配置。

需要转移自己的资料时，先确认分享的是单条服务器、订阅地址还是整个配置。三者包含的范围不同：单条记录不携带完整订阅更新关系，规则片段也不一定携带所有引用对象。传递前写清资料类型与用途，接收后再做字段核对，比只发送一个没有说明的长字符串更容易发现遗漏。

05 更新策略：保留现场，再验证变化

更新订阅与更新应用分开进行

订阅更新是重新请求远端服务器资料；应用更新则通过 App Store 完成，两者不是同一个过程。某次订阅更新失败，不代表需要立刻更新应用，也不能仅凭应用已更新就认定订阅已刷新。日常维护时，应先确定要解决的是远端资料变化、连接故障还是客户端操作问题，再选择对应动作，减少不必要的变量。

执行更新前，先确认当前网络能访问订阅地址，并记录当前选中的服务器及可用状态。远端可能调整名称、地址、端口、认证或条目数量，本地列表会相应变化。不要假定更新总是只增加新记录，也不要把保留旧记录当作所有情况的固定行为。对重要手填调整，应先备份，因为订阅管理的数据可能在刷新时被远端结果覆盖。

选择更新时机与更新范围

手动更新适合在收到自己服务商的变更说明、发现条目失效或需要核对资料时进行。若当前界面提供自动更新相关设置，应根据自己的网络条件与使用频率配置，并在一段时间后检查实际结果。自动化不能替代验收：网络不可达、账号状态变化和返回格式异常，都可能导致预期的更新没有完成。

不建议为了排查一次连接失败而连续触发所有订阅更新。多个请求同时失败时，难以区分公共网络问题与某个订阅自身的问题；远端也可能对频繁请求作出限制。更清楚的方法是先更新一个相关订阅，核对错误与列表变化，再处理其他订阅。若正在依赖某条连接完成重要操作，先保留可用状态，选择合适时机维护。

用结果而不是按钮状态判断成功

更新结束后，至少抽查一条预期有变化的记录，确认字段确实刷新。按钮恢复可点或加载图标消失，只能说明操作结束，不能单独证明返回内容正确。如果服务商明确更换了端口，而本地仍是旧值，应确认更新的是正确订阅、链接指向正确资料，以及远端是否已经发布了变化，不要立刻反复重建所有记录。

部分订阅会附带用量或到期信息。这类信息来自远端，客户端负责展示，不等于客户端独立核实了使用额度。若显示缺失或与服务商记录不一致，应分别确认返回头或资料内容与账号状态。不要根据一个名称中的日期推断权限，也不要把旧显示当成续期已经生效的凭据。

更新后原先选中的条目可能被重命名、替换或移除，随后应重新确认选中项，并做一次真实访问。若配置规则引用了自定义名称或策略，还需检查引用是否仍有效。数据刷新成功但访问路径改变，常常属于引用与选择问题，不是订阅请求本身失败。相关分流背景可查阅Global Routing 三种模式的区别。

如果远端资料已经确认有误，应等待其纠正，而不是在客户端中逐项猜参数。临时手填的可用条目可以单独标记，避免下一次更新时误以为它仍受订阅管理。恢复后再清理临时副本，把长期维护关系重新收敛到清楚的订阅与少量手填记录。

06 多订阅整理：名称、归属与规则引用

以订阅归属建立清晰的层次

多订阅管理的目标是知道每条记录从哪里更新、为什么保留、当前是否仍在使用，而不是让列表尽可能长。建议先为每个 Subscribe 父项设置稳定别名，再保留远端条目的原有辨认信息。别名可以表达个人用途或资料类别，不应包含完整凭据。即使两个订阅返回相同服务器名称，也应能够通过所属分组区分它们。

订阅别名与服务器 Remarks 承担不同作用。父项用于识别更新来源，子项用于识别具体连接目标；手填副本则应额外标明其维护方式。可以采用“个人订阅·日常”“个人订阅·备用”“手动·测试”这样的标签逻辑，但不要把标签中的“备用”误当成自动故障切换已经配置完成。名称只是管理提示，实际选择仍取决于当前设置。

重复条目不能只按显示名称删除

两个记录同名，不一定指向同一台服务器；地址相同，也可能使用不同端口、认证或传输。判断是否重复，应依次比较所属订阅、Type、Address、Port 和关键传输字段。认证只在本地核对，不必为了比对导出到公开表格。若两个订阅各自维护同一目标，删除一个本地子项后，它还可能在下一次刷新时重新出现。

因此，应先决定是否仍需保留对应订阅，而不是不断删除它管理的重复子项。如果同一订阅确实被重复添加，确认哪个父项承载当前使用关系，备份后再移除多余父项。若只是测试时产生的独立副本，先确认其没有被当前规则或选择引用，再删除。清理应分批进行，每批后做一次访问检查，避免一次清空后无法还原依赖关系。

不要把列表排列当成分流策略

服务器列表的显示顺序主要服务于查找。把某条记录移到顶部，并不必然让全部请求使用它；按名称排序，也不会自动建立优先级与故障转移。真正影响请求去向的还包括 Global Routing、当前选中服务器，以及 Config 中的规则和策略引用。整理列表后应检查这些实际设置，不要仅凭第一行名称判断当前连接路径。

如果自定义配置引用具体名称，重命名前应先查看引用方式。有些配置通过明确名称指向对象，另一些通过筛选表达式组织对象，两者受名称变化影响的方式不同。远端更新也可能改变原名。维护时应让命名规则与配置引用保持一致；不能仅因修改名称后列表仍存在，就认定所有规则关系都已自动同步。

名称筛选应尽量明确，避免过于宽泛的关键字把无关记录纳入。远端命名不是永恒不变的接口，依赖名称中的地区、符号或编号时，更新后应抽查筛选结果。一个空的候选集合或意外扩大的集合，可能影响策略选择，即使所有服务器本身都能连接。此时要排查集合与引用，而不是重复修改服务器认证。

长期不用的订阅可先评估其是否仍需保留，清理前保存必要的恢复资料。不要把失效状态、暂时不可达和不再需要混为一谈：前两者是故障判断，后者才是管理决定。先确认用途再删除，能避免为了让列表整齐而意外移除仍在使用的备用资料。

07 Connectivity Test：延迟、排序与实际访问

先说明测试测到了哪一层

Connectivity Test 的结果需要结合测试方式理解。TCP 类测试主要观察到服务器端口的建连情况，HTTP 类测试还涉及指定目标与相应请求过程；不同方式不能直接混在一起比较。某个端口能响应，不等于认证、TLS、代理转发和目标网站全部正常。测试失败也不一定意味着服务器永久不可用，应先确定失败发生在哪个层级。

测试前检查 Settings 中当前采用的相关测试方式与目标，具体可见设置以应用界面为准。比较多条服务器时，尽量保持网络、目标和测试方式一致。移动网络与无线网络、不同时间段以及设备所处信号环境，都可能影响结果。若每条记录在不同条件下测试，即使数字看起来整齐，也不具有可靠的横向比较意义。

一次测试结果不能代表长期质量

延迟反映的是特定条件下的一次或一组往返耗时，不等于下载速度、持续吞吐或长连接稳定性。最低数字可能来自距离较近的入口，但后续目标访问仍有其他路径与负载因素。管理时可以把测试作为候选筛选，再用真实业务验证，而不是只保留数字最低的一条，立即删除其他仍有用途的记录。

出现超时时，先抽选一两条复测，避免立即对全部订阅反复执行批量测试。大量并发测试本身会产生连接请求，也可能受到当前网络或远端限制的影响。若所有条目在同一时间失败，优先检查公共网络、测试目标与当前设置；若只有某一条稳定失败，再集中核对其 Address、Port、认证和传输，范围会更清楚。

排序用于查找，访问用于验收

按延迟排序后，留意结果是否仍是刚才测得的数据，是否存在未测试或测试失败条目。不同状态可能采用不同排列方式，不要把空值当成零延迟。排序也不等于选中；完成排列后应明确选择预期记录，再检查系统连接状态。若配置使用策略组，还要确认实际请求是否经过该记录，而不是被组内其他选择接管。

1. 固定当前网络与测试方式，对相关服务器进行测试，记录异常范围。
2. 选择一条需要验证的记录，核对 Global Routing 和当前 Config，避免目标被 DIRECT 处理。
3. 建立连接后访问原本需要使用的目标，观察是否能够完成正常请求，而不只看首页是否出现。
4. 失败时记录准确提示，分别检查解析、建连、认证、TLS 与目标访问，不同时改动多个层面。

测试成功而真实访问失败时，应考虑规则是否让目标走了不同策略、DNS 是否返回了预期地址、TLS 是否匹配，以及目标本身是否可用。反过来，某个测试目标不可达，而实际业务可以正常使用，也可能只是测试条件不合适。不要通过单一测试结论覆盖真实观察；两类结果应共同用于定位，而不是强行选择其中一个。

为了临时排查而改变 Global Routing 后，应在验证结束时恢复原来的日常设置。Proxy 可以帮助观察代理路径，但不是所有问题的通用修复；Direct 可以提供直连对照，但不能证明代理链路正常。Config 下则要关注实际匹配结果。若目标被 REJECT 拒绝，更换服务器可能没有作用，应检查规则与误匹配，参见REJECT 策略与匹配边界。

最终保留的应是用途明确、参数可维护、实际验证符合需求的记录，而不是只在某次排序中排在顶部的名称。测试用于缩小排查范围，不能代替账号状态确认，也不能代替备份。长期比较时使用相同方法与少量记录，通常更容易识别变化原因。

08 删除与备份：按数据范围恢复

先区分要删除的对象

删除单条服务器、删除 Subscribe 父项、删除 Config 和删除系统 VPN 配置，处理的是不同对象。单条记录承载连接参数，订阅父项承载远端更新关系，Config 承载规则等设置，系统 VPN 配置则属于设备授权与连接配置。执行前先确认对象层级，不要把所有删除操作都理解为“重新开始”，否则可能保留了错误资料，却移除了仍需要的规则。

删除订阅管理的子项后，下次更新可能重新出现，因为远端仍返回该记录。删除父项则可能同时移除其管理的条目，具体范围应阅读当前确认提示。无论哪一种，本地删除都不等同于取消远端权限，也不会自动撤销已经泄露的订阅地址。远端账号与凭据的处理，应通过自己的服务商账户流程完成。

备份内容应覆盖实际依赖

只保存一条分享链接，往往只能恢复一条连接；只保存订阅地址，也不一定恢复本地改名、手填副本、规则文件和个性化设置。备份前列出实际需要的范围：订阅 URL、重要手填条目、正在使用的 Config，以及影响连接的必要设置。不要假定名称里写着“备份”的文件就自动包含所有这些对象，应通过当前导出功能说明确认范围。

若使用应用提供的备份或导出入口，应检查生成资料包含什么、是否包含凭据，以及恢复时是否覆盖现有数据。若采用分项方式保存，给每份资料标明用途与范围，例如“规则配置”“个人订阅地址”“手填测试记录”。命名无需写入真实服务器密码。备份文件可包含敏感认证，存放位置应限制访问，并按个人设备的安全策略保护。

恢复应小范围验证，不直接覆盖全部

1. 先确认当前设备中的记录是否需要保留，必要时另做一份现状备份。
2. 按资料类型恢复订阅、手填条目或配置，核对导入结果，避免同一资料重复进入多个分组。
3. 检查当前选中服务器、Global Routing、Config 与相关设置，不把“列表出现”当作恢复完成。
4. 完成测试与实际访问，再清理重复记录和临时文件，保留一份范围清楚的有效备份。

换机时，应用本身与应用内资料需要分别确认。通过 App Store 获取已购应用，并不意味着所有订阅和本地配置都会按预期恢复；是否随设备数据迁移，应以实际迁移方式和恢复结果为准。购买与已购恢复流程见换机与重装说明。应用开发者应为 Shadow Launch Technology Limited，产品页应用 ID 为 932747118。

恢复到另一台 iPhone 或 iPad 后，系统可能需要重新确认 VPN 配置授权。旧设备授权不能直接当作新设备已授权的证据。还要检查服务端对设备数量或同时连接的限制，避免把远端限制误认为备份损坏。先使用一条已知参数的记录验证，再逐步恢复其他资料，能较快区分设备授权、数据迁移与服务器状态。

备份也需要维护。远端重置认证、调整地址或本地修改规则后，旧备份可能不再适用。应在一次完整验证成功后更新有效备份，并标明它覆盖的资料范围。不要无限保存多份难以辨认的敏感副本，也不要在确认新备份能够恢复之前急于删除唯一旧副本。删除与保留都应以可恢复性为依据。

本页的管理闭环是：资料有明确来源，导入后核对字段，更新前保留现场，整理时检查引用，测试后验证真实访问，删除前确认备份。若仍有具体错误，前往常见问题按现象继续查阅；若需要重新完成首次连接，则返回入门指南，按单一主线逐步验证，不必同时重建全部订阅与配置。