Shadowrocket 订阅更新失败怎么办:手动更新、打开时自动更新与排查顺序

先区分：订阅更新失败，还是连接失败

Shadowrocket（小火箭）的订阅更新，是从用户提供的地址获取服务器信息，再整理到 Home 列表的过程。它不是更新应用本身，也不等于连接某个服务器。列表仍能看到旧条目，只能说明本地还有已保存的数据，不能证明这次刷新已经成功。

先记录失败发生在哪一步：是刷新立即出现提示、等待后超时，还是显示更新完成但没有新增条目。若更新已经完成，只是某个服务器不能连接，应转到连接测试排查，不要反复删除订阅重新添加。

这条流程也解释了两种常见现象：旧服务器仍能连接，但订阅地址已经失效；订阅能正常刷新，但其中某个服务器暂时不可用。两者并不矛盾。前者卡在获取列表，后者发生在使用列表之后。

手动更新：从 Home 开始，保留原订阅

先做一次手动更新，便于观察完整结果。不要把“重新添加”作为第一步：同一地址重复导入，可能让 Home 中出现多个来源组，也会增加判断难度。需要重新输入地址时，优先核对并编辑现有订阅。

1. 找到订阅

   进入 Home，确认要更新的订阅分组。记下分组名称及当前条目数量，避免把单独添加的服务器误认为订阅。

2. 核对地址

   打开该订阅的编辑页面，核对 URL 与自己的服务商提供的地址是否一致。首次导入的路径是 Home → 右上角「+」→ Type → Subscribe；已有订阅不必再创建一份。

3. 下拉刷新

   回到 Home，在列表顶部下拉触发刷新，等待本次请求结束。若存在多份订阅，要分别留意各组结果，不把其中一组成功当作全部成功。

4. 核对结果

   记录成功或失败提示，再检查目标分组。条目数不变可能只是远端内容未变；是否完成请求与解析，应结合更新提示判断。

打开时自动更新：在 Settings 中设置

自动更新适合减少日常手动操作，但不会修复失效链接。建议先让手动更新成功，再启用打开时更新。进入 Settings → Subscribe，找到 Update On Open 并开启；界面文字大小写或位置可能随应用调整，以实际显示为准。

这项设置针对打开应用时触发订阅更新，不应理解为固定间隔、持续后台执行的刷新任务。切回应用后若不能确认是否已更新，直接回到 Home 手动刷新并检查结果，比反复切换开关更容易判断。

• 先确认开关：Settings → Subscribe → Update On Open。不要在 Config 中寻找服务器列表的自动刷新设置。
• 再验证行为：启用后重新打开应用，等待请求结束，检查目标订阅是否出现更新结果；仅看到 Home 页面不代表请求成功。
• 留意当前网络：打开应用时若尚未联网，或所连 Wi-Fi 仍需认证，自动更新也可能失败。网络恢复后再手动刷新一次。
• 不要混淆功能：Settings → On Demand 管理按需连接，不能替代 Subscribe 中的更新选项。连接启动与订阅刷新是不同动作。

如果自动更新失败、手动更新却成功，先比较两次操作时的网络条件和连接状态。打开应用的一刻可能恰好处于 Wi-Fi 与蜂窝网络切换期间。一次差异不足以说明设置失效，应在相同网络下重复验证。

第一步：排查订阅链接失效与权限变化

首先向自己的服务商确认订阅入口仍有效。不要拿网页登录地址替代订阅地址，也不要凭记忆删除查询参数。一个看起来很长的 URL，可能同时包含账号标识、访问凭据与输出格式选择，少一个参数就可能得到不同结果。

https://example.com/sub?token=xxxx

上面只是不可用于实际导入的示例。实际排查时，应在本机将地址与来源逐字核对，尤其检查开头的协议、域名、路径、问号后的参数，以及复制时带入的空格或换行。不要把真实地址发到公共页面或不明转换工具中。

• 地址被重置：如果服务商重新生成过订阅链接，旧 token 可能不再有效。将新的完整地址保存到现有订阅后再刷新。
• 访问权限变化：账户状态、服务期限或服务商访问限制可能影响订阅响应。客户端购买状态不能替代这些权限。
• 返回 401 或 403：若错误详情出现这些 HTTP 状态，优先核对授权与访问限制；它们不能仅凭数字确定为同一种原因。
• 返回 404：核对完整路径及入口是否变更。此时盲目修改服务器端口，通常不能修复订阅接口的路径问题。
• 返回 429：暂停连续刷新，按服务商说明等待后重试。频繁重试可能继续触发请求频率限制。

浏览器能打开同一域名的首页，不代表订阅接口有效。首页与订阅路径可能使用不同权限检查；跳转到登录页面也不等于获得了服务器列表。判断对象应是完整订阅 URL 的响应，而不是域名是否能访问。

第二步：排查当前网络与请求超时

确认链接有效后，再检查设备能否稳定访问订阅地址所在的主机。先完成 Wi-Fi 的网页认证，确认普通页面可正常加载，再比较 Wi-Fi 与蜂窝网络。每次只改变一个条件，避免同时改地址、模式和网络后失去对照。

上述英文是排查时可能看到的提示，系统语言和错误来源不同，显示文字可能不同。不要为了匹配某一句报错忽略错误详情。若出现证书相关提示，还应核对设备日期与时间，并让服务商检查证书，不要通过忽略证书验证来绕过问题。

1. 在系统设置中确认当前网络已连接；需要网页认证的 Wi-Fi，先完成认证。
2. 记录 Shadowrocket 当前连接状态及 Global Routing 的选择，先在原状态刷新一次。
3. 仅切换 Wi-Fi 或蜂窝网络，再刷新同一份订阅，比较结果。
4. 若怀疑当前连接影响请求，在可控条件下断开连接再测；如果启用了 On Demand，留意它是否重新触发连接。

Global Routing 中的 Proxy、Direct、Config、Scene 是整体流量处理方式的选择，不是“修复订阅”按钮。不要为刷新一个地址长期强制改变全部流量处理方式，也不要未经验证就添加 DIRECT 规则。订阅请求的实际路径需要结合当前连接和设置判断。

第三步：排查返回内容与格式不识别

网络请求完成后，仍可能没有可导入的条目。HTTP 返回 200 只表示请求在 HTTP 层面成功，返回正文可能是登录页、维护页、错误说明，或当前导入入口无法识别的数据。此时继续更换网络未必有用。

• 先确认入口类型：Home →「+」→ Type → Subscribe 用于导入订阅。Config 管理配置文件，不能把完整配置文件地址与服务器订阅地址直接视为同一类输入。
• 再确认输出用途：向自己的服务商说明使用 Shadowrocket，核对其提供的订阅输出是否适用于当前导入方式。不要只根据文件后缀判断。
• 检查空结果：返回内容为空，或者内容中没有可识别的服务器条目，都可能使列表无法按预期更新。应由服务商确认响应正文，而不是先清空本地列表。
• 检查条目完整性：Address、Port 以及协议所需的认证信息需要与服务端匹配。订阅可以被读取，不代表每个条目的参数都完整可用。

Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 是协议名称；Subscribe 是导入订阅的类型。不能因为两种服务都写着同一个协议，就认定它们的订阅封装相同。协议、订阅格式与完整配置结构属于不同层次。

更新后的收尾：验证条目，再处理重复内容

更新成功后，先看目标分组，再选择其中一个条目测试连接。Connectivity Test 可以帮助观察测试条件下的可达性与延迟，但不是带宽测试；一个数字也不能证明所有网站、所有业务都正常。

1. 确认更新结果：检查目标分组名称与条目变化。服务商没有修改内容时，数量和名称保持不变属于可能的正常结果。
2. 测试具体连接：选择已有条目，运行 Connectivity Test，再实际打开需要访问的页面。列表刷新成功与访问成功分别记录。
3. 核对重复来源：如果同一份订阅曾导入多次，先确认哪一组保留了正确地址，再移除多余分组，不要只凭服务器显示名判断重复。
4. 保留维护记录：记录这次更改的是 URL、网络还是自动更新设置。下次出现相同现象时，可以直接从对应环节检查。

仍然失败时，向自己的服务商提交网络类型、失败时间、完整报错文字和已尝试的步骤，并通过其私密支持渠道核对订阅权限。提供公开截图时遮住凭据。这样的信息比只说“更新不了”更容易定位是地址、接口响应还是格式问题。

Shadowrocket 是一次性买断的闭源商业应用，主要用于 iPhone 与 iPad，唯一获取入口是 App Store。系统要求以 App Store 页面标注为准。客户端买断 ≠ 线路套餐，购买应用不会自动获得服务器或订阅。本站仅说明用户已有订阅的管理，不提供、不销售、不推荐节点或订阅。