摘要

  • BTW 的记录把 AS211386 列为唯一资源：类型 ASN、类别 virtual、状态 observed、所有者引用 azure-london-internet-exchange-ltd；承载该记录的档案最后更新于 2026 年 6 月 16 日，置信度 0.7。
  • 名字暗示 LINX 在 Microsoft Azure 内的一台路由服务器，但档案本身就承认：没有任何运行文档、路由活动或 LINX 与 Microsoft 的官方声明能证实这一角色。
  • 可辩护的责任链有四环——记录、经核验的授权与联系人、可观测的运行、可追溯的控制方；两个别名只填满第一环。

一份注册不是一家公司。它是一张写着名字的授权书，而正是这个差别，决定出事之后谁来答话。

在 BTW 为 AZURE London Internet Exchange Ltd. 维护的名录档案 仅限战略圈层会员 里，AS211386 是唯一的资源条目：类型 ASN，类别 virtual，状态 observed，所有者引用 azure-london-internet-exchange-ltd。这份档案最后更新于 2026 年 6 月 16 日，置信度 0.7。登记的法定名称是一家私营公司 AZURE London Internet Exchange Ltd.，另有两个别名：London Internet Exchange Ltd. 与 LINX-ROUTE-SERV-AZURE London Internet Exchange Ltd.。

第三个别名最耐人寻味。一串字符里同时出现了伦敦的互联网交换中心、一台路由服务器和微软的云。把它当描述读，它承诺了一套架构；把它当登记读，它只承诺了一个名字。档案在这件事上坦白得罕见：名称暗示 London Internet Exchange（LINX）在 Microsoft Azure 内承担路由服务器职能，但没有运行文档、没有路由活动、也没有 LINX 或 Microsoft 的官方声明证实这一角色；目前该实体仅作为一条注册记录存在。

档案还列了四处不加修饰的空白：LINX 与 Microsoft 都没有公开确认或否认归属；AS211386 的用途与启用时间未知；没有任何与这条注册相关的联系人或人员记录；也没有任何网络设施或服务的证据。这组事实有一个立刻可用的推论：档案点了两家大机构的名字，却无法把号码归给其中任何一家。

站得住脚的链条有四环：记录、经核验的授权与联系人、可观测的运行、可追溯的控制方。一个名字占住第一环，其余三环全空。所以正确的问题不是 AS211386 属于谁，而是谁能证明自己控制它、拿什么文件证明、向谁证明。档案把内容建立在两份技术文档上：RIPEstat 的 AS211386 as-overview 端点，以及 211386 的 RDAP autnum 记录。

本文唯一核实到的外部材料讲的是另一件事。ComputerWeekly 报道，LINX 把与 Megaport 的合作形容为 Linx Cloud Connect 服务的“powerful expansion”，通过可信的网络基础设施直接接入核心云服务，获得低时延、稳定在线以及更强的数据流量控制力。这是一条关于该交换中心云战略的真实材料，却不触及本文对象：文本没有提到 AS211386，没有描述路由服务器，也没有声称拥有任何 ASN。

BTW 曾在 2026 年 5 月 26 日以 company-region-global-type-cloud-service 分类发布过同一注册的档案，把它当作一个靠名字与大型交换中心和大型云厂商关联的休眠 ASN。这篇简报换了轴心：它不预测这个号码将来做什么，而是检查要让某人为它负责，需要哪些证据，以及其中哪一部分已经存在。

有三项事实会立即改变分类。一条带 maintainer 与运行联系人的委派记录，就能证明存在托管关系。一次前缀起源观测，会把这个号码变成正在使用的设施。一个 RPKI 状态，则说明是否有人以它的名义授权通告。三者中任何一项都能把讨论从名录拉回运行，而任何一项都无法用别名推断出来。

本文不就 AS211386 的 as-name、委派状态、maintainer、最后修改日期、前缀起源或 RPKI 状态作任何断言。本可确定这些取值的注册与路由文档，在本文证据里并未落实为可读字段，它们也不从名字推导而来。

一个没有书面托管人的号码不是谜团。它是一张等待主人的授权书。