Summary

  • ARIN 的 active 记录确认 AS401110、AS-SOVYCLOUD、Sovy Cloud Services 与 SCSL-51 之间的登记关系;它证明网络身份真实存在,却不等于品牌网站、客户服务或生产网络目前仍在运行。
  • PeeringDB 仍把该网络描述为全球范围的 NSP,并列出五处设施,但同时显示零 IPv4 前缀、零 IPv6 前缀和零交换点;设施条目是待核实的自述足迹,不是现行入驻、合同或服务可用性的证明。
  • 2026 年 7 月 20 日,.cloud RDAP 显示 sovy.cloud 可供注册,三个 DNS 解析视角均返回 NXDOMAIN;同一时间点的 RIPEstat 数据把 AS401110 标为未宣告,并显示零现行前缀、零观测邻居和零 RIS 可见性。
  • AS401110 并非从未运行过。RIPEstat 保存了 2024 年至 2025 年的多段路由历史,但其中最后被该 ASN 看到的 IPv4 前缀如今由另一个 ASN 宣告。对采购者而言,正确结论不是猜测公司命运,而是把历史痕迹与当前运营证明分开核验。

三套公开记录,指向三个不同的时间

Sovy Cloud Services 的公开轮廓之所以值得研究,不是因为某一个数据库给出了异常字段,而是因为不同证据层正在讲述不同时间的故事。

ARIN 保存的是网络身份的登记史。它告诉读者,AS401110 不是一个拼写错误,也不是由第三方评论临时创造的标签。PeeringDB 保存的是网络面向互联社区所提交的自我描述,其中包括名称、类型、范围、设施和互联字段。RIPEstat 与 DNS 则更接近带时间戳的外部观测:在查询发生的那一刻,域名是否存在、自治系统是否正在宣告前缀、路由收集器是否看见邻接关系。

这三套记录不必同时更新,也不具有相同的证明力。登记可以在业务变化后继续存在;目录条目可以比运营状态更长寿;路由观测则可能受采集范围影响,却能回答“现在的公共互联网看见了什么”。当它们彼此一致时,研究者容易形成判断;当它们分离时,更需要保留来源、日期和限定语,而不是从一条残留记录直接推演完整现状。

Sovy 的案例正好提供了一次证据排序练习。最耐久的身份记录仍在,最鲜明的品牌入口已经消失,最接近实时的公共路由表面也沉默了。这个组合降低了“现行公开运营”的可信度,但仍没有跨过“企业已停止一切活动”的证明门槛。

ARIN 能确认主体,却不能替主体证明在线

ARIN 将 AS401110 记录为 AS-SOVYCLOUD,状态为 active,登记日期为 2024 年 5 月 29 日,最后变更日期为 2024 年 5 月 30 日。关联实体是 Sovy Cloud Services / SCSL-51,登记地址位于美国南达科他州沃特敦的 25 First Ave. SW STE A。这些字段把自治系统、名称和一个可定位的登记主体连在一起,是整条证据链最稳固的身份锚点。

这里的 active 必须按注册系统的语境理解。它说明该号码记录没有在 ARIN 数据中被标为已删除或失效,不是对服务器、路由会话、支持队伍、客户合同或收入状态的实时健康检查。自治系统号码是一种网络资源身份;拥有登记身份与正在用该身份对外运营,是两个需要分别举证的命题。

联系信息也显示出时间差。ARIN 中嵌套的行政、技术和滥用联系人使用 sovy.cloud 邮箱,POC 备注则显示,自 2025 年 5 月 7 日起没有收到验证请求的回应,因此联系点处于未验证状态。这个字段能支持的说法是“公开登记联系的验证质量已经变弱”。它不能证明某个具体邮箱无法收信,更不能证明客户支持、账单处理或私人联系方式全部不存在。

域名后来出现的变化,使这些联系字段更值得复核。如果联系人地址依赖一个目前没有 DNS 存在性的域名,那么新客户、上游、设施方或事件响应团队不能只凭注册表里的旧地址假设沟通链仍然有效。合理的下一步是要求一个经过实时验证、并与合同主体匹配的联系渠道,而不是把未验证备注直接写成失联结论。

PeeringDB 留下的是一份自述足迹

PeeringDB 将 AS401110 关联到 sovy.cloud、Sovy Cloud Services 与 Sovy Cloud Services LLC,把网络类型标为 NSP、范围标为 Global,并保留 IRR 名称 AS-SOVYCLOUD。同一网络对象的字段显示零 IPv4 前缀、零 IPv6 前缀、零 IX 数量和五处设施。这个组合本身已经说明,目录中的组织轮廓与现行可见路由之间不能简单画等号。

五条 netfac 记录分别是:

  • Equinix SG1 - Singapore
  • Equinix SG3 - Singapore
  • Equinix HK2 - Hong Kong
  • Linxdatacenter (Moscow)
  • NewTelco Kiev

这组城市横跨亚洲和欧洲,足以解释为何 PeeringDB 档案曾把 Sovy 描述为全球网络。但 netfac 是目录关系,不是现场审计。它没有说明设备在查询日是否仍然存在、由谁拥有、承载什么服务,也没有给出交付状态、合同期限或当前流量。本文因此把它称为“声称的设施足迹”,既不把五条记录删除成无意义的旧数据,也不把它们升级成已验证的现行部署。

其他 PeeringDB 接口进一步显示了档案的稀薄程度。netixlan 对网络编号 36371 没有返回交换网 LAN 记录,公开 POC 接口也没有返回可公开的联系人。零交换网记录只能说明该平台没有公开列出 IX LAN 连接,不能推出该网络没有 IP transit、私人互联或其他非公开连接。零公开 POC 同样不等于不存在私人联系人。

PeeringDB 的价值在于保存运营方曾经希望互联社区如何识别自己。它的局限也正来自这里:资料的持续有效性依赖维护者更新。采购者如果把设施列表当作当前服务地域,至少还应取得设施方或运营方提供的当期确认,并核对该确认是否对应同一法律主体、同一网络和同一服务。

域名变化把举证责任推回运营方

2026 年 7 月 20 日的 .cloud RDAP 查询显示,sovy.cloud 可供注册。系统解析器、Cloudflare 1.1.1.1 与 Google 8.8.8.8 对该域名进行 A 记录查询时,都返回 NXDOMAIN。三个解析视角的一致结果说明,在这一带日期的检查中,公共 DNS 没有把该品牌域名视为存在。

“可供注册”比网页暂时超时更接近域名控制层面的变化。网页故障可能来自主机、TLS、应用或网络路径;NXDOMAIN 与注册可用状态则表明,研究者甚至无法从常规 DNS 入口抵达一个现存域名。对于把官网地址写入 PeeringDB、又把联系人邮箱放在同一域名下的网络,这是一项重要的当前性缺口。

但边界仍然要守住。域名不可解析不能证明 Sovy Cloud Services 的法律实体已经终止,也不能证明所有客户实例、管理地址或私人网络已经离线。服务可能使用其他域名、直接地址、第三方控制台或未公开连接,事实包没有提供这些方向的证据。本文也不能根据 DNS 结果断言旧的行政、技术、滥用或客户支持邮箱一定无法投递,因为没有邮件系统层面的测试。

真正发生变化的是举证责任。过去,一份带官网和联系人地址的 PeeringDB 档案可能足以让潜在合作方开始对话;当域名已经可重新注册且不存在于 DNS 中,旧档案就不能继续充当当前服务入口。若运营仍在继续,最有说服力的补充应是由当前主体控制的域名、可验证的技术与事件联系、现行服务端点,以及能够与 AS401110 或其他明确网络身份连接起来的证据。

公共 BGP 视野中的“零”需要带上测量边界

RIPEstat 的 AS overview 在 2026 年 7 月 20 日 08:00 UTC 把 AS401110 标记为未宣告。announced-prefixes 接口在最新两周窗口中没有返回当前前缀。routing-status 则给出更完整的零值组合:零个当前 IPv4 宣告前缀、零个当前 IPv6 /48、零个观测邻居,以及 IPv4 和 IPv6 均为零的当前 RIS 可见性。

ASN-neighbours 接口在最新可用时间也没有看到 left、right、unique 或 uncertain 邻居。换成运营语言,就是 RIPE RIS 的公共路由观察面没有为 AS401110 暴露当前的上游、下游或对等路径。再与 PeeringDB 的零 IX LAN 记录并置,外部研究者缺少一条能够证明 Sovy 网络此刻连接到公共互联网的可观察链路。

这些零值很重要,却不是全知视角。RIPEstat 的 announced-prefixes 结果说明,RIS 完整路由表中可见度极低的路由可能被排除。公共 BGP 收集器也不会完整呈现所有私人互联、内部路由、按需备用会话或封闭服务网络。因此,准确表述应是“在所查 RIPEstat 公共视图中没有当前路由表面”,而不是“世界上不存在任何 Sovy 网络活动”。

测量边界不应成为忽略结果的理由。对于一个在 PeeringDB 自称全球 NSP、又留下五处设施条目的网络,公共视图中同时缺少前缀、邻居和交换网连接,本身就是显著的当前性信号。它不完成关闭证明,却使任何“仍在公开交付 Sovy 品牌云服务”的主张需要更直接、更新鲜的反证。

历史路由证明 AS401110 曾经不是空壳

如果只看 2026 年 7 月的零值,容易把 AS401110 误写成从未真正使用的登记号码。RIPEstat 的 routing-history 否定了这种简单说法。查询窗口显示,该 ASN 在 2024 年 5 月、6 月至 2025 年 2 月前后的不同阶段,曾发起以下前缀:

  • 166.88.177.0/24
  • 2a12:8fc6:4011::/48
  • 81.161.230.0/24
  • 109.206.237.0/24
  • 136.0.121.0/24
  • 23.27.222.0/24

routing-status 还把 2a12:8fc6:4011::/48 的首次可见日期记录为 2024 年 5 月 31 日,并把 109.206.237.0/24 记录为最后看到的 AS401110 IPv4 前缀,日期为 2025 年 2 月 14 日。这条时间线说明,Sovy 的网络身份曾进入公共 BGP,而不是仅停留在 ARIN 和 PeeringDB 表格里。

历史存在仍不能替代当前状态。路由曾经出现,可以证明自治系统具备过实际的公共宣告活动,却不能说明当时承载了多少客户、何种产品、多少流量或怎样的服务质量。路由后来消失,也不能单独解释原因:可能涉及供应关系、地址使用、网络重构、业务变化或其他未公开因素。事实包没有合同或运营说明,不能选择其中任何一种作为结论。

这正是时间序列比单点截图更有价值的地方。ARIN 证明身份建立,routing-history 证明身份曾被使用,当前 routing-status 则显示这种公共使用没有持续到查询时点。三者连接起来,能够写出“真实但不再获得当前公共证明”的判断,而不必把未知原因填成故事。

前缀换了 origin,也不等于找到了商业解释

两个历史前缀提供了更细的后续线索。109.206.237.0/24 是 routing-status 中最后被 AS401110 看见的 IPv4 前缀;在 2026 年 7 月 20 日的 RIPEstat prefix overview 中,它当前由 AS16045 BULINFO-HOSTING Spektar AD 宣告。与此同时,最早出现在 AS401110 记录中的 IPv6 前缀 2a12:8fc6:4011::/48 当前没有被宣告。

IPv4 origin 的变化是可以观察的控制平面事实。它说明全球路由系统现在把该 /24 的起源指向另一自治系统,而不是 AS401110。它不能单独证明地址所有权发生转移,也不能说明两个网络之间是否存在租赁、托管、供应终止、重新分配或任何其他商业安排。BGP 记录的是路由选择所依赖的宣告,不是合同登记簿。

同样,IPv6 前缀当前未宣告,只能说明在所查公共视图中没有现行路由。它不证明地址资源已被注销,也不证明任何特定设备已下线。把“origin 已变”和“前缀未宣告”作为现状证据是合理的;用它们推断公司关闭、客户迁移完成或设施撤离,则超出了数据范围。

对尽调而言,这种变化仍然十分关键。如果供应商以历史前缀、旧网络图或旧监测截图证明今天的可达性,采购者应重新核对当前 origin、当前授权、当前 DNS 和当前服务端点。基础设施身份不是永久凭证,地址空间的使用关系也可能随时间改变。只有把检查日期写进结论,才不会把一段真实历史误当作现行保证。

四层证据,比“公司是否存在”更有操作价值

面对这类记录分离,最有用的问题不是要求数据库替公司做生死判断,而是把证据分成四层。

第一层是身份层。ARIN 的 AS401110、AS-SOVYCLOUD、SCSL-51、名称和地址回答“哪个主体建立了这个网络身份”。这层证据最耐久,也最不适合被当作在线状态指标。

第二层是声明层。PeeringDB 的 NSP 类型、Global 范围、设施条目、IRR 和网站字段回答“运营方曾向互联社区如何描述自己”。它适合寻找核验对象,不适合独立证明这些对象今天仍然有效。

第三层是公共运营层。域名 RDAP、DNS、当前 BGP 前缀、邻居、origin 和交换网记录回答“外部观察者在特定日期能看见什么”。这一层最接近当前状态,但仍会漏掉私人和低可见度服务。

第四层是服务层。它应包括可用的客户入口、经过验证的支持和滥用响应、合同主体、服务状态、近期故障记录,以及运营方能向客户提供的当期网络与连续性证据。事实包没有闭合这一层,因此本文不能替 Sovy 给出服务可用性结论。

这套分层避免两个相反错误。一种错误是看到 active ASN 和五处设施,就认为业务必然在线;另一种错误是看到 NXDOMAIN 和零路由,就宣称所有活动必然结束。公开资料支持的是中间结论:身份和历史真实,现行公共运营证明薄弱,私人或替代服务表面未知。

云服务采购者应要求“当前证据包”

对正在评估 Sovy Cloud Services 或任何低可见度云品牌的企业,静态目录搜索只是第一步。一个可执行的当前证据包至少应回答以下问题:

  1. 主体与入口是否一致。 报价、合同、发票、服务门户和技术联系人是否指向同一法律主体?当前域名由谁控制,何时续期,是否能通过独立渠道确认?
  2. 网络身份是否仍在使用。 生产服务实际使用哪个 ASN 和哪些前缀?这些前缀在查询日由谁发起,是否有可验证的路由授权和外部可达性?
  3. 设施声明是否仍然有效。 PeeringDB 中的五条设施关系,哪些是现行交付点,哪些只是历史或互联目录记录?确认应明确日期、主体和服务范围,而不是复述设施名称。
  4. 公共与私人路径如何区分。 如果服务不依赖公开 BGP 或公开网站,客户通过什么入口访问,控制台、API、备份和事件通知又依赖哪些域名或网络?
  5. 联系链是否经得起故障。 技术、滥用、安全和账单联系是否经过近期测试?若品牌域名不可用,是否有独立域的应急渠道,且不会与同一故障域一起消失?
  6. 退出与连续性如何验证。 客户能否定期导出数据和配置,如何验证恢复,服务中断或网络身份变化时有哪些通知、迁移与终止安排?

这些问题不是对 Sovy 已发生故障的断言,而是从现有证据缺口导出的采购要求。供应商完全可能通过受控文件、实时演示或第三方确认回答其中部分问题。关键在于,答案必须比 2024 年的登记日期和一份未更新的目录档案更接近今天。

对中小企业而言,这种核验尤其重要。规模较小的采购方往往没有多云迁移团队,也很少持续监测 ASN、DNS 和前缀 origin。一旦控制台、联系人和网络身份同时发生变化,恢复成本可能来自信息不足,而不只是技术故障。把当前证据包纳入续约流程,比在事件发生后追溯旧网页更有效。

对运营方,透明不等于公开敏感拓扑

要求当前证据并不意味着供应商必须公开精确设备位置、客户名单或安全细节。一家仍在运营、但选择使用私人网络或第三方承载的服务商,可以通过较高层次的材料恢复可信度:说明法律主体与品牌关系,公布受控域名和稳定联系人,提供日期明确的网络边界说明,并让客户验证服务入口和数据导出。

PeeringDB 档案也可以被视为需要维护的运营接口,而不仅是宣传页面。若五处设施仍然相关,更新网络前缀、公开联系人或互联方式能够减少歧义;若部分关系已经过时,及时修订比让旧足迹继续代表现状更有价值。目录准确性不会取代服务审计,但能降低合作方寻找基本事实的成本。

对于 ARIN 联系记录,重新完成 POC 验证同样是一项低层但重要的治理动作。它不证明网络性能,却表明资源主体仍能接收并回应注册管理体系的联系。若原域名不再使用,则应把资源记录中的联系渠道更新到受控地址,避免登记身份与可达联系人继续分离。

这些动作都不能单独反转 RIPEstat 的零路由结果。若 Sovy 品牌服务确实继续存在,最有力的说明仍应连接服务入口、网络路径和客户支持,而不是只更新一个描述字段。透明的目标不是制造更多资料,而是让不同证据层重新指向同一时间。

监测应记录变化,不应追求一次性判决

本文的结论绑定在 2026 年 7 月 20 日。域名可能被重新注册,路由可能重新出现,PeeringDB 可能更新,ARIN 联系也可能重新验证。未来任何变化都应被当作新证据,而不是用来否认旧查询当时的准确性。

一个简洁的后续监测基线可以包括:sovy.cloud 的 RDAP 状态与 DNS 存在性;AS401110 的 announced 状态、前缀和邻居数量;历史前缀的当前 origin;PeeringDB 网络、设施、IX LAN 与公开 POC 字段的更新时间;ARIN POC 的验证状态。每次检查都应保存时间、数据源和原始字段,避免只留下“在线”或“离线”两个不可复核的标签。

如果 AS401110 再次发布前缀,研究者还需要确认那是短时异常、测试宣告还是持续运营,而不能在首次出现时立即宣布全面恢复。如果域名被新注册,也要核对注册主体和内容,防止把另一个注册人的使用误归给 Sovy Cloud Services。状态变化会增加信息量,但身份对应关系仍需重新建立。

反过来,如果登记与目录继续保留,而 DNS 和路由长期没有恢复,当前运营等级会进一步变弱。它仍然不是法律终止证明,却会让历史资料与现行服务之间的距离越来越大。基于趋势的判断,比从单一数据库状态中寻找绝对答案更适合基础设施研究。

不要把接口数量误当成独立证据数量

这组资料包含多个查询入口,但入口多并不自动意味着证据彼此独立。ARIN 的自治系统记录与实体记录来自同一注册管理体系,前者把 AS401110 连到 SCSL-51,后者补充主体名称和登记地址。它们可以互相校验字段,却不能被当作两家互不相关的机构分别证明 Sovy Cloud Services 正在运营。

RIPEstat 的 AS overview、announced-prefixes、routing-status、ASN-neighbours 与 routing-history 也承担不同功能,但都依赖公共路由观测体系。一个接口说“未宣告”,另一个接口给出零前缀和零邻居,可以增强内部一致性;研究者仍不应把这些零值算成五次完全独立的互联网测量。更准确的做法,是把它们归为一个有多个切面的“公共 BGP 观察层”。

PeeringDB 的网络、组织、设施、IX LAN 与公开 POC 接口同样属于一套目录。五处设施、零交换网记录和零公开联系人描绘的是同一份自我维护档案的不同字段。它们能显示档案内部存在怎样的张力,却不能把一项运营方声明通过重复读取变成第三方现场确认。

DNS 的三个解析视角也需要这样理解。系统解析器、Cloudflare 1.1.1.1 和 Google 8.8.8.8 都返回 NXDOMAIN,说明结果不是单一终端的偶发缓存表现;但三个递归解析器最终询问的是同一个域名体系。再加上 .cloud RDAP 显示域名可供注册,证据才从“解析结果”延伸到“注册状态”,形成两个相关但功能不同的观察面。

真正增加判断力的不是接口总数,而是不同证据层的收敛。ARIN 提供耐久身份,PeeringDB 保存运营方曾经给出的互联描述,DNS 与域名 RDAP 描述当前品牌入口,RIPEstat 描述当前公共路由可见性。四层资料在 2026 年 7 月 20 日共同呈现“身份仍可追溯、公开运营表面却缺少新鲜证明”的格局,这比任何一个零值都更有意义。

这种分组还能防止虚假的精确感。若五个 RIPEstat 接口同时依赖相近的收集范围,它们不能消除公共收集器对私人路径的盲区;若三次 DNS 查询都观察同一个不存在的名称,也不能证明其他未披露域名不存在。尽调报告应说明证据来自几个独立层,而不是只列出调用了多少个接口。

时间戳决定每条记录能回答哪一个“现在”

Sovy 的公开轨迹可以按时间重新排列。ARIN 记录显示 AS401110 于 2024 年 5 月 29 日登记,次日发生最后变更;RIPEstat 把 2a12:8fc6:4011::/48 的首次可见时间放在 2024 年 5 月 31 日。这个紧凑顺序支持“网络身份建立后很快出现公共路由活动”,但并不说明那条 IPv6 路由承载了什么产品或客户。

随后,routing-history 在 2024 年至 2025 年初保存了六段 IPv4 与 IPv6 前缀的可见窗口。routing-status 把 109.206.237.0/24 标为最后由 AS401110 看到的 IPv4 前缀,并给出 2025 年 2 月 14 日这一日期。这里的“最后看到”是观测边界,不是合同终止日、设备关机日或企业活动结束日。

ARIN 联系人的未验证备注又提供了另一只时钟:自 2025 年 5 月 7 日起,验证请求没有得到回应。它晚于上述最后可见 IPv4 日期,但两者不能被直接写成因果链。路由观测和联系人验证属于不同流程,公开材料没有证明前者导致后者,也没有证明二者源于同一运营变化。

到了 2026 年 7 月 20 日,新的查询才把品牌域名可供注册、三个 DNS 视角返回 NXDOMAIN、AS401110 未宣告、零当前前缀、零观测邻居和零 RIS 可见性放到同一个检查日。正是这一带日期的组合,使“当前公开运营证明偏弱”成为可辩护的评级。若省略日期,读者很容易把 2024 年建立的身份、2025 年出现的验证缺口和 2026 年的当前观测压成一个静态事实。

PeeringDB 的五处设施条目则不应被强行塞进一条未经证明的终止时间线。现有资料确认查询时目录仍返回这些关系,却没有提供每一处部署的现场核验日期。它们适合放在“尚待当期确认”的一栏,而不是被安排在路由消失之前或之后,继而推断撤场顺序。

因此,尽调中的每个句子都应同时带有“来源能看见什么”和“它看见的是哪个时间”。登记日期回答身份何时建立;路由历史回答公共宣告何时被观察到;查询日的 DNS 和 BGP 回答当时外部观察面呈现什么;服务是否持续,则需要另一个尚未闭合的证据层。所谓当前性,不是字段旁边出现 active,而是证据与待回答问题的时间尺度匹配。

品牌域名是入口,也是多条公开责任链的共同依赖

在 PeeringDB 档案中,sovy.cloud 不只是一个宣传网址。ARIN 的行政、技术和滥用联系人也使用该域名下的邮箱。品牌发现、资源管理联系和滥用响应因此至少在公开记录层面共享同一个命名依赖。域名一旦不再存在于公共 DNS,受影响的不只是网页可见性,也包括外部人员如何判断旧联系地址是否仍由登记主体控制。

这并不等于邮箱已经被逐一测试为无法投递。NXDOMAIN 是域名层面的观察,本文没有进行邮件投递、第三方工单或私人联系渠道测试。准确的风险描述是:公开记录指向的多个入口失去了可由 DNS 验证的共同基础,外部人员不能继续把这些地址当作已确认的当前渠道。

域名可供注册还引入了身份连续性问题。未来若 sovy.cloud 再次出现 DNS 或网页内容,仅凭名称恢复不能证明它仍由 Sovy Cloud Services 或 SCSL-51 控制。研究者需要重新连接注册控制、法律主体、网络身份和服务入口,防止把后来注册人的活动误归给旧主体。原名称重新上线与原运营方恢复,是两个不同命题。

对采购方而言,共同依赖意味着备用联系不能只是在同一域名下再增加一个邮箱别名。技术、滥用、安全、账单和合同通知至少需要一条经过近期验证、且不会随品牌域名同时失去可发现性的替代路径。替代路径可以保持非公开,但应在合同和事件手册中由双方验证,并明确谁负责维护。

对网络资源治理而言,ARIN POC 的重新验证也有独立价值。它不能证明云实例可用,却能缩短外部网络运营者在路由或滥用事件中寻找责任主体的路径。如果运营方已改用别的域名,那么更新资源记录比保留一个无法从公共 DNS 解析的旧地址更能维护 AS401110 身份的可问责性。

这个案例说明,域名不是孤立的市场资产。它可能同时支撑官网、联系人、事件响应和品牌身份的外部连续性。评估低可见度服务商时,应先画出这些依赖,再判断一次域名状态变化会让多少公开责任链同时变得不可验证。这样得到的是可操作的风险图,而不是把 NXDOMAIN 简化成“网站坏了”。

五处设施应被改写成核验矩阵,而不是覆盖地图

Equinix SG1 - SingaporeEquinix SG3 - SingaporeEquinix HK2 - Hong KongLinxdatacenter (Moscow)NewTelco Kiev 在视觉上很容易被读成一张跨区域基础设施地图。可是 PeeringDB netfac 返回的是网络与设施之间的目录关系,不是五份租赁合同、五次现场盘点或五个可购买的云区域。

每一行至少需要四个独立问题。第一,关系是否仍由 Sovy Cloud Services、Sovy Cloud Services LLC 或与其有明确关系的主体维持;第二,关系对应的是 AS401110,还是其他网络或第三方交付安排;第三,设施内存在的是互联、设备、远程接入还是仅留存的目录关联;第四,这一关系在什么日期仍可被设施方或运营方确认。现有资料没有替这些问题给出答案。

同一城市出现两处 Equinix 条目,也不能自动证明冗余。冗余需要知道电力、网络、控制面、人员、上游和故障域如何分离;两行设施名称只证明目录中有两个不同关系对象。同样,五个城市横跨多个地区,也不等于客户数据会在这些地点复制,更不等于任一地点承担备份、灾难恢复或客户接入。

PeeringDB 同一网络对象显示零 IPv4 前缀、零 IPv6 前缀与零 IX 数量,使设施关系更需要当期解释。如果这些地点仍服务于 Sovy,运营方可以说明所用网络身份、接入方式和服务边界;如果它们只反映历史互联或第三方安排,目录也应相应更新。零值没有自动取消设施行,但让设施行失去独立证明现行网络覆盖的能力。

核验矩阵还应区分“存在于设施”与“从该设施交付本文所讨论的服务”。即使某一关系仍有效,也不能据此推出客户实例、存储、控制台、支持团队或备份位于该处。对云采购最有价值的确认不是一张带五个城市的截图,而是说明具体服务依赖哪个交付点、由哪个主体负责、发生故障时怎样切换。

在没有这些确认时,最稳健的处理不是删掉设施清单,也不是照单全收。应保留它作为调查线索,给每一行标注“目录声明、当前状态待核实”,并把确认日期纳入续约材料。这样既尊重 PeeringDB 保存的历史信息,也不会让一份耐久目录替代当前运营证明。

“零”的组合有意义,但不能被重复计票

AS overview 的未宣告状态、announced-prefixes 的空结果、routing-status 的零前缀与零 RIS 可见性,以及 ASN-neighbours 的零邻居,在方向上高度一致。它们共同说明,在查询时点和相关 RIPE RIS 公共观察范围内,没有形成一条可见的 AS401110 路由表面。这个组合比单独一个空数组更稳健。

但这些字段不应被包装成多家观察机构分别得出同一结论。它们都描述公共 BGP 的不同切面,而且 announced-prefixes 明确存在低可见度路由可能被排除的限制。将五个相关零值简单相乘,不会让公共收集器看见私人互联、内部网络或未被完整路由表覆盖的路径。

PeeringDB netixlan 的零交换网 LAN 记录来自另一个资料层,因此可以补充“没有公开列出的 IX 接入”。它仍然不是零 transit、零专线或零私人对等的证明。一个网络可以不在 PeeringDB 公布 IX LAN,却通过上游或私下安排连接;现有材料没有证实 AS401110 在查询日存在这样的安排,也没有证实它们不存在。

DNS 与域名 RDAP 提供了更独立的当前信号。品牌域名可供注册且三个解析视角返回 NXDOMAIN,与 BGP 沉默并非同一测量系统的重复输出。两者同时出现,说明公开品牌入口和公共路由身份都缺少当前可见性。即便如此,它们仍没有观察客户是否通过其他名称、第三方平台或私人地址访问服务。

负面证据的强度取决于预期。如果一个档案自称 Global NSP、保留五处设施并把 sovy.cloud 作为网站,那么外部观察者合理预期至少能找到一条新鲜的品牌、联系或网络链路。多个层面都没有满足这一预期,会显著降低当前运营评级;它所降低的是主张可信度,而不是把未知状态直接改写成确定关闭。

这也是为何本文使用“当前公开运营证明偏弱”,而不是给出绝对的在线或离线标签。评级承认相关零值的一致性,也保留测量范围之外的可能性。它要求运营方用更直接的当期证据消除歧义,而不是要求研究者从公共观察的缺口中猜出私人事实。

六段历史前缀呈现的是活动轨迹,不是容量报表

RIPEstat 保存的六段历史前缀有一项明确价值:它们反驳了“AS401110 从未进入公共路由”的说法。IPv4 与 IPv6 记录分布在 2024 年至 2025 年初的窗口,说明这个自治系统号码曾被用作实际 origin,而不仅是停留在 ARIN 登记页和 PeeringDB 档案中的标识。

然而,前缀数量不能直接换算成服务器数量、客户数量、带宽、收入或可售容量。一个 /24 可以承载多种用途,也可能在短期测试、迁移或供应安排中出现;一条 /48 的存在同样不能说明有多少 IPv6 用户。routing-history 记录路由可见性,不记录云控制面、虚拟机清单、流量或服务等级。

可见窗口也不是连续运营证明。公共收集器在某些时段看到一个 origin,只能说明至少在相应观察面出现了宣告。没有逐日持续性、路径稳定性和业务资料,研究者不能把若干窗口连接成无间断服务史。反过来,窗口结束也不能自动解释为客户迁出或网络关闭。

2a12:8fc6:4011::/48 的首次可见日期和 109.206.237.0/24 的最后可见日期,为这段轨迹提供了两个有用锚点。前者把实际路由活动放到 ASN 登记之后,后者给出目前所知的较晚 IPv4 观察。两个锚点能描述“曾开始、后来不再被当前视图看到”,却不能填补中间的商业故事。

对采购者来说,历史前缀最适合用于提出核对问题。旧架构图中的地址是否仍由当前服务使用?若不再使用,客户入口何时切换到什么网络身份?监控和防火墙白名单是否仍引用旧前缀?这些问题可以通过当期配置和双方记录回答,而不是从 BGP 历史推测。

对研究者来说,保留六段前缀的具体列表也有未来价值。如果其中任何一段重新由 AS401110 宣告,或者转向新的 origin,可以与当前基线比较。但新的宣告仍需观察持续时间和主体对应关系,不能仅因历史地址再次出现就宣布 Sovy 品牌服务恢复。

当前 origin 变化要求重新建立映射,而不是猜测原因

109.206.237.0/24 在 routing-status 中是最后被 AS401110 看到的 IPv4 前缀,而当前 prefix overview 把它的 origin 指向 AS16045 BULINFO-HOSTING Spektar AD。这是一项明确的控制平面变化:同一地址块在两个观察时点由不同 ASN 发起。

变化本身没有携带商业解释。它不说明地址所有权,也不说明 Sovy Cloud Services 与 AS16045 BULINFO-HOSTING Spektar AD 之间是否存在供应、租赁、迁移、转售或终止关系。把新 origin 当作旧服务的继承者,或把它当作某种争议证据,都需要本文没有的额外材料。

与之并列的 IPv6 观察是 2a12:8fc6:4011::/48 当前未宣告。这两条后续状态并不相同:一个 IPv4 前缀仍在公共路由中但 origin 已变,一个 IPv6 前缀在当前视图中没有宣告。它们共同说明历史网络清单不能直接代表今天的 Sovy 路由表面,却不能被压缩成单一原因。

采购核验应把“品牌、主体、ASN、前缀、服务端点”重新逐项连接。若当前服务使用其他 ASN 或第三方网络,运营方应说明客户看到的地址如何对应合同主体、谁负责路由事件、谁能处理滥用与安全通知。若历史前缀已经退出服务,旧白名单、监控目标和灾备文档也应明确废止。

这一映射对事故处理尤其重要。遇到可达性或安全问题时,只知道旧品牌或旧 ASN,可能把通知发送给无法验证的域名联系人;只知道当前 IP,又可能找到与合同主体不同的 origin。一个可用的运营证明需要让客户从服务端点沿责任链找到当前网络运营者,再回到承担合同和事件责任的主体。

因此,origin 变化不是用来制造戏剧性结论的线索,而是提醒尽调人员重新做归属验证。BGP 可以告诉外界谁在当前路由视图中发起前缀,不能替合同、授权或服务文档解释“为什么”。把这条边界写清楚,反而能让可确认的网络事实发挥更大价值。

对“仍在运营”的主张,最低充分证据不止一个 active 字段

若 Sovy 品牌服务仍在运行,一份最低充分的当前证明至少需要闭合五个环节。第一是主体:提供服务、签署合同和承担责任的是谁,它与 Sovy Cloud Services、Sovy Cloud Services LLC、SCSL-51 之间是什么关系。ARIN 能锚定网络资源登记主体,却不能独自回答全部商业身份问题。

第二是控制入口:由该主体控制的当前域名、服务门户或 API 应能被验证。由于 sovy.cloud 在查询日可供注册并返回 NXDOMAIN,继续运营的主张需要另一个明确入口,或者说明何时、为何更换。仅展示旧网页截图或 PeeringDB 中的旧网站字段,不能建立当前控制。

第三是网络路径:客户实际使用哪个 ASN、哪些前缀或哪家第三方网络。若不再使用 AS401110,运营方可以说明新的路径和责任边界;若仍声称使用 AS401110,则应解释为何公开 RIPEstat 视图没有当前宣告、前缀或邻居。私人路径可以存在,但其存在需要面向相关客户的验证材料。

第四是服务交付:客户如何登录、监控、备份、导出和恢复。路由历史证明网络曾经可见,五处设施证明目录曾经记录关系,都不能替代一次当前控制台或服务端点验证。证明不必公开客户数据,却应让采购方确认自己购买的服务确实存在且可操作。

第五是问责联系:技术、滥用、安全、账单和合同通知由谁接收,最近一次验证是什么时候,品牌域名失效时备用渠道是什么。ARIN POC 的未验证备注和 PeeringDB 零公开 POC 让这一环节成为当前证据包不可缺少的部分。

五个环节不要求运营方公开敏感拓扑。主体文件可以受控提供,网络边界可以用不暴露设备细节的方式说明,服务交付可以通过客户自己的实例验证,联系人可以在双方事件手册中测试。最低充分证据的目标是闭合责任链,而不是把内部网络全部公开。

如果只补齐其中一项,评级也只能有限上调。一个新网站不能证明网络和服务;一条新 BGP 宣告不能证明品牌控制和客户支持;一封能收到的邮件不能证明设施与数据连续性。当前运营是多环节命题,因此需要多环节证据,而不是寻找另一个耐久字段替代 active

对“已经关闭”的主张,现有公开资料同样不足

谨慎必须是双向的。域名可供注册、DNS 返回 NXDOMAIN、公共 BGP 沉默、联系人验证变弱,足以质疑当前公开运营,却没有提供企业注销、合同终止、客户清零、资产撤离或所有私人服务停止的直接材料。本文也没有来自 Sovy Cloud Services 的状态声明。

五处 PeeringDB 设施关系没有得到当前确认,并不等于已经撤销。公共 POC 接口为空,并不等于运营方与设施、上游或客户之间没有私人联系。RIPE RIS 看不到邻居,也不能排除收集范围之外的私人连接。每一个“没有看到”都必须限定观察面。

法律主体、网络资源、品牌域名和服务产品还可能以不同速度变化。一个域名可以先于实体失效,一个 ASN 可以在不宣告前缀时继续保留,一个历史产品也可能通过第三方入口处理遗留客户。公开资料没有证明这些情形发生在 Sovy,也没有排除它们;它们只是说明为什么不能把单层信号升级成关闭判决。

要支持更强的关闭结论,需要与结论同等级的证据,例如主体的正式状态、运营方通知、合同处理安排、设施或上游确认,以及对客户入口的可复核观察。即使取得其中一项,也应说明它覆盖的是品牌、法律实体、网络还是具体服务,避免把局部终止扩大成全部活动结束。

因此,保留不确定性不是替运营方辩护,而是维护报告的可验证性。读者可以依据当前资料提高采购门槛、暂停依赖旧记录作决定,或要求补充证明;他们不需要先接受一个未经证实的关闭叙事,才能采取审慎行动。

采购评审应把证据有效期写进续约条件

许多供应商评审在签约时收集一次注册资料、网络图和联系人,此后只在事故发生时重新核对。Sovy 的记录分离说明,这种一次性方法会让真实但过期的材料长期占据决策位置。更稳健的做法,是为每类证明设定负责人、核验日期和下一次复核条件。

主体与合同资料可以按续约周期核对;域名控制、服务入口和事件联系应在变更后立即复核;ASN、前缀和 origin 可以在网络变更或异常告警时检查;设施声明则应在供应地域、灾备设计或数据位置影响采购决定时取得当期确认。不同证据不需要同一频率,但都不应没有有效期。

续约材料还应记录“什么变化会使旧证明失效”。品牌域名不可解析、服务端点更换、origin 改变、联系人无法完成验证、设施清单变化,都应触发重新建立映射。触发条件比笼统要求供应商“保持信息最新”更可执行,因为客户知道何时必须停止依赖旧截图。

对于 AS401110,采购方应保存查询日的 announced 状态、前缀数量、邻居观察和历史 origin;对于 sovy.cloud,应保存 RDAP 状态、DNS 结果和控制主体确认;对于五处设施,应保存逐项答复而不是只保留 PeeringDB 页面。这样,下一次变化可以被识别为状态迁移,而不是在不同时间的截图片段之间猜测。

证据有效期也应进入退出设计。如果服务入口或网络身份发生变化,客户能否继续导出数据、访问备份、取得账单和联系责任人,不应等到旧域名失效后才讨论。一次恢复演练或数据导出验证,比供应商在问卷中勾选“有灾备”更接近客户真正需要的连续性证明。

这套要求并非只针对 Sovy,也不意味着每家小型服务商都要承担大型云平台的披露负担。关键是让证明与风险成比例:依赖越集中、替代越困难、公开表面越薄,采购方越需要新鲜且可复核的材料。Sovy 的当前公开信号使这一门槛自然提高。

网络运营方与云客户需要从不同入口核验

网络运营方看到 AS401110 时,首先关心的是路由身份、当前 origin、可联系的技术与滥用责任人,以及是否存在可建立或排障的互联路径。ARIN、RIPEstat 和 PeeringDB 正好覆盖这些入口,但当前资料留下的是登记身份清楚、公共路径与公开联系薄弱的组合。

云客户的起点不同。客户更关心服务门户、实例可达性、数据导出、备份恢复、账单主体和故障通知。即使 AS401110 重新出现在公共路由中,也不能替代这些服务层检查;即使客户通过第三方网络正常访问,也不能自动解决旧资源记录和事件联系人是否准确的问题。

设施方或上游的关注点又有所不同。它们需要确认与哪个主体建立关系、哪个网络资源被使用、谁有权提出技术变更,以及发生滥用或路由异常时谁能响应。PeeringDB 的五处关系可以提供查找线索,却不能代替双方的现行授权与联系记录。

三类角色的交集是责任链。服务端点必须能找到负责的运营主体,运营主体必须能说明当前网络路径,网络路径发生事件时必须能找到有效联系人。只要其中一环依赖一个已不可解析且可重新注册的域名,或者仍指向不再可见的网络身份,事件处理就可能在最需要信息时失去方向。

因此,同一份尽调不应只问“公司在线吗”。对网络运营方,应问公共和私人路径如何被验证;对云客户,应问服务与数据如何连续;对设施方和上游,应问授权与联系人如何保持有效。答案可以不同,但最终必须指向同一主体和同一当前时间。

这种角色分解也能防止误用证据。客户不能拿五处 netfac 当作灾备证明,网络运营方不能拿一个能打开的门户当作 BGP 责任证明,设施条目也不能拿 ARIN 的登记地址当作现场设备证明。每条记录只有在回答它能够回答的问题时才有价值。

用状态迁移表代替“在线”或“离线”标签

Sovy 的公开记录至少包含四种状态迁移。网络身份从 2024 年的登记进入可见路由活动;部分历史前缀后来不再由 AS401110 出现在当前视图;其中一个 IPv4 前缀转为由另一 origin 宣告,而早期 IPv6 前缀当前未宣告;到 2026 年 7 月,品牌域名也呈现可注册和 NXDOMAIN 状态。

把这些变化放进表格时,每一行只需要记录对象、旧观察、新观察、时间、来源层和仍待回答的问题。AS401110 的 active 字段与“未宣告”可以同时为真,因为前者描述注册状态,后者描述路由状态。109.206.237.0/24 仍被宣告与“不再由 AS401110 发起”也可以同时为真,因为地址可见性和 origin 身份是两个字段。

状态迁移表不会自动解释原因,却能暴露哪些解释需要额外证据。例如,从“由 AS401110 发起”到“由 AS16045 BULINFO-HOSTING Spektar AD 发起”之间缺少商业关系说明;从“PeeringDB 列出网站”到“域名可注册”之间缺少运营方变更说明;从“五处设施关系”到“当前公共路由为零”之间缺少当期设施用途说明。

未来若出现新信号,也应追加而不是覆盖。域名重新注册要记录新控制主体是否可确认;AS401110 重新宣告要记录前缀、持续时间和邻接可见性;PeeringDB 更新要记录哪些字段变化;联系人重新验证则要记录验证日期。这样可以区分恢复、短时测试、第三方使用和单纯目录更新。

二元标签最大的问题,是它会让后来者不知道判断依据。写成“在线”,可能掩盖只有注册记录仍 active;写成“离线”,又可能越过私人服务的未知边界。状态迁移保留了每一层的真实变化,使采购者能在没有绝对判决时仍作出风险决定。

在当前表格中,最合理的落点仍是弱当前公开运营证明。这个评级不是永久属性,而是基于 2026 年 7 月 20 日可观察状态的结论。只要新的主体、入口、网络、服务和联系证据出现,它就可以按同一标准上调;若现有缺口持续扩大,也可以在不编造关闭原因的前提下下调。

现有证据允许怎样的结论

关于 Sovy Cloud Services,可以较有把握地说:它建立过真实的 ARIN 自治系统身份;AS401110 曾在公共 BGP 中发起多段 IPv4 和 IPv6 路由;PeeringDB 保留了一个全球 NSP 及五处设施的自述档案。也可以说:在 2026 年 7 月 20 日,品牌域名可供注册且返回 NXDOMAIN,RIPEstat 没有看到该 ASN 的当前宣告、前缀、邻居或 RIS 可见性,PeeringDB 也没有公开 IX LAN 或 POC 记录。

不能据此说 Sovy Cloud Services 已被证实关闭,不能说五处设施已经停用,不能说公司没有客户,也不能说所有支持或滥用邮箱必然失效。公共路由沉默更不能排除私人连接、私人客户、未公开服务或公共观察点没有覆盖的低可见度路径。

因此,最稳健的评级是:当前公开运营证明偏弱。身份与历史路由是真实的,目录足迹也值得保留;但它们没有与当前域名、当前路由、当前交换网连接或当前公开联系人闭合成一个可验证的 Sovy 品牌云服务表面。

这不是一篇关于消失公司的讣告,而是一种尽调方法。网络登记擅长保存过去建立的身份,互联目录擅长保存运营方曾经声明的范围,DNS 与 BGP 则提供带时间戳的当前观测。采购者只有把三者分开,再要求服务层证据补齐,才能避免让耐久的登记痕迹替代今天的运营证明。

来源

  1. https://rdap.arin.net/registry/autnum/401110
  2. https://rdap.arin.net/registry/entity/SCSL-51
  3. https://rdap.registry.cloud/rdap/domain/sovy.cloud
  4. https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS401110
  5. https://stat.ripe.net/data/as-overview/data.json?resource=AS401110
  6. https://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS401110
  7. https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS401110
  8. https://stat.ripe.net/data/prefix-overview/data.json?resource=109.206.237.0/24
  9. https://stat.ripe.net/data/prefix-overview/data.json?resource=2a12:8fc6:4011::/48
  10. https://stat.ripe.net/data/routing-history/data.json?resource=AS401110&starttime=2024-05-29T00:00:00&endtime=2026-07-20T08:00:00
  11. https://stat.ripe.net/data/routing-status/data.json?resource=AS401110
  12. https://www.peeringdb.com/api/net?asn=401110
  13. https://www.peeringdb.com/api/netfac?net_id=36371
  14. https://www.peeringdb.com/api/netixlan?net_id=36371
  15. https://www.peeringdb.com/api/org/38348
  16. https://www.peeringdb.com/api/poc?net_id=36371