Shadowrocket
订阅与服务器管理

01 / Subscribe

Subscribe：建立可更新的订阅

订阅是一个可重复请求的远程地址，返回的内容用于生成服务器条目。它与单个服务器分享链接不同，也不等于 Config 中决定连接去向的配置文件。导入前先确认手中的内容属于哪一种：若是一条用于获取整组服务器的地址，应使用 Subscribe；若是以协议名称开头的单条分享链接，应按服务器导入处理。把网页地址、账户页面或说明页面填入 Subscribe，即使地址能够打开，也不意味着返回内容可以被解析。

保存前核对 URL 与备注

在 Home 使用添加入口进入 Add Server，将 Type 设为 Subscribe，再填写订阅 URL。不同界面布局可能把类型选择放在列表中，判断依据是保存对象确实为 Subscribe，而不是任意服务器协议。备注应表达这份订阅的用途，例如“个人常用”或“备用测试”，不要把完整凭据写进备注。粘贴后重点检查开头、结尾、问号和连接符，确认没有带入聊天引用符、换行或句末标点，再保存并等待首次获取结束。

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

上面的地址只说明结构，不提供实际服务。路径用于定位资源，问号后是查询参数；参数名称与值应完整保留，不要根据示例自行改写自己的地址。订阅 URL 通常具有访问凭据的作用，能够读取它的人可能获取相应服务器信息。不要将完整地址放进公开截图、笔记标题或问题反馈正文；需要说明地址结构时，用示例域名和假值替代，并保留标点位置即可。

首次获取后检查什么

保存成功与获取成功是两个状态。先检查订阅下是否出现服务器，再看条目的类型、备注和数量变化是否符合预期；数量只作本地核对，不代表质量。如果显示了错误，应记录错误原文，而不是反复新建同一订阅。能够看到服务器也不等于已经连接：还要在 Home 选中默认服务器，检查 Global Routing，并通过实际请求确认。首次连接的连续步骤可回到入门指南逐项执行。

若出现获取失败，按地址、网络、响应内容的顺序排查。先重新对照原始地址，确认凭据未过期或被替换；再判断当前网络是否能访问该订阅地址；最后区分返回的是服务器数据还是登录页面、错误页面。不要为了验证而把地址提交给陌生的在线解析工具。若只有这份订阅失败，保留错误文字与发生条件；若所有网络请求都异常，应先处理设备网络，避免把同一个网络问题误判为多个订阅同时失效。

订阅与连接状态分别管理

更新订阅会重新读取服务器信息，但不会自动证明当前服务器仍然可用，也不应被当作修复所有连接问题的按钮。某条服务器失效时，先用同一份订阅中的另一条做对照，再决定是否更新。订阅保存的是远程列表入口，服务器保存的是连接参数，Global Routing 决定请求如何使用这些参数；把三个层次分开，才能判断应修改地址、切换服务器，还是检查配置规则。

02 / Add Server

Add Server：逐项核对手填字段

手填适用于已有完整服务器参数、需要核对导入结果，或只管理少量独立条目的情况。先在 Add Server 选择正确的 Type，再填写该类型显示的字段。类型决定参数含义，不能先把资料填进任意表单，再靠修改名称来改变协议。开始前把地址、端口、认证信息、TLS 与传输要求分开记录；资料不完整时应先补齐，不以“常见默认值”替代缺失字段，否则保存成功也可能无法完成握手。

公共字段与认证字段

Address 填主机名或 IP 地址，Port 填对应端口，不把整条分享链接放进 Address，也不要在主机名后重复附加端口。若资料给的是一个包含协议前缀的 URL，需要先辨明它是分享链接还是字段说明。备注只用于识别条目，不参与连接。认证字段则依 Type 而变：有的使用 Password，有的使用 UUID，有的还涉及用户名或密钥。复制认证值时保留大小写与连接符，检查前后空格，不通过缩短值来试错。

TLS 与传输方式独立检查

TLS 负责相应连接层的加密与身份验证，传输方式描述数据如何承载，二者不能互相替代。已有资料要求 TLS 时，应核对服务器名称等相关字段，而不是只打开开关。使用 WebSocket 等传输时，还需核对 Path 与 Host；Path 的开头斜杠、Host 的拼写都可能影响请求。某些参数只在选定相应类型后才出现，未显示的字段不应随意塞进备注、地址或密码栏。

Address、TLS 的服务器名称以及传输层 Host 可以分别承担网络连接、证书验证和请求路由职责，不保证三者文字相同。导入后发现它们不同，不应立即统一成同一个域名。只有现有资料明确要求时才修改，并一次只改一个字段。遇到证书错误，优先核对名称、设备时间和参数是否完整，不把放宽验证当作常规修复；否则可能掩盖填写错误，也降低身份验证的意义。

保存后的验证顺序

建议先以清晰备注保存一条测试记录，选中后再连接。保存仅证明表单被接受，不能证明地址可达、认证通过或传输匹配。先看 Connectivity Test，再发起一个实际请求，并观察是否仅部分目标失败。如果基础连通性正常而指定网站失败，应转向规则、DNS 或目标访问条件排查，不反复更换认证值。若同类型的其他条目正常，可逐项比较字段，但不要在公开反馈中展示完整密码或 UUID。

VMess 与 VLESS 的字段差异可继续查阅UUID、加密与传输方式说明；WireGuard 的参数较多，另见Private Key、Endpoint 与 MTU 说明。本地手填条目通常应按独立对象管理，不预期它随某份订阅同步变化。需要长期保留的手填记录，应在验证通过后及时备份，并注明哪些字段来自原始资料、哪些是后续本地调整。

03 / Scan QR Code

扫码与剪贴板：先识别内容再导入

二维码和剪贴板只是传递文本的方式，不是独立的服务器协议。相同二维码可以承载单个服务器分享链接、订阅 URL，甚至只是普通网页地址。使用 Scan QR Code 或剪贴板导入之前，应先知道自己准备导入哪一类对象，再依据结果核对。操作省去了手填，并不意味着可以省去识别、权限确认和连接测试；来源已知且内容完整，才适合直接交给客户端解析。

Scan QR Code 的操作检查

从应用内的 Scan QR Code 入口调用相机，按系统提示允许相机权限，将完整二维码放入取景范围。保持边缘完整、对焦清晰并避免反光，识别失败时先调整距离，不要立即认定二维码失效。若此前拒绝相机权限，应到设备的系统设置中检查 Shadowrocket 的相机访问状态，再返回重试。系统相机识别出的普通文字或网页提示，不等同于已在 Shadowrocket 内建立服务器记录。

二维码显示在另一台设备上时，可以直接扫描；若保存在当前设备，只有在当前入口明确提供图片识别能力时才从图片导入，不把其他系统功能的行为当作应用承诺。二维码密度高、经过压缩或截掉边缘时，可能无法识别，宜使用原始清晰图片或直接复制原始文本。不要将带有个人凭据的二维码上传到公开识别网站，也不要为提高识别率反复转发给无关人员。

剪贴板导入的内容边界

复制时尽量只选中链接本身，不包含“服务器地址：”之类的标签、代码围栏和说明段落。回到应用使用对应导入入口，若系统询问是否允许粘贴，应确认这是本次主动操作，再选择允许。未出现条目时，先回到原始文本检查是否复制完整；剪贴板可能已被后续复制行为覆盖，系统权限未允许也可能使读取失败。不要仅凭复制成功的提示判断导入已经完成。

多行文本应先确认每行都是完整对象，且当前导入方式支持批量处理。自动换行只是屏幕显示时，通常不需要自行插入换行；真正插入的空格或断行则可能破坏 URI。若一批内容只有部分条目成功，先保留失败条目的原文，在本地逐条核对结构，不要重复导入整批来寻找遗漏。这样可以避免成功条目越积越多，最后难以分辨哪个是新导入、哪个是旧记录。

导入之后核对对象与字段

导入完成后先看结果出现在哪里：若新增的是 Subscribe，应能管理订阅地址与后续更新；若新增的是单个 SERVER，则应能打开其协议参数。再核对 Type、Address、Port、备注，以及 TLS 和传输相关内容。备注可能由链接的片段生成，只是识别文本，不代表条目已通过测试。对于同名记录，应查看字段差异，而不是只凭列表标题覆盖旧条目；原有可用记录最好等新记录验证后再处理。

发生识别失败时，把问题拆成三层：相机或粘贴权限是否可用、原始文本是否完整、文本是否为当前入口支持的格式。若能得到文本却无法解析，继续阅读下一章的分享链接结构；若可以解析但无法连接，回到 Add Server 的字段检查。反馈时记录操作入口、是否出现系统授权、导入结果和错误文字即可，二维码原图与完整 URI 都应视为敏感资料，避免随反馈一起公开。

04 / URI & Config

分享链接：区分协议、订阅与配置

服务器分享链接通常使用协议前缀标明类型，随后携带连接所需的信息；订阅地址通常用于获取一组条目；配置文件则可能描述规则、策略及其他连接行为。三者都可能表现为一段可复制的文字，但导入位置和更新方式并不相同。先识别对象，才能判断应使用服务器导入、Subscribe 还是 Config。不能把“能够在浏览器打开”当作格式正确的标准，也不能按文件名猜测响应内容。

前缀、参数与备注分别承担什么

分享链接常见的组成包括协议前缀、认证信息、地址、端口、查询参数和备注片段，但不同协议并不采用完全相同的编码方式。某些链接将一部分内容编码后保存，另一些直接以参数表示传输和 TLS 选项。不要照搬一种协议的拆解方式去修改另一种协议，也不要把看起来相似的字段当作通用字段。手动编辑 URI 前，应先保留原文，能够从原始资料重新导入后再做实验。

在一般 URI 结构中，问号后用于携带查询参数，连接符用于分隔参数，井号后常用于备注片段。百分号编码可能用于表示空格、中文或其他特殊字符；复制时应保留原样，不能看到编码就手动删除。备注乱码不一定意味着连接参数错误，反过来，备注显示正常也不能证明认证信息完整。应将名称显示与连接测试分开判断，先验证字段，再考虑修正便于识别的备注。

判断导入结果，而不只看链接外观

同一个协议可能存在不同的分享格式，字段也会随所用传输方式而变化。若解析后缺少 TLS、Path 或 Host，应对照已有参数确认导入是否完整，不根据协议前缀自行补默认值。对于无法识别的文本，可以在资料完整的前提下按 Add Server 手填；如果原始资料只给了一条无法解析的链接，而没有必要参数，应先确认格式说明，避免凭猜测建立看似完整、实际错误的条目。

订阅 URL 的返回内容也可能因访问权限、地址有效性或服务端设置而不同。请求得到网页、认证提示或空内容时，问题并不是“服务器导入数量太少”，而是尚未取得可解析数据。不要将网页里的任意按钮地址继续填入 Subscribe 试探。检查原始订阅说明、错误文本和当前网络条件，能够明确返回内容类型后，再决定是修正地址还是检查解析兼容性。

Config 与服务器列表的分工

Config 中的规则决定连接如何分流，服务器条目提供代理连接参数。下面是 Shadowrocket 配置的规则片段，只演示规则顺序和策略关键字；它不是订阅地址，也不包含服务器凭据。示例中的 PROXY、DIRECT 是规则策略名称，其含义不能用列表中的服务器备注替代。完整配置还可能有其他部分，粘贴片段前应先备份现有文件，并确认插入位置属于相应规则区域。

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

第一行域名规则优先判断，后续 GEOIP 规则处理相应 IP 归属条件，FINAL 作为前面规则未匹配时的最终策略。规则有顺序，服务器列表排序则主要用于管理与选择，两者不是同一套机制。Global Routing 为 Config 时才按当前配置规则处理；选择 Proxy 或 Direct 会改变整体处理方式。因此，导入服务器后访问结果不符合预期，应同时检查选中的服务器与 Global Routing，而不是只重新生成分享链接。

05 / Update

更新策略：控制变化并保留可用状态

订阅更新是再次请求原来的远程地址，并根据返回内容调整本地订阅条目。它可能增加服务器、移除旧条目，或改变同名条目的连接参数；并不只是刷新名称。更新前应知道当前使用哪份订阅、哪条服务器，以及是否在订阅条目上做过本地修改。需要继续保留的独立调整，应先通过应用提供的导出或备份能力留存，而不是默认远程更新一定保留本地编辑。

手动更新作为排查基线

首次使用、地址变更后或怀疑内容过期时，先执行一次可观察的手动更新。记录开始前是否已经连接、所处网络及当前条目状况，完成后检查是否有明确错误、服务器是否变化、原先选中的条目是否仍然存在。不要在同一时间连续修改地址、切换网络并反复更新，否则即便恢复也无法判断原因。一次操作对应一次观察，才能区分获取成功、解析成功和连接成功三个阶段。

自动更新适合已确认可稳定获取的订阅。若当前界面提供更新开关或周期选项，应按实际使用频率选择，不预设越频繁越好。更新行为可能受设备网络、系统后台调度及应用状态影响，不应承诺精确到某个时刻。长时间未打开应用后，若怀疑本地内容落后，可主动检查并手动更新一次，再做连接验证；不要只依据自动更新选项已开启，就认为当前列表一定是最新结果。

区分地址错误与获取路径问题

更新失败首先核对 URL 是否仍为自己的有效地址，尤其是凭据重置后有没有继续使用旧地址。随后检查当前网络能否取得订阅响应。若只有连接开启时失败，或只有连接关闭时失败，应分别记录两种条件，检查是否存在获取路径依赖；不要笼统认定必须始终通过某种方式更新。配置规则与当前服务器状态都可能影响请求路径，排查应依据实际结果，而不是套用固定开关组合。

错误响应也要分层理解：连接超时意味着未在条件范围内完成请求，认证失败通常需要核对访问凭据，解析失败则说明取得的内容不符合预期格式。一次失败不等于已保存的服务器全部失效，也不应立即删除整份订阅。若旧条目仍可正常连接，可先保留它们，将更新问题作为独立问题处理。若错误页面包含个人资料，记录错误类型即可，不将完整响应直接发布。

更新后的选择与规则复核

更新完成后，原先选中的服务器可能已经更名、被替换或移除。应回到 Home 确认默认选择，重新测试常用条目，再观察实际请求。名称相同不能证明参数相同，延迟正常也不能证明所有目标都可访问。若本地有引用具体名称的设置，还应检查名称变化是否影响引用。重要用途不宜在即将开始使用的最后一刻批量调整，先留出验证时间，再清理旧记录。

更新订阅与更新应用也应区分：前者刷新已有订阅返回的服务器资料，后者由 App Store 管理应用本身。购买、恢复与兼容性说明见正版核验页，系统要求以 App Store 页面标注为准。不能把连接故障都归为应用需要更新，也不能把一次订阅更新当作应用行为发生变化的证据；先确定变化对象，再比较更新前后的具体字段和请求表现。

06 / Organize

多订阅整理：命名、去重与使用边界

多份订阅并存时，管理目标不是让列表尽量短，而是让每条记录的来源、用途和维护方式可以辨认。先区分订阅生成条目与本地手填条目，再为订阅本身设置稳定备注。建议用用途命名，例如“日常”“临时测试”“个人设备”，不把密码、完整域名列表或订阅凭据放进标题。备注应帮助选择，但不能替代字段记录；一旦发生重名或更新，仍要能够定位到具体订阅。

建立两层命名习惯

第一层是订阅备注，用于回答“这批服务器由哪个已保存入口维护”；第二层是服务器备注，用于回答“当前选中哪条记录”。远程列表本身可能带有命名规则，本地大量重命名之前，应考虑下次更新是否会重新生成名称。若需要保留自己的说明，优先在私密记录中维护用途映射，或使用当前界面明确提供的备注能力，不依靠在远程字段中加入额外文字来长期保存管理信息。

对于临时测试的独立条目，可以明确加上“测试”及用途说明，验证后再决定保留。不要将所有条目都命名为“常用”，也不要仅按数字连续编号，因为更新插入新条目后，编号很难反映真实关系。整理时先保持当前可用服务器不变，逐份检查订阅，不在同一次操作里重命名全部条目、删除重复项并切换默认选择。分批处理可以让错误回退到明确的一步。

判断重复不能只看名称

两个同名条目可能使用不同端口、认证信息或传输参数；两个名称不同的条目也可能指向完全相同的连接配置。判断重复时，应在本地比较 Type、Address、Port、认证、TLS 和传输字段。比较过程中不要将敏感值复制到公共表格。若字段相同但来自两份不同订阅，它们还有不同的更新归属，删除其中一条并不保证下次更新不会重新出现，应先确定需要保留哪份订阅的维护关系。

对于订阅内部的重复项，先观察它是否来自返回内容；若每次更新都重现，单纯本地删除只能暂时改变列表。对于重复导入同一订阅的情况，应核对完整地址与管理用途，再决定保留哪份，不能只按备注相同就删除。清理前确认默认服务器不在即将移除的对象内，并准备一个已测试的替代选择。若当前界面没有明确的批量清理能力，逐项处理比尝试含义不明的批量动作更可控。

显示顺序与实际路由分开理解

排序用于提高查找效率，不意味着排在第一位的服务器自动成为默认，也不保证应用在故障时自动切换。调整显示顺序后，仍要通过 Home 的选择状态确认实际使用对象。若使用配置中的策略组，还要理解该策略组自己的选择规则，不能把服务器列表顺序当成策略组行为。建议将稳定常用项保持在容易找到的位置，将临时测试项单独辨认，避免连接前匆忙选择了未经验证的记录。

可以建立一份不含凭据的私密管理清单，只记录订阅备注、用途、是否有本地修改和最近一次操作结果。这里的“结果”应是自己观察到的事实，例如“已验证实际请求”或“待核对传输字段”，而不是凭名称推测可用性。更完整的操作顺序见多个订阅的分组、排序与重复条目整理。整理完成后回到常用场景测试一次，确保清单变得更清楚的同时，连接状态也保持可解释。

07 / Connectivity Test

延迟测试与排序：读懂结果的范围

延迟测试用于观察在当前网络与测试方法下，一次特定连接操作是否完成以及耗时情况。它不等于持续传输速度，也不能直接证明某个网站或应用可用。判断结果前先确认测试方式、测试目标和当前网络条件；不同方法得到的数值不应直接排名。测试超时同样是一次观察，不足以单独证明服务器永久失效，应结合重复测试、实际请求和其他条目对照。

固定条件后再比较

比较几条服务器时，尽量保持相同网络、相同测试方法与相近时间，避免一条在移动网络下测、另一条在 Wi-Fi 下测。测试期间减少大文件传输等明显竞争流量，先测当前常用项，再测备选项。若界面提供多种方法，应理解它们覆盖的连接阶段可能不同：能够建立基础连接，不代表认证、TLS、传输层和目标请求都已完成。测试方法越接近实际请求，通常能覆盖更多环节，但也更受测试目标影响。

Connectivity Test 与真实访问互相补充

选择服务器并打开连接后，使用 Connectivity Test 观察连通性，再打开实际需要使用的页面或应用。如果测试成功而目标失败，应检查 Global Routing 是否符合预期、目标是否命中了相应规则，以及 DNS 解析是否正常。不要在没有证据的情况下把问题都归给服务器。反过来，如果目标可以访问而某个测试失败，也应考虑测试目标自身的响应条件，避免因为一项测试就删除正在正常工作的记录。

Global Routing 的 Config 按当前配置处理请求，Proxy 使用代理处理方式，Direct 使用直连处理方式。进行对照时先记录原状态，一次只改变一个条件，测试完恢复需要的设置。模式改变会影响结果含义：在 Direct 下能够打开的页面，并不能证明当前选择的服务器可用；在 Config 下访问正常，也可能是该请求命中了 DIRECT。因此验证服务器时，要确认测试请求确实经过了预期路径。

按结果排序后的复核

按延迟排序只是对当次结果重新排列，数值较小的条目不一定在长时间使用中更稳定，也不一定拥有更高吞吐能力。避免看到一次最小值就频繁切换。可优先选择重复测试表现一致、实际使用正常的条目，再保留一个验证过的备选。排序后重新确认默认选择状态，特别是列表很长或有同名条目时，不要把视觉上的第一条误认为应用已经选中并使用的那一条。

如果同一条服务器在不同网络下表现差异明显，应把网络条件纳入记录，而不是继续修改密码。若更新后突然只有某些条目失败，应回看字段是否变化；若所有条目同时异常，先检查共同条件。故障记录可以包含测试方式、网络类型、Global Routing、错误原文及实际目标表现，但不要包含完整订阅 URL。首次连接的检查顺序另见默认服务器、连接开关与 Connectivity Test 检查表，便于避免遗漏基本步骤。

08 / Backup & Remove

删除与备份：明确范围再执行

删除之前先确认对象：单个服务器、整份 Subscribe、Config 中的配置文件，以及应用本身，是不同层级的操作。它们的恢复材料也不同。删除一个服务器不等于撤销订阅访问凭据，删除订阅也不代表远端资源已经取消。备份的目标是能够恢复需要的本地状态，同时妥善保护认证信息；不是把所有内容随意复制到一个容易公开访问的地方。

建立与恢复目标对应的备份

若只需要恢复订阅生成的列表，保存有效订阅地址与必要说明通常比逐条抄写更直接，但仍应考虑地址未来可能变更。若要恢复手填服务器，需要保留完整协议参数或使用应用提供的服务器分享、导出能力。若还希望恢复分流行为，则必须另外保存相应 Config；仅有服务器链接不会自动还原规则。使用当前界面提供的备份功能时，应阅读范围说明，不假设一个入口必然覆盖所有设置。

备份内容可能包含订阅凭据、密码、UUID 或密钥，保护级别应与原始资料相同。建议放在自己控制、具有访问保护的存储位置，并明确区分“仅备注清单”与“含完整凭据备份”。不要以公开分享链接代替长期备份，也不要把完整服务器资料附在问题反馈中。用于说明结构的副本应换成示例值，实际恢复用的副本则必须保持完整，不能将两者混用。

删除单条与整份订阅的差别

删除单个订阅生成条目前，应考虑下次更新是否会重新生成；若目标是彻底移除这批本地服务器，需要查看整份订阅的删除范围。执行整份订阅删除时，认真阅读确认提示，判断是否连同关联条目一并移除。不同对象的操作不可互相替代：只删一个显示条目，不能保证订阅停止更新；只清除本地数据，也不能让已经泄露的远程访问凭据失去效力。

删除当前选中服务器前，先切换到另一条已验证记录，确认需要的连接可以继续工作，再处理旧条目。若列表中只有这一条，先准备好恢复材料，不要抱着“删除后再想办法”的顺序操作。批量清理时先做小范围试验，核对结果后再继续，避免把同名但参数不同的条目一起移除。Config 的删除也应单独备份，因为服务器仍在并不能替代原有的规则与策略设置。

恢复顺序与备份验证

恢复时先确认应用已经从 App Store 获取，已购项目找回方法见换机与重装恢复说明。购买记录恢复的是获取应用的资格，不应被当作服务器与配置自动恢复的保证。随后恢复订阅或手填条目，检查字段与默认选择，再恢复需要的 Config，最后核对 Global Routing。按这个顺序可以在连接异常时定位到具体层级，避免将所有备份同时导入后无法识别冲突。

备份完成后应验证它确实能够读取：检查导出内容是否为空、订阅地址是否完整、独立条目是否包含必要字段，以及 Config 是否为自己准备保留的那份。验证不要求先删除原数据，可以通过查看范围、核对条目或受控导入来完成。若受控导入产生重复记录，应在确认恢复材料有效后清理测试副本。定期检查保存位置仍可访问，比只记住“以前备份过”更可靠。

发现凭据曾被公开时，仅删除截图、链接或本地记录不足以解决访问风险，应按自己现有服务的管理方式更换或撤销相关凭据，再更新应用内地址及备份。日常维护可保持固定顺序：修改前保存基线，修改后验证连接，验证后整理重复项，最后更新备份。若只需要重新走一遍连接流程，返回入门指南；若是常见操作疑问，可查阅开关、Global Routing、订阅更新与已购恢复问答，不必为一个局部问题重建全部数据。