Shadowrocket 订阅更新方法:手动更新、打开时自动更新与更新失败排查

订阅可以手动更新,也可以在打开应用时自动更新,文中分别说明设置位置。另整理更新失败时最常见的几类原因:链接失效、网络环境、返回格式不符,并给出逐项核对方法。

本文速览

已有自己服务商与订阅的用户,可以先在 Home 手动刷新,再到 Settings → Subscribe 检查 Update on Open。更新失败时依次核对链接授权、请求所走的网络和返回内容;更新成功但无法连接时,转查连接参数与路由设置,不要把两类问题混在一起处理。

订阅更新的范围:拉取列表,不等于建立连接

Shadowrocket(小火箭)的订阅更新,是用已保存的订阅 URL 向服务端请求内容,再解析其中的服务器条目。手动刷新适合首次导入后核对结果、服务商通知条目调整,以及定位某一次失败;打开时自动更新适合在日常进入应用时检查列表变化。

更新请求成功,只能说明这次请求拿到了可处理的内容。它不能证明每个服务器都能连接,也不能证明账号剩余流量、服务器证书和远端端口均正常。反过来,某个已保存条目仍能连接,也不能证明订阅 URL 仍然有效:订阅授权和连接凭据可能是分开管理的。

手动更新:先确认分组,再检查刷新结果

首次导入时,应复制服务商提供的完整订阅 URL,而不是账户登录页、付款页或某一个服务器的分享链接。链接末尾的查询参数往往包含授权信息,不能因为地址太长就删掉。以下用假值说明地址结构,不可用于连接:

https://example.com/sub?token=xxxx
  1. 核对来源

    从自己的服务商账户页面复制订阅 URL。保留协议、路径和查询参数,检查首尾是否混入空格、换行或聊天标点。

  2. 保存订阅

    首次添加时进入 Home → 右上角「+」→ Type → Subscribe,在 URL 中粘贴完整链接并保存。已有订阅直接使用原分组,不必重复添加。

  3. 下拉刷新

    返回 Home,在列表中下拉触发刷新,等待请求结束。排查期间不要连续重复下拉,以免把多次请求的结果混在一起。

  4. 检查内容

    展开目标订阅分组,核对条目名称、数量和预期调整。若列表未变化,先确认服务端是否实际发布了新内容,再判断是否需要继续排错。

一次下拉可能涉及多个已保存订阅。某个分组失败,不代表其他分组也失败;应记录具体分组及提示。列表数量保持不变也不一定表示没有更新,因为服务端可以只调整地址、端口或连接参数,而不改变名称与数量。

不要通过反复删除并导入来验证刷新。这样会丢失前后对照,也可能造成重名分组。先保留现有条目,确认新的订阅 URL 能正确解析后,再处理旧分组。

打开时自动更新:设置位置与触发边界

进入 Settings → Subscribe,启用 Update on Open。该选项用于打开应用时触发订阅更新,不应当理解为固定间隔的后台轮询。启用后,仍需检查一次实际请求结果,不能只凭开关处于开启状态判断列表已经更新。

如果自动更新时失败,而稍后手动刷新成功,应比较两次请求时的网络条件。例如打开应用时 Wi-Fi 尚未完成登录,或代理连接尚未建立,都可能让首次请求与稍后的请求得到不同结果。先复现这个差异,再调整选项,比同时改动多个开关更容易定位原因。

更新失败:按提示区分授权、网络与内容

先记录提示原文、发生时间和所处网络。下面列出可用于识别问题的提示或 HTTP 状态;具体显示语言与详细描述可能不同,HTTP 状态也可能只出现在服务端响应或诊断记录中。不要仅凭一个笼统的加载失败提示就认定订阅已经到期。

Failed to load subscription

原因与解法:这是加载失败的概括,单凭这句话不能区分授权、网络或格式问题。先核对完整 URL,再检查是否伴随超时、HTTP 状态或解析提示。

The request timed out.

原因与解法:请求未能在限定时间内完成,可能与当前网络、访问路径或服务器响应有关。先换一个可用网络重试,再判断是否需要 Update via Proxy。

401 Unauthorized

原因与解法:服务器没有接受本次请求的授权。重新从自己的账户页面复制当前订阅 URL,检查 token 是否遗漏、失效或已被重置。

403 Forbidden

原因与解法:服务器拒绝访问,可能涉及账户权限或访问限制。向自己的服务商核对限制条件,不要把反复刷新当作解除权限限制的方法。

404 Not Found

原因与解法:请求路径没有找到对应资源。检查地址是否截断、路径是否已变更,并从原账户页面重新获取订阅 URL。

HTTP 状态有助于缩小范围,但不能替代账户核对。例如链接失效可能返回错误状态,也可能返回一个状态为 200 的说明网页。后者在网络层面已经完成请求,在订阅解析层面仍然不能使用。

Update via Proxy:只在已有可用连接时测试

Settings → Subscribe → Update via Proxy 用于调整订阅请求的访问路径。它不是修复无效 token 或转换订阅格式的开关。当前网络无法直接访问订阅域名,而已有条目可以正常建立代理连接时,才适合用它做对照测试。

观察条件 下一步操作 结果如何判断
当前网络可直接更新 保留已验证可用的设置,检查自动更新 不必为排错额外改变请求路径
直接请求超时,已有代理可用 建立连接后启用 Update via Proxy,再手动刷新 若仅此路径成功,重点检查订阅域名的网络可达性
两条路径均返回 401 或 403 停止反复刷新,核对授权与访问限制 更换路径不能替代服务器授予访问权限
没有任何可用连接条目 先测试其他可用网络,并联系自己的服务商 不能依赖尚未建立的代理完成首次拉取

结论:每次只改变一个条件

保持同一订阅 URL,先比较网络,再比较 Update via Proxy;记录每次提示。若同时改链接、切换网络并更换配置,就无法确定究竟哪个变化解决了问题。

还应核对 Home → Global Routing 的当前选项。Direct 是直接连接姿态,Proxy、Config 与 Scene 也各有不同用途;不能把连接开关开启等同于所有请求一定经过代理。排查时要结合实际选中的路由姿态、配置和可用连接观察结果,不要为了刷新订阅而随意改写整个 Config。

格式检查与连接检查:更新成功后继续核对什么

订阅 URL 必须返回 Shadowrocket 能识别的内容。把服务商的登录页当成订阅地址,或复制了需要浏览器会话才能访问的临时页面,即使浏览器能显示文字,也不能证明应用能解析其中的服务器信息。需要向自己的服务商确认适用于 Shadowrocket 的订阅输出,而不是自行猜测编码或删改内容。

当列表已经正常拉取,但连接测试失败,应转而检查账号状态、服务器可达性、认证信息、TLS 与传输参数。此时继续刷新同一份内容通常不会改变结果。Config 中的 DOMAIN-SUFFIX、GEOIP、IP-CIDR 与 FINAL 负责规则匹配,不会修复服务端返回的错误订阅格式。

常见问题:自动更新、列表变化与失败后的处理

打开应用没有看到列表变化,是没更新吗?

先到 Settings → Subscribe 检查 Update on Open,再在 Home 手动刷新一次。服务端内容没有变化时,成功更新后列表也可以保持原样;应结合请求提示和服务商发布的具体调整判断。

更新失败后,要先把原订阅删掉吗?

先不要删除。记录原分组和报错,核对当前 URL 与账户授权,再排查网络和格式。删除不能修复过期授权,还可能使原本可用的已保存条目失去对照。

浏览器能打开链接,为什么仍然更新失败?

检查浏览器显示的是订阅内容还是登录、验证页面。浏览器可能带有已登录会话,应用请求未必具有相同条件;不要把网页显示成功等同于订阅解析成功。

开了 On Demand,就会自动刷新订阅吗?

不会由这个选项安排订阅刷新。Settings → On Demand 管理按需连接;订阅打开时更新在 Settings → Subscribe → Update on Open 中设置,临时更新则回到 Home 下拉刷新。

刷新后少了几个条目,需要重新安装吗?

先向自己的服务商核对返回列表是否移除或改名了这些条目,再确认正在查看正确的分组。重新安装不能恢复服务端已移除的内容;处理前保存必要的个人配置记录。

App Store 正版核对 →