已有自己的订阅时，先在 Home 手动刷新并确认列表有效，再到 Settings → Subscribe 开启 Update on Open。更新失败应先判断请求有没有到达订阅地址，再检查返回内容能否解析；不要把订阅刷新、连接测试和 Config 更新当成同一件事。本文按操作、验证、排错的顺序说明。
订阅更新的范围：刷新列表，不是更新应用
Shadowrocket（小火箭）的订阅更新，是重新读取自己已有的订阅地址，并据此更新 Home 中对应分组的连接条目。远端调整名称、地址、端口或其他连接参数后，本地通常需要重新获取，才能反映这些变化。本文以用户已经持有自己的服务商与订阅为前提。
这条流程中，能请求到内容和能解析出条目是两个独立条件。订阅服务器返回登录页面，即使网络请求成功，也不等于获得了有效订阅；列表已经更新，也不等于其中每条连接都能正常使用。连接是否可用还取决于远端服务状态、认证参数与当前网络。
- Home：查看已有连接与订阅分组，执行列表刷新，并核对更新后的条目。
- Settings → Subscribe：管理订阅相关行为，包括打开应用时的更新开关。
- Config：管理配置文件；其中的规则或远程配置更新，不应与 Home 的订阅列表刷新混淆。
- App Store：负责应用本身的获取与更新，不负责刷新你的订阅内容。
手动刷新：先核对地址，再检查分组
第一次导入或更新出现异常时，先使用手动刷新。这样可以观察本次操作的结果，而不是等待自动触发。操作前记下目标分组的名称、当前条目数量，以及一条你准备核对的连接名称；这些信息用于前后比较，不需要记录或公开订阅凭据。
-
确认订阅类型
进入 Home，找到已有订阅分组。首次添加时使用 Home 右上角“+”→ Type → Subscribe，填写自己的订阅地址并保存。单条分享链接不是可持续刷新的订阅列表。
-
核对完整地址
打开对应订阅的编辑项，核对 URL。确认查询参数完整，没有复制到前后空格、换行或说明文字；只检查自己的地址，不把完整内容发到公共讨论区。
-
下拉刷新列表
回到 Home，在列表区域向下拉动并松开，触发订阅刷新。等待本次操作结束，留意失败提示；多个订阅同时存在时，分别确认目标分组的结果。
-
检查更新结果
对比目标分组的名称、数量和已知变更的条目。如果远端已明确修改某条连接，进入该条目的编辑信息核对地址或端口，再进行连接测试。
下面仅展示地址的结构，不能用于连接。示例中的 token 是查询参数；实际地址可能使用其他参数名，也可能通过路径承载凭据。不要根据示例替换自己地址里的字段。
https://example.com/sub?token=xxxx打开时自动更新：在 Subscribe 中设置
手动刷新成功后，再进入 Settings → Subscribe → Update on Open，开启打开应用时更新。该设置用于在打开应用时触发订阅获取，不是固定间隔的后台定时任务。只让连接保持运行、没有打开应用，并不能据此推断订阅已经刷新。
- 先验证手动操作：如果地址本身失效，开启自动更新只会重复遇到同一问题，不会修复远端凭据。
- 开启后回到 Home：下次打开应用时，检查目标分组与已知变更条目，不要只凭开关状态判断更新成功。
- 有明确变更时手动刷新：需要立即读取远端调整时，主动刷新并核对结果，比等待下一次打开更容易确认。
- 控制排错变量：正在比较两次刷新差异时，可暂时关闭自动更新，完成验证后再按需要恢复。
Update on Open 与 On Demand 的用途不同。前者控制订阅获取的触发时机，后者用于连接的按需触发。修改 Settings → On Demand 不会修复订阅地址，也不能替代列表更新；排查订阅时无需同时调整这两组设置。
| 操作或设置 | 触发方式 | 核对重点 |
|---|---|---|
| Home 下拉刷新 | 用户手动操作 | 本次提示、目标分组和已知条目变化 |
| Update on Open | 打开应用时触发 | 实际获取结果，而不只是开关是否开启 |
| On Demand | 按连接条件触发 | 连接状态，不作为订阅更新证据 |
结论：手动成功后再启用自动
先建立一次可复现的成功刷新，再开启 Update on Open；后续出现问题时，就能区分地址失效与自动触发未完成，而不必同时修改多项设置。
更新失败排查：链接、网络、格式分开检查
先记录屏幕上出现的完整提示，再按下面三类原因排查。不同系统语言或请求阶段可能显示不同文字；报错只能提供线索，不能单凭一句通用提示断言订阅已经过期。
报错：Failed to load subscription
原因与解法：这是订阅加载失败的概括性提示，可能涉及地址授权、请求失败或返回格式异常。先向自己的服务商确认地址有效，再分开检查网络可达性与返回内容。
报错：The request timed out.
原因与解法：请求未能在等待时间内完成，可能涉及当前网络、请求路径或订阅服务器响应。分别在 Wi-Fi 与蜂窝网络下手动刷新，对比是否只有某一种网络失败。
报错：A server with the specified hostname could not be found.
原因与解法：订阅地址的主机名未能解析。先检查域名是否复制完整，再更换网络复测；若域名已变更，应从自己的服务商处确认当前地址。
第一类：链接失效或授权变化
服务商重置凭据后，旧地址可能继续保存在 Home 中，却已经不能取得内容。若请求返回 HTTP 401 或 403，优先检查授权状态与访问限制；若返回 404，检查路径是否变更。这些状态并不自动等同于某一种具体账户问题，需要结合自己的服务信息判断。
- 从自己的服务商管理页面重新复制订阅地址，与本地保存值逐项核对。
- 确认复制的是订阅地址，而不是账户主页、登录页或一条连接的分享文本。
- 更换地址后只刷新目标订阅，检查新结果，不要持续重试已确认失效的旧地址。
第二类：网络不可达或请求路径异常
如果 Wi-Fi 失败而蜂窝网络成功，说明值得优先检查两种接入环境的差异，而不是立即重建订阅。先完成网络切换对照，再检查当前连接是否影响请求。Global Routing 下的 Proxy、Direct、Config、Scene 是路由姿态；更改它们可能影响网络访问，但不会改变订阅凭据的有效性。
- 一次只改变一个条件，例如仅从 Wi-Fi 切换到蜂窝网络，保持订阅地址不变。
- 若需要比较当前连接开启与关闭时的结果，先记录原状态，测试结束后恢复。
- 不要为修复一次超时同时改动 DNS、路由与全部连接参数，否则无法确定哪项变更产生影响。
第三类：返回内容无法识别
HTTP 200 仅表示请求获得了成功响应，不保证内容就是有效的连接列表。服务器可能返回登录页、维护通知或其他文本。浏览器能显示页面，也不能证明 Shadowrocket 能将该内容作为订阅解析。
- 确认远端提供的是适用于 Shadowrocket 的订阅内容，而不是需要人工登录后阅读的网页。
- 如果请求完成但条目为空，向自己的服务商确认该地址当前应返回的条目数量与内容类型。
- 不要自行给整段内容增加编码、删除字段或替换协议名；这可能掩盖原始问题并破坏连接参数。
刷新后没有变化：用条目字段验证
订阅可以成功刷新但看起来完全不变：远端没有修改内容时，名称与数量自然保持原样。反过来，数量相同也不能证明没有更新，因为服务器地址、端口或认证参数可能已经变化。验证时应选择一条已知发生变化的条目，而不是只看列表长度。
| 看到的现象 | 需要核对 | 下一步 |
|---|---|---|
| 名称和数量都未变化 | 远端是否实际修改内容，是否查看了正确分组 | 核对一条已知变更的连接字段 |
| 列表已变，连接失败 | 远端可用性、认证参数与当前网络 | 转入连接排查，不再反复刷新列表 |
| 仅部分条目缺失 | 远端返回数量、条目格式与参数完整性 | 向自己的服务商确认缺失条目是否仍在订阅内 |
| 打开应用后仍是旧内容 | Update on Open 状态及本次请求是否完成 | 手动刷新一次，并记录提示 |
例如，远端明确告知某条连接的端口从 443 改为 8443，刷新后就核对该条目的端口，而不是只看名称。这里的数字仅用于说明验证方法，并不代表任何现有连接的推荐端口；实际参数必须与用户已有配置一致。
提交问题前：保留现象，隐藏凭据
完成上述对照后，仍然失败时应整理最小排错记录。记录应让对方能够区分“取不到内容”和“取到但不能解析”，同时避免泄露可访问订阅的完整地址。订阅凭据可能位于查询参数，也可能位于路径，不能只遮住名为 token 的字段。
- 触发方式：说明是 Home 下拉刷新失败，还是仅在 Update on Open 开启后未看到变化。
- 接入环境：记录 Wi-Fi 与蜂窝网络各自的结果，以及测试时连接是否开启。
- 原始提示：抄录完整错误文字；如果有 HTTP 状态码，一并记录。
- 变化范围：说明全部订阅失败、某一分组失败，还是某些条目缺失。
- 隐私处理：隐藏完整订阅地址、密码、UUID 及其他认证字段，只保留必要的现象描述。