摘要

  • 在截取的 9 月 8 日 14:00—15:00 UTC 文件里，WHOIS 的 total_queries 为 3,192,583，七类查询合计 3,183,463，相差 9,120；同一文件的 RDAP 总数与分类和完全一致。
  • 从 6 月 30 日上线到本次证据截止，共有 1,691 个连续小时文件。除一个 WHOIS 为零的小时外，其余 1,690 个有流量小时全部无法勾稽：1,011 个小时总数较大，679 个小时分类和反而较大，因此补一个非负的“其他”类别不能解释两种方向。
  • APNIC 为 APNIC 62 预先公开的实施更新称 prop-167 仍在实施，并有数据准确性问题正在解决；材料没有指明本文的算术差异。稳妥的修复是公布计数阶段、排除项、校验结果和替代版本，而不是披露原始查询。

公开统计最有价值的时刻，不是它给出一个很大的数字，而是外部读者可以把这个数字重新算一遍。APNIC 依据 prop-167 发布 WHOIS 与 RDAP 的小时汇总，把查询规模、对象类型、来源 ASN 和不同源地址数量放进可下载、可归档的 JSON。这个开放动作值得肯定，也让一个简单问题无处可藏：总数能不能由分项还原？

本次冻结的最新快照覆盖 2026 年 9 月 8 日 14:00 至 15:00 UTC。WHOIS 区块把 total_queries 写成 3,192,583。类型分布依次包括 1,670,618 次 inetnum、1,284,709 次 route、93,537 次 aut-num、88,530 次 domain、31,500 次 organisation、13,888 次 as-set 和 721 次 inet6num。七项相加为 3,183,463。

两者相差 9,120，占声明总数的 0.2857%。随文件发布的 MD5 与本地计算一致，所以这不是下载过程中丢了字节。同一份 JSON 里的 RDAP 也提供了直接对照：五类查询合计 588,346，正好等于它的总数。格式有能力做到内部一致，差异只出现在 WHOIS。

如果这只是数百万请求中的一个小尾差，仍可能被当作发布延迟。完整档案说明，它不是偶发时点，而是数据合同的常态。

只要 WHOIS 有流量，两个数字就不相等

扫描从 6 月 30 日 03:00 UTC 的首个存档开始，到 9 月 8 日 14:00 UTC 结束。四个月度目录共列出 1,691 个文件，与时间区间应有的小时数完全一致。文件名没有断档；每个 gzip 都能解压；每份 JSON 都能解析；内部半开时间区间与文件名吻合；解压后的内容没有重复。

检验方法不需要统计模型。对每个服务，把 query_type_distribution 的所有整数相加，再用 total_queries 减去该和；对每个展示的 ASN 行，则比较 query_count 与 query_count_by_type 之和。

RDAP 是同一生产环境里最有说服力的对照组。1,691 个小时的服务总数全部对齐，展示的 ASN 行也没有一行出现内部差额。它证明“总数等于分类和”并非对这套文件提出了不可能的要求。

WHOIS 只有一个小时对齐：8 月 27 日 09:00—10:00 UTC。那一小时恰好报告零查询、零 ASN、空分类和零行。换句话说，所有 1,690 个包含 WHOIS 流量的存档文件都同时给出两个不同的服务总数；这些小时也都至少有一条 ASN 行无法由行内类型相加还原。全期共有 347,490 条展示行存在这种差额。

上线第一小时已经如此。6 月 30 日 03:00—04:00 UTC，WHOIS 总数为 4,774,145，类型合计 4,801,599，分类和高出 27,454。扫描的最后一个存档小时里，总数为 2,989,539，类型合计 2,987,334，这次总数高出 2,205。

方向变化比累计差额更重要。1,011 个文件中，总数大于分类和。一个可能解释是：入口接受了某些查询，但解析器没有把它们归入已公布的对象类型。若增加 unknown 或“其他”桶，正差额或许可以闭合。

另外 679 个文件却相反，分类和大于总数。7 月 14 日 05:00—06:00 UTC 是最明显的一例：总数 3,288,941，分类和 3,652,538，后者多出 363,597，相当于总数的 11.0551%。非负的“其他”桶不能减掉这部分。8 月 20 日 03:00—04:00 UTC 则出现最大正差额：80,961，占 2.3823%。一种固定补项无法同时修复两种小时。

同样不能把正负差额相加，称为“错误查询净额”。不同方向互相抵消，并不会创造一个有定义的业务量。唯一稳固的结论是：文件没有提供一条稳定等式，把总量字段与分类字段连接起来。

两个计数器可能各自诚实

最强的反方解释来自服务结构。入口计数器可能记录所有已接受命令，类型计数器则在语法解析之后递增。一条命令也可能触发多个对象类别。内部重试、格式错误、缓存命中、迟到事件、来源 ASN 丰富失败或不同的关账时刻，都可能让两个计数器面向不同总体。这样的设计未必有错。

问题是 README 没有说清采用了哪一种。文档把 total_queries 定义为收到的查询总数，把 query_type_distribution 定义为查询类型到数量的映射；它说明一小时的 UTC 区间和 ASN 行结构，却没有说明计数点、多类别规则、排除项、重试、迟到数据或每个阶段的结算时间。它也没有提供未分类数量、质量状态或更正链接。

因此，现有证据不能裁定 3,192,583 与 3,183,463 哪个“正确”。它们也许分别准确回答了两个问题：入口收到了多少命令，解析器产生了多少分类增量。若是这样，错误不在计数器，而在把两个阶段以“总数”和“分布”并列，却不给读者阶段名称。

校验和只能守住另一道边界。MD5 证明读者拿到的字节与 APNIC 发布的字节一致，不能证明字节里的两个字段共享分母。传输完整性、分类完整性和指标一致性必须分开验证。

ASN 数组还有一个未明说的截断。许多小时报告数千个来源 ASN，但观察到的 asns 数组最多只有 1,000 行。这很像为了控制体量而列出的前一千名，却没有在 README 中被标为排行，也没有选择规则。因此即使每一行都修复，展示行之和仍不能被默认当成服务总数。

“已实施”与“实施中”可以同时为真

prop-167 页面目前仍显示 Implemented，并在历史表中写着“2026 年 6 月 30 日—Implementation Complete”。与此同时，APNIC 已经为 9 月 10 日计划举行的 APNIC 62 Policy SIG 场次公开了一份实施更新。prop-167 幻灯片把状态写成“In Implementation”，说明 6 月 30 日进行了初次发布，部分数据准确性问题正在解决，预计第三季度末完成。

这里必须守住两个时间与因果边界。文件是在预定场次之前抓取的，只能称为已公开的演示材料，不能写成讲者已经在会上作出声明。材料也没有说明“准确性问题”就是本文发现的差额；把两者直接画等号是在替 APNIC 下诊断。

这份材料仍然证明了一件较窄但重要的事：初次上线不是实施故事的终点。政策页可以用“已实施”描述服务存在，更新材料可以用“实施中”描述质量保障。可用性、覆盖、算术一致和更正能力属于不同完成层。一个总状态把它们压成同一句话，才会制造表面矛盾。

分母会进入下一步决定

公开流的用途真实存在。研究者可以观察 WHOIS/RDAP 规模、对象类型结构、来源 ASN 集中度和不同源地址数量，又不必接触源 IP 或被查询资源。逐小时保存也允许别人复算，而这正是公共基础设施应有的属性。

但任何复用都会选择分母。用某一 ASN 行除以 total_queries 得到一个占比，用同一行除以类型和得到另一个。按总数字段画出的需求曲线，可能与按类型重建的曲线方向不同。如果分类器升级导致一条命令多记一个类型，图表会把规则变化误读成用户行为变化；如果未分类命令只进入总数，类型结构会漏掉一部分负载。

本文没有证明查询丢失、重复、答错或被滥用，没有发现隐私泄露，也没有把任何 ASN 变成嫌疑对象。零查询小时不能在没有服务通告的情况下称为宕机。这里审核的是公开证据能否自我还原，而不是 WHOIS 服务的全部运行质量。

给每个小时一张不含个人信息的勾稽表

修复可以保持聚合。第一行写入口接受请求数，随后写成功解析数、分类增量，以及因语法错误、不支持类型、超时或其他通用原因被排除的数量。若一条查询可以增加多个类别，明确多记规则；若各阶段不同时间关账，公布每个截止点和迟到处理。

第二部分记录转换身份：采集器与分类器版本、运行标识、完成时间，以及重新计算所有等式的校验结果。来源 ASN 丰富失败只需公开合计，不需要地址。1,000 行上限应写成排名，并给出选择依据。

第三部分保存更正链。每个小时标为暂定、已验证、已更正或撤回，并带文件指纹。替代文件引用旧指纹、更正时间、原因类别和受影响字段；旧版本保持可发现。这样，外部文章和图表才能说明使用的是初版还是修订版。

这张勾稽表不需要公开谁查了什么。它只要求发布两个总数的机构解释两者如何连接。APNIC 已经完成了昂贵部分：按小时生成、开放下载、保留档案和提供校验和。剩下的是一条让数字成为可复用证据的等式。

来源