本文适用于已经持有自己订阅链接的 Shadowrocket（小火箭）用户。先在 Home 手动刷新，确认链接能返回有效内容，再到 Settings → Subscribe 设置打开时自动更新；失败时按链接、请求路径、返回格式的顺序排查。订阅更新与服务器连接测试是两件事，保留现有配置通常比先删除再导入更便于定位问题。
一、先区分订阅更新与连接失败
订阅更新是向已有订阅地址发起请求，并将返回内容解析为服务器条目。它不等于测试每个服务器是否可连接，也不等于更新 Config 中的路由规则。Home 中条目可以连接，不代表订阅地址仍然有效；订阅更新成功，也不能保证所有条目在当前网络下均可使用。
开始操作前，保留当前仍可用的条目和配置，记录报错原文。不要因为一次超时就删除整个订阅分组。如果旧条目仍可连接，它们还可能为订阅请求提供可用的网络路径。
- Home：查看已有订阅及服务器条目，执行刷新，并检查条目变化。
- Settings → Subscribe：设置订阅更新行为，包括打开时更新与经代理更新。
- Config：管理配置及规则。刷新服务器订阅不代表此处的配置文件同步更新。
- Settings → On Demand：设置按条件建立连接的行为，不是订阅定时更新入口。
Shadowrocket 是 Apple 平台的付费客户端，唯一获取入口是 App Store。客户端买断 ≠ 线路套餐。本文只说明如何管理用户已有的订阅，不提供、不销售、不推荐订阅或相关服务。
二、在 Home 手动更新已有订阅
先做一次可观察的手动更新，再开启自动更新。这样可以区分“请求本身失败”与“没有触发自动更新”，避免同时改动多个设置。
-
核对订阅
进入 Home，找到要更新的订阅分组，核对其名称和保存的 URL。多个分组并存时，先确定报错来自哪一个，不要把另一组条目增加当作本组更新成功。
-
检查链接
检查 URL 是否完整，尤其是问号后的参数。复制时带入换行、首尾空格，或漏掉 token 的后半段，都可能使同一域名返回不同结果。
-
下拉刷新
在 Home 的列表区域下拉触发订阅刷新，等待本轮请求结束。存在多个订阅时，分别检查各组结果；不要连续下拉，用重复请求掩盖第一次的错误信息。
-
核对结果
检查错误提示是否消失、分组是否仍有条目，以及名称、地区或数量是否出现预期变化。内容未变化也可能是成功更新，不能仅凭数量不变判断失败。
若尚未保存订阅，入口是 Home 右上角「+」→ Type → Subscribe，再填写用户已有的 URL 并保存。重新添加不是已有订阅更新失败时的首选处理；先确认原地址是否仍有效，才能避免留下多个指向同一地址的重复分组。
https://example.com/sub?token=xxxx以上仅为明确虚构的地址示例，不可用于导入。实际订阅 URL 中的 token 往往具有访问凭据作用，不要将完整地址贴入公开日志、截图或站点文件。
三、设置打开时自动更新与更新路径
进入 Settings → Subscribe，找到 Update on Open 并开启。它用于在打开应用时触发订阅更新，不应理解为持续驻留后台、按固定分钟数轮询。应用一直停留在前台时，也不要把“没有再次刷新”直接视为故障；需要立即获取内容时，在 Home 手动刷新。
| 设置或操作 | 控制内容 | 适用检查 |
|---|---|---|
| Home 下拉刷新 | 主动发起一次订阅更新 | 确认地址与当前请求路径能否工作 |
| Settings → Subscribe → Update on Open | 打开应用时触发更新 | 手动更新正常后，再验证自动触发 |
| Settings → Subscribe → Update via Proxy | 让订阅更新请求使用代理路径 | 当前直连网络无法访问订阅地址时进行对照 |
| Settings → On Demand | 按所设条件建立连接 | 检查连接行为，不用于替代订阅更新设置 |
结论：先验证路径，再启用自动更新
手动刷新尚未成功时，开启 Update on Open 只会重复同一失败请求。先让一次手动刷新成功，再验证重新打开应用后的更新行为。
如果需要开启 Update via Proxy，先确认现有代理连接确实能工作，再执行手动刷新。订阅更新依赖代理，而代理所需的新条目又只能从该订阅获取时，会形成依赖循环；此时应保留可用旧条目，或在另一个可访问该地址的网络下重新测试。
Global Routing 中的 Config、Proxy、Direct、Scene 是连接处理姿态，不是订阅更新频率设置。不要为解决一次订阅报错就同时切换这些姿态、修改规则和重建配置；先单独验证 Update via Proxy 对本次请求的影响，才能知道改变的是哪一环。
四、按报错区分链接、网络与返回内容
下列是网络请求中可能出现的错误原文或 HTTP 状态。应用提示可能带有地址、错误域或其他上下文，应保存实际显示的完整错误；不要要求每次提示都与下面逐字相同。
报错：401 Unauthorized
原因与解法：服务器没有接受请求携带的认证信息。核对 URL 参数是否完整，并向自己已有订阅的服务方确认凭据状态；如果地址已重置，应替换保存的 URL，而非反复刷新旧地址。
报错：403 Forbidden
原因与解法：服务器拒绝当前请求，可能涉及访问策略、凭据状态或请求来源限制。先确认自己有权访问该订阅，再核对服务方给出的订阅入口与要求；不要仅凭 403 就认定是应用解析故障。
报错：404 Not Found
原因与解法：请求路径不存在，或服务器以此状态隐藏不可访问的资源。核对地址路径、参数与复制完整性，确认是否误用了账户页面地址或已经停用的旧入口。
报错：The request timed out.
原因与解法：请求未在允许时间内完成，故障可能发生在解析、建立连接或等待响应阶段。先切换 Wi-Fi 与蜂窝网络进行对照，再在已有可用连接的前提下测试 Update via Proxy。
HTTP 状态只能缩小范围，不能单独证明订阅到期。比如 403 既可能来自源站，也可能来自中间访问控制；确认时应同时记录网络类型、是否使用代理以及同一地址在另一网络下的结果。遇到证书错误时，应检查设备日期时间与地址是否正确，不要通过降低证书验证要求来替代排查。
五、地址能打开，为什么仍然无法导入
“网页能打开”只说明收到了某种响应，不代表响应是订阅。浏览器可能显示登录页、访问验证页或错误说明；甚至 HTTP 状态为 200，正文仍可能是一段 HTML。Shadowrocket 需要的是可以识别的订阅内容，而不是能在浏览器中阅读的网页。
- 返回登录页面：核对是否复制了账户管理页面，而不是用于客户端导入的订阅地址。浏览器已有登录状态，也不代表应用请求携带相同的会话信息。
- 返回验证页面：页面交互通过后，浏览器能继续访问，不代表订阅请求也能自动通过。应向自己已有订阅的服务方确认其客户端订阅入口。
- 返回空内容：确认账户及订阅状态、是否存在有效条目，并区分真正的空响应与未加载完成的页面。
- 返回格式不符：确认取得的是适用于 Shadowrocket 的订阅内容，不要把完整路由配置、普通说明文本或其他用途的数据直接填入 Subscribe。
协议名称与订阅封装格式也不是一回事。内容里出现 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard 的名称，并不能保证整个响应一定可被当前导入入口识别；仍需核对实际返回结构和字段是否符合要求。
固定订阅 URL，先比较两种网络；固定网络，再比较是否使用 Update via Proxy。每次记录结果后再改下一项，不要同时更换地址、清空分组、修改 DNS 和重写规则，否则难以判断哪项改变起了作用。
六、自动更新与刷新结果的常见问题
手动更新成功，为什么打开应用时没看到变化？
先到 Settings → Subscribe 确认 Update on Open 已开启，再离开应用并重新打开，观察是否有更新结果。服务器列表没有变化并不等于没有请求；若远端内容相同，刷新后名称与数量也可能完全不变。
订阅更新超时，要先打开连接开关吗？
不必一律如此。地址直连可访问时，可先直接刷新；只有需要代理路径时，才先建立可用连接，再到 Settings → Subscribe 检查 Update via Proxy。连接开关已打开也不代表所选条目实际可用。
更新成功以后，为什么网页还是打不开？
先在 Home 检查当前选择的服务器及连接状态，再检查 Global Routing 与 Config。订阅刷新只完成列表获取和解析，网页访问还取决于所选服务器、DNS 与规则；不要把后续连接故障继续当作订阅更新失败处理。
开了 On Demand，会定时更新订阅吗？
On Demand 处理连接触发条件，不负责按固定周期刷新订阅。需要打开应用时更新，应检查 Settings → Subscribe → Update on Open；需要立刻更新，应回到 Home 手动刷新。
排查仍失败，需要保留哪些信息？
记录报错原文、发生时间、Wi-Fi 或蜂窝网络、Update via Proxy 开关状态，以及旧条目是否可连接。对外提供信息前遮住完整 URL、token、账号和密码；这些信息足以帮助定位请求阶段，不必公开访问凭据。
恢复后保留一个已验证成功的更新路径即可。若需要检查首次导入和授权步骤，可继续阅读使用说明；需要区分订阅与配置的管理范围，可查看订阅手册。订阅刷新操作不改变应用购买状态，系统要求与设备兼容性以 App Store 页面标注为准。