TL;DR：先查 iOS 权限，再查 URL。Shadowrocket 更新订阅超时，最常见的现场是：系统没有给客户端稳定的网络权限、订阅地址实际返回网页、二维码复制缺参数，或远程规则文件先卡住。
Shadowrocket 是 iOS 上的网络扩展应用，更新订阅并不等于普通浏览器下载文本。它要经过 iOS 的 VPN 配置、本地网络权限、蜂窝数据权限和应用自己的解析流程。因此排查时别从「重装 App」开始，先把输入和系统条件拆开。
快速判断表
| 检查点 | 正常表现 | 异常表现 |
|---|---|---|
| 蜂窝数据 | 设置里允许 Shadowrocket 使用 | 仅 Wi-Fi 可更新，移动网络超时 |
| VPN 配置 | iOS 已信任配置且可启动 | 点更新前后 VPN 状态反复跳变 |
| 订阅 URL | Safari 打开后返回配置文本 | 登录页、HTML、403、空白 |
| 二维码 | 编辑页 URL 与原文一致 | 少了 token、? 后参数缺失 |
| 远程规则 | 规则 URL 可单独打开 | raw 文件超时或返回错误页 |
1. 先处理 iOS 权限
到「设置」里确认 Shadowrocket 的蜂窝数据没有被关闭；如果你只在公司 Wi-Fi 或酒店 Wi-Fi 下失败，也要换到个人热点测一次。iOS 的 Network Extension 有自己的连接生命周期，当前 VPN 已经处于异常状态时，更新请求可能会沿着一条坏链路发出。
做法很简单：关闭 Shadowrocket，删除正在连接的临时状态，切到普通网络，再点一次更新。不要一边让旧配置运行，一边更新同一个订阅。
2. URL 要看最终返回
把订阅 URL 复制到 Safari，只看「能打开」不够，要看最终内容。正常应是可被客户端识别的订阅文本或配置；如果看到登录页、套餐提示、CDN 错误页，Shadowrocket 只能报超时或解析失败。
二维码导入尤其要核对。很多二维码内容是长 URL，截图识别、聊天软件转发、手动复制都可能吃掉 & 之后的参数。进入配置编辑页，把 URL 从头到尾看一遍，必要时让提供方重新生成。
3. 远程规则也会拖慢
有些配置把规则放在远程 URL。订阅更新时，客户端会同时拉取规则；规则源如果在 GitHub raw、私有 CDN 或短链后面，卡住的并不是节点列表，而是规则文件。可以先临时禁用远程规则，只更新订阅本体，再逐个恢复。
如果你还没有可导入的配置，可以选一份配套订阅线路，重点看它是否给出 Shadowrocket 可识别的导入格式。
服务端响应也要看
如果权限和 URL 都正常，再看服务端响应。订阅服务端有时会根据 User-Agent、地区、过期状态返回不同内容：Safari 看到的是可读文本，Shadowrocket 请求时却拿到 429、403 或短暂的网关错误。此时可以让提供方检查访问日志，确认请求是否到达、返回码是多少、响应体是否为空。
还要留意短链。短链多一次跳转，多一个失败点。排查阶段尽量使用最终长链接，等确认稳定后再决定是否换回短链。若订阅地址带 token，不要在群聊或截图里公开；泄露后服务端可能主动限流，表现出来仍是更新超时。
复测顺序
- 关闭当前 VPN 状态，切换到普通网络。
- 用 Safari 打开订阅 URL，确认最终内容。
- 在 Shadowrocket 新建一个测试配置，不覆盖旧配置。
- 暂停远程规则，只拉订阅本体。
- 恢复规则，逐个检查慢源。
这个顺序的好处是每次只改一个变量。很多人一边换网络、一边改规则、一边重新扫码，最后虽然恢复了，却不知道真正原因；下次同样问题还会从头猜。
记录一次完整现场
排查结束后，建议把可复现的信息记下来：网络类型、iOS 版本、Shadowrocket 版本、订阅 URL 的域名、返回码、远程规则数量、失败时间。下次再出现同类问题时，可以先比对这些信息，而不是凭感觉更换配置。尤其是只在某个 Wi-Fi 下失败的情况，记录网关、DNS 和是否有强制登录页，会比截图一个超时弹窗更有价值。
如果要反馈给订阅提供方，不要只说「更新不了」。给出时间、客户端、网络类型和服务端返回现象，对方才能查日志。涉及 token 的 URL 只发打码版本，避免把凭证暴露在工单或聊天记录里。
相关阅读
FAQ
更新超时要不要清空所有配置？ 先不要。复制当前配置，单独新建一个测试项；确认新项能更新，再删除旧缓存。
只在后台更新失败怎么办？ iOS 会限制后台网络活动。打开 App 前台更新一次，确认成功后再看自动刷新。
规则和订阅谁先排查？ 先订阅 URL，再规则 URL。订阅本体不正常时，规则排查没有意义。