Shadowrocket 订阅更新超时，不要先卸载 App。最省时的排查顺序：断开当前 VPN 状态，检查 iOS 对 Shadowrocket 的网络权限，再看订阅 URL 的最终 HTTP 响应和正文格式。

如果 URL 返回的是 HTML 登录页、403、429、5xx、空白响应，或者 DNS 把域名解析到错误地址，Shadowrocket 没法凭空把它变成节点列表。把「请求有没有到达服务端」和「内容能不能被解析」拆开，才能避免反复扫码。

##判断是哪一层超时

表现更可能原因做哪一步
Wi-Fi 可以更新，蜂窝数据超时iOS 蜂窝数据开关、运营商 DNS、当前 VPN 路径到「设置 → 蜂窝网络」确认 Shadowrocket 可用蜂窝数据
Safari 打开是登录页订阅 URL 已过期、短链跳转、token 丢失进入 Shadowrocket 编辑页校验完整 URL
Safari 显示 403 或 429服务端拒绝、限流、User-Agent 策略记录时间和域名，让提供方查访问日志
一直转圈，没有返回内容DNS 解析慢、DoH 失败、网关拦截、服务端 5xx换 DNS/网络，并查服务端状态码
节点出现但规则失败远程规则、Geo 文件或 GitHub raw 源慢暂停远程规则，只更新订阅本体
扫码后 URL 少一截二维码识别、聊天软件转义、& 参数丢失复制原始链接，不用截图二次识别

iOS 权限先看哪几个开关？

到「设置 → 蜂窝网络」确认 Shadowrocket 没被关闭蜂窝数据。只在移动网络失败、Wi-Fi 正常时，这个开关比重装 App 更值得先看。

再看「设置 → VPN 与设备管理」里的 VPN 配置是否反复跳变。Apple 的 VPN 文档把 iPhone / iPad 上的 VPN App、按需连接和按 App VPN 都归在系统网络路径里；当前隧道异常时，订阅请求可能继续走一条坏路径。

「本地网络」权限只在特定场景里相关。Apple 支持文档说明，iOS 14 以后应用访问局域网设备会触发本地网络权限；普通公网订阅一般不靠它，只有订阅源、DNS、规则源放在 NAS、旁路由或局域网网关时才要检查「设置 → 隐私与安全性 → 本地网络」。

订阅 URL 返回了什么才算正常？

把订阅 URL 粘到 Safari，只看「能打开」不够。正常结果应该是配置文本、JSON、YAML 或一串可解析的订阅内容；如果看到登录页、套餐页、CDN 错误页，Shadowrocket 通常只会表现为超时或解析失败。

排查阶段尽量用最终长链接，不要用短链。短链会增加一次 301/302 跳转，某些服务端还会按浏览器和客户端请求返回不同正文。URL 带 token 时，只发打码版本给客服或同事，不要把完整地址贴到群聊截图里。

二维码导入后也要进编辑页校验。长 URL 里的 ?token=、&flag=、%2F、%3D 被截断或解码错误时，Safari 可能还能打开一个提示页，Shadowrocket 拿到的却不是订阅。

HTTP 状态码怎么读？

HTTP / 响应在订阅更新里的含义处理办法
200 + 配置正文服务端返回正常继续检查内容格式和远程规则
200 + HTML登录页、公告页、套餐页或风控页让提供方改成直接返回订阅正文
301 / 302短链或迁移跳转排查时改用最终 URL
401 / 403token 无效、权限拒绝、请求特征被拦查过期状态和服务端日志
404路径不存在或订阅被删除重新生成订阅链接
429请求过快或 token 被限流停止反复刷新，等待窗口期或换 token
5xx服务端、网关或上游故障等服务端恢复，别在客户端来回改配置
空响应 / 超时DNS、网关、TLS、服务端连接都可能出问题换网络并记录失败时间、域名、解析结果

iPhone 上不方便看完整状态码时，可以让提供方按时间查日志；电脑端可用 curl -I 看响应头，再用 curl -L 跟随跳转看最终内容。最终要确认的是 Shadowrocket 请求拿到了有效订阅文本，还是错误页、跳转页或空响应。

DNS 和 DoH 为什么会让更新卡住？

订阅更新的第一步是解析域名。DNS 被污染、运营商缓存异常、DoH 服务器不可达、当前 VPN 规则把订阅域名错误分流，都会让客户端停在「正在更新」。

先断开 Shadowrocket，再用普通网络打开订阅域名。若断开后正常、连接后失败，问题多半在规则分流或 DNS 策略；若两种状态都失败，再看域名解析和服务端。

有些服务端把订阅域名放在 CDN 后面。不同地区、不同 DNS 可能拿到不同边缘节点，导致同一个 URL 在公司 Wi-Fi、酒店 Wi-Fi、蜂窝数据下表现不一致。记录失败网络比反复切换节点更有价值。

内容格式错了会是什么表现？

Shadowrocket 能导入不代表任何文本都能解析。常见订阅内容大致分三类：Shadowsocks SIP008 JSON、Base64 编码的 URI 列表、Clash / Mihomo 风格 YAML。提供方说「支持 iOS」时，最好让对方明确 Shadowrocket 具体吃哪一种。

Shadowsocks 官方 SIP008 文档要求在线配置用 JSON，包含 version 和 servers，单个服务器通常有 id、server、server_port、password、method 等字段，并建议 HTTPS 交付、Content-Type: application/json; charset=utf-8。如果服务端返回的是网页壳，字段再完整也没意义。

Base64 订阅常见问题是换行、尾部 =、URL 编码被聊天工具处理掉。Clash YAML 常见问题是包含 Shadowrocket 不支持的协议字段、规则写法或 provider 结构。看到「更新成功但节点为空」时，要优先怀疑格式，而不是继续改 iOS 设置。

远程规则怎么单独验证？

部分订阅会同时拉取远程规则、Geo 数据或 GitHub raw 文件。订阅本体已经返回 200，但规则源慢，界面仍可能显示整体失败。

做一次最小化测试：复制当前配置，新建测试项，暂停远程规则，只更新订阅本体。节点能出现后，再逐个恢复规则源。哪一个恢复后开始超时，问题就落在那条 URL 上。

如果你的服务端日志显示 Shadowrocket 请求经常拿到 403/429，且不同网络都复现，问题已经不在客户端。排查时可以准备一个配套订阅线路做对照，只比较「同一台 iPhone、同一网络、同一时间」下的导入格式和响应状态，不要把多台设备混在一起测。

修好后怎么确认？

修好不是看「这次没报错」就结束。至少做三次验证：普通 Wi-Fi 更新一次，蜂窝数据更新一次，连接后再手动刷新一次。三次都能拿到节点列表，才说明权限、DNS、URL 和内容格式都基本完整链路。

记录一组现场信息：iOS 版本、Shadowrocket 版本、网络类型、订阅域名、HTTP 状态、DNS 解析结果、远程规则数量、失败时间。下次只要同一域名又出现 403 或 429，就可以直接查服务端日志，不用从 App 权限猜起。

如果最近刚更新 Shadowrocket 或 iOS，也要留意系统级隧道状态。Apple Developer Forums 里有 Network Extension / Packet Tunnel 更新后连接状态异常的讨论，这类证据不能当成 Shadowrocket 官方说明，但能提醒你：App 更新、系统 VPN 状态和订阅更新失败有时会叠在一起。

相关阅读