摘要

  • RIPE NCC 的公开会员名单上列有 Nebius B.V.；为这家运营方查得的 whois 回答给出五个自治系统对象——NebiusMAD、NebiusPA10、CoreNebiusNet、NebiusCloud 与 NEBIUS-UK，其中三个带有机构标识 ORG-NB187-RIPE。
  • 2026 年 10 月 21 日取到的宣告前缀数据显示，五个系统里有四个正在发起地址，数量从五个到二十七个不等；CoreNebiusNet 返回空前缀列表，其 as-overview 记录的 announced 字段为 false。

登记库不是宣传册。它是一个号码变成名字的地方，而这个名字别的网络可以据以行动——上游运营商、过滤服务、审计方在判断「这批流量是谁的」时，看的正是这里。对任何把工作负载放在一份 AI 云合同背后的人来说，运营方的登记条目因此是一份工作文件，不是脚注。

RIPE NCC 的会员名单把 Nebius B.V. 记在荷兰（RIPE NCC 会员名单）。名录条目对这家公司的处理很克制：这条记录只被当作会员资格与号码资源背景，本身并不证明该实体销售接入、IP 转接、云、注册或托管网络服务（名录条目）。号码本身来自登记库自己的回答。

先解释一句：自治系统号（AS 号）是登记库里代表「一个统一执行路由策略的网络」的编号，前缀则是一段实际被宣告出去的地址。二者不是一回事，混淆它们正是这篇报道要处理的问题。

2026 年 10 月 21 日，通过 RIPEstat 取得的 whois 回答覆盖五个名称里带 Nebius 的自治系统号。AS203326 给出的名称是 NebiusMAD，并带机构键 ORG-NB187-RIPE（AS203326 whois）；AS214415 给出 NebiusPA10 与同一个机构键（AS214415 whois）；AS215169 给出 CoreNebiusNet，第三次出现该键（AS215169 whois）。

这条线索到这里就断了：AS213291 只返回名称 NebiusCloud（AS213291 whois），AS211318 只返回 NEBIUS-UK（AS211318 whois），所取得的片段里没有机构键。

四个在宣告，一个保持沉默

转发层面的记录并不整齐。同一天的宣告前缀快照里，AS203326 宣告五个前缀（AS203326 前缀），AS214415 十三个（AS214415 前缀），AS213291 二十七个（AS213291 前缀），AS211318 六个（AS211318 前缀）。AS215169 返回的是空前缀数组（AS215169 前缀），而该号的 as-overview 记录把持有者写作「CoreNebiusNet Nebius B.V.」，announced 为 false（AS215169 概览）。

一个已经登记、却什么都不发起的自治系统，在登记库里是再普通不过的对象。它可能是一份预留，可能是迁移过程中保留下来的号，可能只在内部使用，也可能只是某个变更之后没有撤掉的条目。记录本身分不清这些情况，也不该被要求分清。它能说的很窄，但可核验：在那一天，这个号没有发起任何全球可见的前缀。因此「CoreNebiusNet 承载某客户的流量」这类说法，需要登记库以外的证据。

名字里的那些词是登记人自己的选择。MAD、PA10、Cloud、Core 和 UK 描述的是机构内部某个人决定如何命名一条记录。它们不是登记库字段，不是地理位置，也不是功能声明。

互联记录并不跟着标签走

唯一取得的互联记录，也不支持把这些词读成地理位置。PeeringDB 上 AS213291 的条目把机构写作 Nebius B.V.，网络类型为「Content」，并列了四处设施：Digita Helsinki Pasila Broadcasting Tower、Elisa Helsinki Lauttasaari、Equinix AM7（阿姆斯特丹）与 Equinix FR5（法兰克福）（PeeringDB AS213291）。清单上没有马德里，也没有宾夕法尼亚。如果 MAD 与 PA10 指的是地点，登记库和这份设施记录都没有显示出来。

这份记录没有证明什么

缺口是具体的，不是含糊的。为这次核对取得的所有材料里，都没有自治系统对象的其余字段：五个号的 descr、origin、mnt-by、created、last-modified 一个也没拿到。ORG-NB187-RIPE 的机构对象全文没有取得。AS203326、AS214415、AS215169 与 AS211318 的 PeeringDB 记录也没有取得，而那几次查询失败属于访问失败，不是空记录——这是两种不同的事实，不能读成「不存在」。

没有任何 RIPE NCC 数据库网页界面的渲染结果被截取。也没有读到任何点名某个自治系统号的 Nebius Group 文件、年报或投资者材料。

就公司自身而言，nebius.com 把 Nebius 描述为 AI 云服务商，提供 GPU 集群、高速网络、托管推理与训练工具，并确认 Nebius B.V. 是运营该服务的法律实体（nebius.com）。文档门户覆盖虚拟机、GPU 集群、Kubernetes 与 VPC 网络，但里面没有一句话把 RIPE 登记的自治系统号对应到某个运营角色、某个站点或某项服务（docs.nebius.com）。两份文件，一个号码，中间没有桥。

能一次性把问题定下来的是某一类文件，而不是同一批数据的更多副本：运营方自己在网络或对等互联页面点出 AS 号，RIR 对象把号码与角色交叉引用，或一份文件明确把某个号分配给某个用途。在这类文件以可读形式出现之前，最站得住的表述就是这条观察本身，日期是 2026 年 10 月 21 日。

对买方而言，后果很具体。一份合同可以写明法律实体和服务区域，却从不提承载流量的那个自治系统号，而登记库不会自己把这个缺口补上。问一句「哪个号在发起我们的前缀」，再问「谁持有能改动这些宣告的凭据」，是公开记录今后可以证实也可以推翻的问题。