官方手册 · 节点管理
Shadowrocket
订阅与服务器管理
从一条已有订阅，到可维护、可测试、可恢复的服务器列表。
本页是系统查阅手册，适合按问题定位章节；使用说明提供首次导入、选择 Global Routing、开启连接与验证的快速上手主线。已经完成首次连接的用户，可以直接查阅更新、整理和备份章节。
全文以用户已有自己的订阅或服务器信息为前提。客户端一次性买断 ≠ 线路套餐。本站是 Shadowrocket 官网与官方手册，不提供、不销售、不推荐节点或订阅。应用唯一获取入口为 App Store，购买与正版核验请参阅下载说明。
- 8 个管理主题
- iPhone / iPad 操作
- 界面词保留英文
01 / SUBSCRIBE
Subscribe 订阅导入
订阅是可重复访问的服务器信息入口，不是某一台服务器的地址。导入时，Shadowrocket 请求该入口，把返回的受支持内容解析为服务器条目。此后更新同一订阅，列表可能增加、减少或替换条目。因此，管理订阅首先要辨认“入口”和“结果”：入口决定下一次从哪里取数据，结果才是 Home 中可以选择的服务器。仅有显示名称，不能证明入口正确或内容完整。
导入前先确认信息类型
准备用户已有的完整订阅链接，确认复制内容来自自己的订阅资料，而不是账户页面地址、说明页面地址或单个服务器分享链接。订阅入口可能包含查询参数，这些参数也是地址的一部分。复制后不要自行删去问号后面的内容，也不要把聊天软件附带的中文说明、句号或换行一起粘贴。若资料分别给出了订阅入口和账户登录页面，两者不能互换。
在 Home 点击添加入口，进入 Add Server 后将 Type 设为 Subscribe，再把完整链接填入 URL。若当前界面提供订阅专用入口，也可以由该入口进入；判断依据是最终填写订阅地址，而不是手动填写服务器端口。给订阅设置容易识别的备注，例如用途与来源代号，再保存并等待获取结果。按钮位置和可选项以当前应用内界面为准，不根据图标位置猜测功能。
首次获取后检查三个层次
第一层检查订阅本身是否保存成功，重新进入编辑页面核对地址是否完整。第二层检查订阅下是否出现服务器，观察名称、协议类型及分组归属，而不只看是否有成功提示。第三层选择其中一项做连接验证。订阅能够保存、订阅内容能够解析、服务器实际能够连接是三个不同结果，不能用其中任何一个代替另外两个判断。
如果获取后列表为空，先保留现有条目，记录错误提示与发生阶段。地址能够在浏览器中打开，也不代表返回的是可解析的订阅内容：服务器可能返回登录页面、访问限制说明或空响应。反过来，浏览器显示一段难以阅读的文本，也不能据此判定内容损坏。应结合应用的解析结果以及用户已有资料中注明的格式确认，不要把完整响应发到公开讨论区。
订阅列表不等于规则配置
Subscribe 主要解决服务器信息的获取与维护；Config 中启用的配置则决定规则、策略及相关行为。导入订阅后，不应假定所有网站都会使用新服务器。还要检查 Global Routing 的当前选择、实际选中的服务器，以及配置中的策略引用。需要建立第一次连接时，沿快速上手步骤依次验证，比同时修改订阅与规则更容易判断问题。
同一链接反复导入可能形成多个管理入口，使之后的更新、删除和排错变得混乱。再次添加之前，先在列表中寻找原有订阅并尝试更新。只有需要保留独立测试副本时，才明确标记副本用途。遇到空列表的分支排查，可继续阅读订阅导入失败或为空的自查；已经导入的旧列表应先保留，避免诊断时失去可用参照。
02 / ADD SERVER
Add Server 手动填写字段
手动添加适用于用户已经拥有一台服务器的完整连接信息，或者需要逐项核对某个条目的情况。先在 Add Server 选择正确的 Type，再填写该协议显示的字段。协议选择不是名称标签，它会决定认证方式、数据封装和连接参数。不能因为两个条目都使用密码，就把 Shadowsocks 与 Trojan 互换，也不能用更改端口的方式把一种协议改成另一种协议。
地址、端口与认证分开核对
服务器地址一般是域名或 IP 地址，应按字段要求填写主机部分，不要把网页地址中的路径直接放进去。端口是服务端监听的端口，并不是任意可选数字。备注只用于辨认条目，不参与认证；把用户名填在备注里，或者把显示名称当作主机名，都不会建立正确连接。填写后先离开键盘，逐项对照原始资料，尤其注意首尾空格与视觉相似字符。
| 信息类别 | 填写依据 | 常见混淆 |
|---|---|---|
| Type | 原始资料注明的协议 | 按名称猜协议 |
| Address / Port | 服务器主机与监听端口 | 把完整网页地址当主机 |
| Password / UUID | 协议要求的认证值 | 截断、混入空格或换行 |
| TLS / SNI | 服务端给出的安全连接参数 | 把连接地址与证书名称混同 |
| Host / Path | 传输层的约定字段 | 自行补写或省略路径 |
协议参数应成组对应
Shadowsocks 的加密方法与密码需要同时匹配，不能只确认密码正确就跳过加密方法。VMess、VLESS 常见的身份字段为 UUID，还应检查资料中给出的传输方式。Trojan 的密码与 TLS 相关字段各有作用。HTTP、SOCKS5 如需用户名与密码，应分别填写；资料没有要求认证时，不要凭空增加一组值。具体可用字段随所选协议和当前界面变化，以实际显示为准。
启用 TLS 时，连接地址与服务器名称可能并不相同。SNI 用于 TLS 握手中的服务器名称，证书校验还涉及服务端证书所覆盖的名称。使用 IP 作为连接地址，并不意味着 SNI 也要改成该 IP。遇到证书错误，应先核对名称、设备时间和原始资料，而不是直接关闭校验。关闭校验会改变信任边界，也不能修复错误密码或错误传输路径。
如果资料指定 WebSocket 等传输方式，Host 与 Path 应连同传输选项一起核对。路径通常具有大小写和斜杠语义，多一个空格或少一个前导斜杠都可能导致握手失败。Hysteria2、WireGuard 等协议还有各自的专用参数，不能用另一协议的字段表替代。缺少必要信息时应先补齐已有资料，不采用“逐项试开所有开关”的方式排错。
保存后保留可比较的原始条目
对于已有但不能连接的服务器，先复制或记录当前字段，再一次只修改一个可疑参数。若同时改动地址、端口与 TLS，连接结果变化后很难知道是哪一项起作用。手动维护的条目应采用单独备注，避免与订阅下的同名条目混淆。订阅管理的条目可能在更新后被重新生成，本地临时修订未必会保留，不能把它当作长期维护方式。
03 / IMPORT
Scan QR Code 与剪贴板导入
二维码与剪贴板只是传递文本的方式，并没有改变服务器信息本身。一张二维码可能装着单条分享链接，也可能装着订阅地址；一段复制内容也可能只是说明文字。开始操作前，应先判断要导入的对象，再检查应用解析后出现的是一个服务器，还是需要获取内容的订阅入口。识别成功只说明文本被读出，不能直接证明其中参数完整或服务可用。
扫码时先提高可读性
在应用中使用 Scan QR Code，对准用户已有资料中的二维码，尽量让四个边角完整进入取景区域。避免反光、倾斜和过度缩放；另一台设备显示二维码时，可适当提高显示亮度并保持稳定距离。若二维码包含较长链接，图案会更密集，压缩过的聊天预览图可能无法准确识别，宜使用原始清晰图像，而不是反复扫描同一张模糊预览。
相机权限被拒绝时，到系统设置检查 Shadowrocket 的相机访问权限，再返回应用重试。权限问题与二维码内容问题要分开判断：完全不能取景通常先查权限，能够取景但始终没有识别结果则先查图像质量。若当前应用入口支持从相册读取二维码，可按界面提示选择已有图片；没有显示该入口时，不应假定所有扫码页面都具备相同操作。
剪贴板导入只复制目标内容
复制前确认选中了完整链接，特别是长文本在屏幕边缘折行的部分。视觉换行不一定是实际换行，但手动拼接时可能引入额外空白。回到 Shadowrocket 后使用当前界面提供的剪贴板导入入口，或把订阅地址粘贴到 Subscribe 的 URL。系统询问是否允许粘贴时，确认本次操作确由自己发起再允许；拒绝后没有内容进入，不应误判为协议不受支持。
从笔记或消息复制内容时，常见问题是把链接前面的序号、后面的解释，以及包裹链接的引号一起复制。先在本地确认首尾边界，再重新复制。不要为了“清理”地址而删除其中的百分号、等号、加号或问号；这些字符可能属于编码和参数。若平台把原文替换成了短摘要或截断显示，应回到原始资料复制，而不是依据预览文本补全。
导入后按字段而不是按数量验收
解析出条目后，打开编辑页面核对 Type、主机、端口和认证字段是否与原始资料一致。二维码可能对应旧参数，显示名称也可能与当前订阅中的名称相同，所以“列表里多了一项”并不是足够的验收标准。若重复导入形成多个同名条目，先分别检查归属和关键字段，保留验证通过的条目，再清理明确重复项，不要在辨认之前批量删除。
扫码得到订阅地址时，后续仍然需要一次网络获取；扫码得到单条分享链接时，通常只创建本地服务器条目。前者应按订阅获取错误排查，后者应按字段解析或连接错误排查。若扫码后跳到网页而不是出现服务器信息，也应先确认二维码承载的内容类型。不要把网页中的任意地址都再作为服务器地址填写，这会把入口问题变成字段问题。
导入和连接之间仍有选择服务器、确认 Global Routing、允许系统 VPN 配置等步骤。首次操作可回到使用说明继续完成主线。若扫码与手动填写导入的是同一条信息，却得到不同结果，应优先比较两份条目的字段，找出解析差异，而不是反复切换网络掩盖差异。
05 / UPDATE
订阅更新与失败回退
订阅更新的目标是重新获取入口当前提供的服务器信息，而不是修复所有连接问题。服务端调整地址、端口、认证或可用条目后，更新可以把这些变化带到本地；如果问题来自设备网络、当前规则或系统授权，单纯更新订阅通常不会解决。开始前先描述现象：是获取失败、列表变化，还是已有条目连接失败。现象不同，后续检查顺序也不同。
建立可追踪的更新过程
更新前确认当前选中的服务器及其所属订阅，记录几个关键名称，必要时先备份。随后只更新目标订阅，不要同时更新所有分组并修改规则。操作完成后，先看是否出现错误提示，再检查列表是否变化，以及原来选中的条目是否仍然存在。某个名称消失可能是入口返回内容改变，不一定是本地误删；名称不变也不能证明背后的地址和凭据没有改变。
如果更新需要网络请求，应先确认设备当前能够访问该订阅入口。某些情况下当前连接路径会影响访问结果，因此可以在安全可控的前提下比较不同网络状态，但每次只改变一个条件。不要把连续点击更新当作检测方法；短时间重复请求可能遇到限制，也会让错误提示相互覆盖。第一次失败后先记录原因，再进行有针对性的重试。
按获取、解析、使用分层处理
获取失败时，检查地址是否完整、网络是否可用，以及入口是否仍有效。解析失败时，重点确认返回内容是否为受支持的订阅数据，是否变成登录页或提示文字。更新成功但连接失败时，则检查新的服务器字段、选中状态与规则策略。三种情况应分开记录；“订阅更新成功”只证明获取和解析达到某个结果，不等于每台服务器都已经通过实际访问测试。
当入口轮换了认证参数，旧列表可能暂时显示正常名称，却已无法建立连接；相反，更新请求失败后，旧条目可能仍可使用。保留现有列表有助于判断变化发生在哪一层，但不要把本地缓存当作长期保证。若更新结果异常，先停止后续批量操作，核对入口状态和原始资料；不要立即删除整个订阅，再用同一条尚未确认的地址重建。
更新频率与本地修改的关系
更新频率应围绕实际变化安排，例如收到已有订阅资料的变更说明、发现条目失效或准备迁移前进行一次核对。若当前界面提供自动更新设置，再结合设备网络和使用习惯决定是否启用。自动更新并不保证每次都能成功，也不替代结果检查。使用受限网络或需要节约流量时，应理解后台获取仍然属于网络请求，而不是本地刷新。
对订阅下的条目做本地修改前，先明确更新可能覆盖这些变化。长期使用的个别定制，适合在应用支持的情况下保存为独立条目，并标注其维护方式；原订阅仍按原入口管理。不要把同一份服务器信息同时当作自动维护和手动维护对象，否则更新后难以分辨哪个字段应以哪份资料为准，也容易在排错时测试到不同副本。
应用更新与订阅更新也应分开理解。前者由 App Store 管理，后者获取用户已有的连接信息；更新应用不会自动补齐缺失的订阅，更新订阅也不会改变应用本身。购买、重新获取应用及系统要求参阅已购恢复说明，连接和解析现象可继续查阅常见问题。
06 / ORGANIZATION
多订阅整理与策略对应
管理多个已有订阅时，首要目标不是把条目合成一张更长的列表，而是保留可追踪的归属关系。每个订阅都应能回答三个问题：从哪个入口更新、哪些服务器属于它、当前使用的条目由谁维护。缺少归属时，同名服务器可能来自不同入口，更新其中一个却误以为另一个也已同步，之后的测试、删除和备份都会出现判断偏差。
先命名分组，再命名例外
给订阅使用简短且稳定的备注，例如“日常资料 A”“测试资料 B”，以用途和自定代号区分，不在名称中放完整地址或认证值。手动添加的条目则明确标记为本地维护。名称最好能够在窄屏上辨认前半段，不要让所有条目都以相同长前缀开头。协议、地区等信息可以辅助筛选，但不应取代来源归属，因为这些信息可能随更新发生变化。
同名不一定重复，异名也不一定不同。确认重复时，应综合比较协议、主机、端口、认证及传输参数；只比较显示名称容易误删。对于不同订阅恰好包含相同连接对象的情况，先决定是否需要保留两个入口的维护关系。保留入口并不要求同时使用所有条目，而删除其中一个本地副本也不意味着另一个订阅会停止返回相同信息。
把列表管理与路由选择分开
服务器列表回答“可以选择哪些连接对象”，Global Routing 回答“请求按什么方式处理”。在 Config 姿态下，还需要理解当前启用配置中的规则与策略。整理好分组之后，应检查常用策略实际引用的是固定条目、当前选择，还是其他配置定义的对象。不要因为某个服务器位于列表顶部，就认为所有规则都会自动使用它。
| 姿态 | 处理方式 | 整理后检查 |
|---|---|---|
| 配置 Config | 按启用配置中的规则处理 | 规则顺序与策略引用 |
| 代理 Proxy | 以代理方式处理请求 | 当前选择的服务器 |
| 直连 Direct | 直接连接目标 | 不要以此验证服务器可用性 |
上表用于区分管理层次，不替代具体配置的检查。尤其在 Config 中，某条请求可能命中 DIRECT，即使当前服务器不可用，该请求仍能成功。反过来，切换了列表中的服务器，也不保证某个固定策略引用随之变化。整理之后应通过实际请求及可见诊断信息确认路径，而不是仅观察连接开关或列表勾选位置。
用小范围变更维持可维护性
一次只整理一个订阅，先改备注和确认归属，再处理明确重复项，最后复测常用请求。每完成一个分组就保留可用状态，避免把更新、重命名、删除和规则调整同时进行。对不确定用途的条目，可先标记待核对，不急于删除。若应用提供筛选或折叠显示，应优先利用这些显示方式减少干扰，而不是为获得短列表直接删掉尚未检查的信息。
订阅更新可能重新生成名称和条目，因此依赖名称匹配的策略也应复查。名称中包含地区或用途的自动选择条件，可能随着命名调整选到不同对象。保存配置前应确认策略仍有可用成员，且没有指向已经删除的条目。只有在理解配置引用方式之后，才适合大范围重命名；如果只是为了便于阅读，先改订阅备注通常影响更小。
多订阅不是连接质量的保证，也不意味着应该逐个全部测试。选择少量有明确用途的候选项，按下一章的方法建立比较条件即可。常用列表之外的条目仍可保留在原分组中，需要时再检查。这样的整理方式既保留更新关系，也减少每次连接前重新辨认大量名称的负担，长期维护时比反复清空重建更容易回溯。
07 / CONNECTIVITY TEST
延迟测试与列表排序
延迟测试提供某种测试方法在某个时刻的响应结果，不能直接等同于网页打开速度、持续传输能力或所有目标的可达性。不同测试方法覆盖的连接阶段不同，因此比较前必须确认方法一致。单次数字较低，只说明该次测试观察到的等待较短；如果实际请求需要额外的域名解析、TLS 握手或目标服务器处理，体感仍可能不同。
先固定测试条件
选定同一网络环境，避免在测试过程中切换无线网络与蜂窝网络。确认设备没有同时进行大量传输，再对同一批候选条目执行 Connectivity Test 或当前界面提供的测试入口。若可以选择方法或目标，应保持相同设置。记录结果时同时记录方法和网络类型，比只记一个数字更有意义；否则下次看到变化，无法区分是服务器变化还是测试条件变化。
TCP 类测试通常更接近检查连接端口的响应，不必然完成协议认证与目标访问；其他涉及实际请求的方法可能覆盖更多阶段，但结果仍与测试目标有关。端口可达不等于密码正确，测试目标可达也不等于所有网站都可达。应按当前应用提供的方法理解结果，不把不同方法的数值直接放在一起排序，再据此得出稳定性结论。
超时、波动与实际体验分开判断
超时不一定表示服务器永久不可用，可能涉及当前网络、解析、丢包、测试目标或服务端状态。先对少量条目重测，并与已知可用对象比较。如果所有候选项同时异常，优先检查设备网络与测试设置；如果只有一项持续异常，再核对该项地址、端口及认证。不要因为一次超时就批量删除，也不要因为一次成功就认定配置没有问题。
在相同条件下间隔进行少量测试，观察是否反复出现显著波动，比追逐最低单次数字更实用。测试过于密集也会产生额外请求，不能无限重复。随后选定候选条目，用常用网站完成实际请求，检查能否持续加载和完成必要交互。实际体验验证应与工作需求相对应，而不是只打开一个很轻的页面，就推断所有业务都没有问题。
排序只改变查看顺序
按延迟排序有助于快速定位候选项，但排序结果通常是测试时刻的视图，不是永久优先级。列表顶部的条目未必就是当前选中的条目，也不必然成为配置中所有策略的使用对象。排序后应重新确认勾选位置与分组归属。若使用了配置中的自动选择机制，还要单独检查其测试目标与选择逻辑，不把手动排序当作策略配置的替代。
地区名称和协议类型也只能提供背景。显示地区可能是维护者的命名信息，并不完整描述请求路径；某种协议在一个网络中表现正常，也不代表换个环境仍然相同。应在自己实际使用的网络上比较，而不是根据名称先下结论。更详细的选择方法可参阅延迟测试、地区与协议类型的判断，重点是保持测试条件可比较。
用诊断信息验证是否走到预期策略
当测试正常而目标访问异常时，先检查请求在 Global Routing 下实际采用的策略。下面的示例表示示例域名使用 PROXY，匹配到中国地区 IP 的请求使用 DIRECT，其余使用 PROXY。规则按顺序检查，示例仅说明逻辑，不适合在未理解现有配置时整段覆盖。不同请求命中不同策略，可能导致同一服务器选择下出现不同访问结果。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY诊断时把“测试能否响应”“协议能否建立连接”“规则是否选中预期策略”“目标是否正常返回”分别记录。这样才能判断该修改字段、切换服务器，还是调整规则。把所有问题概括为延迟高低，会遗漏认证错误、规则误匹配和目标自身异常，也容易在没有必要时破坏原本可用的订阅结构。
08 / BACKUP & REMOVE
删除、备份与恢复验证
删除前应先明确对象是单条服务器、整个订阅，还是 Config 中的配置文件。三者影响范围不同：删除单条可能只影响本地列表，删除订阅会失去对应的管理入口，删除配置则可能改变路由行为。还要区分应用中的本地删除与服务端信息变更，前者并不会自动撤销订阅地址或使已经分享出去的凭据失效。涉及泄露时，需要处理原始凭据，而不只是清空设备列表。
备份按层保存，不只保存截图
第一层是订阅入口与归属备注，第二层是独立手动条目的必要字段，第三层是当前启用的规则配置与需要记录的设置。若当前应用提供导出或备份入口，应先检查导出内容覆盖哪些层，再把文件保存到自己控制的安全位置。不同导出对象可能只包含服务器或只包含配置，不能因为文件成功生成，就假定所有状态都已经包括在内。
截图适合记录勾选位置和操作现象，不适合作为唯一恢复材料。长地址可能显示不全，隐藏的认证字段也不会因为截图而被保存。另一方面，截图中的二维码、订阅参数和密码又可能泄露连接信息。备份应优先保留可恢复的原始数据，并控制访问范围；用于求助的截图则应单独制作，遮住敏感部分，不把完整备份直接发送给他人。
删除前做一次引用检查
确认待删条目不是当前选中的服务器，也没有被常用策略固定引用。对于订阅中的条目，单独删除后，下一次更新可能再次出现；如果目标是停止维护某个订阅，应处理订阅入口本身，而不是逐项删除返回结果。对于手动条目，确认原始参数已经保存在备份中，再进行删除。名称相似时先打开编辑页辨认，避免仅凭列表位置操作。
删除 Config 文件前，先确认当前启用的是哪一份，保存必要内容并准备可用替代配置。仅删除服务器不会自动修正规则中的引用，反过来删除规则配置也不会撤销订阅入口。批量清理时按“备份、核对、少量删除、连接复测”的顺序进行。每一步都能回到已知状态，比一次清空所有内容后再寻找缺失信息更容易控制影响。
恢复后逐层验收
在新设备或重装后，先通过 App Store 获取已购应用，操作说明见已购恢复。应用购买记录与服务器数据是两回事，重新获得应用不等于所有连接信息会自动回来。系统要求及购买适用性以 App Store 页面标注为准。恢复数据时，也不能假定系统备份必然包含所有条目，应检查实际恢复结果。
先恢复一个明确的订阅或手动条目，核对字段并验证连接，再恢复其他分组。订阅重新获取后检查当前列表，不要仅与旧截图比较数量。随后恢复规则配置，确认 Global Routing 的选择、当前服务器与策略引用；最后检查需要的 On Demand 等设置。首次建立连接时，按系统提示处理 VPN 配置授权，不能用恢复文件代替系统权限确认。
旧备份中的入口和凭据可能已经失效，因此恢复失败不一定是文件损坏。应把导入能否完成、订阅能否更新、服务器能否连接分开验证。备份中的名称也可能与新列表不一致，需要重新检查固定引用。恢复成功后保存一份当前状态记录，并明确区分旧备份与已验证的新备份，避免下次误用尚未核对的数据。
保留最少必要副本，并定期清理已经确认不再使用的敏感材料。修改后的规则与手动条目应及时补充到备份，但不需要为每次临时测试留下大量难以辨认的副本。若恢复过程中仍有问题，带着失败阶段、已执行步骤和脱敏提示查阅常见问题；需要重新建立操作顺序时，回到使用说明逐步验证。