Shadowrocket更新订阅后节点变了?先看这套刷新机制
一句话结论
小火箭不会实时同步机场的节点列表,它只在你手动下拉刷新订阅、或后台自动更新周期触发时才重新拉取一次。因此机场上线新节点、下线故障节点、调整倍率之后,手机端要更新过才会体现。更新后节点数量减少往往是机场主动下线,而不是客户端出错;流量与到期日显示同样来自订阅响应头,机场没有返回时会长期空白。
小火箭和机场之间不是一条常连的通道,而是一次性的问答:App 在某个时刻访问一次订阅地址,机场返回当下的节点清单,App 把它解析成列表——然后连接就断了。在下一次访问之前,机场那边发生的一切变动,你的手机都不知道。
这个模型能解释这一类问题的绝大部分。机场凌晨上线了三条新加坡节点,你早上打开手机看不到,不是机场骗人,是你还没问过它;某条节点昨天还在、今天不见了,也不是 App 弄丢了,是最近一次问答里机场没有再返回它。
真正需要区分的是三样数据的来源:节点列表来自订阅响应的主体,流量与到期日来自响应里附带的用量信息,延迟数值则完全由你的手机现场测出、与订阅无关。三者刷新的时机各不相同,混在一起看就会得出「更新有时候生效有时候不生效」的错觉。
手动更新订阅具体点哪里,多久做一次合适?
手动更新的动作在配置页:找到那条订阅条目,在列表区域下拉松手,即触发一次重新拉取。部分版本还支持左滑条目调出更新按钮,效果相同。
频率上不必勤快,按事件触发比按时间触发更有意义:
| 触发时机 | 是否需要手动更新 | 原因 |
|---|---|---|
| 机场公告说上线了新节点 | 需要 | 新节点只有重新拉取才会出现 |
| 常用节点突然全部连不上 | 需要 | 可能已被下线或换了端口 |
| 刚续费完套餐 | 需要 | 用量信息与可用节点可能同步变化 |
| 换了新手机第一次配置 | 不需要额外操作 | 首次导入本身就是一次拉取 |
| 只是速度慢一点 | 不需要 | 与节点清单无关,应先换节点或查模式 |
一个容易被忽略的细节:下拉刷新是一次真实的网络请求。此刻如果代理开着而所选节点正好不通,请求可能失败;完全断网时更是直接报错。遇到更新失败先看这一层,再怀疑订阅本身。
后台自动更新为什么经常不生效?
小火箭的设置里有自动更新开关,但它的实际执行权在 iOS 手上,而不在 App 手上。系统按电量、网络状态和你的使用习惯自行决定何时唤醒后台任务,这就带来了一批看似随机的现象:
- 手动把 App 从后台划掉之后,自动更新基本不会再发生。 被用户主动终止的应用,系统不会再为它调度后台刷新。
- 低电量模式下后台刷新被系统整体压制。 这时自动更新几乎不会执行。
- 系统设置里的后台 App 刷新如果被关掉,开关在 App 内打开也没有意义。
- 长期不打开的 App 调度优先级会降低。 系统会学习使用习惯,一周没碰过的 App 被唤醒的机会更少。
结论很直白:自动更新是锦上添花,不能当成机制来依赖。真正需要拿到最新节点的时候,下拉一次只要两秒,比排查后台调度快得多。
更新后节点变少了,是我的问题还是机场的问题?
先把归因做对再动手。节点数量减少有四种成因,处理方式完全不同:
| 现象 | 常见成因 | 判断依据 | 该怎么做 |
|---|---|---|---|
| 少了几条,机场后台也少了 | 机场下线或合并节点 | 两边数量一致 | 无需处理,属正常调整 |
| 少了几条,机场后台仍然有 | 部分节点用了本机版本不支持的协议 | 缺的都是较新的协议类型 | 升级 App 版本再试 |
| 一次性少一大半 | 套餐等级变化或降级 | 缺的多为高级线路组 | 回机场后台核对套餐权限 |
| 全部消失只剩空列表 | 订阅地址失效或返回异常 | 刷新时通常伴随报错 | 按报错文本逐条排查 |
第二行值得特别说明:同一份订阅在电脑客户端上有四十条、在小火箭里只有三十五条,这不是订阅坏了,而是这个版本的 App 解析不了那几条节点的协议类型,于是直接跳过。这属于客户端能力边界问题,升级版本往往就能补齐。
最后一行如果伴随明确的错误提示,不必自己猜,按提示文字对号入座更快,常见的六类报错整理在 订阅导入失败的报错分类。
流量余额和到期时间为什么一直不刷新?
这两个数字不是 App 算出来的,而是机场在返回节点清单时顺带附上的一段用量信息。它长这样(结构示例,非真实数据):
# 订阅响应里附带的用量信息(结构示例)
已用上行 12884901888
已用下行 96636764160
总量 322122547200
到期时间戳 1790000000
机场返回了,App 就显示;机场没返回,那一栏就永远空白。因此:
- 一直是空白,通常是机场没有输出这段信息,不是 bug,也无法通过重装 App 修复。
- 数字长期不动,是因为它只在你刷新订阅时才更新一次,不会随流量消耗实时跳动。
- 数字与机场后台对不上,以后台为准。手机上显示的是上次刷新那一刻的快照。
有些人把这个数字当成流量监控用,发现严重滞后。它本来就不是监控工具。要准确掌握余量,唯一可靠的来源是机场用户中心。
更新会不会把我自己改过的设置覆盖掉?
要分清哪些东西属于订阅,哪些属于本地。
| 内容 | 归属 | 更新订阅时 |
|---|---|---|
| 订阅带来的节点列表 | 订阅 | 整体替换 |
| 你对订阅内节点做的重命名或改端口 | 订阅 | 会被覆盖 |
| 自己手动新建的单节点 | 本地 | 不受影响 |
| 自己写的分流规则 | 本地 | 不受影响 |
| 路由模式、DNS 等偏好设置 | 本地 | 不受影响 |
| 远程配置文件带来的规则组 | 配置源 | 按配置源更新时重写 |
所以「更新订阅会不会把我的规则清空」的答案是不会——除非你用的是远程配置文件那条路径,那一条本来就是由配置源统一管理的。反过来,如果你手动改过某条订阅节点的名字,更新之后它会变回机场给的原名,这是预期行为,想保留自定义就把它另存成一条本地节点。
机场重置订阅地址后,旧链接还能更新吗?
不能,而且是彻底不能。订阅地址末尾那串 token 就是身份凭证,重置意味着服务端作废了旧凭证并发放一条新的。旧地址此后请求到的要么是拒绝响应,要么是空数据。
需要注意的连锁反应:那条失效的订阅如果留在列表里,每次自动更新都会失败一次,并且它带来的旧节点可能仍然显示在列表中——已经失效却还看得见,最容易在切换节点时踩空。正确的顺序是回机场后台复制新地址,在 App 里新建一条,确认节点拉取正常后再删掉旧条目。
用二维码取新地址往往比复制粘贴更省事,扫码入口和内容判别方式写在 二维码导入的正确顺序。
什么情况下应该删掉重导而不是继续更新?
大多数问题不需要重来。满足下面任意一条时,重导才是更快的路径:
- 机场重置过订阅地址。 旧条目已无救,直接换新的。
- 列表里混进了两批同名节点。 通常是同一机场加了两次,分不清哪条属于哪次,清掉重来最干净。
- 刷新反复失败但地址在浏览器里能正常打开。 说明本地存的那条记录可能已经损坏。
- 套餐等级变更后权限没跟上。 重导可以确保拿到的是当前等级对应的完整清单。
反过来,以下情况删了重导毫无帮助:节点数量与机场一致只是变少了、流量栏空白、某几条节点延迟高、晚高峰变慢。这些要么是机场侧的正常状态,要么属于选节点和路由模式的范畴,和订阅记录本身没有关系。整条配置链路的位置关系可以回到 小火箭全流程专题 对照。
小结
小火箭对机场是「问一次答一次」,不问就不会知道任何变动。手动下拉是唯一可靠的触发方式,自动更新受 iOS 后台调度限制,把 App 划掉或开着低电量模式基本就不会执行。节点变少先对照机场后台,两边一致即属正常调整,只在手机端少的那几条多半是协议解析不支持。流量和到期日来自机场返回的附加信息,空白是机场没给,修不了也不影响使用。订阅地址被重置后旧条目应当删除重建,而不是反复刷新。
常见问题
小火箭多久会自己更新一次订阅?
没有固定周期。它依赖 iOS 的后台刷新调度,系统会按电量、网络和使用习惯自行决定何时唤醒 App,可能几小时也可能一整天都不触发。要立刻拿到最新节点,手动下拉最可靠。
更新之后节点从四十条变成三十条,是不是订阅坏了?
多数情况不是。订阅返回什么,列表就显示什么,数量减少说明机场那边下线或合并了节点。判断方法是打开机场用户中心看当前节点数,两边一致就说明客户端如实同步了。
流量已用多少和到期日一直是空白,能修好吗?
这不是客户端能修的。这两个数字来自订阅响应里附带的用量信息,机场没有返回时就是空白。功能上不影响节点使用,想看余量只能回机场后台。
订阅更新会覆盖我自己加的分流规则吗?
订阅更新只替换节点列表,本地新建的节点和自己写的规则不受影响。真正会被覆盖的是远程配置文件那条路径,它更新时会按配置源重写规则组。