Shadowrocket（小火箭）的订阅更新需要先取得响应，再解析其中的服务器条目。本文以用户已有自己的服务商与订阅为前提，按“保留现状、核对地址、检查响应、验证网络、复核自动更新”的顺序排查。先区分请求失败、返回内容不适用和成功返回空列表，再决定下一步，避免反复删除订阅后失去对照。
一、先区分更新失败、解析失败与列表为空
订阅更新失败不等于现有服务器立即失效，列表为空也不一定表示请求没有发出。更新过程包含网络请求、身份验证、内容解析和列表展示几个环节。某一环节出错，应当记录对应现象，而不是把所有情况归为“链接坏了”。
先回到 Home，确认查看的是目标订阅分组，而不是其他分组或筛选后的结果。再区分：旧条目仍在但提示更新失败，还是更新后目标分组确实没有条目。如果 Config 中的配置文件仍可见，也不能据此认定订阅正常；配置文件与 Home 中的服务器列表是不同的核对对象。
- 记录手动更新的时间、当前网络是 Wi-Fi 还是蜂窝网络，以及完整错误文字。
- 记下更新前目标分组的条目数量；有可恢复的配置时先保留副本，不把删除订阅当作第一步。
- 只对目标订阅执行一次手动更新，观察错误提示与列表变化，避免同时更新多个来源。
- 如果只是某个条目连接失败，转而检查该条目的地址、端口和认证字段，不继续按“空订阅”处理。
二、核对订阅地址完整性与返回内容类型
订阅地址是获取一组条目的入口，不是服务商账户页面，也不是单条分享链接。ss://、vmess://、vless://、trojan:// 描述的通常是单条连接信息，不能仅因为它们可以导入，就把它们当成可定时更新的订阅地址。HTTPS 地址也不必然是订阅：登录页、帮助页和错误页面同样可以使用 HTTPS。
https://example.com/sub?token=xxxx上面是不可用于连接的格式示例。实际核对时，逐项比较协议、主机名、路径和查询参数。尤其注意复制时是否漏掉 ? 后面的内容，是否把 & 误写成字面量 &，或者把聊天文字中的句号、引号、换行一并粘入。不要自行删除看似冗长的 token，也不要随意改写百分号编码。
- 复制来源：从自己的服务商账户页面重新复制适用于 Shadowrocket 的订阅地址，替换前先比较新旧地址是否一致。
- 返回格式：确认服务端输出的是应用可识别的订阅内容，而不是完整配置页面、账户说明或网页表单。
- 敏感字段：token 可能具有访问权限。不要把完整地址放进公开截图、在线解码页面或公开讨论区。
- 验证边界：浏览器能打开网址，只说明该浏览器取得了某种响应；浏览器已有的登录状态，不一定会由应用订阅请求携带。
如果浏览器展示的是登录框、验证码或到期提示，应先解决账户侧问题。不要把网页另存的文本当成订阅重新导入。若页面展示了看似编码后的文本，也不能仅凭外观认定可解析；需要确认该地址确实是对应客户端的导出入口。
三、按 HTTP 响应检查到期、限制与空内容
服务商侧的账户有效期、流量状态、订阅地址是否重置，以及请求频率限制，都可能影响返回结果。应在自己的账户页面逐项核对，再根据实际响应判断。下面列出的是 HTTP 标准响应原文；只有错误详情或服务端记录确实出现相应状态时才适用，不代表 Shadowrocket 一定会逐字显示这些文字。
报错：401 Unauthorized
原因：请求未通过身份验证，可能是凭据缺失或失效。解法：在自己的账户页面核对订阅地址是否已重置，重新复制完整地址后再尝试一次。
报错：403 Forbidden
原因：服务端拒绝了本次请求，可能涉及账户权限、来源限制或访问策略。解法：核对账户状态，并向自己的服务商提供脱敏后的错误与发生时间，不要直接认定是客户端解析问题。
报错：429 Too Many Requests
原因：请求触发服务端频率限制。解法：停止连续刷新，若响应包含 Retry-After 则遵循其等待要求，再做单次验证。
报错：503 Service Unavailable
原因：服务端暂时无法处理请求，可能处于维护或过载状态。解法：保留现有条目，稍后重试，并核对自己的服务商是否说明了当前服务状态。
即使状态是 200 OK，也只表示 HTTP 请求成功处理，不保证响应包含有效服务器。返回正文可能为空、是账户提示文字，也可能是 HTML 页面。若条目数量从非零变成零，应同时核对账户侧是否仍有可用条目，以及订阅导出是否返回了预期内容。
结论：先确认响应，再调整解析相关设置
当响应实际是登录页、权限提示或空正文时，修改规则和服务器协议不能补回缺失条目；先恢复订阅入口的有效响应，再做一次手动更新。
四、用单变量测试核对更新时的网络路径
订阅更新请求的可达性，与订阅内某个服务器的可达性不是同一件事。旧条目还能连接，不代表订阅地址一定能访问；订阅可以更新，也不保证每个新条目都能建立连接。排查时保留当前配置，每轮只改变一个条件，并记录结果。
- 确认基础网络：完成当前 Wi-Fi 的网页认证；若网络本身不可用，先处理接入问题，再回到应用更新。
- 切换接入网络：在条件允许时从 Wi-Fi 切到蜂窝网络，对同一地址执行一次更新。只记录两次是否成功，不同时更换地址。
- 检查更新专用设置：进入 Settings → Subscribe，查看当前界面提供的更新选项。若存在
Update via Proxy，先记下原状态；仅在已有可用连接时测试经代理更新，再与原状态比较。 - 核对证书与时间：若提示证书或 TLS 错误，检查设备日期时间及目标域名是否正确。不要用关闭证书验证的方式掩盖错误。
不要把 Home → Global Routing 下的 Proxy、Direct、Config、Scene 当成订阅解析格式开关。它们涉及路由姿态，不能修复被截断的 token，也不能把 HTML 变成服务器列表。更新请求是否走代理还要结合更新专用设置与当前连接状态判断，不能只看某个姿态名称就推断全部请求路径。
同样，修改 DOMAIN-SUFFIX、GEOIP、IP-CIDR 或 FINAL 并不是处理空响应的第一步。只有在已经确认订阅域名受当前路由路径影响时，才需要进一步核对相关配置，并在修改前保存副本。
五、手动更新成功后，再检查自动更新时机
自动更新不能替代有效地址和可用网络。应先在应用前台完成一次手动更新，确认列表出现预期条目，再检查 Settings → Subscribe 中实际提供的自动更新选项与间隔。不同界面可能有不同文案，以设备上显示的项目为准，不把某个固定时间当作所有设备必然执行的计划。
- 先做前台基线：记录一次手动成功的时间和条目数量，再启用或调整自动更新，便于判断问题是请求失败还是执行时机不同。
- 避免过密刷新：不要以连续点按刷新来验证自动更新。短时间重复请求可能触发频率限制，反而改变原本可用的测试条件。
- 考虑系统调度：锁屏、后台运行和网络切换时，不能假定应用始终获得执行机会；回到前台后核对实际列表与更新结果。
- 分清触发机制：Settings → On Demand 用于按条件建立 VPN 连接，不等于订阅定时更新开关。开启 On Demand 也不保证每次都拉取订阅。
如果自动更新失败而手动更新成功，优先比较两次发生时的网络、连接状态和更新路径。若手动更新同样失败，则回到地址与响应检查，不应继续缩短更新间隔。恢复后抽查新条目的地址、端口与协议字段；订阅更新成功只是取得配置，连接可用性仍需另行验证。
六、常见追问与提交排查信息
旧节点还能用，为什么订阅就是更新不了？
旧条目保存的是已有连接参数，更新请求访问的是订阅地址。先在自己的账户页面确认地址与 token 是否仍有效，再在 Home 对目标订阅手动更新一次；不要为了验证更新而先清空可用条目。
浏览器打开有内容，为什么应用里仍然是空的？
先看内容是不是登录页面、错误说明或不适用的导出格式。浏览器登录成功不代表应用请求带有相同会话。重新核对账户页面中适用于 Shadowrocket 的订阅入口，而不是复制浏览器地址栏里的账户页面。
更新后数量变少，要不要马上反复刷新？
先核对目标分组和筛选状态，再看账户侧实际提供的条目数量。记录变化时间并停止连续刷新；数量减少可能来自服务端内容调整，也可能是部分内容无法解析，需结合响应和错误详情判断。
把完整订阅链接发给别人检查可以吗？
不要公开发送带 token 的完整地址。反馈时提供脱敏域名、发生时间、网络类型、错误原文与更新前后数量即可。若权限凭据已经泄露，先通过自己的服务商账户重置，再替换应用内保存的地址。
向自己的服务商反馈时，把“不能用”改成可复核的描述，例如：“在蜂窝网络前台手动更新，响应显示 403，原有条目仍保留；切换 Wi-Fi 后结果相同。”没有观察到状态码时就写实际提示，不猜测错误类别。这样的记录能够区分账户、网络和内容格式问题，也能减少反复索取敏感地址的需要。