摘要

  • RIPE NCC 论坛同一用户先后报告两组查询差异：输入单个 IP 没有数据，输入对应的已宣告前缀却有结果。
  • 9 月 3 日约 04:13 UTC，本文对两组输入进行了四次查询，均返回数据，没有重现报告中的现象；这不等于证明问题已经永久解决。
  • 单个 IP 查询需要先找到覆盖它的已宣告前缀。把空结果解释为路由撤回之前，必须先弄清查询对象、数据时点和观察范围。

14.137.164.1 是一个地址，14.137.164.0/24 是一段地址。在界面上，两者只差几个字符；对查询服务来说，却未必是同一道题。

9 月 2 日，一名用户在 RIPE NCC 论坛报告，RIPEstat 的 Looking Glass 对前者返回空结果，对后者则返回路由数据。次日的四次复测没有重现这一差别。两个输入都能查到数据，先前讨论过的另一组输入也一样。

因此，这篇报道不能写成“RIPEstat 仍然故障”，也不能写成“问题已经修复”。有依据的判断更窄：一次带有日期的用户报告，揭示了从输入地址到解释路由之间的一道中间环节；后来的正常结果，并没有补齐先前异常的原因。

地址要先变成什么问题

按照 Looking Glass 接口说明，直接输入前缀时，它需要与路由数据中的前缀精确匹配。输入 IP 地址时，服务则尝试寻找覆盖该地址的已宣告前缀，再返回相应观察结果。默认回看限制为 86,400 秒，超过这一时限的条目会被排除。

便利性来自这一步转换。用户无需事先知道地址属于哪段正在宣告的网络，但服务必须替用户完成判断。转换与后续数据读取不是同一项工作。前一步出现问题，理论上可以影响查询结果，而不需要任何网络撤回路由。这里说明的是依赖关系，不是认定本次报告的根因已经找到。

也不能把经验简化成“加上 /24 就好”。真实宣告的前缀未必是 /24，任意补一个掩码，可能只会提出另一个查不到数据的问题。可比较的输入，应当是一端为地址，另一端为已得到证据支持的实际路由前缀。

报障没有给出的答案

论坛记录中的首帖发布于 8 月 24 日，涉及 159.138.184.0 与 159.138.184.0/24。8 月 25 日，公开标记为 RIPE NCC 员工的账号 ties 解释了最长前缀查找，认为现象似乎是暂时的，并表示会请同事查看查找失败时的处理。

9 月 2 日，原发帖者 moonteach 说，之前的地址后来可以查询，但 14.137.164.1 又出现空结果，对应 /24 则有数据。帖子中两次查询的时间相差 27 秒，不是同一瞬间的对照实验。这里始终只有一名报告者；不能据此推导影响比例，也不能把员工回复理解成正式根因说明或修复公告。

复测正常，结论为什么仍要保留

9 月 3 日 04:13:08.929 至 04:13:10.945 UTC，本文依次发出四次普通查询。它们的 HTTP 状态均为 200，接口状态均为 ok，数据均非空。两个单 IP 响应都明确提示已转换为覆盖该地址的 /24，实际查询参数也显示了转换后的前缀。

输入 采集器条目 对等会话记录行
159.138.184.0 23 343
159.138.184.0/24 23 343
14.137.164.1 23 325
14.137.164.0/24 23 325

表中数字只描述保存下来的响应，不是独立运营商数量，也不是 RIS 全部设施的规模。后一组的两个 latest_time 相差 20 秒，因此相同的行数不能证明底层快照完全一致。表内链接会重新执行实时查询，不是历史结果的永久镜像。

这组复测的重要性，在于把报道范围缩小了：在这些输入、这个时点，异常没有出现。它无法重建用户当时遇到的服务器状态，无法说明其间发生了什么，也不足以估算整个服务的可靠性。保留这种区别，比在“故障持续”和“已经恢复”之间仓促选一边更准确。

200 回答的是哪一层

Data API 文档区分状态、消息、版本和缓存等信息。成功返回响应，不等于已证明某个地址可达；同样，返回的数据为空，也不自动构成路由撤回的证据。请求处理与网络运行之间，还有没有被这次查询测量的环节。

RIS 的工作是通过自愿提供数据的对等会话收集 BGP 观察结果，并不是替用户向目的地址发送业务流量、检验端到端转发。一个前缀能否在某个视角中被看到，与客户能否实际访问服务，相关却不等同。

公开材料没有证明本次现象造成断网、流量损失或路由劫持。真正值得保留的技术问题是：在宣布“路由不见了”之前，查询究竟把哪个前缀交给了数据层？如果这个对象尚未弄清，空结果仍应当是一条待调查线索，而不是对运行网络的判决。