Shadowrocket
订阅与服务器管理手册

Add Server：按协议核对手填字段

先选 Type，再填地址与认证

手动添加适合已有完整服务器参数、且需要独立维护单条记录的情况。打开 Add Server 后先选择 Type，再按该协议显示的字段填写。不同协议使用不同的认证方式，不能把某种协议的密码、标识或传输参数照搬到另一种协议。协议名称相近，也不表示字段可以互换。

主机字段通常填写域名或地址本身，端口字段填写对应的数字。除非当前字段明确要求 URL，否则不要在主机前添加网址协议，也不要把路径、端口和查询参数一起塞进主机字段。复制资料时应核对分隔符的位置，尤其是含冒号的地址；把地址与端口混为一段，容易让解析结果与预期不同。

认证参数与传输参数分别检查

Shadowsocks 需要核对加密方法与密码；VMess、VLESS 需要核对相应标识以及传输配置；Trojan 应检查密码和 TLS 相关要求。Hysteria2 与 WireGuard 也各有独立参数，不能只凭一个服务器域名就完成填写。字段不足时应回到已有的参数说明确认，而不是用任意值补齐表单。

密码或标识应完整复制，不要自动删去看似多余的符号，也不要把备注当作认证信息。某些输入框会遮挡内容，保存前可在安全环境中逐段检查长度与首尾字符。涉及截图记录时，应遮住整段认证数据，而不只是遮住中间几个字符；局部残留也可能帮助识别真实凭据。

TLS、SNI、Host 与路径并不是同一字段。连接地址用于找到服务器，SNI 参与 TLS 名称协商，Host 和路径可能参与上层传输请求。已有配置中即使这些值看起来相似，也应分别保留。尤其不要为了让测试通过而随意关闭证书验证，这会改变安全边界，并掩盖名称或证书配置错误。

若使用 WebSocket 等传输方式，遗漏路径或把 Host 写错，可能表现为地址可达但连接无法完成。排查时先确认服务器协议，再核对认证，最后核对传输层字段。一次只调整一个已确认有误的值，保留原始参数作为对照，避免在连续试改后无法判断究竟是哪项造成变化。

给手动记录建立清晰边界

备注用于辨认条目，不是连接协议的一部分。可以写明用途、位置或维护方式，但不应把密码放进备注。手动条目与订阅生成的条目最好采用不同命名习惯，例如明确标注哪条由自己维护。这样订阅更新后出现相似名称时，仍能判断应检查哪份记录，而不是误以为两条完全等价。

保存前后都应核对 Type、主机、端口、认证与传输五类信息。保存动作通常只能说明客户端接受了当前字段，不代表服务器确认这些参数正确。接下来仍需连接测试，并观察目标访问是否符合预期；如果只有部分站点失败，不要马上重新填写全部服务器字段，应先检查分流与解析路径。

订阅内条目的手工修改可能在后续更新时被重新生成的内容替换。需要长期保留的个性化参数，应先确认当前操作是在修改订阅条目，还是创建独立的手动记录。若选择独立维护，就同时承担后续跟随服务器变更更新参数的责任，不能再假定订阅刷新会自动维护这一份副本。

遇到协议字段含义不清时，可先在概念速查核对术语，再回到已有服务器资料逐项填写。本手册不建议通过猜测协议、随机组合字段或反复切换证书选项解决问题。完整、对应且仍然有效的参数，才是手动添加能够稳定工作的前提。

分享链接：识别格式与编码边界

前缀决定解析方式，不代表参数正确

服务器分享链接用约定的文本结构携带协议与连接参数。常见前缀包括 ss://、vmess://、vless://、trojan:// 与 hysteria2://，但不同格式的内部结构并不相同。看到前缀只能初步辨认类型，不能据此判断认证有效、服务器可达或所有扩展参数都已被支持。

订阅地址通常以普通网址形式出现，用于返回一组条目；单条分享链接则直接描述某个连接目标。两者都可能很长，也都可能包含凭据，所以不能单凭长度区分。应根据资料说明与前缀辨认，再选择 Subscribe 或单条导入，而不是把所有长文本都当作订阅。

编码不是加密，也不能任意改写

部分分享格式会把结构化内容进行 Base64 编码，部分格式则把参数放在查询字符串中。编码的作用主要是让文本适合传输，不是替凭据提供保密保证。能够还原编码的人仍可能读到地址、密码或标识，因此不要把一串看不懂的字符误当作已经安全脱敏的文本。

查询参数中的百分号编码、大小写与特殊符号应保留原样。重复解码可能把原本属于密码或路径的字符变成分隔符；重复编码也可能让服务器收到与预期不同的值。除非明确知道格式定义与字段含义，否则不要先在其他工具中转换，再把结果交给客户端尝试识别。

链接末尾的片段部分常被用于备注，但具体处理取决于格式。中文备注经过编码后可能变长，这本身不表示链接损坏。相反，聊天工具把链接截成两段、把普通符号替换为全角字符，才可能真正影响解析。出现乱码时应先对照原始文本，不要立即重写认证字段。

Config 与服务器分享不能混为一类

配置文件可以决定域名或地址应由哪个策略处理，但一段规则不一定包含完整服务器参数。把规则文本粘贴到单条服务器导入入口，不会自动生成连接目标。同样，导入一个服务器分享链接，也不会自动建立适合所有用途的规则文件；服务器与分流需要分别确认。

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

这是一段用于说明匹配顺序的 Shadowrocket .conf 规则片段，不是完整配置。规则按顺序判断，先处理指定域名后缀，再处理对应地址范围，最后由 FINAL 接住此前未命中的连接。示例中的域名为虚构教学值，应用到自己的配置前应理解目标策略与现有条目的关系。

Global Routing 选择 Config 时，当前配置中的规则才是重点检查对象；选择 Proxy 或 Direct 时，流量处理方式不同。因此，出现导入成功但访问路径不符合预期时，应先确定当前模式，再检查规则，不要仅凭服务器分享格式完整就认定分流也一定正确。模式说明见Global Routing 三种模式区别。

安全地报告格式问题

需要描述解析失败时，可以报告协议前缀、失败发生的步骤，以及是否出现不支持参数的提示。不要公开完整链接，也不要把真实编码内容交给公开解码页面。若需要制作演示文本，应从虚构地址与虚构认证重新构造，而不是只替换备注后继续使用原来的有效链接。

如果原始资料可以重新导出，优先重新取得同一条记录的完整文本，再与本地导入结果比对。不要通过删除所有查询参数来追求导入成功，因为被删掉的部分可能决定传输、TLS 或认证行为。能生成条目只是解析层面的结果，最终仍需用正确参数完成连接验证。

多订阅整理：保留来源边界与引用关系

先建立分组含义，再处理排序

同时保存多个已有订阅时，最重要的是能辨认每条记录由谁维护、属于哪个订阅，以及更新会影响哪些条目。不要先把所有服务器改成相似名称，再尝试回忆原来的分组。应先给订阅设置稳定的别名，以用途或自己能够理解的分类命名，避免把凭据或账户信息写进可见名称。

订阅别名表达的是本地管理关系，不是对服务器质量的评价。可以用工作用途、测试用途或维护责任区分，但不要把一次测试的快慢写成永久结论。测试结果随时间与网络变化，名称却常被长期保留；把短期状态放进名称，容易让后续选择依赖已经失效的信息。

手动条目最好与订阅生成条目保持可辨认的边界。若确实需要复制某条订阅服务器作独立修改，应清楚标记它已由自己维护，并保留原始参数的安全记录。否则订阅更新后，一份记录改变而另一份保持旧值，会看起来像同一服务器时好时坏，实际是两份参数已经不同。

去重之前比较连接身份

同名不一定是重复，同一个主机也不一定只对应一种连接。辨认时应同时比较协议、主机、端口、认证与传输参数，必要时检查 TLS 名称和路径。两条记录即使显示相同备注，也可能使用不同端口或不同认证；只按名称批量删除，可能误删仍然需要的独立记录。

反过来，名称不同也可能对应同一组连接参数。这样的重复往往来自多次导入、手动复制或多个订阅包含重叠条目。先确认保留哪一份作为日常使用记录，再清理冗余副本。不要为了列表短一些而立即删除整个分组，因为分组还可能承担后续更新与维护的边界。

服务器选择与规则引用一起核对

Home 中当前选择的服务器，与 Config 内的策略或规则引用可能有关，但不能只看高亮位置判断所有连接最终会走哪里。某条规则可能指定策略，某个策略也可能使用独立选择。整理列表后，应检查常用配置是否引用了被改名或删除的对象，再进行真实访问验证。

在 Global Routing 的 Config 模式下，规则匹配顺序决定连接处理方式；Proxy 用于将连接交给代理处理；Direct 用于直连。三种模式不是订阅分组的筛选器，也不会替你合并重复服务器。维护列表时把模式、当前选择和配置名称一起记录，才能解释整理前后行为为何不同。

若正在处理重要连接，不宜同时重命名订阅、批量删除条目和改写规则。可以先整理一个分组，完成更新与测试，再处理下一个。每次只改变一个范围，即使结果不符合预期，也能明确回退对象；一次整理全部内容则很难区分是名称引用、参数变化还是网络波动。

建立轻量而不泄露凭据的记录

管理记录可以包含订阅别名、用途、是否自动更新、最近一次检查结果和是否另有手动副本。无需记录完整订阅地址，更不应把密码复制到普通备忘文本。遇到需要跨设备核对的情况，可以给两端使用一致的非敏感别名，通过名称对应管理对象，而不是在聊天中发送有效凭据。

iPhone 与 iPad 上的列表是否一致，应通过实际查看确认，不要因为应用使用同一购买账户，就假定全部订阅、当前选择与 Config 自动完全相同。购买恢复解决的是应用获取资格，服务器资料与配置恢复属于另一层操作。换机前应按本页删除与备份章节分别检查。

整理结束后，选取常用配置和常用服务器做一次验证，再检查更新操作是否仍指向正确订阅。保留清晰边界比追求列表极短更重要：当某个订阅读取失败时，能够迅速知道哪些条目受影响、哪些手动记录仍可独立工作，才能在不扩大修改范围的前提下继续排查。

删除与备份：先验证恢复，再清理记录

先确认删除的是哪一层

清理前先区分单台服务器、整个订阅和 Config 文件。删除单台服务器可能只改变本地列表；如果它由订阅生成，后续刷新还可能重新出现。删除订阅会影响该订阅对应的管理关系与条目，删除 Config 则影响分流配置。三种操作不能互相替代，也不应把其中一种当作重置所有内容的方法。

不要在订阅更新失败时立即删除唯一一份本地记录。先确认是否仍有可用服务器、原始订阅地址是否安全保存，以及能否重新取得已有参数。删除动作通常不能撤销远端凭据，也不能修复网络请求。只有明确记录已不再需要，且恢复方式经过检查后，才适合进行清理。

清理重复条目前，应确认有没有规则或策略引用其名称。删除后即使服务器列表更整洁，依赖该名称的配置也可能需要调整。可以先处理单个不再使用的条目，验证常用配置仍然工作，再逐步扩大范围。批量删除更适合已经完成备份和引用检查的情况，而不是用来试探问题来源。

备份要覆盖不同数据对象

备份前列出需要保留的对象：订阅地址、独立手动服务器、Config 文件以及与使用有关的设置。订阅地址通常能重新取得远端当前列表，但不保证恢复曾经存在的旧条目，也不保证保留本地改名和手动修改。仅保存订阅地址，不能替代对独立服务器和自定义配置的检查。

在当前应用提供的导出或分享入口中，确认实际导出的范围，再选择自己控制的安全保存位置。若某个入口只分享单条服务器，就不能把它当成完整备份；若导出的是配置文件，也要检查里面是否确实包含恢复所需的服务器关系。不要根据文件名称推断备份覆盖范围。

恢复验证比导出成功更重要

完成导出后检查文件是否存在、是否能够读取，并确认保存位置在换机后仍能访问。重要内容可以保留受控的第二份副本，但两份都应有清楚的用途与访问边界。若只把文件留在准备清除的旧设备上，导出操作虽然完成，实际却没有形成可用于换机恢复的备份。

恢复时先确认目标设备上的 Shadowrocket 已通过 App Store 正常取得，再按对象逐项导入。应用已购恢复与服务器资料恢复是两条流程：前者处理购买资格，后者处理连接数据。iPhone、iPad 的系统要求、兼容性与通用购买以 App Store 页面标注为准，具体步骤见已购项目恢复说明。

目标设备已有内容时，先做现状备份，再导入旧资料，避免覆盖或重复后难以辨认。可以先恢复一个订阅或一条手动服务器，确认参数正确，再恢复 Config 与其他记录。导入完成后核对当前选择、Global Routing 和常用规则，而不是看到列表出现就立即清除旧设备。

至少完成一次真实连接与目标访问验证，再检查订阅是否能够刷新。旧服务器参数当前仍可连接，不代表订阅凭据仍有效；反过来，订阅能够刷新，也不代表自定义规则已正确恢复。把读取、连接和分流三个层次分别确认，才能认为关键使用状态已经恢复到新设备。

凭据泄露与本地删除分别处理

如果完整订阅地址、二维码或备份曾被公开，应通过已有服务的管理方式更换或撤销相关凭据，再更新本地记录。只删除聊天消息、清空剪贴板或移除服务器，不能保证已复制出去的内容失效。更换后还应检查旧备份与其他设备，避免日后恢复时重新导入已经废弃的地址。

长期维护可以采用固定顺序：先记录当前状态，再更新一个订阅，验证常用连接，随后整理重复条目，最后更新备份。这样每次变更都有明确边界，也便于回查。需要重新走通首次连接时返回使用说明；需要辨认字段时查阅概念速查，不要以反复清空数据代替分层检查。