Shadowrocket（小火箭）的订阅故障应分成链接、请求、响应内容和列表显示四个环节检查。本文以你已有自己的服务商与订阅为前提，说明怎样确认链接是否完整、区分超时与解析失败、在 Settings → Subscribe 中检查更新方式，以及如何在保留原有配置的情况下验证恢复结果。
先区分解析失败与列表为空
订阅更新是先获取数据，再把数据解析为服务器条目。请求没有完成、服务器返回了登录页、返回内容不被识别，都可能表现为未能获得新条目；而列表为空还可能与搜索筛选、订阅分组折叠或服务端实际返回空内容有关。只看最终列表，不能直接判断是哪一步出错。
先回到 Home，清除正在使用的搜索条件，展开对应的订阅分组，再确认是所有条目都没有，还是仅某个分组没有。记录本次更新出现的完整提示与发生时间；如果旧条目仍在，暂时保留，不要把“更新未成功”当作“旧配置已经失效”。
- 一直等待后失败：优先检查当前网络是否能访问订阅地址，以及更新是否需要通过已有代理连接。
- 很快提示解析失败：优先确认响应是不是订阅数据，而不是账户页面、错误说明或访问验证页面。
- 更新后条目数为零：先检查显示条件，再向自己的服务商确认该订阅当前是否确实有可用条目。
- 有条目但连接失败：这是下一阶段的连接问题，应核对服务器参数并使用 Connectivity Test，不宜反复重新导入订阅。
核对订阅链接：完整地址与鉴权参数
从自己的服务商账户页面重新复制适用于 Shadowrocket 的订阅地址，与应用内保存的地址逐项比对。账户首页、套餐说明页和单个服务器分享内容，不等于订阅地址。复制时要确认选中了完整内容，尤其是问号之后的鉴权参数。
https://example.com/sub?token=xxxx上面是不可用于导入的示意地址。这里的 https:// 是协议部分，example.com 是域名，/sub 是路径，?token=xxxx 表示查询参数。真实地址的路径和参数名由你的服务商决定，不能直接照着示例修改。订阅地址中的 token 通常关联访问权限，应按账户凭据保护。
- 检查地址前后是否多出引号、空格、换行或聊天软件附带的标点。不要删除 URL 内原本有效的编码字符。
- 确认
?、&、=等分隔符完整。若复制的是网页源码中的文本，要留意参数分隔符是否被误保存成字面量&。 - 保留原始 token 的大小写及编码形式，不随意解码
%2F、替换加号或重新排列含签名的参数。 - 如果服务商刚重置过订阅地址，重新复制新地址；旧地址即使外观相似，也可能已被撤销。
浏览器打开地址可作为辅助检查，但不能作为唯一结论。浏览器可能依赖已登录账户的 Cookie，应用的订阅请求未必具有同一登录状态；反过来，浏览器显示一长段编码文本或触发保存内容，也不代表响应有问题。需要确认的是该地址是否能独立返回应用支持的订阅内容。
检查响应：超时、鉴权失败与内容不匹配
能访问域名不等于订阅接口可用，收到响应也不等于拿到了有效订阅。如果应用提示、诊断记录或服务商返回信息中提供了 HTTP 状态码，应连同发生时间一起记录。下面列的是标准 HTTP 状态或网络错误词，不代表每次都会在 Shadowrocket 中以完全相同的文字显示。
HTTP 401 Unauthorized
原因：服务器未接受当前请求的身份凭据，可能与失效的 token 或缺少鉴权信息有关。
解法：从自己的账户页面重新复制订阅地址，并请服务商核对该地址的鉴权状态。
HTTP 403 Forbidden
原因：服务器拒绝了当前请求，可能涉及账户权限、来源限制或访问策略，不能仅凭状态码认定是套餐到期。
解法：核对账户状态，向服务商提供请求时间和状态码，确认是否存在访问限制。
HTTP 429 Too Many Requests
原因：服务端限制了请求频率，连续刷新可能延长排查过程。
解法：停止重复请求，按服务端给出的等待提示或服务商说明，稍后只执行一次更新。
Request timed out
原因：请求未在等待时间内完成，问题可能位于网络路径或订阅服务端。
解法：先对照 Wi-Fi 与蜂窝网络，再检查 Update via Proxy 是否需要一个已经可用的代理连接。
若响应是账户登录页、维护通知或访问验证页面，即使 HTTP 状态为 200，也不代表可解析为服务器列表。请服务商确认所提供地址返回的是适用于 Shadowrocket 的订阅格式，而不是要求交互操作的网页。不要把错误页面中的文本当成服务器参数手动填写。
结论：先确认收到什么，再调整解析相关设置
当返回内容不是订阅数据时，反复导入同一个地址不能修复问题。先让自己的服务商确认响应内容与授权状态，再重新更新一次。
检查 Settings → Subscribe 与更新路径
在 Settings → Subscribe 中检查订阅更新相关设置，重点是 Update via Proxy。它影响更新请求的路径，不会替你修复地址，也不会把不支持的响应内容转换成有效订阅。排查时一次只改变一个条件，并记下更新结果。
- 先保留当前设置做一次更新：在 Home 对订阅执行更新，例如下拉刷新，观察是否出现错误提示，不要连续触发多次请求。
- 直接访问超时时再考虑代理路径：如果已有可用服务器，先选中它并建立连接，再到 Settings → Subscribe 检查并启用 Update via Proxy，然后重新更新。
- 检查代理是否真的可用：使用 Home 中的 Connectivity Test 辅助判断。测试有结果只说明对应测试条件下的连通情况，不保证订阅接口一定可访问。
- 代理路径失败时做反向对照：在当前网络允许直接访问订阅接口的前提下，关闭 Update via Proxy 后再试一次。不要同时修改 DNS、Global Routing 和订阅地址。
如果列表已空、没有任何可用的既有服务器，仅开启 Update via Proxy 并不能形成可用连接。此时应先检查直接访问路径，或向自己的服务商确认订阅接口的访问条件。订阅获取与服务器连接是两个环节，后者依赖的配置尚未取得时，不能用一个开关跳过前者。
选择更新时机，避免把旧结果当成新故障
服务商刚恢复账户权限、重置 token 或调整订阅内容后，应该先确认变更已经生效，再手动更新。不要预设所有订阅都有相同的刷新间隔，也不要把应用留在前台等待当作已经完成更新。自动更新行为应以 Settings → Subscribe 中当前实际配置为准。
| 当前情况 | 先做什么 | 再核对什么 |
|---|---|---|
| 账户状态刚恢复 | 确认服务商账户页显示的权限已生效 | 手动更新后是否产生预期条目 |
| 订阅地址刚重置 | 把应用中保存的地址换成新地址 | 是否还在请求旧 token 对应的地址 |
| 网络刚从 Wi-Fi 切到蜂窝网络 | 等待当前网络连接稳定 | 相同地址在新网络下是否仍超时 |
| 收到 HTTP 429 | 停止连续刷新并按提示等待 | 下一次请求是否仍被限制 |
| 服务商确认订阅内容已调整 | 执行一次手动更新 | 对应分组的条目与参数是否同步变化 |
更新没有成功时，旧条目可能仍然可见，因此“列表里还有服务器”不等于刚才更新成功；同样，条目名称没有变化也不等于没有更新，服务端可能只修改了连接参数。应结合更新提示、实际条目及服务商确认的变更判断，不要只看名称。
- 恢复后清除搜索条件，展开对应订阅分组，核对是否出现预期的服务器。
- 选中一个属于该订阅的服务器，使用 Connectivity Test，再验证需要访问的实际服务。
- 如果条目已恢复但仍无法连接，转向服务器地址、端口及协议参数检查，不再重复处理链接格式。
常见追问与提交排查信息
同一个地址在浏览器能打开，为什么应用里解析失败？
先看浏览器显示的具体内容。如果是登录页面或账户后台，不能证明拿到了订阅数据；即使显示订阅文本，也要向自己的服务商确认格式适用于 Shadowrocket。不要直接把浏览器中的整页内容粘贴到服务器字段。
开启 Update via Proxy 后反而更新不了，怎么办？
先确认选中的既有服务器能够建立连接，并在 Home 做 Connectivity Test。若代理路径不可用，而订阅接口可以直接访问，到 Settings → Subscribe 关闭 Update via Proxy 后只更新一次，记录两次结果的差异。
列表为空，要先删除应用重新导入吗？
先清除 Home 的搜索条件并展开分组，再核对订阅地址和服务商账户状态。重装会增加恢复原有设置的工作量，不能改变服务端返回的内容；保留旧配置更有利于对照失败前后的差异。
订阅更新成功，为什么 Connectivity Test 仍然超时？
成功获取订阅只说明取得并解析了配置，不等于每个服务器都可达。确认 Home 中选中的是预期服务器，再向自己的服务商核对地址、端口及协议所需参数。不要因连接测试失败就擅自改写订阅 token。
需要服务商进一步排查时，提供足够定位问题的信息，同时保护订阅凭据。公开讨论中不要贴出完整订阅地址、二维码或含 token 的截图；完整地址只应在确有必要时，通过自己的服务商指定的私密支持渠道提交。
- 现象：是请求超时、解析失败，还是更新后可见条目为零。
- 时间与网络：记录发生时间及所用 Wi-Fi 或蜂窝网络，不必公开个人网络地址。
- 更新方式：说明 Update via Proxy 的状态，以及当时是否已建立可用连接。
- 响应线索：提供完整错误文字或实际观察到的 HTTP 状态码，说明是否曾返回登录页。
- 对照结果：说明更换网络或改变单项设置前后的结果，避免只写“始终不能用”。
完成以上检查后，处理方向应当清楚：地址错误就修正地址，权限问题由服务商确认，网络超时检查更新路径，格式问题确认响应内容。不要在原因未明时同时修改多个设置，否则一次成功或失败都难以解释。