Shadowrocket 订阅更新教程：手动更新、打开时自动更新与更新失败排查

订阅更新的范围：刷新列表，不等于连接成功

Shadowrocket（小火箭）的订阅更新，是用已经保存的订阅地址重新请求内容，并将解析后的条目更新到 Home。服务商调整服务器地址、端口、认证信息或条目名称后，客户端通常需要重新获取订阅才能接收到这些变化。客户端买断 ≠ 线路套餐；本文以用户已有自己的订阅为前提。

更新成功只说明这次获取和解析订阅的过程完成，不代表其中每个条目都能建立连接，也不代表正在使用的连接已经切换到新条目。订阅列表、Config 中的规则以及系统 VPN 连接是不同层次的设置，排查时应分开观察。

Home 中添加的 Subscribe 是订阅来源；单独导入的一条服务器记录不一定具有订阅地址，因此不能按订阅的方式获取后续变化。Config 中远程配置文件的更新也不等同于 Home 中订阅列表的更新，操作前先确认正在维护的是哪一类内容。

手动更新：先定位订阅，再执行刷新

首次导入、服务商通知配置发生变化，或者自动更新后列表没有变化时，优先使用手动更新。这样可以明确触发一次请求，并立即观察结果。不同界面语言下文字可能不同，以下保留英文界面词；订阅分组操作入口也可能随界面布局调整。

1. 定位订阅

   打开 Home，找到对应的订阅分组，核对分组名称。若尚未导入，进入 Home 右上角「+」→ Type → Subscribe，将自己已有的订阅链接填入 URL，再保存。

2. 检查地址

   进入该订阅的编辑入口，确认 URL 完整，尤其是问号后的参数。复制时不要带入空格、换行、中文标点或说明文字；检查后返回 Home。

3. 触发更新

   在 Home 列表顶部下拉刷新。需要单独更新某个订阅时，可长按对应订阅分组并选择 Update；以当前分组实际显示的操作菜单为准。

4. 核对结果

   等待请求结束，观察有无错误提示，再展开目标分组，检查条目名称、数量或已知修改是否体现。不要在请求尚未结束时连续重复刷新。

5. 复查连接

   确认当前选中的条目仍存在于更新后的列表。若服务商替换了该条目，重新选择有效项，再单独测试连接；有正在进行的会话时，先保存工作再调整连接。

列表数量没有变化，不一定表示更新失败：服务端可能只修改了同名条目的认证信息，或者这次返回的内容与上次相同。反过来，数量增加也不能证明所有条目可用。应把更新结果与服务商明确告知的变化对应起来，而不是只看数字。

打开时自动更新：设置入口与适用条件

自动更新的常用入口是 Settings → Subscribe → Update on Open。打开后，应用会按该选项的触发条件尝试更新订阅。若当前界面提供更新间隔等附加限制，也应一并核对；不要把每次切回前台都理解为必定重新请求一次。

此设置适合希望在打开应用时获取订阅变化的用户，但它依赖当时网络可访问订阅服务器。它不是对系统后台定时任务的保证，也不等于设备锁屏后仍会持续获取订阅。若开关名称或入口层级与本文不同，应以 Settings 中 Subscribe 分组的实际选项说明为准。

Settings → On Demand 用于按条件触发 VPN 连接，与订阅的自动获取不是同一项功能。只打开 On Demand，不能据此认定订阅会自动更新；只打开 Update on Open，也不会因此自动完成系统 VPN 授权或保证连接可用。

手动与自动更新：按维护场景选择

两种方式获取的是同一个订阅来源，主要区别在于触发时机和排错可观察性。自动更新不会把失效链接变成有效链接，也不会改变订阅服务器返回的格式。遇到问题时，保留自动设置不动，先做一次可观察的手动请求，通常更容易定位原因。

• 订阅很少变化：需要时手动更新即可，不必反复请求。
• 订阅经常调整：先验证链接，再考虑启用 Update on Open。
• 服务商限制请求频率：遵守自己的服务商给出的更新间隔，避免连续触发。
• 需要保留本地修改：更新前记录必要差异；订阅生成的条目可能被下一次更新覆盖，不能当作持久保存手动修改的位置。

更新失败排查：先读错误，再检查对应环节

先记录错误发生的时间、所处网络、目标订阅以及提示内容。下面列出常见网络层英文错误原文；实际界面可能显示本地化文本或附加说明，应按含义对应处理。错误文字描述的是失败环节，并不能单独证明服务商账户或某个服务器一定有问题。

HTTP 状态与返回内容要分开看

• HTTP 401：通常表示请求缺少有效认证。核对链接中的认证参数是否完整，并确认服务商是否重新生成了地址。
• HTTP 403：服务器拒绝了请求，可能涉及访问限制或凭据状态。不要直接认定为到期，应让自己的服务商核对拒绝原因。
• HTTP 404：请求路径不存在。检查是否复制了旧路径，或把管理页面地址当成了订阅地址。
• HTTP 429：请求过于频繁。暂停刷新，按服务器返回的等待要求或服务商说明稍后重试。
• HTTP 5xx：通常涉及服务端或其上游处理异常。保留状态码与发生时间，稍后重试；反复修改本地条目一般无助于恢复远端服务。

即使服务器返回 HTTP 200，也可能得到登录页、验证页面或空白内容，而不是客户端能解析的订阅。若提示格式错误或更新后没有有效条目，应检查返回内容的类型，并核对自己的服务商是否提供适用于 Shadowrocket 的订阅输出；不要仅凭浏览器能打开某个网页就判断订阅正常。

链接过期与格式不符：核对完整 URL

订阅 URL 往往携带访问凭据。示例 https://example.com/sub?token=xxxx 只是明显的假值，不是可用服务地址。实际地址中的路径和查询参数都应原样保留；删掉问号后的内容，可能使一个有效订阅变成未认证请求。

1. 比对来源：回到自己的服务商提供订阅信息的位置，确认复制的是订阅地址，而非账户主页、登录页或使用说明页。
2. 核对有效性：确认订阅资格、有效期与链接状态。某些服务会在重新生成链接后使旧地址失效，仅恢复账户状态不一定恢复旧链接。
3. 检查复制完整性：保留原始编码和全部参数，不自行替换 %、&、= 等字符，也不要把省略显示的地址直接当作完整地址。
4. 核对输出格式：使用服务商标明适用于 Shadowrocket 的格式。订阅容器的编码与内部条目协议是两个层次，不能只看文字中出现了某个协议名称就认定整份内容有效。
5. 修改后单次测试：更新现有订阅的 URL，再手动刷新一次。保留原分组有助于对照问题，避免因为重复导入而混淆新旧条目。

Shadowsocks、VMess、VLESS、Trojan 等名称描述条目的协议类型；订阅地址负责一次返回一组配置。单条分享链接与可刷新的订阅来源不同，把单条链接放入 Subscribe 的 URL 字段，不会自动获得远端列表更新机制。

订阅凭据按敏感信息处理

向服务商反馈时，优先提供错误文字、时间与已经遮盖凭据的地址。不要公开完整订阅链接、认证参数或包含这些信息的截图；怀疑链接泄露时，通过自己的服务商重新生成凭据。

更新成功却不能使用：回到连接与分流层核对

订阅刷新与连接使用可能经过不同的网络路径。更新成功后仍不能访问，应先确认当前选中的是更新后存在的有效条目，再检查连接状态与 Global Routing，而不是持续刷新同一订阅。反复更新只会增加请求次数，无法修正规则匹配结果。

• 核对条目：检查名称、服务器地址与端口是否符合自己的服务商说明。不要仅因为两条记录名称相似，就认定认证参数也相同。
• 核对连接：确认应用连接开关和系统 VPN 状态；必要时在保存当前工作后重新连接，使新连接使用更新后的配置。
• 核对姿态：Global Routing 下的 Proxy、Direct、Config、Scene 决定不同的流量处理方式。使用 Config 时，请求还受当前配置规则约束。
• 核对规则：DOMAIN-SUFFIX、GEOIP、IP-CIDR 与 FINAL 等规则影响策略选择，不决定订阅服务器返回哪些条目。应在 Config 中检查实际生效的配置和规则顺序。
• 区分故障：单个条目失败而其他条目可用，应检查该条目及对应服务端；全部条目失败但订阅能更新，则继续检查连接权限、网络与配置，不应把两者混为一次更新故障。

完成维护后，再执行一次手动更新，确认目标分组仍能正常刷新，并检查 Update on Open 是否符合日常使用需要。需要反馈时，整理触发方式、错误原文、网络类型和已做过的检查即可，无需公开订阅凭据。