订阅刷新了，列表没变？先看 304 与配置生效

订阅提示更新成功，节点列表却没有变化，先核对更新的是哪份资源、是否下载了新内容，以及当前运行配置有没有采用它。节点名称不变，不能单独证明更新失败；日志里的 HTTP 304，也不等于下载到了一份空配置。

本文适合订阅更新没有明显报错，但列表与预期不一致的情况。如果已经出现授权失败、地址找不到或解析错误，可以先看本站的订阅更新错误处理顺序。

作者：小六｜资料核对日期：2026年10月16日

先确认：更新对象和查看对象是否相同

一个客户端可能同时保存多份配置，每份配置又可能引用不同的节点集合。点了某个订阅的更新按钮，之后却查看另一份正在运行的配置，就容易觉得列表始终没变。

先记下当前启用的配置名称、更新条目和操作时间，再看日志是否对应同一次操作。还要分清“整份配置更新”“节点集合更新”和“节点延迟测试”，它们处理的对象不同。

例如，Mihomo 的代理集合配置分别定义了资源更新间隔与健康检查间隔，后者用于延迟检查。重新测速后数字变了，不代表订阅正文也重新下载过。见代理集合官方配置说明。

客户端可以先保存一份资源，后续通过条件请求询问它是否仍然有效。如果返回 304 Not Modified，含义是本次无需重新传输对应资源的完整内容，客户端应结合已有副本处理。304 响应本身没有正文。见 MDN 的 304 说明。

其中，ETag 可以理解为服务器给某个资源版本的标签；客户端可能通过 If-None-Match 带上已有标签进行校验。它不是节点数量，也不是订阅到期时间。

因此，不要把 304 的空正文保存成新的空订阅，也不要把它直接归类为网络故障。是否正确保留并使用旧副本，还取决于客户端的实现和当前本地状态。

网页里的图标、脚本也可能产生 304。只有确认时间和资源路径对应正在排查的订阅，才可以把它用于判断。看到服务网站某个请求返回 304，不代表客户端更新也经过同样的过程。

使用 Mihomo 内核时，其全局配置文档提供了外部资源下载的 etag-support 选项。但桌面软件自己发起的订阅下载是否采用同一机制，仍应按软件文档和实际日志核对，不能仅凭内核名称推断。

订阅来源的内容、客户端保存的副本和最终显示的列表，不一定是同一层。即使拿到了新正文，节点仍可能经过本地处理，或者只有部分集合被当前策略组使用。

以 Mihomo 代理集合为例，filter 可以筛选节点，exclude-filter 可以按条件排除节点，exclude-type 可以排除特定类型。这些功能见前述官方集合文档。比较节点数时，应先确认是否存在相关处理。

不要为了凑出与别人截图一样的数量，就直接删除过滤条件。先了解这些条件的用途，再检查缺少的节点是否本来就不属于当前显示范围。

如果涉及自己的规则扩展，另看订阅更新后的覆写与备份方法。本次先确认列表来源，不必同时重做全部规则。

这些是定位方向，不是对服务方或客户端的故障结论。尤其是 200，只说明请求返回了相应响应，不能单凭状态码证明内容一定比本地副本新。

内容查看只在本机进行即可，不需要把专属地址或完整配置交给第三方网站。分享记录前，可按本站的订阅链接保护清单遮挡凭据。

不必一开始就清空。304 本来就可能依赖已有副本，删除后怎样重新获取，应使用客户端明确支持的更新或重新导入流程，不能假定每款软件都有相同的“强制刷新”行为。

重置订阅地址也不是缓存修复的通用步骤。若只是列表显示与预期不一致，先保留上述对照信息，再向服务方确认当前入口应该提供什么内容；只有确需重置时，才按其说明处理其他设备的更新。

想交流“更新成功但列表仍旧”的情况，可以带上客户端版本、更新条目类型、状态码和加载结果，隐藏完整地址与配置内容：Telegram 联系我。