Shadowrocket
订阅与服务器管理

先区分订阅、服务器与 Config

订阅地址用于取得一组服务器记录，客户端可以在之后再次请求这个地址，接收新增、移除或参数变更。单条服务器记录描述一个连接端点，通常包含协议、地址、端口和认证信息。Config 则负责配置与规则等内容。三者可能来自同一份服务说明，但作用不同；把 Config 地址填进服务器订阅入口，并不一定能得到可用列表。

开始操作前，先确认手中的内容是完整订阅链接，而不是账户页面地址、介绍页面或某个服务器的分享链接。订阅链接从你的服务商处获取，并按其提供的 Shadowrocket 使用说明选择对应格式。不要根据链接是否以常见文件后缀结尾来判断类型；有些订阅由动态地址返回，真正决定解析结果的是响应内容。

在 Add Server 中选择 Subscribe

进入 Home，打开 Add Server，在 Type 中选择 Subscribe，再把完整地址填入 URL。为该记录设置便于辨认的名称，建议使用用途或来源标识，而不是含有账户信息的长备注。界面布局可能随设备与应用内显示状态变化，操作时以当前可见字段为准；关键是确认 Type 已经切换为 Subscribe，而不是保留在某种单服务器协议上。

粘贴后先从头到尾检查一次。开头的协议部分、域名、路径以及问号后的参数都应保留，末尾不能混入中文句号、引号或换行。部分通信工具会把长链接折成多行显示，显示折行不一定改变原文，但手动分段复制容易漏掉中间内容。尽量使用原始复制操作，不要照着截图逐字输入地址。

1. 核对 Type 为 Subscribe，URL 为完整订阅地址。
2. 保存后返回 Home，确认出现对应订阅记录或服务器分组。
3. 等待读取完成，检查服务器是否归入预期订阅，而不只看名称是否出现。
4. 选择一条记录查看字段，再继续连接与测试。

如何判断导入是否真正完成

保存入口、请求订阅、解析内容和生成服务器列表是不同阶段。入口保存成功只能说明本地记录已建立，不能证明远程内容已经读到。若仅出现一个订阅名称但没有服务器，应先查看更新是否结束，再检查返回内容是否为空或无法解析。不要连续重复添加相同地址，否则会留下多份入口，使后续排查无法确定正在更新哪一份。

首次出现列表后，抽查一条记录的 Type、Address、Port 与认证字段是否符合已有资料。名称通常只是说明文字，不能代替参数核对。导入后服务器数量与原说明不同，也不应立即判定客户端丢失数据；远程订阅可能依据账户状态或使用范围返回不同内容。确认地址与账户状态后，再向你的服务商核实该地址应返回哪些记录。

如果订阅本身能读取，但某条服务器连接失败，应转到参数与测试章节，不必重新创建整个订阅。若所有记录都未生成，则按链接完整性、请求结果、内容格式的顺序检查。两类故障发生在不同阶段，把它们分开记录，可以避免用连接开关反复尝试一个尚未导入完成的列表。

本章处理的是把远程列表登记到本地。关于以后何时更新、更新是否覆盖本地编辑，以及列表为空时应保留哪些证据，见更新策略；想沿着一次完整连接流程操作，可返回快速上手教程继续。

把连接端点与显示名称分开

手动添加适合已有一组明确参数、需要建立单条服务器记录的情况。在 Home 打开 Add Server，首先选择 Type。不同协议显示的字段会变化，因此不要先把全部内容填好再更换类型。切换后必须重新检查认证与传输选项，避免某些字段被清空，或旧输入在新协议下被误读为另一种含义。

Address 是服务器地址，通常填写域名或 IP 地址；Port 是连接端口，必须使用资料中的数值。不要把带路径的网页地址直接填入 Address，也不要从地址末尾猜测端口。显示名称只用于列表辨认，可以按用途命名，但名称中的协议字样不会改变实际 Type。名称正确而类型错误，仍然无法得到预期连接。

认证、TLS 与传输层逐项对照

Shadowsocks 需要按资料核对加密方法与 Password；VMess、VLESS 常见 UUID 字段，但两种协议不能只替换 Type 后沿用全部设置；Trojan 重点核对 Password 与 TLS 相关参数。HTTP、SOCKS5 的认证要求又有所不同。字段是否出现、是否必填，应结合所选协议和当前界面判断，不存在适合所有类型的一张通用填写表。

TLS、SNI、Host 与 Path 分属不同层次。Address 决定连接到哪里，SNI 用于 TLS 连接中的服务器名称，Host 与 Path 则可能参与所选传输方式的请求。它们有时使用同一个域名，但不是必须相同。原始资料没有提供某项时，不要把 Address 机械复制到所有空白字段，也不要根据其他服务器的写法补齐。

遇到证书相关错误，应先核对系统时间、SNI 和服务端证书配置。Allow Insecure 涉及证书校验行为，不应作为常规修复步骤随意启用。证书检查失败意味着需要解释失败原因，而不是只让错误提示消失。对于 WireGuard、Hysteria2 等类型，应完整使用对应参数组，不把它们套进 Password 或 UUID 的简单对应关系。

保存后用最小变更排错

完成填写后，先返回编辑页复查一次，尤其注意密码首尾空格、UUID 中缺失的字符和端口输入。输入法可能把普通标点替换为全角字符，手工转录尤其容易出错。如果资料允许复制，应优先复制原始值。发现错误时一次只修正一个字段，记录修改前后表现，避免同时调整多项后失去判断依据。

如果相同服务器通过分享链接可以正常导入，而手填记录失败，可将两条记录并排核对 Type、认证、TLS 与传输层，而不是先怀疑地址失效。对比时保留一条原始导入记录作为参照，不要直接覆盖它。反过来，手填成功而订阅生成的记录失败，可能需要核实订阅内容是否仍包含旧参数。

保存成功只表示字段被接受，不代表认证与远程服务已经通过验证。接下来选中记录进行 Connectivity Test，再检查 Global Routing 与实际访问结果。Trojan 的字段关系可参阅Address、Port、Password 与 SNI 参数说明；不要把某一种协议的示例当成其他协议的默认配置。

扫码前确认二维码承载什么

二维码可以编码单条服务器分享链接，也可以编码订阅地址，外观不能说明内部类型。扫码成功只表示图像里的文本被识别，并不表示其中的地址可访问或参数有效。已有二维码时，先结合原始说明确认它指向订阅还是单条记录，再使用 Shadowrocket 中可见的 Scan QR Code 入口。

首次调用相机时，系统可能请求相机权限。确认用途后再授权；如果此前拒绝，可在系统设置中检查 Shadowrocket 的相机权限。扫描时让二维码完整进入取景范围，避免边缘被裁切、屏幕反光或图片经过过度压缩。二维码中内容较长时方块会更密集，放大原图通常比反复靠近相机更有帮助。

二维码显示在当前设备上时，可按应用当前提供的图片识别入口处理；若界面没有对应入口，使用已有的原始文本链接导入。不要为了绕过识别问题而把二维码上传到不明网页解析，也不要重新制作一张含有真实凭据的公开图片。保留原始二维码的目的应是恢复操作，而不是作为可公开传播的说明素材。

剪贴板内容要保持单一、完整

使用剪贴板导入时，先从原始资料复制一条完整内容，再回到 Shadowrocket 使用当前可见的剪贴板导入操作。若系统显示粘贴确认，应确认这是刚刚复制的资料。不要依赖剪贴板中很早以前的内容，跨应用复制可能已经覆盖它，跨设备剪贴板也可能带来与预期不同的一段文字。

复制范围尽量只包含链接本身，不带标题、编号、代码围栏或聊天记录的引述符号。多条链接混在一起时，应用是否能一次识别取决于具体格式；为了便于核对，首次操作建议一条一条导入。每次完成后检查列表增加了什么，再继续下一条，避免重复记录与错误记录混在一起难以回溯。

1. 回到已有资料，复制原始链接或打开原始二维码。
2. 选择 Scan QR Code 或应用当前提供的剪贴板导入操作。
3. 在确认或编辑界面辨认 Type，检查 Address、Port 等关键字段。
4. 保存后确认记录归属，再进行测试；不要只看导入提示。

若应用未识别剪贴板内容，先确认它究竟是订阅 URL、协议分享链接还是普通说明文字。对于完整订阅地址，可以回到 Add Server，选择 Subscribe 后手动粘贴 URL。对于单服务器链接，应按对应协议处理，不能为了让界面接受输入而一律改为 Subscribe。载体不同，不代表对象类型可以省略判断。

识别失败与连接失败分别处理

扫码没有反应，优先处理图像质量与权限；识别后提示格式不符，优先检查文本结构；已经生成服务器但无法连接，才进入字段与网络排查。把这三种情况分开描述，可以显著缩短排错路径。例如“相机能看见图案但未生成记录”与“已生成 Trojan 记录但认证失败”，需要检查的内容完全不同。

导入后出现重复名称时，不要立即删除其中一条。先查看它们是否来自不同订阅、是否使用不同端口或传输方式。二维码标题通常只是便于辨认的备注，相同标题不等于相同参数。确认重复后，保留来源明确且能够恢复的一份，随后按本页删除章节处理，不在尚未验证时批量清理。

如果需要向他人描述问题，可以只报告导入方式、识别出的 Type、错误发生阶段和已完成的检查，不附上完整内容。完成导入后及时复制其他不敏感文本替换剪贴板中的凭据；若怀疑内容已经外泄，应从你的服务商处获取替换后的资料，而不是只把本地记录改一个名称。

协议前缀说明了解析方向

单服务器分享链接一般带有协议前缀，例如 ss://、vmess://、vless:// 或 trojan://。前缀用于提示解析方式，后面可能是编码后的字段，也可能是带查询参数的地址结构。看见前缀只能判断大致类型，不能仅凭肉眼确认认证值、TLS 与传输层已经完整。

以常见结构理解，分享链接可能同时携带用户信息、主机、端口、查询参数和备注。不同协议及不同生成方式的组织形式并不完全一致，不能用一种协议的拆分方法处理所有链接。最稳妥的做法是保留原文，由 Shadowrocket 解析，再到编辑页核对可见字段，而不是先在文本编辑器中自行改写。

https://example.com/sub?token=xxxx
trojan://[email protected]:443?security=tls&sni=example.com#Example

以上只展示订阅 URL 与单服务器链接的外观区别，全部为教学假值，不是可用连接信息。问号后通常是查询参数，井号后常用于备注，但应以具体协议格式为准。链接中的百分号编码也有意义；把编码字符替换成看起来更易读的文字，可能改变密码、路径或备注的实际内容。

编码不是加密，订阅也不是规则文件

部分链接或订阅响应使用 Base64 等编码表达内容。编码的目的是表示数据，并不等于为凭据提供保密保护。即使一长串字符无法直接阅读，也应按完整密码资料对待。排查时不要把整段内容粘贴到公开解码工具，只需先确认复制是否完整、响应是否属于预期类型，以及应用能否正常解析。

订阅响应可能包含多条服务器链接或其他受支持的结构。浏览器打开时，有的内容像文本，有的会触发文件保存，有的则显示登录页面；这些表现都不能单独证明它适合当前入口。如果实际返回的是登录提示、错误说明或网页内容，客户端就可能无法生成服务器，即使请求本身已经到达远程地址。

Config 中的规则片段则是另一类内容。下面展示一个常见的 Shadowrocket 配置结构，用于说明规则如何列在 [Rule] 下。它不包含服务器认证参数，也不能代替 Subscribe 地址。只有在理解现有配置结构、确认需要修改的范围后，才将规则应用到自己的 Config 中。

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

导入对象与实际路由还需衔接

服务器记录解决“使用哪个连接端点”，Global Routing 解决“流量如何选择连接方式”。Config 模式按当前配置处理；Proxy 模式使用代理路径；Direct 模式直连。若刚导入服务器后仍使用 Direct，实际访问没有经过该服务器并不代表导入失败。测试结果应结合当前模式解释，不能只观察服务器列表是否有选中标记。

在 Config 模式下，规则顺序与当前启用配置同样重要。示例中的 DOMAIN-SUFFIX 用于域名后缀匹配，GEOIP 按地址归属信息判断，FINAL 是前面规则未匹配时的兜底项。不要只复制 FINAL 一行就认为建立了完整分流策略，也不要把某段示例当成适用于所有网络环境的配置。

如果同一份资料同时提供订阅与 Config，应分别确认它们的用途、更新方式和管理入口。更新服务器列表不必然更新规则文件，切换 Config 也不必然替换服务器参数。把两者分别记入备份说明，后续遇到“列表正常但部分访问路径不符”时，才能从正确层次开始检查。

什么时候需要更新

服务端调整服务器地址、认证信息或可用范围后，本地列表可能仍保留旧内容，此时需要更新对应订阅。更新的主要作用是同步远程列表，而不是提高当前连接的速度。若只是某次访问超时，先测试现有记录与网络状况，不要立即同时更新所有订阅、切换 Config 并重启连接，否则很难判断是哪一步改变了结果。

在应用提供的订阅管理操作中，对目标订阅执行更新，并观察该组的反馈。若当前界面有更新周期或自动更新选项，可按实际需要设置；不要假定应用在后台始终运行，也不要把没有看到更新提示理解为系统已经完成同步。需要确认重要变更时，主动更新一次并核对结果，比仅依赖时间推测更可靠。

更新前可以记录当前可用服务器的名称与关键参数，必要时保存独立备份。订阅是由远程内容维护的列表，更新后某些服务器可能更名、移除或改变参数，这是同步结果的一部分。保留旧记录便于对照，但旧记录能否继续使用仍取决于远程服务状态，备份不等于延长其有效范围。

按请求、解析、使用三层定位

请求阶段失败时，先检查当前网络是否正常，再检查 URL 是否有多余空格或被截断。若订阅地址中的域名无法解析，问题发生在取得内容之前，反复编辑服务器 Password 不会解决它。也不要先删除原有列表；保留记录可以帮助判断是远程入口暂时无法访问，还是本地已保存的服务器同样失效。

解析阶段失败时，需要确认返回的到底是什么。账户到期提示、访问限制提示或普通网页都可能占据原本应返回服务器列表的位置。客户端无法从这些内容生成服务器，不意味着需要换一个随机协议类型。先核对账户状态与地址适用范围，再从你的服务商处获取确认后的订阅资料。

已经生成列表却无法连接时，应转向某条服务器的参数与 Connectivity Test。订阅更新成功与服务器可用性没有必然等号：列表中的端点可能正在维护，认证也可能与远程状态不一致。把“更新成功、记录存在、测试失败”作为完整现象记录下来，比笼统描述“订阅坏了”更有利于定位。

避免重复更新与覆盖手工修正

连续高频更新通常不能改变错误的响应内容，反而可能触发远程访问限制。一次失败后，先等待当前请求结束，核对失败阶段，再进行有目的的重试。切换网络进行对照时，一次只改变网络条件，不同时改 URL；只有变量清楚，才能判断问题与本地网络还是远程入口有关。

订阅内的手工重命名或参数修改，可能在下一次同步时被覆盖。对于临时验证，可以复制为独立记录并标注用途；对于应长期修正的错误，应核实远程订阅内容，而不是每次更新后重复本地修改。自动化维护的前提是上游资料正确，手工修正不能替代这一点。

确认更新完成后，检查当前选中的记录是否仍存在，并重新测试。服务器更名或移除后，不应仅凭旧名称判断是否仍选中了原端点。更完整的逐项自查可阅读订阅更新失败或列表为空的检查清单，其他连接问题见疑难解答。

按维护边界安排订阅

管理多个已有订阅时，首先保留清楚的来源边界。每个订阅入口应有独立名称，让你能够判断更新哪一组、删除哪一组，以及某条服务器由哪一份远程列表生成。不要把不同入口都命名为“默认”或“常用”，也不必把完整订阅 URL 放进备注；后者会增加截图和日常展示时泄露凭据的机会。

建议使用稳定的用途说明，例如“日常连接”“备用连接”或“测试记录”，再在自己的私密管理说明中记录入口与用途的对应关系。若已有命名习惯，应优先保持一致，不必为了排序反复改名。名称中写了某种地区或用途，也不能证明服务器实际行为；需要以已有资料与测试结果核对。

同一订阅重复导入后，可能出现名称相近的多组记录。处理前先比较入口、服务器字段和更新状态，不要只看组名。两个不同 URL 也可能返回重叠列表，而同一个入口在不同账户状态下可能返回不同结果。整理的目标是减少不必要副本，不是把所有看起来相似的记录强行合并。

分开管理生成记录与手工记录

订阅生成记录适合跟随远程变化，手工记录适合保存单独提供的参数或进行临时核对。两类内容可以同时存在，但应让名称或分组体现区别。若为了排查把订阅记录复制为独立记录，建议在备注中说明它是本地副本，并记下复制原因；以后原订阅更新时，才不会误以为副本也已同步。

临时副本最容易逐渐变成无法解释的旧记录。一次排查结束后，明确它是继续保留、更新说明还是删除。如果保留，需要说明与原记录的差别，例如修正了 SNI 或改用了资料中指定的端口。不要只标记“能用”，因为这个结论没有记录当时网络与参数，换一个时间便难以复现。

若应用当前提供按订阅查看、筛选或折叠列表的操作，可先缩小到一个维护范围再修改。批量操作前确认筛选条件与实际选中范围，尤其注意筛选后隐藏的记录是否也在选择范围内。无法确定时，先对一条非关键记录验证操作效果，再继续处理其余内容，避免一次改变全部列表。

选中、排序与规则引用不是同一件事

列表中的位置只决定显示顺序，通常不能代表当前连接选择。把某条服务器移动到最上方后，仍需确认 Home 中实际选中的记录。若 Config 涉及策略或分组，还应检查规则最终使用的目标。视觉上的“第一条”和路由中的“当前目标”是不同概念，整理时不要把它们混为一谈。

如果配置依赖某些名称，重命名或删除相关记录可能影响后续选择与维护。修改前先查看 Config 的关联内容，保留原名与新名的对应关系。对不熟悉的配置，不要一边批量改名一边改规则；先完成服务器列表整理并验证，再单独检查配置，这样出错时能缩小回退范围。

在 iPhone 与 iPad 上维护同一批资料时，可以沿用相同的分组说明，但不要假定两台设备上的排序、选择和同步状态完全一致。每台设备都应独立核对入口与当前选择。整理完成后保留一份简短目录，写明哪些内容跟随订阅、哪些需要手动维护，比只保存一张服务器列表截图更有恢复价值。

先理解正在测量什么

Connectivity Test 用于观察服务器在当前测试条件下的连通表现。具体测量含义取决于应用当前选用的测试方式与目标；不要把所有显示为毫秒的结果都理解为同一种指标。网络路径、域名解析、远程端点与测试目标都可能影响结果，因此不同时间、不同网络下的数字不应直接当作同一条件进行比较。

延迟主要描述某个测试阶段所花的时间，并不直接表示持续传输速度，也不能保证所有网站都能正常访问。一条记录测试较快，可能仍在实际请求中遇到认证、TLS、规则或目标站点问题。测试超时也不必然说明整条服务器永久不可用；先确认测试方式是否适合当前环境，再结合实际访问检查。

开始对照前，记录当前使用的是无线局域网还是蜂窝网络，确认没有正在进行的大量传输，并保持测试目标与方式一致。若一次只想比较服务器差异，就不要同时切换网络与 Global Routing。可重复的测试依赖稳定条件，而不是依赖一次看起来很理想的数字。

用少量重复测试识别稳定性

先测试当前选中的一条记录，确认操作能够完成，再按需要测试同一组的其他记录。连续结果波动时，观察是否只有某一条变化，还是整组同时变化。整组同时变慢更值得检查本地网络或共同路径；只有单条持续失败，则优先检查该端点的参数与远程状态。不要仅凭一次结果立即删除记录。

测试完成后，应进行一次与实际用途对应的访问验证，并确认流量路径符合预期。Global Routing 为 Direct 时，访问成功不能证明服务器工作正常；Config 模式下，某些请求可能按规则直连。必要时在应用可见的记录中核对对应请求，避免把直连成功误认为代理连接已经通过验证。

实际访问失败时，尽量描述具体阶段，例如域名无法解析、连接等待、TLS 报错或收到远程响应。不同阶段需要不同检查：解析问题应先看 DNS 与路径，认证问题应先看凭据，规则问题应先看 Config。反复按测试按钮只能重复同一个观察，不能代替对错误阶段的分析。

排序服务于选择，不替代判断

若当前界面提供按延迟排序，可在一轮完整测试后使用，避免把新旧结果混在一起。没有测量结果、失败结果与有效结果的排列方式可能不同，排序后仍应查看具体状态。列表第一条只是当前排序条件下的位置，不是长期固定的最佳选择；网络变化后，原有排序结论可能失去参考意义。

日常使用可以保留少量已验证记录作为候选，其他内容按归属折叠或整理。这样既保留替换空间，也减少每次测试全部列表的负担。候选的依据应包含连接稳定、参数来源明确与实际访问表现，而不只是一项延迟。测试用于辅助选择，不用于对任何服务商作价值评价。

如果已经确认某条服务器与模式组合可用，可先保持这一基线，再逐项检查异常记录。不要在保留基线之前批量更新、删除和改名，否则失去对照后难以判断问题来自新增变更还是原有网络。有关模式选择的细节见Global Routing 功能说明，常见连接分支见疑难解答。

删除前确认对象范围

删除单条服务器、删除整个订阅入口与移除 Config 是不同操作。单条记录被删除后，若它来自订阅，后续更新可能再次生成；删除订阅入口则可能同时影响该组服务器。执行前阅读当前确认提示，弄清影响的是一条记录还是整组内容，不以长按位置或列表外观推测操作范围。

如果只是暂时不使用某条记录，可以先选择其他已验证记录，而不必立即删除。确实需要清理时，先确认它不是当前唯一可用的连接，也没有被现有配置依赖。对于来源不明的本地副本，先核对是否保存了原始参数；没有恢复材料时，删除会使排查从可对照状态变成只能重新收集资料。

从列表移除内容不会撤销已经泄露的凭据，也不等于变更远程账户状态。若清理的原因是怀疑订阅地址或密码外泄，需要从你的服务商处获取替换后的资料，并按其流程处理旧凭据。本地删除只改变当前设备上的记录，不能代替远程侧的凭据更新。

备份应覆盖三个层次

第一层是订阅入口与来源说明，第二层是独立添加的服务器参数，第三层是 Config 与需要保留的规则设置。只保存订阅地址，可以重新取得远程列表，但不一定恢复手工记录与规则；只导出 Config，也不能假定其中包含所有订阅凭据与应用设置。应根据实际导出内容确认覆盖范围。

应用提供 iCloud 同步或导出功能时，先查看当前可用选项与完成状态，再决定是否足够覆盖换机需求。启用同步不代表所有内容已经传到另一台设备，也不代表误删除一定能回退。同步强调多设备状态一致，备份强调保留可恢复副本；重要变更前，仍应保留一份单独存储的材料。

备份文件、二维码和分享链接都可能包含认证信息，应存入只有必要人员可访问的位置。不要为了便于查找而放进公开文档或公开相册。为材料写明用途与所含项目即可，不需要把密码再抄进文件名。完成保存后实际检查文件能否打开、内容是否完整，避免换机时才发现保存的是空文件或普通网页。

按购买、导入、选择、验证恢复

新 iPhone 或 iPad 上，先通过 App Store 核对并恢复已购应用；购买适用范围与系统要求以 App Store 页面标注为准。应用购买记录只负责取得应用，不保证服务器、订阅和 Config 自动恢复。相关购买步骤见已购恢复说明，不要把重新购买当作数据丢失的处理方式。

1. 确认应用来自正确的 App Store 产品页，并完成首次打开。
2. 恢复同步数据或导入备份，检查订阅、独立记录和 Config 是否齐全。
3. 对订阅执行必要更新，确认当前选中的服务器与 Global Routing。
4. 完成 Connectivity Test 与实际访问，再考虑清理旧设备资料。

恢复后出现同名记录时，先判断它们分别来自同步、导出还是重新导入，不要立即批量去重。可以先保留一组经过验证的数据作为基线，再清理多余副本。若新设备与旧设备表现不同，应逐项比较当前网络、Config、服务器字段与系统授权状态，不能仅因列表名称相同就认为两端配置完全一致。

更详细的迁移顺序可阅读配置备份、iCloud 同步与换机恢复步骤。日常维护时，把更新与删除安排为两个独立动作：先确认新数据有效，再清理旧内容。这样能够保留明确的回退路径，也让下次排查有完整、可解释的起点。