Shadowrocket 订阅与服务器管理

先辨认资料，再选入口

如果手里是一条会返回服务器列表的订阅地址，优先查找 Subscribe；如果手里只有单台服务器的 Address、Port 和认证信息，则转到下一章的 Add Server。两者的区别不是连接能力的高低，而是资料如何维护：订阅通常由一个地址交付多条服务器记录，后续可以重新获取列表；手填记录则由你逐项保存，修改时也要逐项核对。把单台服务器的分享链接当成订阅地址填写，或把订阅网页地址当成服务器 Address，都会让后续排查失去方向。

打开 Shadowrocket 后，在 Config 及服务器管理相关入口查找 Subscribe。不同屏幕尺寸和应用内排列可能影响入口位置，以当前应用显示为准。准备操作前先确认复制的是完整地址，尤其不要漏掉路径、查询参数或结尾字符。用于理解格式的假地址可以写成下面这样；它仅是示意，不会返回可用资料。真实地址属于敏感信息，不应贴在公开讨论区、截图或问题反馈中。

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

保存后分开检查三个结果

在 Subscribe 中填写已有地址，按当前界面提示保存或更新。第一层检查是订阅记录是否出现在列表中；第二层是更新后是否生成服务器条目；第三层才是选中某条记录后能否完成连接。这三个结果不能互相代替：出现订阅名称不代表已经成功解析，出现服务器名称也不代表参数可用。初次导入时，先看条目数量与名称是否符合你手头资料的预期，再展开一条记录核对其 Type、Address 和 Port，最后才进行连接测试。

如果列表为空，先回到原始文字核对是否复制了换行、前后空格或只截取了地址的一部分。若应用提示获取失败，检查当前设备是否能够访问该地址，并确认该地址仍由你已有的资料管理方维护；不要立即反复删除、添加，因为重复操作可能留下难以辨认的同名记录。若已获取内容却无法解析，应把“获取失败”和“解析失败”作为两个不同线索记录下来。前者偏向地址与网络可达性，后者偏向返回内容及格式；更细的排查顺序见订阅更新失败自查清单。

订阅记录与服务器记录的关系

订阅是后续更新的入口，服务器条目是可供选择的结果。更新后某个条目的名称、顺序或数量发生变化，并不能单独证明应用内手填设置被改动；先看变化是否来自同一条订阅，再看当前选中的服务器是否仍在列表中。订阅交付的内容由你已有的资料决定，Shadowrocket 负责按收到的内容显示与管理。需要长期保留的手动调整，应先弄清它是否会在下一次订阅更新时被覆盖，不要把更新得到的条目当作永远固定的本地草稿。

第一次导入只建议处理一条你能辨认的订阅：记住它的显示名称、更新前后的条目变化，并记录一次测试结果。这样做不是限制订阅数量，而是建立可追溯的起点。多条订阅同时加入后才发现空列表，往往很难判断是哪条地址、哪次更新引起变化。已有多条记录时，可跳到多订阅整理，先建立清楚的命名与检查顺序。

按已有资料确定 Type

Add Server 适用于已经拿到单台服务器完整参数的情况。先选择与资料一致的 Type，再填写该 Type 下出现的字段；不要先凭印象选择协议，随后把不同协议的参数硬塞进同一张表。Shadowsocks、VMess、VLESS、Trojan 等名称是协议类型，具体字段会随所选 Type 与应用内选项变化。最稳妥的核对方法，是把手头资料与当前表单并排阅读：字段名称、格式和开关状态逐项对应，缺少的资料不要猜测补齐。

理解基础字段与附加字段

Address 指向远端服务器，Port 指向该服务器提供的接入端口，Remark 只帮助你在列表中辨认条目。Password、UUID、加密方式、TLS、SNI 等参数是否出现、怎样组合，以所选 Type 的表单和你的已有资料为准。比如 Trojan 资料常需核对 Password 以及 TLS 相关字段；VMess 与 VLESS 资料通常还会涉及 UUID 和传输设置。看到相似的字段名不代表可以在两个 Type 之间直接复制整份配置。有关这些差别，可分别阅读Trojan 字段说明和VMess 与 VLESS 字段区别。

手填时建议从不会暴露认证信息的项目开始核对：先看 Type，再看 Address 的字符与 Port 的数字，接着核对协议特有字段，最后填 Remark。完成后保存并重新打开该条目，确认没有因为键盘自动替换、复制时的空白字符或表单切换而改变内容。示例中的 example.com、443、your-password 都是假值，只用于辨认字段形态，不能代替你自己的资料。密码、UUID 与私钥一类内容不适合出现在公开截图里。

保存不等于完成验证

能够保存一条 Add Server 记录，只说明表单接受了当前输入。接下来还要在列表中选中它，按需要查看连接状态与测试结果。如果测试未通过，先排除 Type 与字段的对应关系，再看资料是否有额外的传输或认证要求；不要同时修改五六处参数。一次只改动一个明确可疑的字段，保存后再次测试，才能知道哪一项产生影响。对照现有资料仍无法确定时，保留原记录的截图或非敏感字段笔记，再询问资料的维护方，避免把猜测写成长期配置。

手填条目适合单独维护，也可以作为核对订阅中某一条服务器参数的参照，但不要把两者默认视作同一份记录。订阅更新可能替换其下的服务器条目；手填条目一般需要自行修改。若列表中同时存在名称相近的订阅条目和手填条目，先从来源与备注区分，再决定保留哪一项。下一章说明扫码和剪贴板导入，它们主要改变录入方式，并不会省去本章的字段复核。

扫码前先看二维码承载什么

扫码是把已有资料交给应用读取的入口，不是一种单独的服务器协议。二维码可能承载单台服务器分享链接，也可能承载订阅地址；扫完后生成的结果应当分别按 Add Server 或 Subscribe 的逻辑检查。在 Shadowrocket 中查找 Scan QR Code 等扫描入口时，以当前应用实际显示的名称和位置为准。使用相机扫描前，确认二维码是你准备导入的那份资料，不要仅凭旁边印着的服务器名称判断内容。扫描后先看应用识别出的 Type、地址或订阅记录，再决定是否保存。

同一台 iPhone 上查看的二维码不一定方便再用该设备相机扫描。此时应检查当前应用是否提供从图片识别或从剪贴板读取的入口；可见选项随界面而定，不应把某个特定按钮位置当作固定路径。若二维码来自另一台设备，可直接用相机完成识别；若来自本机的图片，先确认图片清晰且完整，再使用应用当前提供的识别方式。识别失败时，不要把画面裁到二维码边缘之外；还应确认二维码内承载的是应用能处理的文本格式，而不只是一个网页入口。

剪贴板录入要防止多余字符

从剪贴板导入适合已经复制了完整分享链接或订阅地址的情况。复制时尽量只选中目标文本，不要连同说明文字、引号、项目符号一起复制。应用若提供剪贴板识别入口，可以查看其预览；若没有匹配的入口，则按照内容类型手动粘贴到 Subscribe 或对应的 Add Server 字段。不要假定复制动作本身就会自动生成记录，也不要在粘贴后未经检查便连接。某些消息界面会缩短屏幕上显示的链接，但剪贴板里是否为完整内容必须另行确认。

识别成功后重点核对“得到的是什么”。若出现的是一条服务器，检查 Type、Address、Port、认证字段以及 Remark；若出现的是订阅地址，检查它是否作为 Subscribe 记录保存，并在更新后查看服务器列表。二维码和剪贴板只是输入媒介，不能替你判断资料是否完整。特别是一个二维码承载多行文本时，应用可能只识别其中可处理的一段；结果与预期不同，应回到原始文字，而不是对识别出来的半条记录继续补猜参数。

导入失败的回退路径

扫码无结果时，先检查画面、亮度与相机权限，再确认二维码内容确实是你已有的订阅地址或服务器分享文本。剪贴板无结果时，先将复制的内容粘贴到设备上的普通文本输入处查看首尾字符，确认没有空格、换行或说明段落，然后返回应用重试。若文本本身不完整，切换入口不会把缺失字段补回来；若内容完整但无法识别，可以按下一章的格式判断区分它是订阅 URL、单台服务器链接，还是仅供人工填写的一组参数。

导入之后避免立即批量重复扫码。重复条目可能显示同样的 Remark，却来自不同录入时间，后续连接时很难判断选中的是哪一个。先打开新条目核对来源，确认是否已存在相同地址和参数；如果只是更新已有订阅，应使用那条订阅的更新操作，而不是反复扫描同一张二维码。需要清理重复记录时，先按本页最后一章做保存与删除前检查。四种入口的整体选择也可对照添加服务器的四种方法。

先看链接指向一份列表还是一条记录

订阅地址通常是可以请求内容的网页式 URL，应用访问该地址后取得可解析的服务器列表；服务器分享链接则通常把一条服务器的参数编码在文本中，供应用读取后生成记录。两者即使都能复制、都能放进二维码，也不该填进同一个字段。判断时不要只凭开头有没有 https://：它可能是订阅地址，也可能只是说明页面。更可靠的线索是你手头资料对它的用途说明，以及 Shadowrocket 导入后的预览结果——显示一条 Subscribe 记录，还是显示单台服务器的 Type 与参数。

分享链接常包含协议标识和编码后的认证信息。你可能看到 Shadowsocks、VMess、VLESS 或 Trojan 对应的链接形式，但屏幕上未必能直接读出所有字段。链接末尾也可能带有用于显示名称的备注，不应把备注当成认证字段。不要为了“看懂”而随意改动编码文本中的大小写、标点或百分号；这类变动可能影响解析。只要导入后能查看字段，优先在应用内核对结果；需要修改参数时，使用已有资料中的明确值，而不是从一段被截断的分享文本推断。

用可读样例理解订阅 URL

下面的地址只展示 URL 的结构：主机名、路径和查询参数都是示意内容。路径属于地址的一部分，查询参数也可能影响返回内容，因此复制时应保留完整字符串。真实订阅地址可能包含敏感标识；给他人描述问题时，只写“地址可以打开但解析为空”之类的现象，不贴出完整地址。仅用于检查格式的假值不能证明实际地址可以访问，更不能用于测试连接。

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

如果已有资料给的是 Address、Port、Password 和其他参数的逐项清单，而没有分享链接或订阅 URL，就按 Add Server 手填。反过来，如果给的是完整订阅 URL，不需要把 URL 拆成 Address 和 Port：订阅页面所在的主机不是其中每一台服务器的 Address。区分这两层地址尤其重要；把订阅主机填进服务器字段，常会生成一条外观看似完整、实际不能按预期工作的记录。

格式兼容与解析边界

不同资料可能采用不同编码和字段组合，实际可识别格式以当前 Shadowrocket 的导入结果为准。应用识别到 Type 后，也要检查附加字段是否齐全，尤其是传输、TLS 以及认证相关设置。即使两条分享链接显示相同协议，也不代表它们使用相同的传输参数。若导入后字段缺失，先确认原文是否完整，再确认资料本身是否给出了该字段；不要把另一个服务器的字段复制过来凑齐。链接解析失败时，保留失败提示与去敏后的格式信息，方便按“文本不完整、入口选错、字段不受当前形式支持”逐项排除。

分享和转发自己的资料时要记住，链接往往包含足以重建服务器记录的信息。公开展示二维码、剪贴板历史或含完整地址的截图，可能同时公开认证内容。需要对照两个条目是否相同，可以在本机比较 Type、备注及不含凭据的字段；向他人说明问题时，改用 example.com 和 your-password 等明显假值。这样仍能讲清问题发生在 Subscribe、分享链接解析还是 Add Server 手填，而不暴露原始文本。

更新意味着重新读取订阅内容

在 Subscribe 上执行更新，是让应用重新获取该地址当前返回的资料，不是给所有服务器“加速”，也不是自动修复错误参数。更新完成后，列表中的名称、数量或字段可能随返回内容而变化；若原订阅暂时不可访问，则先查看应用提示和现有列表状态，不要凭空推断原来的服务器已经永久失效。开始前记下当前选中的条目和订阅名称；更新后将预期变化与实际结果对照，再做连接测试，才能区分“内容确实变化”与“只是本机选择状态变化”。

对于已经稳定使用的记录，不必把重复刷新当成连接问题的第一种处理方式。若只是当前一条服务器连接失败，先确认它的测试结果与实际连接状态；若同一订阅下多条记录同时出现异常，再检查订阅地址和本次返回内容。若你明确收到已有资料的变更通知，则可以更新对应的 Subscribe，而不是顺手更新全部订阅。如此一来，列表出现变化时可以追溯到哪条记录、哪次操作。

把失败提示分成获取与解析两类

获取失败时，重点检查订阅 URL 是否完整、设备当前网络是否能访问该 URL，以及原有地址是否仍有效。解析失败或更新后为空时，重点核对返回内容是不是应用可识别的服务器资料，是否把网页说明地址当成了订阅地址，以及原文本是否多了换行或被截断。更新显示成功却没有预期条目，还要检查当前查看的是哪个订阅分组、是否存在同名记录，以及结果是否被列表排序或筛选方式改变了位置。一次只处理一个分支，避免在尚未找出原因时删除原记录。

自动更新相关选项若出现在当前应用界面，应结合使用需要设置，不要假定所有订阅都需要相同的更新节奏。频繁更新会使列表变化更难追踪；长期不查看更新结果，则可能继续使用与已有资料不一致的旧条目。更可控的做法是记录哪些订阅由你定期检查、哪些只在资料明确变化时手动更新，并在更新后观察条目数量、名称和关键字段，而不仅仅看一个完成提示。更新过程涉及设备联网，离线时不能用旧测试结果判断本次获取是否成功。

更新后怎样确认连接没有被误判

先找到更新前使用的条目：如果它仍在列表中，核对 Type、Address、Port 和必要的附加字段是否改变；如果名称变了，按所在订阅与字段查找，不要只靠 Remark 判断。随后执行可用的连接或测试操作，必要时在 Home 查看当前选中的服务器及 Global Routing 状态。Global Routing 的 Config、Proxy、Direct 分别对应按配置、代理和直连的姿态；路由状态不同，测试与日常访问的表现也可能不同。测试时应清楚自己在验证服务器参数、规则路径，还是目标服务的可达性，不能把三者混为一次“更新失败”。

若更新后结果明显不符预期，先保存能够描述变化的非敏感信息，例如订阅显示名、更新提示、条目数变化及某条记录的 Type。不要反复覆盖当前状态，也不要把原地址公开求助。可依照五步自查清单继续缩小原因；涉及具体地址或认证信息时，只向该份已有资料的维护方核对。计划重新添加订阅前，先按删除与备份章节确认现有资料是否另有保存。

用名称记录用途，不用名称代替字段

当 Subscribe、手填服务器和扫码条目同时存在，最容易出现的问题不是记录太多，而是无法辨认记录之间的关系。建议先确定每条订阅的可识别显示名，再让手填条目的 Remark 与其有所区分。名称可以提示用途或来源类别，但不应包含 Password、UUID、完整订阅地址等敏感信息。也不要把“速度快”“一直可用”写成永久备注：测试结果会变化，而 Remark 往往长期留在列表中，容易造成过时判断。

整理时先找订阅记录，再看其下的服务器结果，最后核对单独手填的记录。若两个条目的 Remark 相同，不要立即删掉其中一个；分别打开查看 Type、Address、Port 以及是否来自订阅。相同服务器可能因不同录入方式出现两份记录，也可能只是名字相同而参数不同。尤其在订阅更新之后，列表顺序可能变化，依赖“第一条就是上次那条”的习惯会增加误选概率。需要经常使用某项排序或筛选时，先弄清当前显示顺序的依据。

区分列表中的条目与正在使用的条目

列表中保存了某条服务器，不表示 Home 当前就选中了它。准备排查连接时，先明确当前选中项，再明确它属于哪条订阅或是否手填，最后查看 Global Routing。在 Config 姿态下，流量按配置规则处理；在 Proxy 姿态下，以对应代理姿态处理；在 Direct 姿态下，走直连姿态。下面的对照只用于整理排查思路，具体流量仍以当前配置和应用界面为准。把路由姿态记录下来，可以避免把 Direct 下的表现错算到某一台服务器。

如果某条订阅更新后新增许多相似条目，先按订阅归属检查，再考虑改变排序。延迟数值和名称都不是唯一标识：同名记录可能指向不同 Address，而延迟会随测试时的网络条件变化。建议建立一条固定的人工检查路径，例如“订阅显示名 → 服务器 Type 与非敏感地址信息 → 当前选中状态 → 测试结果”。这样即使列表顺序变化，也能重新找到需要检查的对象。对于不再使用的条目，先查其是否还被当前配置选中，再进入清理流程。

配置文件与订阅列表不要混淆

Config 中还可能保存规则配置；规则配置与 Subscribe 的服务器列表是两类资料。规则中的 PROXY、DIRECT 等是策略关键字，并不是订阅名称。下面片段展示规则如何匹配域名、地理位置与最终流量，仅供认识语法；它不包含可用服务器，也不应该被粘贴进 Subscribe 地址栏。若规则指向的策略与当前可用服务器不一致，应分别检查配置和服务器选择，而非只反复更新订阅。

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

多订阅管理的目标是让每次更新和测试都能找到明确对象，而不是把条目压缩成尽量短的列表。先留下足够辨认的名称与来源关系，再根据实际使用情况清理。需要进一步理解 DOMAIN-SUFFIX、GEOIP 和 FINAL 时，可查阅术语表；初次选择 Global Routing 的操作主线见快速上手。

先弄清测试测量的对象

延迟测试通常用于观察某条服务器在当前网络下的响应情况；Connectivity Test 等诊断入口则应结合其界面说明判断测试目标。测试显示一个数值，不表示所有网站、所有规则路径都具有相同响应，也不等于已经完成日常连接验证。测试前确认设备当前能够联网，目标服务器条目已正确导入，并记住当前网络环境。否则，同一条记录在不同时间出现不同结果，可能只是测试条件变化，并不足以说明订阅内容被改动。

建议先对少量已核对字段的条目测试，观察应用显示的是数值、失败提示还是等待状态。数值用于同一次、同条件下的参考；失败提示则需要与 Type、Address、Port、认证信息及网络可达性结合判断。不要只凭一个低延迟结果就跳过后续验证，也不要只凭一次超时就删除记录。测试请求可能与实际访问采用不同目标和路径，尤其在使用 Config 规则时，应确认你测试的是服务器连通性，还是经由某条规则到达的目标。

排序是视图，不是资料修改

按延迟或其他条件排序可以缩短查找时间，但通常改变的是列表的展示顺序，不能把排序结果当成资料内容的永久顺序。更新订阅、切换排序条件或重新测试后，条目可能移动位置。排查时应使用订阅归属与字段辨认条目，不要写下“第三个服务器”作为唯一线索。如果测试失败的条目被排在末尾，也不代表它从订阅中消失；先检查当前筛选与排序状态，再判断记录是否真的缺失。

比较两条服务器时，尽量在同一网络下、相近时间测试，并核对两条记录的 Type 与来源。一次测试可以帮助选择下一步检查对象，却不能替代字段核对。若某条记录显示测试可达而实际访问仍不符合预期，回到 Home 核对是否真的选中了它，再看 Global Routing 是否为 Config、Proxy 或 Direct；在 Config 下继续检查规则匹配的策略。反之，若实际使用正常而单项测试未得到数值，也应先理解该测试的目标和提示，不宜立即修改一份已能工作的配置。

从服务器诊断走向规则诊断

当服务器参数与连接状态已确认，才进入规则层检查。下面几行展示常见匹配类型在配置中的位置：DOMAIN 匹配指定域名，DOMAIN-SUFFIX 覆盖域名后缀，IP-CIDR 面向地址段，FINAL 处理未被前面规则命中的流量。规则示例的 example.com 和地址段只用于阅读语法；其中 PROXY 是否能按预期工作，仍取决于当前配置与服务器选择。不要把规则片段当成延迟测试的目标列表。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

如果问题只发生在某个目标，先看该目标命中了哪条规则，再看对应策略与当前服务器；如果多个目标都失败，再回到服务器连接、订阅更新和设备网络状态。这样从局部到整体检查，比同时切换服务器、更新订阅和重写规则更容易定位原因。测试与排序是管理工具，不是修复动作：它们告诉你接下来该检查哪一层，不能代替原始参数和规则本身。更多现象可在疑难解答按类别查找。

先确认要删的是哪一层

清理列表前，先分清订阅记录、订阅生成的服务器条目、手填服务器和 Config 规则配置。删除其中一项可能影响后续更新或当前选择，因此不要仅凭相似名称批量清理。准备删除订阅时，确认它是否仍是某些服务器条目的更新入口；准备删除单台服务器时，确认它是否正被选中，以及它是否会在下一次订阅更新后重新出现；准备删除 Config 时，先检查是否有需要保留的自定义规则。界面给出的删除对象与确认提示应逐字阅读。

更稳妥的顺序是先查看目标记录的来源和非敏感字段，再检查当前连接是否依赖它，随后确认原始资料仍由你自行保存。订阅 URL、服务器认证字段和规则文件各自承担不同用途，只保存某一张列表截图未必足以重建配置。反过来，保留完整敏感地址的公开截图也不合适。备份应放在你自己可控制的位置；记录名称和用途时可使用去敏文字，真正用于恢复的完整资料则要按其敏感程度妥善保管。

分别准备订阅、手填项和规则

订阅记录要能重建，至少需要保留你自己已有的完整订阅地址以及它对应的辨认名称；手填记录要能重建，需要按 Type 保存必要字段及附加选项；自定义规则配置则应单独保存其内容。不要假定保留订阅 URL 就等于保留所有手填服务器，也不要假定保留一条分享链接就能还原此前的规则文件。若应用当前提供导出、共享或 Import from Cloud JSON 等相关入口，应先阅读界面说明，确认导出或导入的到底是哪一类资料，再决定是否使用。不同入口的覆盖范围不能只凭名称推断。

执行备份后，做一次不改变现有记录的核对：检查保存的内容能否辨认订阅与手填项，确认文本没有被截断，并核对规则片段是否仍保留换行与顺序。对包含认证信息的文件或文本，不要通过公开评论或截图测试是否“备份成功”。如果你仅需要给自己留下排查笔记，可以另写一份去敏清单，记录订阅显示名、服务器 Type、非敏感备注和操作日期；这份笔记方便定位，但不能替代完整的恢复资料。

删除后如何判断是否需要重新导入

删除完成后，返回列表检查目标记录是否确实消失，当前选中项是否发生变化，以及其余订阅能否继续按原方式更新。如果删除的是订阅生成的单台条目，而订阅记录还在，下一次更新的结果可能再次包含它；如果删除的是订阅本身，原先依赖其更新的路径也需要重新确认。需要重建时，先按Subscribe或Add Server章节选择正确入口，不要同时从扫码、剪贴板和手填三个入口重复创建同一条记录。

更换设备或重新获取应用时，先按已购恢复说明核对 App Store 中的购买记录，再处理自己的订阅与配置资料。Shadowrocket 在 iPhone、iPad 上的获取及系统要求均以 App Store 页面标注为准；应用购买状态与服务器资料的保存是两件事。客户端一次性买断 ≠ 线路套餐，恢复已购应用也不等于自动重建你手动保存的全部服务器字段。若有疑问，先确认缺少的是应用、订阅记录、服务器条目还是规则配置，再按对应类别恢复。