Shadowrocket
订阅与服务器管理手册

02 / ADD SERVER

Add Server 手填字段与参数核对

手动添加适合已有完整服务器参数、需要逐项核对连接信息的场景。先选择协议类型，再填写对应字段，不要先把地址和密码填完后反复切换类型。不同协议使用的认证方式和传输设置并不相同，切换后某些字段可能不再适用。手填的目标是忠实还原已有资料，而不是靠尝试组合得到一个看起来完整的表单。

地址、端口与认证信息分开填写

服务器地址填写资料中的域名或 IP 地址，端口填写提供的端口数字。普通地址字段通常不需要附带网页路径，也不要把完整分享链接放入地址栏。域名前后不要保留空格；端口应当是有效的整数。资料中出现冒号时，要区分它是在分隔端口，还是属于 IPv6 地址的一部分，不能简单按最后一段文字拆分。

认证信息必须与所选协议对应。Shadowsocks 需要匹配加密方式与密码；VMess、VLESS 常涉及 UUID；Trojan 通常使用密码；HTTP 与 SOCKS5 可能使用用户名和密码。不要将 UUID 当作服务器域名，也不要把“备注”内容填进密码。字符相似时用复制方式减少误差，但粘贴后仍需检查首尾空格和意外换行。

TLS、SNI 与传输设置不能猜测

TLS 相关名称不一定与连接地址完全一致。服务器地址决定连接目标，SNI 参与 TLS 握手中的名称表达，二者用途不同。若资料明确给出 SNI，应按原文填写；没有说明时，不要随意套用其他服务器的值。出现证书错误时，应核对名称、设备时间和证书状态，不应把关闭校验作为日常解决方法。

使用特定传输方式时，Host、Path 等字段也可能影响服务器能否正确处理连接。路径中的斜杠、大小写和查询内容都可能有意义，不能按中文阅读习惯改写。相同地址与端口并不保证传输参数相同。如果提供的信息缺少关键字段，应向你的服务商核实，而不是从另一条可用记录中复制一组设置碰运气。

用单变量方式验证手动记录

保存前给手动记录加上明显备注，区分它与订阅生成的记录。首次验证时只选择这一条服务器，暂时不要同时更改 Config、DNS 与连接条件。先检查参数能否通过当前网络建立连接，再判断规则是否按预期工作。如果同时修改多项，即使恢复可用，也很难知道真正影响结果的是哪一个字段。

手动记录通常不会因为某条订阅刷新而自动得到相同更新。服务商更换端口、密码或证书要求后，需要重新核对这条记录。应当记录参数来源与用途，但不要把完整密码写入可见备注。测试用的重复记录完成核对后及时整理，避免以后误选旧记录，把参数过期误认为应用连接故障。

WireGuard 等类型有自身的密钥、地址和对端参数结构，不能按普通“域名加密码”的思路填写。只在拥有完整且匹配的资料时手动配置；涉及私钥的内容应当保密。需要先了解各类型区别，可阅读支持协议与字段概览，再返回本章逐项检查。

04 / LINK FORMATS

分享链接格式与配置边界

分享链接是连接参数的编码表达，不是普通网页地址的另一种写法。不同协议使用不同前缀与字段组织方式，参数还可能经过编码。判断链接是否完整，应关注前缀、主体、查询参数和备注部分是否被保留，而不是尝试肉眼读出密码。对无法识别的链接，应先核对格式说明与原始内容，不要盲目替换字符。

分清单条链接与订阅 URL

以 ss://、vmess://、vless:// 或 trojan:// 等前缀表达的内容，通常用于描述相应协议的服务器信息。普通 HTTPS 订阅 URL 则是获取一组记录的网络入口。前缀能帮助判断类别，但不保证当前内容有效或适配；同一协议还可能存在不同编码形式与附加参数，需要由应用按支持的格式解析。

不要把分享链接直接当成浏览器网址来验证。浏览器无法打开某种协议前缀，并不说明服务器不可用；反过来，HTTPS 地址能显示页面，也不说明它就是可导入的订阅。需要判断的是返回内容是否属于预期格式，以及客户端是否生成了正确记录。排查时先明确入口类型，再选择对应的导入位置。

# 仅展示订阅 URL 的结构；不是可用服务
https://example.com/sub?token=xxxx

# 常见单条分享链接前缀
ss://
vmess://
vless://
trojan://

编码、查询参数与备注的处理

链接中的百分号编码与 Base64 内容可能承载必要字段，不应为了“看起来整齐”而手工转换。某些字符串中的加号、斜杠与等号有编码意义；复制工具如果把加号改成空格，或漏掉末尾字符，就可能导致解析失败。首先重新取得完整原文，再判断兼容性，不要把一次复制错误归结为协议本身有问题。

问号后的参数可能描述 TLS、传输方式、路径或其他协议选项，不能统一当作追踪信息删除。井号后的部分在不少分享格式中用于备注，但仍应按原格式保留交给应用处理。中文名称显示异常，可能与备注编码有关，不一定影响主体参数；应分别检查显示名称与连接能力，不要把两种问题混在一起。

服务器链接不能替代 Config

导入服务器通常只是保存连接目标，不代表已经设置好规则、DNS 或 Global Routing。要按规则分流，应核对当前 Config 与配置模式；临时使用 Proxy 或 Direct 时，流量处理方式也不同。服务器名称中出现某种用途字样，只是备注，不会让客户端自动创建相应规则，更不能代替实际的配置检查。

下面是 Shadowrocket .conf 中的规则片段示意，仅说明匹配关系，不是一份完整配置。规则按文件中的实际顺序自上而下检查，首条匹配后结束，FINAL 应作为最后的兜底。PROXY、DIRECT 与 REJECT 是规则动作，不是三组可以任意重新排序的优先级。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ad,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

把格式问题与规则问题分开验证

如果链接解析后地址、端口或协议缺失，优先检查原始内容与格式兼容性；如果服务器参数完整但某个域名的访问路径不符合预期，则应检查规则命中。不要通过反复修改分享链接来修复规则，也不要通过导入陌生配置来掩盖一个字段缺失的问题。每次只处理一个层面，结果才有可解释性。

需要交流故障时，可以提供协议类型、错误提示与经过脱敏的字段结构，但不要发送完整认证主体。仅遮住显示名称通常没有意义，真正敏感的信息可能位于编码主体或 URL 参数中。拿不准如何脱敏时，只描述现象与字段名称，保留原始资料在自己的可信存储中，避免为了寻求帮助而扩大信息暴露范围。

关于配置、代理、直连三种选择的具体用途，可阅读Global Routing 的 Config、Proxy、Direct 说明。本章侧重数据格式与对象边界，日常连接步骤仍以使用说明为主线。

06 / ORGANIZE

多订阅整理与记录归属

管理多条订阅时，首要任务不是把名称改得统一，而是保留每条记录的来源与维护方式。订阅生成的服务器、手动添加的服务器与临时测试记录应当能够区分。否则一条服务器失效时，很难判断该更新订阅、修改手动参数，还是直接清理临时记录。整理结构应服务于后续维护，不需要为了外观整齐增加复杂层级。

采用稳定、低敏感度的命名规则

订阅名称可用用途加来源代号，例如“日常 A”“备用 B”；手动记录可加“手动”标识，临时记录可加“测试”标识。名称中不要出现密码、完整订阅 URL 或认证令牌。对同一来源采用一致代号，后续更新与备份时便于对应。备注可记录用途，但不应承诺某条服务器永远可用，因为状态会随网络与远端条件变化。

订阅生成的名称可能在刷新时被远端内容替换，因此不要把重要维护信息只写在这类名称里。需要长期保存的说明，可以放在受保护的独立记录中，标明订阅代号与必要的识别特征。不要只用列表位置记忆服务器，因为更新、折叠与排序都可能改变位置；至少结合名称、协议和归属进行确认。

重复条目按身份核对，不按名称判断

两条记录同名，可能连接到不同地址；两条记录名称不同，也可能使用相同目标。判断重复时应比较协议、地址、端口和关键认证或传输设置。比较过程不要把敏感字段公开展示。若分别来自两条订阅，即使参数暂时相同，也应先保留归属信息，因为未来远端的更新方向可能不同。

发现重复后，优先清理明确属于误操作的临时导入记录，不要未经确认就删除订阅下的条目。某些本地修改可能在下次刷新时被重建或覆盖，实际行为以当前应用为准。若长期不再使用某条订阅，应先完成迁移与备份，再删除订阅入口；单独删掉几台服务器，未必能改变后续更新返回的集合。

列表分组与规则策略不是同一个概念

Home 中为了展示而形成的分组，不应直接理解为 Config 中的策略选择。显示在同一订阅下，只说明这些服务器具有共同的数据来源，不代表它们会按某种规则自动切换。实际流量如何处理，仍取决于 Global Routing、当前配置以及其中的策略引用。整理列表后，应核对原有选择是否仍然符合日常用途。

配置里引用名称时，重命名可能改变对应关系。调整前先检查是否有自定义规则或策略依赖该名称，并保留原名与新名的对应记录。不要为了统一命名一次修改全部条目，再同时更新订阅。将命名整理与远端同步分开操作，能清楚判断是哪一步影响了连接或选择。

用小范围维护替代一次性大清理

建议按订阅逐个整理：先确认入口有效，检查列表归属，选择一条记录测试，再清理明确重复的临时项。完成一组后再进入下一组，不要同时折叠、重命名、排序和删除全部内容。每一轮只改变少量对象，即使结果不符合预期，也容易返回上一个可用状态，不必重新构建整个列表。

测试与排序结果只能作为整理依据之一，不能直接决定删除。某条服务器在当前网络超时，换到另一种网络后可能表现不同；临时延迟偏高也不代表参数失效。先将“当前不可用”“参数已过期”和“不再需要”分开记录，再决定保留、修正或移除，避免把暂时的网络问题变成资料丢失。

多设备使用时，应明确每台设备的同步方式与管理责任。两台设备保存同一订阅，并不表示手动备注、排序或选中状态会自动一致。不要在未确认同步机制时假定一处修改处处生效；迁移到另一台 iPhone 或 iPad 后，仍应独立检查服务器、Config 与系统连接授权。

08 / BACKUP & REMOVE

删除、迁移与备份的安全顺序

删除前先确认对象、影响范围和恢复材料。单条服务器、订阅入口、Config 文件与系统 VPN 配置不是同一种对象，删除其中一项不等于清理其余内容。若目的是停止连接，先关闭连接并检查 On Demand 条件；若目的是整理列表，再处理记录。不要用删除所有资料的方式代替一次普通断开操作。

先备份必要资料，再执行删除

备份至少应覆盖有效订阅地址、手动服务器参数、实际使用的 Config，以及用于理解它们的归属说明。订阅地址只能帮助重新获取远端当前内容，不保证恢复过去的服务器集合；配置文件也不一定包含手动添加的全部服务器。需要恢复哪些对象，就分别确认哪些材料能够重建它们，不要只保存一张列表截图。

如果当前应用提供导出、分享或备份入口，应检查导出内容的范围，确认是否包含认证信息与自定义配置。不同入口可能只导出单条记录，而不是完整状态。导出后先在可信位置核对文件是否可读、内容是否完整，再决定删除原记录。不要在没有验证的情况下，把“文件已经生成”视为恢复一定成功。

敏感备份应当受保护

备份可能包含订阅令牌、密码、UUID 或私钥，应存放在受保护且由自己控制的位置。使用设备间同步时，确认同步账户、访问设备与共享范围，不要放进默认公开的文件夹。为备份设置清楚的用途与对象说明，但文件名不应包含完整凭据。临时导出完成后，也要处理消息附件、相册或其他中转位置中的副本。

重新取得应用与恢复业务数据是两件事。更换 iPhone 或 iPad 后，从 App Store 获取已购应用的流程可查阅已购恢复说明；能重新安装应用，不代表服务器、订阅和自定义配置必然完整恢复。不要仅依赖对系统备份的猜测，应事先确认自己能够重建关键资料，并保留独立的核对清单。

按小范围顺序清理记录

删除服务器前先切换到确认可用的其他记录，并检查是否有名称引用依赖它。删除订阅前阅读确认提示，核对关联条目会如何处理；具体联动行为以当前应用提示为准。仅删除订阅下的单条记录，后续刷新可能再次生成，因此长期停用某个来源时，应从订阅层面规划，而不是每次更新后重复清理。

删除 Config 前先导出自定义内容，并确认另有适合的配置可用。若删除后访问行为变化，优先检查当前 Global Routing 与选中文件，不要立即修改服务器密码。清理系统 VPN 配置后，后续连接可能再次请求授权，应理解这是系统连接配置的重建，不是订阅重新购买或服务器凭据失效。

恢复后按导入、选择、验证重新验收

恢复时先添加订阅或手动服务器，确认列表与归属，再导入并选择所需 Config，最后检查 Global Routing 与系统连接授权。不要同时恢复大量旧记录并立即删除重复项，先验证一条完整路径可以使用。配置副本来自过去时，还应核对其中引用的服务器名称是否仍存在，避免资料恢复成功却引用已经失效。

新设备验证完成前，保留旧设备与备份中的有效资料。确认日常访问、更新入口和自定义规则均正常后，再清理不再需要的副本。若备份中的订阅令牌或密码已被重置，应以从你的服务商处取得的当前资料为准；旧备份可用于理解结构，但不能继续承担有效认证材料的角色。