Shadowrocket 订阅与服务器管理

Subscribe 入口与订阅记录

先分清订阅地址与服务器地址

订阅地址用于请求一份服务器列表，服务器地址则是某个连接配置实际访问的主机。两者可能都含域名，却不能放进同一个字段。开始前检查手中的信息究竟是完整订阅 URL、单个服务器分享链接，还是一组供手填的参数。只有拿到列表订阅地址时才选择 Subscribe；不要因为文本以 HTTPS 开头，就直接断定它是订阅，普通网页同样使用这种形式。

从 Home 进入 Add Server，在 Type 中选择 Subscribe，按当前界面提供的 URL 等字段填写已有订阅地址，并为记录设置容易辨认的名称。不同界面布局中的入口位置可能有差异，应按英文名称核对。粘贴后查看开头、结尾和查询参数是否完整，特别注意聊天软件自动添加的空格与换行。保存前不要将订阅地址改成其中某台服务器的域名，也不要自行删去看似多余的参数。

保存成功与取得列表是两个阶段

订阅记录能够保存，只说明客户端接受了这条记录，不代表远端请求成功。保存后按订阅记录提供的更新操作获取内容，再返回 Home 检查是否出现对应服务器。若只有订阅名称，没有服务器条目，应继续核对更新结果，而不是立即打开连接开关。列表已有内容时，也要辨认这些条目是否属于本次订阅，避免把之前导入的手动记录误当成更新成果。

订阅响应需要包含客户端能够识别的服务器描述。若返回的是登录页、说明网页或错误提示，即使浏览器能打开 URL，也不能证明内容可导入。检查时优先使用客户端给出的错误信息，并向已有服务的管理方确认该地址的用途和支持格式。不要把含凭据的订阅地址放进公开查询工具，也不必为了排错反复向不同地方粘贴完整链接。

确认订阅与 Config 的边界

服务器列表与 Config 中的规则承担不同职责。前者回答连接到哪里、使用什么协议和凭据，后者决定请求应走 PROXY、DIRECT 还是 REJECT。导入订阅后，不应默认当前规则文件也已替换；同样，切换 Config 不等于重新获取服务器。把两个操作分开验证，可以避免列表正常却因规则路径不同而误判连接失败。

完成导入后，记录订阅名称、导入方式和当前选中的服务器，再按首次连接步骤测试。如果出现空列表，先检查 URL、返回内容和网络可达性；如果列表完整但无法连接，再进入参数与测试章节。排查顺序应沿着“取得列表、读出参数、建立连接、访问目标”逐段前进，不要同时更换订阅、Config 和 DNS，否则很难确定是哪一次修改改变了结果。

Add Server 手填字段

Type 决定需要填写的参数

手动添加适合已有完整服务器参数、且需要逐项核对的情况。从 Home 进入 Add Server 后先选 Type，再填写后续字段。Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 与 Hysteria2 所需信息并不相同；切换 Type 后出现或消失的字段不是可随意替换的别名。应以原始配置明确写出的协议为准，不能靠尝试不同类型来弥补缺失参数。

Address 通常填写服务器主机名或 IP，Port 填写对端提供的端口。除非当前字段明确要求 URL，否则不要把协议前缀、网页路径和查询字符串一起放入 Address。域名和 IP 也不能总是互换：使用域名时可能涉及解析、证书名称与服务器路由。若原始资料给的是域名，应先按原值填写，而不是为了减少变量就直接换成解析得到的 IP。

认证、传输与 TLS 分层检查

Password、UUID 等内容属于认证数据，应完整保留字符与大小写。Shadowsocks 的 Method 需要与对端一致，不能认为所有加密选项都可互通。VMess 或 VLESS 若还指定传输方式，应继续核对对应字段；传输层的 Host 与 Path 也可能参与请求匹配。单纯把地址、端口和认证数据填对，并不能保证其他必需参数已经自动补全。

TLS、SNI 与连接地址之间存在关联，但不是同一概念。连接地址决定访问的端点，SNI 在需要时用于传达服务器名称，证书验证则检查连接身份。原配置明确提供名称时应按原值核对，不要将关闭证书验证作为常规修复方式。若报错涉及证书，应先检查设备时间、名称是否一致及对端证书状态，再确认传输设置，而不是只更换端口。

独立参数不要跨协议套用

WireGuard 的私钥、对端公钥、Address、Allowed IPs 与 MTU 属于另一套配置关系。这里的 Address 可能表示隧道地址，不能机械套用普通服务器 Address 的含义；Endpoint 才用于定位对端。Hysteria2 的认证和传输选项也应逐项按原始资料填写。需要理解 WireGuard 字段时，可继续阅读WireGuard 参数说明，不要用其他协议字段推测缺失值。

保存前逐项对照原始资料，优先检查容易忽略的首尾空格、全角标点和自动换行。保存后重新打开编辑页，确认字段确实按预期保留，再执行连接验证。若错误出现在认证阶段，先处理凭据；若端点不可达，再检查网络与地址。为每次试验只改变一个字段，并记录改前值，能够避免多次尝试后忘记哪套参数才是服务端实际提供的组合。

扫码与剪贴板导入

Scan QR Code 读取的是内容

二维码只是文本载体，图案本身不说明其中装的是订阅、单个服务器还是普通网页。使用 Scan QR Code 前，确认二维码来自自己的配置资料，并保持完整边缘、合适亮度与清晰度。首次使用相机时，系统可能请求访问权限；是否允许应由用户根据操作需要决定。识别失败先检查图像质量和权限，不要立即修改已有服务器，更不要删除原记录来“腾出位置”。

识别成功后先看导入结果属于哪一种记录。若二维码包含单个服务器链接，通常得到单条连接信息；若包含订阅地址，还需要完成列表获取。遇到确认页时核对 Type、Address 和名称是否合理，不能仅凭“识别成功”就认定参数齐全。二维码也可能包含过时凭据，因此导入后的连接验证仍然必要，扫描动作无法证明远端配置是否仍有效。

剪贴板保留完整文本

通过剪贴板导入时，只复制需要导入的链接或配置文本，避免把介绍文字、序号、代码围栏和句末标点一起带入。若当前界面提供剪贴板导入入口，按其提示确认；系统询问粘贴权限时，核对发起操作的应用。复制后立即导入，减少其他复制动作覆盖内容的机会。剪贴板为空或被新内容替换时，应回到原始资料重新复制，而不是手动拼接记忆中的字符。

长链接在聊天窗口中常被视觉换行，视觉换行不一定是真实换行；相反，复制多段文本时也可能真的带入换行符。若提示格式无法识别，应先检查前缀与末尾，再确认中间是否被截断。不要把所有空格都一键替换，因为名称部分与编码内容的处理方式不同。最稳妥的做法是从原始文本重新复制完整一条，再与导入后的关键字段对照。

处理重复、批量与识别失败

批量导入前先确认文本格式是否受当前入口支持。多条链接逐行排列不一定会被当作订阅，某些输入只接受单条记录。可以先用一条自己已有的有效信息验证入口，再处理剩余内容。导入后按协议、地址和端口核对数量与条目关系，不能只数名称；两条同名记录可能指向不同端点，两条名称不同的记录也可能保存了完全相同的连接参数。

重复导入后不要立刻按名称批量删除。先确定哪些记录由订阅维护、哪些是手动导入，再检查正在使用哪一条。若扫码结果与剪贴板结果不同，应比较两份原始内容是否确实一致，尤其留意是否复制了二维码旁边的另一条链接。相同资料在两种方式下都无法识别时，问题更可能位于格式或内容，而不是相机；此时应转到分享链接章节检查结构。

完成导入后回到 Home，选择新记录并重新验证。此前已建立的连接不一定已经切换到新服务器，浏览器旧页面也可能仍显示缓存。测试时明确记录当前选择，使用新的请求判断结果。若只想确认能否导入，停留在参数检查即可，不必为了测试而同时开启 On Demand。将输入动作与连接动作分开，可以让失败现象对应到具体步骤。

分享链接格式与 Config 边界

前缀、主体、参数与名称

服务器分享链接通常由协议前缀、承载连接信息的主体、可选查询参数和显示名称组成。常见前缀包括 ss://、vmess://、vless:// 与 trojan://，但前缀可识别不代表后续字段一定完整。某些主体使用编码文本，某些直接包含认证与地址，不同格式不能靠替换前缀转换。导入时应保留整条链接，不要先按外观自行整理成另一种协议。

链接中的问号通常引入查询参数，井号后可能放显示名称，百分号编码用于表示某些特殊字符。这些位置具有语法含义，不只是装饰符号。手动改写时若把参数连接符删除、把编码字符解码后再复制，可能导致客户端读到不同内容。需要改名称时，优先在导入后的编辑界面修改显示名称，避免顺手破坏认证或传输参数。

单条链接与订阅不是同一对象

单个分享链接通常描述一条服务器记录，订阅 URL 则用于向远端获取列表。订阅返回的正文可能包含多条服务器描述，也可能采用其他受支持形式；这是响应内容的格式，与订阅地址本身的写法不同。不能把浏览器看到的一整页文本随意塞进 Address，也不能把单条服务器链接当成可以持续更新的列表地址。先明确对象，再选择导入入口，才有后续维护关系。

如果导入后的关键字段为空，应先怀疑格式不匹配、文本截断或链接缺少参数，而不是默认使用客户端显示的默认值。特别是传输、TLS 和认证信息，默认值可能与原配置不同。可以逐项对照已有的结构化参数，但不要仅凭可读名称推断协议。名称写着某种地区或用途，只是标签，不构成地址、协议或可用性的技术依据。

规则文件管理请求路径

Shadowrocket 的 .conf 文件可以包含规则内容，不能把规则片段当作服务器分享链接。下面示例仅说明匹配顺序与动作，不包含服务器参数，也不是可直接替代个人配置的完整文件。使用前应理解现有文件的其他段落及策略关系；修改已有配置时，先复制备份，再定位对应部分，避免把一小段示例覆盖到整个文件上。

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

DOMAIN-SUFFIX 按域名后缀匹配，GEOIP 按相关 IP 地理数据判断，FINAL 处理前面未匹配的请求。规则按顺序执行，前面的命中会影响后续是否继续检查。示例中的 PROXY 表示相应代理动作，并没有在这里定义某台服务器。即使规则语法正确，服务器凭据失效时也不能靠修改 FINAL 来恢复认证。

分享前应确认接收设备是否确实需要完整凭据，并选择自己可控的传递方式。若只是协助排错，通常只需提供协议名称、报错类别与经过遮盖的参数结构，不必发送整条链接。含凭据的文字一旦被他人获得，删除本地消息不等于原凭据已失效；需要撤销访问时，应在自己的服务管理范围内更换相应凭据，再更新客户端记录。

订阅更新策略与失败处理

更新改变列表，不等于改变所有设置

订阅更新是重新请求地址并解析返回内容，可能增加服务器、移除旧条目或改变已有参数。它与 App Store 的应用更新、Config 的文件更新是三件不同的事。应用功能更新不保证订阅内容同步，订阅成功也不意味着规则文件发生变化。排查时分别确认是哪一种更新，避免看到服务器列表改变后，仍用旧名称判断当前配置是否完整。

更新前记录当前正在使用的条目，并确认是否有手动改过的字段。订阅管理的记录可能在重新获取内容时被重建或覆盖，因此不应把重要的本地修改仅保存在其下属条目中。需要保留试验配置时，先保存独立副本并注明用途，再执行更新。订阅端如何标识条目与客户端如何呈现变化可能受内容格式影响，不能假设名称相同就一定维持同一条内部记录。

手动确认与自动更新的分工

手动更新适合首次导入、明确收到配置变更通知和排错后的复核。若当前设置提供自动更新选项，应按实际需要选择，并确认其具体作用对象。自动更新不是持续在线监控，设备后台执行还可能受到系统状态影响；因此在重要使用前，应主动查看列表和最近一次可见结果，而不是把设置已打开等同于内容已经按时刷新。

不必在失败后连续快速触发更新。短时间重复请求通常不会修复地址错误，还可能令日志充满相同现象。先保留错误提示，确认本机网络能正常工作，再判断是域名解析、连接、响应状态还是内容解析失败。若订阅 URL 发生变化，应编辑正确记录并复核完整参数，而不是不断添加新订阅，留下多组来源相同却状态不同的列表。

成功后再检查使用中的记录

更新显示成功后，查看订阅下的条目是否符合预期，尤其检查当前选择是否仍存在。如果原记录已被移除，重新选择有效条目再验证连接。若客户端保留了之前结果，应区分“列表仍可见”和“本次请求成功”；旧列表存在只能说明本地有数据。反过来，列表内容没有变化也不必视为失败，远端可能确实未修改，应结合更新反馈判断。

当基础网络与代理路径表现不同，应先明确更新请求实际使用的路径，再做针对性检查，不能假设它必然跟随当前选中的服务器。若出现延迟正常、订阅域名却无法解析的情况，可参考DNS 与解析失败排查。不要在没有记录原值时同时改 DNS、路由姿态和订阅地址，这些变量会使成功或失败的原因难以分离。

完成维护后保留一个简短记录即可：本次是否取回内容、哪些条目发生变化、是否已重新验证。记录不应包含完整订阅凭据。若更新导致当前连接不可用，先使用已确认有效的备份记录进行对照，再核对新参数；不要直接把旧列表重新导入同一订阅并期待后续更新永远保留它，长期维护仍应以有效的订阅内容为准。

多订阅命名与服务器整理

按管理关系命名，而非按表现命名

已有多个订阅时，先为订阅记录设置能区分用途的名称，例如个人测试、日常配置或备用记录，再为独立手动记录标注其来源类别。名称应服务于查找，不必写入凭据、完整地址或临时测试结果。将某次延迟写进名称容易过时，把“可用”当永久标签也会误导后续维护；稳定的命名方式应表达归属和用途，而不是承诺实时性能。

订阅名称与其下属服务器名称承担不同层级的信息。维护时先辨认服务器属于哪条订阅，再看连接参数，避免只按显示名称判断重复。不同订阅可能返回同名记录，同一订阅也可能返回多个相近名称。建议把需要保留的本地试验独立标识，确保日后更新或清理时，能够分清哪些由远端维护、哪些需要自己继续负责。

重复条目应比较关键字段

判断是否重复至少应比较 Type、Address、Port 和相关传输参数；在需要认证的协议中，还应确认凭据是否相同，但比较过程不必把凭据抄到普通笔记。即使端点相同，不同凭据或不同传输选项也可能具有不同用途。反过来，名称不同却所有连接字段相同的记录，可能只是重复导入。删除前先查当前选中项，避免误删正在使用的独立记录。

整理订阅时不要把所有条目复制成手动记录来追求表面统一。这样会失去更新关系，后续参数变化只能逐条修正。适合保留为独立记录的是明确需要固定参数的测试副本，且应写清它不会自动跟随原订阅变化。若同一地址被重复添加为多个订阅，先确认是否存在不同筛选或管理需求，再决定合并，不能只因 URL 相似就批量移除。

列表整理与 Global Routing 分开

服务器排序解决查找与选择问题，Global Routing 决定请求如何处理。列表最前面的记录并不因此自动成为所有请求的出口；当前选中项、配置中的策略关系和路由姿态仍需分别确认。整理完成后应回到 Home 查看当前选择，再打开所用 Config 检查规则动作。只改变名称或顺序通常不应成为重写整份规则文件的理由。

当列表较长时，先利用当前界面提供的分组、查找或排序能力缩小范围，再检查参数。具体入口以实际界面为准，不应为了复现某个布局而重建全部记录。每次只整理一个订阅，处理完后确认其条目仍可辨认，再继续下一组。分批操作的好处是出现异常时能清楚回到最近一次变更，而不是面对一整页同时变化的记录。

整理还应包括敏感信息管理：用于说明用途的备注不应含 Password、UUID 或完整订阅 URL，公开截图时也应检查订阅名称是否暴露私人标识。若需要跨设备保持相同组织方式，先在一台设备上确定命名规则与备份范围，再恢复到另一台设备并检查差异。多设备同时手动重命名容易造成混淆，维护顺序应比名称本身更明确。

Connectivity Test 与排序判断

先明确测试测量的对象

Connectivity Test 的结果需要结合当前测试方式解释。不同方法可能检查端点连接、经代理访问测试目标，或其他特定环节，因此一个数字不能概括完整使用体验。测试前查看相关设置，确认测试目标、方法和当前网络，再比较结果。不要将不同网络、不同目标或不同方法得到的数据直接排序后当作同一条件下的性能结论。

连接端点有响应，不等于认证、TLS、传输与目标访问全部成功。某条记录即使显示延迟，也可能因凭据失效或参数不匹配而无法完成实际请求；反过来，测试目标暂时不可达也不一定说明服务器完全不可用。应把测试结果作为线索，再用自己需要访问的正常目标验证。遇到差异时先定位是哪一段失败，而不是立刻删除所有显示超时的条目。

在一致条件下比较与排序

进行排序前，固定设备网络与测试设置，避免在测试过程中从 Wi-Fi 切换到蜂窝网络。对少量候选记录进行重复观察，比一次对整个列表得出结论更容易解释。排序只代表当次条件下的结果，不保证后续带宽、稳定性与访问目标均相同。不要把短时差异过度解释为服务质量变化，也不要用单次最低数值决定所有后续请求的路径。

测试完选择某条记录后，确认选择状态确实变化，再按需要重新建立连接并发起新请求。浏览器缓存、已有长连接和其他应用的会话可能让观察滞后，因此旧页面仍然可见不能作为新服务器成功的证据。验证时使用明确的新操作，并记住当前 Global Routing 姿态；若处于 Direct，直接访问成功并不能证明代理记录已正常工作。

将故障拆成可验证的步骤

建议按基础网络、服务器参数、连接状态、DNS、规则与目标服务的顺序检查。基础网络异常时先恢复设备正常联网；参数异常时回到 Add Server 对照；只有目标域名解析异常时再处理 DNS。若所有候选都表现相同，应优先寻找共同变量，例如当前网络、测试目标或 Config，而不是逐条修改每个服务器的认证字段。

日志与 Data 中的可用信息可以帮助辨认请求是否实际发出、走了什么路径，但应先看与本次操作相邻的记录，避免把旧错误当成当前结果。分享排错资料时只保留必要的错误类别与经过遮盖的字段，不发送完整凭据。如果现象是延迟正常而网页打不开，可继续阅读DNS 专项排查，按解析与请求路径分别验证。

最后把排序与长期维护分开：临时超时的记录可以留待复核，确认远端已移除或凭据已撤销的记录再进入删除流程。一次测试不应触发大规模清理，也不应自动修改规则。得到稳定结果后，记下使用的测试条件和当前选项即可；下次网络环境改变时重新验证，比长期依赖旧排序更能反映实际情况。

删除、备份与换机恢复

先列清备份对象

备份前先区分订阅记录、独立服务器、Config 文件与相关设置。保存一份规则文件，不应自动理解为所有订阅地址和凭据都已保存；保存服务器分享链接，也不代表完整保留当前规则与设备设置。应检查当前导出或同步功能明确覆盖的范围，再决定是否补充其他对象。特别是手动填写过的参数，若原始资料已经找不到，删除前必须确认有可恢复副本。

使用 iCloud 相关能力时，先核对当前设备账号与应用内相应设置，并查看实际同步结果。云端可见性、系统可用空间和网络状态都会影响操作，不应只凭开关已开启就认定备份完成。同步也不必然等于历史归档：一次删除可能被后续同步反映到其他设备。需要保留删除前状态时，应额外保存独立副本，并确认副本不随当前整理操作一起改变。

删除前确认归属与影响

删除单个服务器前，查看它是否属于订阅及是否正在使用。订阅下属条目即使本地移除，也可能在下次更新时重新出现；若目的是永久改变远端列表，单纯删除本地条目并不能改变订阅响应。删除整个订阅的影响范围也可能更大，应先辨认关联记录和当前选择，再根据确认提示操作。不要为了隐藏一个名称相似的条目而误删整组数据。

清理独立服务器时，先保留必要的参数副本，再检查 Config 中是否存在对相关策略或名称的引用。名称与策略的关系应按实际配置确认，不要只看 Home 列表已经整齐。删除后重新检查当前选项与路由路径，必要时选择有效记录并验证新请求。若操作目标只是停用某条记录，保留清楚标记的备份通常比立即彻底清空更便于回退。

新设备按顺序恢复并验证

换机时先按已购恢复说明从 App Store 取得 Shadowrocket，再恢复自己的数据。应用购买记录与连接资料是不同对象，恢复应用不代表订阅、服务器和 Config 已全部返回。系统要求与购买适用性以 App Store 页面标注为准。新设备首次建立连接时，按实际出现的系统提示处理 VPN 配置授权，不要把授权弹窗误认为订阅已经验证成功。

恢复顺序建议从已有原始资料开始：先确认订阅地址和独立参数可用，再恢复服务器记录与 Config，最后核对 Global Routing、DNS 和 On Demand 等相关设置。每恢复一层就验证一次，避免一次导入多份相似备份后无法分清当前启用的是哪份。旧设备仍可使用时，先保留其原状作为参照，直到新设备已完成列表、连接与目标访问的完整验证。

若恢复后缺少条目，先确认备份范围与文件选择，不要立即断定数据损坏；若条目齐全却无法连接，则转入参数和测试章节。订阅凭据如果已在远端变更，旧备份只能恢复旧值，仍需按自己的有效资料更新。关于同步、导出与迁移的进一步说明，可阅读配置备份与换机迁移。完成后记录哪些对象已恢复，并安全处理不再需要的临时副本。