网络中断时，http 类型的更新可能失败。官方写明：path 是集合落盘路径（未填则用 url 的 MD5 作文件名，且限制在 HomeDir）；http 或 file 解析失败时，可以用 payload 作为备用代理。该页没有写「下载超时一定不会改写 path」。网络恢复后，不要假设覆盖策略，而要核对当前加载的是哪一种来源，以及下一次更新是否仍按 url 经 proxy 进行。
适用条件
适用于 type 为 http，曾经导入成功，之后更新失败，网络又恢复，需要确认现在用的不是失败产物、好的节点有没有被错误替换。inline 本来只用 payload；file 只读本地文件，不涉及远程更新覆盖。
按加载来源核对
- 定位
path。未填写时文件名是url的 MD5，路径须在 HomeDir，或由SAFE_PATHS追加。文件还在，只说明落盘位置符合文档，不能单独证明内容仍是失败前那一份。 - 若写了
payload：解析失败时它是备用节点。恢复后若节点名称、类型与payload一致，当前更可能是备用在工作，而不是远程更新成功。判断：集合与payload一致，不能当成更新已完成。 - 健康检查只针对当前已加载节点访问
health-check.url。测试通过只说明这些节点能测通，不说明这次已经重新下载并写入path。health-check.lazy为 true 时，开始使用该集合才会测试，更不能用「终于有延迟数据」反推更新成功。 filter、exclude-filter、exclude-type只决定哪些节点被筛进来，不能回答文件有没有被新内容覆盖。interval到期后会再次经proxy下载url。恢复后若要确认「好配置被成功更新」，应看这一条下载路径是否重新完成，而不是看健康检查是否变正常。
判断依据
有 payload 且失败后节点与备用内容相同：按「解析失败走备用」理解。健康检查成功：只验证节点连通。文档未保证超时失败会保留旧 path，因此不能只靠「还有节点」得出「没有覆盖好配置」。能依据文档确定的是：备用 payload、path 的位置约束、以及更新仍走 url 加 proxy。
验证不了覆盖结果时下一步
检查 proxy、url、header 仍是用于更新的那一组，等到 interval 让核心再拉一次。担心新文件过大时核对 size-limit（0 为不限制）。订阅若为 age armor，确认 age-secret-key 仍能解密；解密失败和旧文件是否被覆盖不是同一问题。必须保留一份确定可用的节点时，把它们写在 payload，或改用 file 指向 HomeDir 内未当作这次更新目标的文件。这是文档提供的本地来源，不是「失败更新不会覆盖」的保证。讨论失败现场时不要贴出真实 url 和密钥。