摘要

  • APNIC 的 10 月档案现列出 10 月 23 日 04:00 UTC 至 27 日 00:00 UTC 的 92 份 WHOIS/RDAP 报告。报告和对应的 MD5 文件都显示在 10 月 29 日 10:16 修改，即目录采用的 UTC+10 时间。
  • 10 月 16 日的故障公告仍没有结束时间或持续时长。校验值能确认下载字节与文件一致；APNIC 公布的数据格式并不标明每小时底层日志是否完整。

92 个小时，在同一批次里回到档案

这次变化不靠公告解释，而是写在文件列表里：10 月 29 日，92 份报告和对应的 MD5 文件都被标成 10:16 修改。目录使用 UTC+10 时间。10 月 27 日的旧快照则从 23 日直接跳到了 27 日。缺口从 10 月 23 日 04:00 UTC 起，到 27 日 00:00 UTC 止，恰好四天、92 个连续的一小时区间。

目录给这次回补留下了一个醒目的共同时间：窗口内每份应有的报告和对应的 .md5 文件，修改栏全写着 10 月 29 日 10:16。这是目录使用的 UTC+10 时间。对首尾两份文件发起 HTTP 请求，返回的修改时间是 00:16:28 UTC。我下载两份压缩文件，检查报告声明的区间，再用 APNIC 发布的校验文件核对 MD5。第一份覆盖 10 月 23 日 04:00–05:00 UTC；最后一份覆盖 10 月 26 日 23:00 至 27 日 00:00 UTC。

当前数据流也在继续更新。APNIC 最新的 WHOIS 和 RDAP JSON 覆盖 10 月 30 日 23:00 至 31 日 00:00 UTC，校验文件与下载文件相符。至少从文件层面看，缺失区间已补齐，小时发布也已追上当前时刻。

故障记录没有同步更新。APNIC 10 月 16 日公告说，日志处理问题导致 UTC+10 10:00 之后的统计不完整；生成工作当时已暂停，受影响文件会在问题解决后重新发布。公告里的结束时间和持续时长仍空着。服务更新索引还列着这条公告，却没有为这次 WHOIS/RDAP 统计故障另发结案记录。

92 份报告已经回到档案。APNIC 的 README 列出每小时报告的字段：时间区间、查询总数、查询类型分布、ASN 数量，以及按 ASN 统计的查询和源 IP 数。公开材料没有修订编号、逐小时完整状态或恢复清单。抽查的两份报告 MD5 与 APNIC 发布的校验值一致。要确认统计使用了哪些日志、受影响时段是否逐小时重建，还需要处理记录。

10 月 27 日保存的目录里没有这 92 个区间，今天的目录则全部列出。按当前目录重算的图表会多出 92 条小时数据，覆盖时段随之改变。研究者要复现旧图表，需要保留当时的目录快照；要判断新数据如何产生，还需要逐小时处理状态。APNIC 的公告仍没有结束时间，也没有给出 10 月 16 日起受影响时段的逐小时恢复记录。

文件回来了，逐小时处理记录仍空缺

APNIC 可以用一份逐区间清单把事情说清楚：受影响的 UTC 小时、恢复状态、处理任务编号、当前校验值，以及故障何时结束。若某个小时仍不完整，也应把状态写在那一行。这样，研究者就能把“文件重新出现”和“统计已确认完整”分开，并在以后复算出同一条时间序列。

目录时间戳记录文件何时更新。修复台账还应列出每小时的处理批次、恢复状态和故障结案时间。APNIC 已把缺失报告放回档案；公开记录仍需说明这些数据如何生成。

来源

APNIC 2026 年 10 月 16 日服务公告；APNIC 服务更新索引；WHOIS/RDAP 统计 README；2026 年 10 月档案；10 月 23 日 04:00 UTC 报告及其 MD5 文件；10 月 26 日 23:00 UTC 报告及其 MD5 文件；APNIC 当前统计 JSON及其 MD5 文件。