Shadowrocket
订阅与服务器管理手册

01 / Subscribe

Subscribe 入口与首次导入

先确定手中资料属于哪一类

订阅是可再次请求的地址，客户端访问后取得一组服务器信息；单个服务器链接通常只描述一条连接；Config 则决定流量如何匹配规则。三者可能都以链接或文件出现，但管理对象不同。导入前先阅读资料说明，确认对方交付的是服务器订阅、单条分享链接还是配置文件。不要因为一段内容能够在浏览器里打开，就认定它适合填入 Subscribe；登录页面、说明页面和订阅响应并不是同一种数据。

订阅地址从你的服务商处获取。复制时应取得完整的一行，包括问号之后的查询参数；这些参数可能承担身份识别作用，删去后即使域名仍然正确，也可能返回空列表或错误页面。使用聊天软件中转时，重点检查末尾是否被截断、是否带入句号以及换行是否成为实际字符。不要把真实地址粘贴到搜索框或公开讨论区；需要询问问题时，只说明错误类型和经过遮盖的域名即可。

在 Add Server 中选择 Subscribe

1. 打开 Home，进入添加入口，打开 Add Server；在 Type 中选择 Subscribe。
2. 将完整订阅地址填入 URL，为这份来源设置容易辨认的备注，再保存。
3. 等待首次请求结束，回到 Home 检查对应分组，确认列表中已经出现服务器。
4. 选中其中一条服务器，按快速上手步骤完成 Global Routing 与连接验证。

保存订阅条目与成功下载内容是两个阶段。能在 Home 看见订阅名称，只能说明本地已保存入口，不能据此判断远端内容已解析。首次导入后应检查分组是否展开、服务器名称是否完整，以及数量变化是否符合自己的资料说明。若列表为空，先查看请求提示，再核对地址；不要立即重复创建多份同名订阅，否则后续难以判断哪一份保存了正确地址，哪一份只是失败的本地入口。

区分请求失败、内容失败和连接失败

请求失败表示尚未取到订阅响应，可能涉及当前网络、域名解析、地址有效性或访问权限；内容失败表示收到的响应不是可识别的服务器列表；连接失败则发生在已取得服务器之后。排查时依次确认这三层，不要把某条服务器超时当作订阅解析问题。若响应实际是一段网页提示，应根据提示核对账户状态或地址，而不是把网页正文当作配置继续导入。公开排错截图也应遮住完整订阅地址。

首次导入宜在当前可以正常访问订阅地址的网络下完成。如果更新请求被送往一个已经失效的服务器，可能形成“需要先更新才能恢复连接、却要先连接才能更新”的循环。此时先停用失效连接，确认本地网络可用，再重新请求订阅；若服务商明确说明访问条件，则按其资料核对。不要频繁切换所有设置，保留一次失败时的具体提示，才能区分环境问题与资料问题。

02 / Add Server

Add Server 手填字段与协议参数

先选 Type，再逐项填写资料

手动添加适用于已经持有完整服务器参数、需要维护独立条目的情况。进入 Add Server 后先选择 Type，因为协议类型会决定后续可见字段及字段含义。不要先选一个看起来相近的类型，再依靠修改端口尝试连接。Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 与 Hysteria2 的认证和传输方式不同，同一个地址与端口不代表它们能够互换。

Address 通常填写主机名或地址本身，不附加网页路径；Port 填资料给出的服务端口，不把冒号和端口一起放入主机名。若提供的原始内容是一条完整分享链接，优先使用导入方式，避免拆解时丢失隐藏在查询参数中的传输设置。备注只用于本地辨认，不能修复连接参数；建议用来源、用途和协议组成名称，而不是在名称里存放密码或身份标识。

认证、TLS 与传输设置分开检查

Shadowsocks 需要核对加密方法和密码；VMess、VLESS 常使用 UUID 作为身份信息；Trojan 需要密码，并应按资料核对 TLS 与 SNI。HTTP、SOCKS5 是否要求用户名和密码，取决于服务器配置，不能因为界面允许留空就自行省略。WireGuard 的密钥、接口地址和对端信息属于另一套结构，不能把订阅口令填入私钥字段。对不了解的参数，先回查原始资料，而不是在不同协议间轮流试填。

TLS 开关决定是否建立相应的加密会话，SNI 用于该会话中的服务器名称；连接地址也可能是独立的入口域名。若资料把二者分别列出，应按字段分别填写。遇到证书名称不符或握手失败，先核对 SNI、系统时间与原始资料，不要将关闭证书校验作为常规修复。只修改一个参数后重试，并记录结果，避免把原本正确的配置一起改坏。

传输类型及其 Host、Path 等设置也必须成套对应。路径中的前导斜杠、尾部字符和查询部分不能凭直觉增删；输入法产生的全角符号、智能引号和空格同样会改变参数。保存前可将字段与资料逐行对照，尤其检查从图片识别来的数字、字母和连字符。若资料没有某个可选字段，保持该协议的默认状态，不要借用另一条服务器的值来补齐。

保存独立条目，保留修改边界

手动条目与订阅生成的服务器应分开维护。直接修改订阅里的服务器，可能在下次更新时被远端内容覆盖；需要长期保留本地差异时，先明确复制或独立添加的结果是否已脱离订阅管理。保存后先做一次测试，再建立连接验证实际请求。若同一组参数在不同网络下表现不同，应分别记录网络条件，而不是立刻判定密码错误。

排错资料只需保留协议类型、经过遮盖的地址、端口、传输类型及报错，不必公开认证值。Trojan 的具体字段关系可继续查阅Trojan 密码、SNI 与 TLS 参数说明。涉及服务端配置的疑问，应拿原始资料逐项确认；客户端不会通过修改备注自动推断缺失字段。

03 / Import

扫码与剪贴板导入的操作边界

Scan QR Code 只负责读取内容

二维码是一种承载文字的方式，不代表其中一定是服务器资料。Scan QR Code 读到的可能是单条服务器分享链接、订阅地址或普通网页。扫描后先查看客户端准备创建的对象，再决定保存；若只打开网页，应回到资料说明确认二维码用途，不要继续把网页地址填进任意协议字段。二维码也可能包含完整凭据，拍照、转发与相册同步都会扩大这些信息的保存范围。

在 Home 的添加入口选择 Scan QR Code，按系统提示授予相机权限，再让整个二维码进入画面。扫描时保持图案完整，避免反光、过度倾斜和屏幕缩放造成的模糊。若二维码显示在同一台设备上，只有在扫描入口明确提供相册读取功能时才从图片导入；没有该入口时，改用资料同时提供的文字链接。不要为识别二维码而把包含凭据的图片提交给外部识别页面。

剪贴板导入前先整理原始文字

复制完整分享链接后返回 Shadowrocket，使用界面提供的剪贴板导入入口；系统询问粘贴权限时，再根据本次操作决定允许。复制来源如果同时带有标题、说明和多个链接，应先确认客户端能够识别哪些内容。对于失败的批量导入，可先只复制一条完整链接做验证，借此区分格式不支持与混入说明文字的问题。不要通过反复授权来代替检查实际复制内容。

1. 从自己的资料中复制一条完整链接，检查开头协议与末尾备注是否都在。
2. 进入剪贴板导入入口，读取预览或结果提示，确认生成对象的类型。
3. 保存后到 Home 查找新条目，检查协议、地址与所属分组。
4. 完成后清理临时中转内容，避免下一次粘贴时误发凭据。

聊天软件可能将长链接显示成折叠文本，屏幕上看起来只有一行并不意味着复制到了全部内容。部分编辑器还会把直引号改成弯引号，或在链接中间插入换行。此时应回到原始文本，使用复制链接或复制原文的方式重试。若必须经过文本中转，选择能够保留纯文本的本地工具，并避免启用自动公开分享；只处理自己的资料，不保存他人的认证信息。

识别成功之后仍要核对字段

导入成功说明解析器找到了可识别结构，不等于全部字段都符合服务器要求。保存后至少检查 Type、地址、端口及 TLS 或传输相关设置，尤其注意备注中提到的用途是否与字段一致。二维码来自图片裁切、识别文字或多次转发时，更应与原始参数核对。若扫描结果和文字链接生成的条目不同，暂时停止连接，先确定两份资料是否确实描述同一个对象。

重复扫码或重复粘贴可能生成多个独立条目，也可能表现为更新已有对象，具体取决于入口与内容。不要仅凭名称认定已经覆盖：回到列表检查来源、分组和条目详情。批量导入前记录原有分组，导入后先检查新增内容，再删除失败的中间结果。如果已有稳定条目，保留到新条目经过实际验证之后，避免因为误删而失去对照基线。

相机权限失败、粘贴权限拒绝和内容解析失败属于不同问题。前两者在系统权限中处理，后者需要检查链接类型、编码和内容完整性；授予更多权限不会让错误格式变成有效服务器。若扫描入口正常但图案始终无法读取，可降低显示屏反光、放大原始二维码或改用文字资料。不要手工猜补二维码里缺失的认证字符，缺失时应重新取得自己的完整资料。

04 / URI

分享链接格式与 Config 的区别

按结构识别，不按链接长度识别

分享链接通常由协议前缀、认证信息、目标地址、端口、查询参数和备注组成。不同协议使用的封装方式并不完全一致：有些字段直接可读，有些经过编码，有些将一组参数封装后再编码。不能把一条链接中的用户名位置机械地套到另一种协议上，也不能以“内容像乱码”为由随意删除编码段。识别时先看协议前缀，再交给对应的导入入口处理，手工分析只用于核对资料结构。

订阅 URL 则通常使用 HTTP 或 HTTPS，由服务器在请求时返回列表内容。URL 看起来像网页链接，并不能说明它是配置文件；响应类型和资料用途才是判断依据。将订阅地址添加为普通 HTTP 代理会创建错误对象，因为 HTTP 代理字段描述连接端点，而不是下载服务器列表的位置。同样，将 Config 文件放进 Subscribe，也不会自动把其中的规则转换成服务器。

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

trojan://[email protected]:443?security=tls&sni=example.com#Personal-Trojan

上面只展示结构，域名、口令与订阅参数均为教学假值，不能用于连接。第一个例子代表可能用于获取列表的地址，第二个例子展示单条 Trojan 分享链接的组成方式。实际资料可能包含额外参数，应完整保留，不要为了使它与示例一致而删改。链接里出现的井号通常引出备注片段，问号之后通常是参数，但具体支持范围仍以对应协议和客户端解析结果为准。

编码不是加密，备注不是认证

百分号编码用于表达某些特殊字符，部分分享格式还使用 Base64 编码。编码后的文本仍可能还原出密码和服务器信息，因此不能作为脱敏结果公开。密码如果含有特殊符号，需要由正确的导出或编码过程处理；直接把包含分隔符的口令拼进链接，可能改变解析边界。遇到导入后字段错位，优先使用原始分享链接重新导入，而不是不断增加转义字符。

备注与服务器身份也应分开理解。两条链接可以使用相同备注，却指向不同地址或采用不同认证；同一个服务器也可能因为备注不同在列表里出现多次。比较时应查看实际字段，而不是只比较井号后面的名字。若要向他人说明格式问题，可重新构造一条使用假域名和假口令的结构示例；仅把备注改成“测试”并没有删除敏感内容。

Config 管理规则，不代替服务器资料

Config 决定请求按什么顺序匹配策略。Global Routing 的配置姿态 Config 使用规则，代理姿态 Proxy 与直连姿态 Direct 则用于不同的全局处理方式。服务器导入正常但访问路径不符合预期时，应检查当前姿态和生效配置，不要再次导入相同服务器。下面是用于理解顺序的规则片段：先匹配指定域名，再匹配地域规则，最后由 FINAL 接住没有命中的请求。

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

这段内容不是订阅，也不是可独立完成连接的服务器资料。PROXY 代表相应的代理策略，实际可用性仍取决于已选服务器及配置上下文；DIRECT 表示相应请求直接连接。规则按顺序判断，前面命中后通常不会再继续向后寻找更合适的结果。因此，维护服务器与维护规则应分别备份、分别测试，一次只改变其中一类，才能看清问题出在连接端点还是流量选择。

需要解释 DOMAIN-SUFFIX、GEOIP、FINAL 或其他界面词时，可对照术语表。处理链接失败时先判断对象，再检查结构，最后检查字段；不要通过更换无关规则来修复格式错误，也不要把导入后的名称显示正常当作认证信息已经正确的证据。

05 / Update

订阅更新策略与失败后的处理

更新的是来源内容，不只是延迟数值

更新订阅会重新请求来源，并据返回内容调整其管理的服务器。地址、端口、认证、传输设置和名称都可能变化；这与重新测试列表延迟不是同一种操作。测试只观察当前保存的条目，无法取得远端已经更换的新参数。出现一组服务器同时失效时，先判断是否需要更新资料，再判断网络；不要只反复测试旧条目，误以为客户端已经同步了来源变化。

建立更新习惯时，应先在可以观察结果的情况下手动完成一次。更新前确认当前使用哪份订阅、哪条服务器，以及是否存在本地修改；更新后检查来源分组、当前选中项和实际连接。若界面提供自动更新选项，再按自己的维护需求启用，不要假设所有平台都在相同时间后台更新。系统后台限制、网络状态和客户端是否运行，均可能影响实际请求时机。

按使用变化确定更新节奏

合理节奏来自资料的变化频率和使用场景，而不是越频繁越好。长期稳定的来源可以在使用前或收到变更通知后检查；出行、切换网络或准备迁移设备时，可提前更新并验证。短时间反复请求既不能修复错误地址，也可能遇到来源侧的请求限制。若界面没有明确显示后台行为，采用手动检查和结果验证，比依赖未经确认的自动刷新假设更可靠。

1. 更新前记录正在使用的来源和条目，必要时先备份本地独立配置。
2. 只更新一份订阅，观察请求提示与分组变化，暂时不要同时调整规则。
3. 确认原选中条目是否仍然存在，检查新参数后进行一次测试。
4. 重新建立连接并验证真实请求，正常后再处理下一份来源。

订阅生成条目的手工修改，可能在后续更新时被覆盖；名称、排序和分组的保留情况也应以实际结果为准。需要长期保留的差异应记录在独立维护的对象中，而不是寄希望于每次更新都记住本地字段。若来源删除了某条服务器，本地缓存仍能显示它，也不代表它继续有效。不要为了保留熟悉的名字而忽略认证或端点已经发生变化。

把失败拆成四个检查层次

第一层检查本地网络是否能够正常发出请求；第二层检查订阅域名能否解析并建立连接；第三层检查来源是否返回了有效内容；第四层检查内容是否可被当前入口解析。每一层需要的证据不同：连接错误与身份失效提示不能混为一谈。若收到权限相关提示，应重新核对自己的订阅地址和账户状态；若收到普通网页，应确认是否误复制了管理页面，而不是服务器订阅。

更新后列表突然为空时，先停止删除操作。检查分组是否折叠、筛选是否隐藏内容，再查看更新是否完成以及来源是否确实返回空结果。若只是显示问题，重新导入会制造重复；若来源内容确实变化，恢复旧缓存也未必恢复使用。保留更新前的必要记录有助于比较，但不要在公开渠道上传原始响应，因为其中可能包含全部服务器密码与访问令牌。

更新成功但连接失败时，将问题移到服务器与网络层排查。先选择一条已更新条目，核对协议参数，再测试其他同来源条目；若只影响一条，通常不应重建整份订阅。若所有来源都同时失败，还要检查当前网络和系统时间。可继续阅读节点超时与连接失败排查，按固定顺序收集证据，避免在多个页面之间反复重置设置。

06 / Organization

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

以来源分组，以用途命名

同时管理多份自己的订阅时，首先保留来源边界，而不是把全部条目混成一个长列表。每个来源应有稳定、容易理解的本地名称，独立手填条目也应有单独标识。这样在更新失败、参数变化或需要删除时，能够明确影响范围。名称可说明用途和维护方式，但不要填入完整订阅地址、账户识别信息或密码；这些内容一旦出现在列表截图里，便可能随普通排错资料外传。

分组命名应表达相对稳定的信息。把瞬时延迟写进名称，下一次网络变化后便会失真；把当前排序序号写进去，也会在更新后产生混乱。更合适的做法是用简短来源代号、用途与协议说明辅助辨认，同时保留原始资料的对应关系。若客户端只允许修改部分显示信息，应接受其边界，不要为了统一外观而改动服务器认证字段。

先判断重复，再决定保留对象

同名不等于重复，同地址也不一定是重复。相同目标可能使用不同端口、协议、认证、传输或 SNI；同一份来源也可能列出服务于不同网络条件的入口。整理时先比较关键字段与来源关系，再考虑删除。若两条记录只在备注上不同，仍应确认其中一条是否由订阅管理、另一条是否是独立副本，因为删除独立副本与删除订阅内条目会产生不同的维护结果。

批量整理宜分两轮完成。第一轮只记录并标识疑似重复项，不立即删除；第二轮逐组确认当前连接、备用对象及备份情况，再执行删除。对于经订阅导入的服务器，远端下次返回时可能重新生成本地删掉的条目，因此反复手动清除不一定能形成持久结果。若界面提供筛选或显示整理功能，先确认它只影响显示还是改变实际数据，再决定是否使用。

把订阅管理与规则策略分开

来源分组说明服务器从哪里被导入，规则策略说明请求将如何被处理，二者不必一一对应。将两份订阅放在不同列表组里，并不会自动给它们分配不同域名流量。需要规则选择时，应在 Config 与相应策略上下文中检查配置，不要依靠分组名称推断路由。先保持服务器资料正确，再调整规则，可以减少“列表整理后访问变化”这类难以定位的连带问题。

更新某份来源后，应复查正在使用的条目是否仍属于预期分组。若一个名称被远端重复使用，先查看详情再切换，避免把熟悉名字当作稳定身份。暂时保留的旧条目可以记录用途和待确认事项，但不要让过期副本与当前来源长期混在一起。维护记录应说明为什么保留、什么条件下再检查，而不是简单标记一个含义不明的星号。

多订阅并不意味着需要同时测试所有条目。可以先对每份来源选少量代表进行检查，确认导入和更新关系正常，再按用途查看其余内容。来源数量增加后，最重要的是操作可追溯：哪一份刚更新、哪一项刚修改、哪一组待删除。一次只处理一组，确认后再继续，可以避免批量操作造成大范围误删，也便于在出现问题时回到前一个已验证状态。

进一步的分组与清理流程可查阅多订阅管理说明。整理的目标是减少辨认成本和维护歧义，不是追求列表尽可能短；对用途尚不清楚的条目，先记录并验证，比直接清空后重新导入更容易保留上下文。

07 / Connectivity Test

延迟测试、排序与实际连接验证

测试结果只回答对应测试的问题

延迟测试是当时网络与测试方式共同作用的结果，不是服务器永久性能标记。TCP 建连、经过代理的请求与真实业务访问检查的环节不同，因此数值不能跨方式直接比较。开始前先确认客户端当前使用的测试设置，再在同一网络、相近时间和相同方法下比较条目。列表显示一个较小数值，并不能说明认证、TLS、域名解析和目标网站访问全部成功。

进行 Connectivity Test 前，先让订阅资料处于已确认状态。测试过期参数得到的结果，对当前来源是否可用没有判断价值；更新失败后也不要把旧列表的超时当作新资料失效。选择一条对象做单项测试，再决定是否测试整组，能够避免批量请求造成等待和结果混杂。测试期间暂时停止大文件传输等明显占用网络的操作，让不同条目获得相对接近的测量条件。

用范围判断问题所在层次

只有一条服务器超时，先核对该条目的地址、端口和协议参数；同来源多条失败，检查资料是否已更新以及来源是否发生变更；不同来源全部失败，则优先检查本地网络、系统时间及当前连接状态。若切换网络后恢复，记录两种网络的差异，不要立刻重写所有认证信息。故障范围比单个延迟数值更有用，它能决定下一步应查客户端字段、远端资料还是本地环境。

排序适合缩短查找时间，但不应代替选择依据。测试结束后可以按当前测量结果排列同类条目，优先验证靠前的候选；尚未测试、失败与已有数值的条目应分别理解。不同协议、不同测试方法或不同时间得到的结果，不宜混排后直接宣布某条始终更好。需要稳定记录时，写下网络条件和测试方法，而不是只保存一个脱离上下文的数字截图。

测试通过后，仍需验证路由与真实请求

选中服务器后建立连接，再确认 Global Routing 当前姿态。配置姿态 Config 会按规则处理，代理姿态 Proxy 侧重代理路径验证，直连姿态 Direct 则不适合作为服务器代理可用的证明。如果某个目标在 Config 下被规则送往 DIRECT，那么它能够打开，并不能证明当前服务器工作正常。验证应使用自己的正常访问需求，并结合连接记录判断实际命中方式，而不是只观察顶部开关。

真实请求失败时，检查连接记录中的错误类型和策略命中，再决定下一步。域名解析错误、TLS 握手失败、认证失败与目标拒绝访问，需要的处理并不相同。不要仅凭“浏览器转圈”就认定服务器超时，也不要因为某个目标失败而删除整份订阅。先用另一项正常需求做对照，再检查是否只影响特定域名、特定协议或特定网络，逐层缩小范围。

对于间歇性问题，保留少量可比较记录比连续点击测试更有效。每次只改变一个因素，例如网络、服务器或 Global Routing 姿态，完成后再观察；同时修改 DNS、规则与认证会让恢复原因无法确认。测试界面里的超时也不等于服务器已被永久移除，删除之前应结合更新情况与跨网络复查。长期不用的疑似失效条目，移入待确认记录后再安排清理。

更完整的错误分支见节点超时、协议参数与系统时间排查。验证通过后再设置自己需要的 On Demand 条件；自动触发连接只改变连接时机，不会修复错误参数，也不能替代手动完成的一次完整连通性检查。

08 / Backup

删除、备份与换机后的恢复顺序

删除前先确定对象与影响范围

单个服务器、整份订阅和 Config 是不同对象。删除独立服务器通常只影响该条本地记录；删除订阅入口可能连带影响由它维护的服务器；删除 Config 则影响规则与策略设置。操作前读清确认提示，并检查当前连接是否依赖将要删除的对象。不要用删除订阅的方法清理一条失败服务器，也不要为恢复列表显示而先清空配置，这会让原本局部的问题失去排查基线。

订阅内某条服务器删掉后，下次更新可能重新出现，因为来源仍然包含它。这不一定是删除失败，而是本地记录再次按来源生成。若不再使用整份来源，应先确定其备份与替代连接，再删除对应入口；若只是暂时不想看到某些条目，应核对界面是否支持显示层面的整理。删除前记录维护关系，比删除后凭名称猜测哪些服务器原本属于哪组更可靠。

按恢复需求准备备份

备份至少要回答三个问题：能否重新取得订阅、能否恢复独立服务器、能否恢复规则。只保存订阅地址，可能恢复不了手填条目与本地 Config；只导出规则文件，也未必包含服务器认证。使用导出功能时，检查实际包含的对象范围，不要把“文件已生成”等同于“全部资料已保存”。备份文件往往含有敏感内容，应存放在自己控制的受保护位置，避免公开共享和随意转发。

1. 记录现用订阅来源与必要维护说明，将完整凭据放在受保护的位置。
2. 备份独立服务器与 Config，确认导出内容范围和文件是否可以正常读取。
3. 记录当前 Global Routing 姿态及需要重新检查的 On Demand 条件。
4. 在旧设备仍可使用时验证恢复步骤，成功后再清理旧资料。

如果采用 iCloud 同步，应先确认自己的设备、账户及实际同步对象是否满足条件，不要把所有本地资料都假定为自动同步。同步强调状态在设备间传递，备份强调保留一个可回退的副本，二者用途不同；一次误删也可能被同步传播。因此，在批量清理、重建分组或换机前，应另外保留可识别的独立备份，并注明包含哪些对象，避免恢复时选错文件。

先恢复资料，再验证规则与自动连接

新设备应先完成客户端获取，再恢复一份订阅或少量独立服务器，确认基础连接正常后恢复 Config，最后检查 On Demand。不要一次导入全部资料后立即启用自动连接，否则错误规则、失效认证与系统触发条件会交织在一起。系统的 VPN 相关授权需要在新设备按提示处理，旧设备连接正常并不代表授权状态会被直接迁移。迁移期间保留旧设备，便于逐项对照。

恢复后的订阅应重新更新，独立条目应重新核对，规则则要验证引用的策略是否仍然存在。名称相同不保证对象身份相同；如果迁移后的配置引用了已不存在的分组，应先修正对应关系，再进行真实请求测试。备份成功的判断标准不是文件数量，而是能够按明确顺序重建可用状态。记录一次实际恢复结果，可以减少下一次换机时重复摸索。

涉及客户端获取时，iPhone / iPad 版在 App Store $2.99 一次性付费，Mac（Apple 芯片与 Intel）、Windows、安卓、Linux 版免费；安装与系统放行请按下载页说明操作，其他平台安装包由本站 /dl/shadowrocket/ 路径提供。iPhone / iPad 的已购恢复与系统要求见下载页对应章节，账户购买记录与订阅认证应分别管理。

完成新设备验证后，再按自己的设备处置流程清理旧设备中的订阅、服务器、导出文件、二维码图片和剪贴板中转内容。若凭据曾经暴露，应按资料管理方提供的方法更换，单纯删除本地文件不会使已泄露的地址或密钥失效。更细的迁移检查可参阅配置备份与换机迁移；日常操作则回到使用教程按连接主线复核。