Shadowrocket
订阅与服务器
管理手册

01 / 先分清输入内容

Subscribe：导入已有订阅

订阅链接是一项可更新的服务器清单入口，不等同于某一台服务器的连接地址。导入后，Shadowrocket 请求该链接，读取其中能够识别的内容，再建立服务器条目。清单里的名称、数量或连接参数发生变化时，需要再次更新才能反映到本地。开始操作前，先确认手中拿到的是完整订阅地址，而不是账户页面地址、介绍页面地址或单个服务器的分享文字。

确认链接用途与敏感部分

从你的服务商处获取自己已有的订阅链接，并保留原始文本。不要先经过聊天软件重新排版，也不要手动删去看似很长的尾部参数。问号之后的内容可能承担身份识别作用，路径本身也可能包含访问凭据。链接能够在某处打开，并不意味着它就是可供客户端读取的服务器清单；如果得到的是登录页面，应该核对链接用途，而不是把账户密码填入服务器的 Password。

下面只展示地址的外形，不可用于实际连接。示例中的域名和参数均为假值。真实链接应只保存在自己的设备与受控备份中，不宜出现在求助截图、公开笔记或共享相册。即使只露出一部分，仍可能泄露足够的访问线索。

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

从 Add Server 进入 Subscribe

在 Home 打开添加入口，进入 Add Server 后查看 Type，选择 Subscribe，再将完整订阅地址填入 URL。为这份订阅填写能够辨认用途的备注，检查地址开头和末尾是否出现空格或换行，然后保存。界面布局可能随设备与应用调整，判断入口时应以 Type 和 Subscribe 这些英文项为准，不必依赖按钮固定出现在屏幕的某个坐标。

保存后返回 Home，检查订阅所属分组及其服务器条目。导入成功的判断不是仅仅看到备注，而是清单确实生成了可选服务器。若只留下一个订阅入口却没有条目，先检查网络能否访问订阅地址，再检查响应内容是否为可识别格式。不要立刻反复添加同一地址，否则容易把一次请求失败变成多个重复分组。

把清单更新与实际连接分开

成功取得清单，只能说明订阅请求与内容解析完成，不能证明每台服务器都能连接。相反，更新失败时，先前保存在本地的服务器也可能仍然可用。排查时分别记录“订阅能否更新”和“已有条目能否连接”，不要用其中一个结果替代另一个。选中服务器后，还需要检查 Global Routing 与连接开关；这些首次连接步骤可回到入门指南核对。

如果同一地址之前已经导入，应优先更新原有订阅，而不是再新增一份。这样既能保留清晰的来源关系，也便于之后判断哪些变化来自清单更新。若不确定条目属于订阅还是手动添加，先查看其所在分组与编辑信息，再决定修改方式；对订阅条目的本地修改，应预期可能被后续更新覆盖。

02 / 字段必须相互匹配

Add Server：手填服务器参数

手动添加适用于已经持有完整服务器参数、需要逐项核对的情况。先选择 Type，再填写该类型要求的字段。协议类型决定客户端如何与服务器通信，不能因为某种类型字段较少就任意替换。Address、Port 与 Password 只是常见字段；某些类型还要求身份标识、加密方法、传输参数或 TLS 相关设置，缺少其中一项都可能导致连接失败。

先确认 Type，再核对基础字段

打开 Home 的添加入口，在 Add Server 中将 Type 设为已有服务器实际使用的协议。随后对照原始信息填写 Address 与 Port。Address 通常是主机名或 IP 地址，不应混入网页路径、用户名或多余空格；Port 是独立数值，不能把冒号后的端口重复写进 Address。除非界面字段明确要求完整 URL，否则不要把整条分享链接直接当作主机地址。

Password 必须与当前服务器相对应，不能用购买应用时的账户密码替代。复制后如需检查，应在私密环境中确认首尾字符与大小写，不要通过公开截图核对。对于使用 UUID 等身份字段的协议，也应按界面字段填写，不要把所有认证内容都塞进 Password。备注只帮助辨认，不参与认证，改名不会修正错误凭据。

协议参数不是可互换的标签

Shadowsocks 的加密方法需要与服务器一致；VMess、VLESS 等类型的身份字段及传输设置应照原始信息核对；Trojan 的认证与 TLS 设置也不能由名称推断。HTTP、SOCKS5、WireGuard、Hysteria2 各有自己的参数结构。这里不提供一套通用默认值，因为能在一台服务器上使用的组合，不一定适合另一台。原始信息缺字段时，应先补齐信息再继续。

如果服务器要求 TLS，应区分连接目标与证书校验所使用的名称。Address 决定连接到哪里，相关名称字段可能用于 TLS 握手；两者不一定相同。传输层的 Host、Path 等也可能各有用途，不应凭字面相近而互相替换。遇到证书相关错误，先检查设备时间、主机名与原始设置，不要通过放宽校验来掩盖输入问题。

保存后进行单变量验证

保存条目后，返回 Home 确认选中的是刚添加的服务器，而不是名称相似的旧条目。先做连接测试，再在实际连接状态下访问一个原本就有权限使用的目标。失败时一次只改一个参数，并记录改动前后的结果。若同时修改协议、端口和传输设置，即使后来成功，也难以确定真正原因，下一次恢复时仍可能重犯。

订阅管理的条目不宜长期靠手填修补。如果只是为了比较某个参数，应在确认功能允许的前提下建立独立测试条目，并明确标注用途，避免与订阅中的原条目混淆。完成验证后，保留一份正确的原始参数记录；如果涉及应用获取或首次 VPN 配置授权，查阅iPhone 获取说明，不要把系统授权问题误当成服务器字段问题。

03 / 先看内容，再保存

扫码与剪贴板导入

扫码与剪贴板导入只是减少手工输入的方式，不会自动判断服务器是否适合当前网络，也不会补齐原始内容缺少的参数。两种方式都应遵循同一个顺序：确认内容属于自己的服务器或订阅，查看解析结果，核对关键字段，保存后再测试。不要把“能够被识别”理解为“参数已经正确”，更不要因为扫码成功就直接覆盖现有记录。

Scan QR Code 的操作顺序

准备好已有服务器或订阅对应的二维码，在 Shadowrocket 中打开 Scan QR Code，并按系统提示允许相机访问。让完整二维码处于取景范围内，避免反光、遮挡与过小显示。识别后查看出现的内容：如果解析为单个服务器，重点检查 Type、Address 与 Port；如果解析为订阅，重点检查 URL 与备注。确认结果与原始信息一致，再执行保存。

二维码模糊时，应优先取得清晰的原始图片或原始文字，不要连续缩放后再截取多次。图片经过压缩可能破坏识别所需细节，屏幕亮度过低或反光也可能影响读取。如果二维码就在当前设备上，查看当前入口是否提供读取图片的操作；没有相应入口时，可以使用原始文字导入，不必为了扫码绕过内容核对。

剪贴板只保留一份明确输入

复制时只选中完整分享内容，不要同时带上说明文字、聊天时间、编号或句尾标点。回到 Shadowrocket 后使用当前界面提供的剪贴板导入操作，按系统提示决定是否允许粘贴。若出现预览，先确认它识别的是订阅还是服务器，再核对字段。系统询问是否允许粘贴，是对剪贴板访问的管理，不是服务器连接请求，也不表示已经建立 VPN。

如果复制了一段包含多行内容的文字，导入结果可能与单条链接不同。首次处理时建议先导入一条，确认格式能够被正确识别，再处理其余内容。导入后条目数量异常，先回看原文是否包含重复链接、标题或被折行切开的地址，不要继续多次粘贴。重复执行通常只会增加相似条目，不能修复内容本身的格式问题。

分别处理权限、识别与连接错误

相机打不开时，先检查设备对 Shadowrocket 的相机权限；能打开取景但识别失败时，检查二维码清晰度与内容格式；识别成功但连接失败时，再检查服务器参数与网络。三个阶段的问题互不相同。剪贴板也是如此：拒绝粘贴后读不到文字属于权限问题，能够读取却不生成条目属于解析问题，保存后测试失败才进入连接排查。

完成导入后，用不含敏感内容的普通文字替换剪贴板，减少之后误粘贴的机会。若之前通过截图传递过二维码，还要检查图片是否进入共享相册或自动同步的公共位置。删除图片并不等于使凭据失效；一旦确认内容已经外泄，应在原有服务的管理方式中更换对应凭据，再更新设备上的记录。

扫码添加与其他导入方式最终都应落到同一套验证步骤：看分组、看类型、看目标地址，再选中并测试。首次打开界面不熟悉时，可配合Home 页区块说明阅读。这样能够把导入入口的问题与 Home 上选错服务器的问题区分开，避免因为名称相近而测试了另一条记录。

04 / 链接外形不等于完整配置

分享链接格式与 Config 边界

分享链接把服务器参数编码成一段可传递的文字；订阅地址则指向可能持续变化的清单；Config 描述的是规则及相关配置。三者可能都通过链接传递，但用途不同。导入前先回答“这段内容描述一台服务器、一份清单，还是一份配置”，再选择入口。仅凭以某种字符开头或能够在浏览器打开，不能判断它应当被放进哪个字段。

识别结构，不手动猜解凭据

常见服务器分享内容可能以 ss://、vmess://、vless:// 或 trojan:// 等形式开头。前缀帮助识别协议，但后面的内容未必都以明文展示：有的使用编码数据，有的以地址和查询参数表达，还有的附带用于显示的名称。应优先让应用解析原始内容，再逐项核对结果，不要根据外形自行拼接出一条“看起来差不多”的链接。

一段经过编码的文字并不因此具备保密性。能够导入的内容通常包含连接所需信息，接收者也可能读取这些参数。分享时应把它当作敏感记录，而不是普通书签。二维码只是这段内容的另一种表现形式，不会改变它的权限范围；把链接改成二维码，也不会减少泄露后的影响。

转义、换行与名称的区别

链接中的百分号编码用于表达特殊字符，不应为了方便阅读而随意改写。加号、斜线、等号等字符在不同格式中可能各有意义；聊天工具插入的空格或换行也可能让内容无法完整解析。发现导入结果缺字段时，先比较原始文本的首尾与长度是否完整，再检查是否误带了中文标点，不要首先更改服务器密码来尝试修复。

一些格式使用 # 后面的片段保存显示名称，但是否采用这种方式取决于具体格式。名称写得像某个地区，不等于服务器位置已经得到验证，也不决定连接质量。只改名称通常不会改变连接目标，但手动编辑分享文字可能误触其他参数。日常整理应在应用内修改备注，涉及连接参数时再对照原始信息处理。

规则文件不能替代服务器信息

Config 中的规则决定流量如何被处理，不负责让一组错误的服务器参数变得可用。下面是 Shadowrocket 配置中常见的规则段落，用于说明匹配顺序与策略含义，不是一份可直接替代个人配置的完整文件。实际使用前，应确认所需策略在当前配置中有效，并检查 DNS、服务器及其他设置是否与使用目标一致。

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

第一条按域名后缀匹配，第二条按目标 IP 的归属条件匹配，最后一条承接前面未命中的流量。规则依顺序判断，不能只看最后一行就认定所有请求都会经过所选服务器。要观察规则是否生效，应在 Global Routing 选择 Config，并对照当前实际加载的配置；如果选择 Proxy 或 Direct，判断路径就不能沿用同一套规则预期。

因此，服务器导入成功后若只有部分目标表现异常，应同时检查配置分流，而不是反复重新导入同一条分享链接。反过来，切换 Config 也不能修复认证错误。界面词容易混淆时，阅读Home、Config、Proxy 与 Direct 的区别。把输入格式、服务器连接与路由策略分为三层，能显著减少无效试错。

05 / 更新前后都要观察

订阅更新策略与失败排查

更新订阅是重新请求清单并同步条目，不是更新 Shadowrocket 应用，也不是延长已有服务的使用期限。应用更新由 App Store 管理；订阅更新由当前保存的订阅地址及其响应内容决定。建立稳定的更新习惯，应先验证手动更新能成功，再考虑自动化，避免在链接尚未核对清楚时反复触发请求。

手动更新先用于确认状态

在 Home 找到需要更新的订阅，使用该订阅的更新操作。执行前记下分组名称、当前选中的服务器以及需要保留的本地备注，完成后检查条目是否发生预期变化。不同界面呈现可能调整，应以订阅对应操作项为准，不把滑动方向或图标位置当作判断依据。如果同时有多份订阅，先更新其中一份，确认结果后再处理其余分组。

更新完成不代表当前选择一定仍然有效。清单可能替换了名称相同但参数不同的条目，也可能移除了原来选中的服务器。更新后应重新查看选择状态，并进行一次连接验证。发现条目变化较大时，先对照原有记录与当前响应，不要急着把所有差异都当成错误；服务器维护或清单调整也会造成合理变化。

自动更新要有可验证的前提

如果当前界面提供打开时自动更新或相关更新设置，应先阅读项目说明，再决定是否启用。自动更新依赖触发条件和当时的网络，不应理解为应用在任何时刻都会持续同步。设备没有可用网络、订阅地址暂时不可达或响应解析失败时，打开应用也不保证清单已经刷新。判断依据仍然是更新结果与实际条目，而不是开关是否处于开启状态。

需要稳定使用某条记录时，可以把更新安排在能够立即检查结果的时间，而不是在即将依赖连接完成任务前进行大范围整理。测试成功的订阅可以保留适度更新习惯；长期失败的订阅则应先查清原因，避免把频繁重试当作修复方法。自动更新也不能替代备份，因为错误或意外变化同样可能被自动同步到本地。

按请求、响应、解析的顺序检查

第一步确认设备本身能够正常访问网络，必要时在不同网络条件下分别测试。第二步核对 URL 是否完整、是否已经更换、凭据是否仍然有效。第三步检查返回内容是否为客户端支持的订阅格式。账户登录页、访问提示页或错误文字，即使请求有响应，也不等于得到了服务器清单。不要将这类内容继续导入到 Add Server 的地址字段。

某些订阅地址的访问路径与服务器连接路径并不相同，所以“当前服务器能使用”不能证明更新请求一定能完成。遇到疑似路径问题，先观察当前 Global Routing 与网络环境，逐项验证，而不是直接清空配置。保留仍可使用的本地条目，有助于在排查期间维持原有状态；只有确认数据损坏且已有备份时，才考虑重新建立订阅。

更细的操作顺序见订阅手动更新、自动更新与失败排查。记录问题时只写分组名称、操作时间范围、网络类型与错误现象，不附真实链接。这样的记录足以帮助区分偶发网络问题与持续的格式问题，也便于下一次更新时比较。

06 / 来源关系比数量更重要

多订阅分组、命名与去重

管理多份已有订阅时，目标不是把所有服务器堆进同一个长列表，而是随时知道每条记录属于哪里、由什么方式维护、是否还能恢复。应保留订阅分组与手动条目的区别，用备注表达用途，用清晰的选择状态减少误操作。整理前先完成一次备份，随后只调整一个分组，确认没有影响当前连接再继续。

建立两层命名，不在备注写凭据

订阅名称用来区分清单，服务器名称用来区分清单内的条目。前者可以描述自己的用途，例如“日常使用”或“备用验证”；后者尽量保留足够的原始辨识信息，避免更新后难以对应。不要把完整订阅地址、密码或身份字段当作备注。备注经常出现在 Home、截图与分享预览中，不适合承担敏感记录的保存职责。

如果同一订阅在不同设备上使用，可以保持一致的分组名称，但不要据此认定两台设备的内容已经同步。每台设备仍可能保存不同时间取得的清单，所选服务器与本地备注也可能不同。发生差异时，先对照订阅地址与更新结果，再判断是否需要重新整理，而不是直接复制另一台设备的全部配置覆盖当前设备。

同名条目不一定重复

去重应比较连接参数，而不只比较名称。相同名称可能指向不同主机、端口或传输方式；不同名称也可能最终描述同一组参数。至少应核对 Type、Address、Port 与必要的传输设置，再判断是否重复。认证信息也属于身份的一部分，但比较时应在私密环境中进行，不要为了整理制作一张公开的明文凭据表。

重复导入同一订阅产生的两份分组，通常应保留一份能正确更新的记录，再删除明确重复的另一份。来自不同订阅的相似服务器则不宜草率合并，因为它们的更新来源与维护状态可能不同。保留来源关系，后续才能解释某个条目为什么改名、失效或被移除。清理时以分组为单位逐步验证，比一次删除所有同名条目更稳妥。

区分显示顺序与实际选择

排序改变的是查找体验，不一定改变当前连接所选的服务器。手动调到列表第一位后，还需要确认是否真正选中了它；按测试结果排序后，也不能假设应用自动切换到了最上面的条目。整理完成应查看当前选择标记，再做一次实际连接检查。尤其在多个分组都有相似名称时，先展开目标分组，避免选到旧记录。

如果当前界面支持自定义顺序，可把经常需要查看的分组放在便于找到的位置，同时保留原始记录便于回查。不要为了视觉整齐频繁改写订阅中的所有条目名称，因为更新可能重建这些条目。对必须长期保留的本地说明，应另写私密管理笔记，记录用途、所属订阅及需要核对的字段，而不依赖每次更新都保留备注。

把测试条目与日常条目分开

为了排查创建的手动副本，应加上明确的测试用途说明。排查结束后决定删除还是保留，避免数周后忘记哪一条仍由订阅维护。独立副本不会自动继承原订阅之后的参数变化；即使名称与原条目相同，也可能逐渐变成旧记录。日常使用与临时验证分开，能够减少“订阅已经更新但仍选中了旧副本”的情况。

完成一轮整理后，逐个检查分组是否仍可更新，常用服务器是否能够选中，测试记录是否已经处理。若希望建立更细的整理清单，可接着阅读多个订阅的分组、排序与重复节点清理。遇到条目消失或重复等具体问题，也可以在疑难解答中按现象继续查阅。

07 / 数字只解释一段路径

Connectivity Test、延迟与排序

Connectivity Test 用于观察服务器在当前测试条件下的响应情况，不能单独代表完整使用体验。延迟低通常意味着某个测试过程完成较快，但不直接等于吞吐能力高、长连接稳定或所有目标都能访问。正确做法是先固定测试条件，在已有服务器之间进行比较，再用实际任务验证，不把一次结果当成长期结论。

测试前固定网络与方法

先确认设备处于稳定网络，避免在测试过程中同时切换无线网络与蜂窝网络。检查当前测试设置与目标，保持同一轮比较采用相同方法。测试方式不同，数字的含义也不同：有的侧重建立连接，有的还包含应用层响应。不要把不同方法得到的结果混在一起排序，也不要拿另一台设备、另一时段的数字直接替代当前观察。

在 Home 运行 Connectivity Test 后，先找出明显无法响应的条目，再对可用候选做重复测试。连续几次结果都较稳定，比偶然出现一次很低的数字更有参考价值。测试期间如果设备还有大量其他网络活动，结果可能受到影响；应先减小干扰，再判断差异是否确实来自服务器，而不是本地带宽争用。

超时、波动与实际访问要分别看

显示超时表示当前测试没有在预期时间内得到结果，不足以单独证明服务器永久失效。可能原因包括设备网络中断、测试目标不可达、服务器认证失败或中间路径异常。应先用已知正常的本地网络访问作对照，再检查服务器参数与测试设置。如果所有条目同时失败，先排查共同条件，不要逐台修改密码。

少数条目失败而其余正常时，再针对失败条目核对地址、端口与协议参数。某条服务器测试成功，但实际目标仍无法访问，则应检查 Global Routing、当前 Config 与目标本身的状态。此时盲目重复延迟测试往往不能定位问题，因为测试访问的目标与实际任务可能不是同一个，经过的规则路径也可能不同。

确认路由姿态后再解释结果

在 Config 下，不同目标可能匹配到不同策略；某个网页打开顺利，并不能直接证明当前服务器承担了这次请求。切换到 Proxy 用于排查时，应记录原来的姿态，验证完成后恢复原有设置。Direct 可帮助理解本地网络的直接访问情况，但其结果也不能代替对服务器本身的测试。每次比较都应说明当时采用的姿态。

排序用于筛选，实际任务用于确认

按延迟排序后，从表现较稳定的候选中选择一条，执行自己真正需要的任务，例如访问已有权限的网页或完成一次正常的数据传输。观察首次响应、持续传输与中途重连是否符合需要。不要一次同时测试大量不同内容，否则难以区分目标网站、设备网络与服务器各自的影响。长时间稳定性需要在实际使用中持续观察。

地区名称可以帮助整理，却不是质量保证。地理距离只是影响因素之一，路径、拥塞、服务器负载与目标位置都会改变体验。保留少量已验证的候选，比单纯追求列表中最小数字更实用。测试结果随时间变化，排序不应成为永久固定结论；网络环境改变后，应在相同方法下重新比较。

完成测试后确认最终选中的条目，并保留至少一个已有且验证可用的替代选择，避免为了清理列表立即删去所有其他记录。关于测试数字与真实体验的区别，参阅延迟、地区与协议类型的选择说明。需要排查连接权限或首次授权时，则应回到入门主线处理，不把所有故障归到延迟上。

08 / 能恢复，再删除

删除、备份与恢复验证

删除前先区分对象：单个服务器、整份订阅、Config 与应用本身并不是同一层数据。删除一个条目可能只影响本地列表，删除订阅可能同时影响其管理的整组记录；具体确认提示应逐字阅读。最稳妥的顺序是先保存恢复所需信息，再验证备份可读，最后执行删除。不要把“以后还能想起来”当作备份。

按数据层建立恢复材料

订阅至少需要保留完整原始 URL 与用途说明；手动服务器需要保留全部必要参数；Config 需要保留当前实际使用的配置内容及相关说明。订阅地址可以重新取得当前清单，但不一定能还原过去的名称、顺序与本地修改。配置文件也不一定包含手动输入的全部服务器记录，因此不能只保存一份规则文件就认为所有内容都有备份。

如果当前界面提供导出或备份操作，应先查看其包含范围，再把生成内容存入自己控制的私密位置。不要默认每个导出选项都会包含凭据、订阅、本地选择与应用设置。导出完成后检查文件是否实际保存、能否重新读取、名称是否足以辨认；保存位置不可访问或内容为空，都不构成有效备份。

删除订阅前检查依赖关系

先确认当前连接是否正使用即将删除的条目，再切换到已经验证的其他记录或结束当前连接。若 Config 中通过名称关联了特定策略或服务器，删除前也要检查这些引用是否仍然成立。列表里删除成功，不代表规则已经自动找到替代目标。删除后应重新检查 Home 的选择状态与实际连接，避免保留一个名称存在但目标失效的配置关系。

仅想移除重复记录时，优先处理明确重复的分组，不要顺手清空其他配置。订阅中的单个条目即使被本地删除，后续更新也可能重新出现，因为清单仍然包含它。需要长期减少显示干扰，应先了解当前界面提供的整理能力，而不是依赖反复删除。订阅的内容维护与本地列表清理，应当分开理解。

恢复应从最小范围开始

换机或重新配置后，先从 App Store 恢复应用购买，再恢复个人订阅与配置。购买记录与服务器数据是两件事；取得应用不代表原有订阅、参数和备注必然已经回来。已购项目与适用条件见换机与已购恢复说明。iPhone、iPad 的系统要求及购买适用性均以 App Store 页面标注为准。

恢复个人数据时，先导入一份订阅或一条手动服务器，核对解析结果并完成连接，再逐步加入 Config 和其他分组。如果一开始就覆盖全部设置，出现失败时很难判断是服务器信息过期、配置引用失效，还是某项设备设置不同。成功恢复后，检查备注、顺序与当前选择，不要仅以“文件能够打开”作为完成标准。

备份也要限制访问与定期复核

包含服务器密码或订阅凭据的文件应采用受控保存方式，避免进入公共共享目录。能够读取备份的人，可能获得与原始分享链接相近的访问能力。发送故障信息时只提供必要结构，先移除 URL 中的敏感参数、认证字段与二维码。若确认备份外泄，删除文件只是第一步，还应更换受影响的凭据，并重新生成可靠备份。

日常维护可以按固定顺序进行：先备份，再更新；先核对，再测试；先确认替代记录，再删除。每次只处理一个问题，留下简短的私密变更说明。这样既能保留明确的恢复路径，也能在下一次故障时知道哪些内容发生过变化。首次连接流程见入门指南，按现象查找后续处理方法见疑难解答。