Shadowrocket
订阅与服务器管理

Subscribe 入口与订阅对象

订阅地址不是一台服务器的地址，而是用于获取一组连接资料的入口。导入后，应用通常同时保留订阅来源与解析得到的服务器条目。前者决定下一次更新到哪里请求，后者决定当前连接使用哪些参数。编辑单个服务器并不等于修改订阅来源，反过来，修改订阅地址也不意味着当前所有旧条目立即完成替换。开始之前先区分这两个层次，后续才能判断问题发生在请求、解析还是连接阶段。

从已有链接判断入口

先确认手中的资料被标明为服务器订阅，还是包含规则的配置文件。仅凭地址以 HTTPS 开头无法区分两者：普通网页、订阅响应与配置文件都可以使用这个形式。查看用户已有资料的用途说明，不要根据文件名猜测。Home 中通过 Add Server 选择 Subscribe 的流程用于建立服务器订阅；Config 中的 Subscribe 面向配置文件订阅。界面层级以实际显示为准，二者名称相近，但不能把服务器列表与规则配置当成同一种内容。

1. 复制完整的已有订阅地址，检查开头、末尾以及查询参数是否连续，避免带入消息中的引号和换行。
2. 在 Home 打开 Add Server，进入 Type 选择 Subscribe；将地址填入对应的 URL 字段，并填写便于辨认的名称。
3. 保存后返回 Home，查看是否出现订阅分组及服务器条目；先确认内容，再选择其中一项进行连接验证。
4. 如果已有资料明确是规则配置订阅，再进入 Config 使用 Subscribe；完成后还需确认实际选中的配置文件。

保存成功与获取成功分别检查

表单能够保存，只说明应用接受了输入，不代表远端已经返回可解析的内容。保存后没有服务器条目时，先观察是否存在请求错误，再检查链接完整性。如果收到的是账户登录页面、说明网页或访问错误文本，地址即使可以在浏览器中打开，也不能据此判断它是有效订阅。不要把网页正文复制到服务器地址栏；应返回已有资料核对准确入口，以及当前账户状态是否允许读取这份内容。

一次导入后应做一轮小范围检查：查看条目类型是否与已有资料一致，随机打开一项确认地址和端口是否合理，再进行手动连接。数量与预期不同并不必然是导入失败，可能来自订阅当前返回的内容、应用支持的字段或筛选条件；应比较同一来源的说明，不以其他来源的条目数量作标准。首次测试尽量只保留一个明确选中的服务器，避免自动选择策略掩盖实际使用对象。

如果已经完成服务器导入但无法访问，先不要反复新增相同订阅。确认 Home 所选服务器、Global Routing 和连接开关，再按开关已打开却无法上网的检查顺序定位。订阅导入只解决资料进入应用的问题，不同时证明认证、远端服务、DNS 与规则都已正确。

Add Server 手填字段核对

Add Server 适合用户已经掌握一台服务器的完整参数，并需要逐项核对的情况。手填的关键不是把所有字段都填满，而是先选择准确的 Type，再填写该协议真正需要的内容。不同 Type 下同名字段的含义可能不同，界面中没有出现的选项也不应凭经验补入。地址、端口、认证与传输设置属于不同层级；只有这些层级同时与已有服务器资料一致，连接测试才有判断意义。

先选 Type，再填写基本字段

1. 在 Home 打开 Add Server，先核对 Type；更换类型后重新检查表单，避免沿用上一种类型的认证内容。
2. 在服务器地址字段填域名或 IP，在 Port 填对应端口。不要把完整分享链接、路径或端口后缀一起填入地址字段。
3. 按类型填写 Password、UUID、加密方式或其他认证参数，保留大小写、连字符及必要符号。
4. 对照已有资料检查 TLS、SNI、传输方式与路径，保存后重新打开一次，确认实际保存的值。

服务器地址用来确定连接目的地，TLS 中的 SNI 则用于握手时声明名称，两者不一定相同。已有资料给出 IP 地址与独立域名时，不要自行把域名覆盖到每一个字段。Port 是远端监听端口，不是订阅链接使用的网页端口；同样不能因为使用 TLS 就推定端口一定是多少。手动录入时，每个值都应有对应资料来源，缺失参数需要先补齐，而不是逐个尝试常见数字。

认证与传输分开排查

认证失败与传输握手失败需要不同的检查动作。前者优先检查凭据是否完整、是否仍有效，以及是否选错协议；后者检查传输类型、TLS 名称和路径。某些凭据中包含容易被输入法替换的符号，复制后应注意全角字符与首尾空格。对于 UUID，保持原有分段形式；对于 Password，不要因为看起来像编码文本就自行解码。应用需要的是对应字段的原始值，而不是肉眼更容易理解的形式。

使用 WebSocket 等传输时，Host 与 Path 可能分别参与请求构造，不能将整段地址放进 Path，也不能把路径中的前导斜杠随意删除。TLS 开关、SNI 与证书验证相互关联，但关闭验证不能作为常规修复办法。遇到证书相关错误，先核对名称、设备时间与已有服务器配置是否匹配。参数不明时保留错误信息并回到已有资料确认，比同时切换多项安全设置更容易定位原因。

命名建议记录用途与来源，不记录 Password 或完整访问令牌。可以用“个人测试 / 手填 / Trojan”这样的说明，区分同一地址的不同参数组合。修改前复制一份可辨认的测试条目，原条目先保留；每次只改一类参数，再重复相同验证动作。成功后核对究竟是哪一项变化起作用，不要把所有尝试过的改动都留在正式条目中。协议名的含义与规则词可继续查阅概念速查。

手填条目通常需要用户自行维护，不能假设订阅更新会替它同步密码或端口。即使地址与订阅内某项相同，两者也可能是独立记录。远端参数调整后，应分别检查来源和本地手填副本，避免误把旧副本的失败理解成整个订阅不可用。

Scan QR Code 与剪贴板导入

二维码和剪贴板是传递资料的载体，不是独立的连接协议。同一张二维码中可以装入单台服务器分享链接，也可以装入一个订阅 URL；剪贴板中也可能只是名称、说明文字或网页地址。应用识别到内容之后，还要查看准备导入的对象类型。不要因为出现扫码成功提示，就立即打开连接开关。正确的闭环是读取内容、确认类型、保存记录、检查字段，最后再验证网络。

二维码读取与保存后的确认

1. 在应用提供的 Scan QR Code 入口打开扫描功能，仅在需要相机读取时授予对应权限。
2. 让二维码完整进入取景区域，保持画面稳定，避免边缘缺失、反光及其他二维码同时进入画面。
3. 读取后观察进入的是 Add Server、订阅录入还是其他确认界面，检查名称、Type、地址与 Port。
4. 保存后返回 Home，确认新增条目所属来源；如果已有相同记录，先比较再决定保留哪一份。

二维码显示在同一台设备上时，可在实际扫码入口支持的情况下从照片读取；如果当前界面没有相应入口，改用原始文本链接导入，不必反复截图。照片读取只改变输入方式，不改变对内容的核对要求。图片经过缩小、压缩、裁切或叠加标记后，可能无法恢复完整内容；应使用清晰原图，或者直接回到已有资料取得文本形式。二维码越密集，对画面清晰度和完整留边的要求越高。

剪贴板读取的边界

复制链接时，从协议前缀开始到最后一个参数结束选中整段，避免把标题、项目符号与解释文字一起复制。返回应用后，依据实际出现的剪贴板识别提示或导入入口继续；系统询问粘贴权限时，确认读取行为由本次操作触发。不同系统设置下，提示出现时机可能不同，未出现自动提示不能直接判定链接无效。可先进入对应录入界面检查是否支持粘贴，再核对文本格式。

从聊天记录和网页复制时，最常见的问题是实际内容与显示内容不同：页面可能只展示缩短后的地址，文本可能被插入换行，末尾也可能附带中文标点。不要手动猜测被隐藏的字符。应复制原始链接，而不是对着屏幕重新输入。批量文本中如果同时包含说明行与服务器行，应用是否全部识别取决于具体格式；首次建议只导入一条完整记录，确认解释方式正确后再处理剩余内容。

如果扫码后的 Type 与原始资料不符，先取消保存，检查二维码是否对应另一份记录。对于读取后字段缺失的情况，保留原始资料，改用 Add Server 对照录入，不要在错误类型的表单里补齐看起来相似的字段。若条目已经存在，可以在名称中标记“扫码测试”，便于与原记录区分；完成对照后删除临时记录，避免下一次测试选中错误对象。删除前应确认临时项不是唯一可恢复副本。

导入完成后，剪贴板与照片中的内容仍然存在。含有真实凭据的二维码不适合用作公开问题截图，剪贴板也不宜长期保留敏感链接。处理完本次操作后，可以复制一段普通文字覆盖当前剪贴板，并按自己的资料管理方式清理临时图片。导入入口之间的操作对照另见订阅与服务器的四种导入入口；这里的安全边界对每一种载体都适用。

排错记录只需说明“扫码未识别”“识别后类型错误”或“保存后连接失败”。这三种情况对应输入、解析、连接三个阶段，应分别处理，避免把图片清晰度问题误当成服务器故障。

分享链接与 Config 格式

分享链接将服务器参数编码为可传递的文本，订阅则可以返回一组这样的内容。看到协议前缀时，先判断它描述的是一台服务器还是一个内容入口，再选择录入方式。常见前缀包括 ss://、vmess://、vless://、trojan:// 与 hysteria2://，但前缀相同并不保证所有参数组合都一致。协议、传输、安全设置及名称编码仍需一并解析；不能用“链接可以识别”替代完整的字段检查。

前缀、查询参数与名称分别处理

部分格式把认证与地址编码到主体中，部分格式则直接展示地址、端口与查询参数。问号之后可能出现 TLS、SNI、传输方式等设置，井号之后通常用于备注名称。名称显示异常时，不代表连接参数一定损坏；反过来，名称正常也不证明查询参数全部正确。排错应在应用内查看解析后的结果，而不是只凭链接的可读程度作判断。名称可在本地改为易辨认文本，但原始连接资料应另行保留。

链接中的百分号编码用于表达保留字符，某些主体则使用 Base64 编码。两种机制不能混用，也不应对整条链接反复解码。密码、路径或名称中原本合法的符号，经过错误解码后可能变成分隔符，改变字段边界。复制时应保持原文；需要排查时只对照应用中的字段与已有资料，避免把解码后的完整凭据发送到公开文本处理工具。编码让文本便于传递，并不构成保密措施。

服务器资料与规则文件的分工

服务器条目回答“连接到哪里、如何认证”，Config 回答“哪些请求采用什么策略”。两者可以配合使用，却不能互相替代。仅导入规则文件，通常不会凭空获得用户所需的服务器凭据；只导入服务器，也不能据此推定已有规则已经生效。检查分流行为时，应同时确认 Home 的所选服务器、Global Routing 的当前模式，以及 Config 实际启用的文件，避免只查看编辑器中打开的某个副本。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

以上为规则语法示例，不是适合所有网络的完整配置。DOMAIN-SUFFIX 按域名后缀匹配，IP-CIDR 指定地址范围，GEOIP 依据相应地址归属数据判断，FINAL 作为最后的兜底。规则顺序会影响命中结果，范围宽的条目放在前面，可能使后续更具体的条件失去机会。PROXY 与 DIRECT 是策略关键字，不能改成中文，也不应在复制时替换逗号或添加说明文字。

使用 Global Routing 的配置姿态 Config 时，需要结合所选配置检查规则；代理姿态 Proxy 与直连姿态 Direct 则用于不同的整体路由选择。它们不是三份服务器资料，也不是三个订阅来源。为了比较某条规则的影响，可以先记录当前模式，再以相同目标进行单次测试，结束后恢复原模式。不要在验证订阅内容的同时替换整份 Config，否则即使访问变化，也很难判断来自服务器还是路由策略。

遇到扩展参数无法确定是否支持时，优先查看当前应用对应字段与原始资料说明。不要删除所有不认识的参数再保存，那可能让链接变得可导入却失去必要设置。格式问题应在导入前后两端核对，规则问题则在 Config 中定位，保持这两条排查路径独立。

订阅更新策略与失败分支

订阅更新是重新请求已有来源并解析当前返回内容，不是单纯测试旧服务器是否在线。更新后，条目可能增加、移除、改名或调整参数；具体变化取决于远端内容及应用的处理方式。因此，更新前应知道哪些记录属于订阅，哪些是自己手填的独立条目，以及当前正在使用哪一项。对用户已经修改过的订阅条目，应把本地改动视为可能被后续更新覆盖的内容，而不是长期保存的唯一依据。

先完成一次可核对的手动更新

1. 记录当前来源名称、所选服务器与关键本地修改；重要内容先做可恢复备份。
2. 使用该订阅当前提供的更新操作，只更新一个来源，观察结果及错误提示。
3. 比较更新前后的分组、名称与参数，确认正在使用的条目是否仍然存在。
4. 选择一项已确认的服务器重新连接，以相同访问目标核对实际效果，再处理其他来源。

按需手动更新适合变化较少、希望先审查内容的情况；应用若提供自动更新设置，可在手动更新成功后按自己的维护需求启用。自动更新周期不等于远端资料变化周期，频繁请求也不能修复已经失效的凭据。系统后台运行条件、本地网络以及应用当时的状态都可能影响执行时机，因此不能把某个计划时间当成每次必达的保证。遇到问题时，先在应用前台手动执行一次，取得明确结果。

把请求失败与连接失败分开

订阅地址无法访问时，先检查当前本地网络、DNS 解析与地址完整性。如果当前连接状态可能影响请求路径，记录状态后再作一次受控对照；不要在没有记录的情况下来回切换，导致无法复现。与认证有关的响应通常需要核对链接是否仍有效；内容解析失败则要判断返回的是订阅资料还是网页。只有成功获得可识别内容之后，才进入服务器参数与连接可用性的检查阶段。

成功更新不等于所有服务器都可用。订阅可以正常返回资料，而其中某台服务器暂时不可达；同样，旧条目仍能连接，也不能证明订阅入口正常。两者应分别保留结果。若更新后只剩部分记录，先检查远端是否调整内容、当前是否存在筛选条件，以及应用能否解析相关类型。不要立即连续刷新大量次数，先查清第一次更新的变化，保留原始错误说明，才能避免覆盖有价值的排错线索。

如果已有订阅地址需要替换，应先备份旧来源并辨认新地址的用途。可在独立名称下验证新来源，确认条目与连接正常后再清理旧记录。替换过程中不要同时删除旧来源、清空配置与重置设置，否则失败后缺少对照。更新完成后还应核对 Global Routing 与 Config 是否保持预期；订阅维护不应顺带改变路由行为，除非本次操作本来就包含明确的配置调整。

记录一次维护的结果，只需写明更新来源、出现的变化、验证对象与结论。无需把完整订阅地址放入日志。这样既能复盘，又能减少敏感资料散落在截图和笔记中的机会。

多订阅分组、命名与重复整理

多个已有订阅并存时，最重要的信息是“条目来自哪里”，而不只是显示名称是否整齐。名称相同的两项可能使用不同地址、端口或认证；名称不同的两项也可能指向同一远端。整理前先建立来源层级：订阅来源、来源下的服务器、独立手填条目、用于验证的临时副本。每一类都应能够辨认，避免更新时找错分组，或者清理测试项时误删正在使用的正式记录。

命名只记录用途，不暴露凭据

订阅名称适合用个人可理解的用途与资料来源代号，服务器备注适合记录协议或测试目的。例如“工作资料 / 主用”“个人测试 / 手填”可以帮助识别，但名称不应包含 Password、访问令牌或完整账户标识。名称也不适合写成测量结论，因为远端状态与本地网络会变化。把某次测试结果写成永久名称，容易使后续选择依赖已经过期的印象，而忽略当前实际验证结果。

1. 逐个来源检查，先确认来源标签与所属条目，不在全列表视图中直接批量删除。
2. 为独立手填项和临时副本增加明确备注，保留其原始资料的私密保存位置。
3. 比较疑似重复项的 Type、地址、Port、认证与传输设置，而不只比较显示名称。
4. 选定保留对象后，检查配置或策略是否引用原名称，再小批量清理并验证。

订阅内部的名称可能由远端维护，更新后不一定保留本地重命名。希望长期保持个人分类时，优先利用应用实际提供的来源分组或备注能力，不要大量改写远端管理的字段。若确实要保存独立副本，应同时记录它不再依赖原来源更新，需要自行维护。副本越多，后续同步成本越高；保留副本应服务于排错或恢复，而不是把每次更新都变成一次完整复制。

重复项的判断需要参数对照

完全相同的显示名称只能说明命名重合。不同凭据可能对应不同的授权范围，不同传输路径也可能对应不同服务设置。删除前应打开条目进行比较，至少确认地址、端口、协议和安全设置；涉及凭据时只在私密环境中核对。若只是地址相同而其他字段不同，先分别测试并保留解释。不能因为列表看起来相似，就把其中一份视为多余，更不能用某次测试延迟接近作为重复证据。

配置中如果使用了具体服务器名或策略组成员名称，重命名与删除可能影响引用关系。整理之前先检查对应 Config，而不是只关注 Home。使用 PROXY 之类策略关键字时，也应理解它与当前选择的关系，不能把显示名称相同误认为引用稳定。整理后选中预期服务器，进入 Config 确认启用文件，再使用固定目标验证。出现异常时优先恢复刚才的名称或条目，避免继续扩大修改范围。

多来源不意味着必须频繁切换。维护时可以设定一个已验证的参考对象，其余来源按需测试。将“当前使用”“备用验证”“等待核对”作为自己的记录状态，比仅按名称排列更容易复盘。记录应放在安全位置，不把状态文字与真实凭据拼在一起。每轮整理只处理一个来源，完成更新、检查和验证后再进入下一组，可以减少参数混淆与遗漏。

对暂时不用但尚未完成恢复核验的记录，先保留比立即删除更稳妥。确定原始资料可用、备份可恢复、配置引用已经处理后，再进行最终清理。列表简洁是结果，来源可追溯与恢复路径明确才是整理的完成条件。

Connectivity Test、延迟与排序

Connectivity Test 用于取得某种条件下的测试结果，不是对服务器质量的永久评价。测试是否建立连接、是否完成协议握手、是否访问了测试目标，取决于实际选择的测试方式。看到一个时间值时，先弄清测量对象，再决定如何比较。地址可达不等于认证成功，认证成功也不等于所有网站都能访问；把这些阶段分开，才能解释“测试有结果但实际访问失败”这样的现象。

固定条件，再比较结果

1. 确认设备当前使用 Wi-Fi 还是蜂窝网络，先验证本地网络基本可用。
2. 选定一种测试方式与同一个目标，记录 Global Routing、所选服务器及相关配置。
3. 在同一条件下测试少量候选项，对异常结果重复一次，不同时修改多个参数。
4. 选择候选服务器进行实际连接，验证常用访问任务，再决定是否调整使用顺序。

TCP 类测试主要反映到目标端口的连接情况，不能独立证明代理认证和后续数据传输全部正常。对使用不同底层传输的协议，某一种测试也未必具有相同解释意义。应用若提供经代理访问目标的测试，应把目标本身的响应状态纳入判断：目标不可达、解析异常或暂时拒绝请求，都可能影响结果。测试方式不同得到的时间值不适合直接混排成统一结论，应先保持测量口径一致。

排序不等于自动选择

按测试结果排序通常改变列表展示顺序，不能据此认为应用一定会切到第一项。实际连接对象取决于当前选中的服务器与配置中的策略。完成排序后应重新确认选中状态；如果配置使用策略组，还需检查该组的选择方式。一次测量中的最小时间值，只是当时该目标下的一项观察，不等于更高持续传输速度，也不等于更适合所有访问任务。不要把列表位置当成连接状态的替代信息。

大量并行测试可能放大设备、本地网络或远端的短时负担，结果也更容易受到瞬时波动影响。对几项候选服务器分批测试，通常更有利于保持条件可比。某项偶尔超时，应在相同条件下复测；持续失败则回到参数检查，区分地址不可达、认证错误与目标请求失败。不要仅因一次红色状态或空白结果删除记录，特别是在当前本地网络也不稳定的情况下。

如果同一服务器在 Wi-Fi 与蜂窝网络下表现差异明显，先保持服务器参数不变，分别记录网络条件，判断是否与本地接入相关。若所有服务器都在同一网络下失败，优先检查本地网络与 DNS，而不是逐项重填认证。如果只有一项持续异常，再比较其 Type、Port、TLS 与传输字段。这样的分层顺序能够减少重复劳动，具体动作可参照速度慢的分层排查。

最终记录应包含测试方式、目标、网络条件与结论，不必只保存一个时间值。排序后仍保留来源分组和可辨认名称，方便下一次更新后重新验证。只有测试结果能够被相同操作复现，才适合作为维护决策的依据；暂时无法解释的差异，应标记待核对，而不是直接归因为某个协议或服务器永久不可用。

删除、备份与换机恢复

服务器管理的最后一步不是删除，而是确认删除后仍有明确恢复路径。应用、订阅来源、服务器条目与 Config 文件属于不同对象，恢复其中一个不代表其他内容自动恢复。App Store 中的已购记录用于重新获取应用；用户自己的服务器凭据、订阅地址与本地配置仍应分别保存。换机前先盘点这些对象，比换机后发现资料缺失再追查更可靠。系统要求及购买适用范围以 App Store 页面标注为准。

按对象制定备份清单

订阅来源应保留完整地址与用途说明，独立手填项应保留协议、地址、端口、认证及必要传输设置，Config 应保留完整文件与启用关系。若应用提供导出或备份功能，应先确认实际包含哪些内容，不把一个文件的名称当成覆盖范围证明。某些导出偏重配置文本，某些操作只分享当前服务器；恢复前必须知道它们分别包含什么。安全保存原始资料，也有助于检查导出过程中是否遗漏扩展参数。

1. 列出来源、手填条目、Config 与关键设置，标明各自的恢复资料保存位置。
2. 在应用实际提供的入口完成导出；检查文件是否包含预期对象，并采用受保护的位置存放。
3. 条件允许时，在独立测试条目或目标设备中验证恢复，不覆盖唯一仍可用的原记录。
4. 核对恢复后的字段、所选服务器、Global Routing 与 Config，再完成连接及访问测试。

分享二维码、单条分享链接与完整备份的覆盖范围不同。只保存一台服务器的二维码，通常不足以恢复订阅来源与更新关系；只保存订阅 URL，也不能恢复本地手改备注、独立条目和规则文件。反过来，保存完整备份可能同时保留大量敏感信息，应限制访问范围，避免与公开截图混放。是否加密、如何解锁以及在目标设备如何读取，都需要在删除原资料之前确认，而不是等恢复失败后再补想。

区分删条目、删来源与停用配置

删除订阅内的某一项，不代表远端已移除它，后续更新时仍可能重新出现。删除整个订阅来源则可能同时影响所属条目，执行前要阅读应用当时的确认提示。停用或切换 Config 不是删除服务器，但会改变请求的处理方式。每次清理只操作一种对象，并在操作后检查当前选择，避免服务器被移除后仍以旧名称判断连接对象。若涉及策略引用，也要同步核对配置中的成员是否仍然存在。

恢复后不应假设连接开关、系统授权或应用内选择全部与旧设备一致。先打开 Shadowrocket，确认导入内容，再选择已核对的服务器与 Global Routing，按系统提示处理 VPN 配置授权。系统弹窗是建立设备网络配置的流程，不会替用户补齐服务器资料。应用重新获取与已购核对可参照换机与重装说明，客户端费用的范围可参照一次性买断与线路费用说明。

误删后应先停止进一步清理，检查已有备份、原始资料与尚未修改的其他设备。不要通过反复更新去猜测本地独立项是否会回来，也不要覆盖仍完整的副本。恢复一份后先检查内容范围，再进行连接验证；确认可用之前保留原备份，避免把不完整的新文件覆盖到唯一旧文件上。整理完成后记录最终保留对象与恢复位置，之后每次重要参数变更再更新备份。