ZEROSPACE Christian Wittenberg 以 Zerospace Cloud 名义出售托管容量，但仍依赖机架、传输和维修窗口

摘要

• RIPE RDAP 将AS201801识别为 ZEROSPACE，并与在荷兰费尔德霍芬以 Zerospace Cloud 名义经营的 Christian Wittenberg 关联；RIPEstat 的AS 概览报告该 AS 于 2026 年 7 月 15 日宣布。
• 路由范围很小但可见：路由状态显示一个 IPv4 前缀、256 个 IPv4 地址、八个 IPv6 /48 和两个观察到的邻居，而宣布的前缀列出了 185.140.53.0/24 加上八个可见的 IPv6 /48。
• 源路由卫生是优势：RIPEstat 为185.140.53.0/24和2a07:1a84::/48返回了有效的 RPKI，其中 IPv6 验证依赖于 2a07:1a84::/44 上的 ROA 和最大长度 /48。
• 运营证据薄弱：PeeringDB列出了 Zerospace Cloud，但公共 IX 计数和设施计数均为零；geofeed将地址片段映射到十个城市标签，但这并未证明在这些城市有本地机架、电力、硬件、支持或客户迁移能力。

该公司拥有真实的网络身份，但该身份是新的

第一个值得从噪音中分离出来的事实是，Zerospace Cloud 不仅仅是一个营销术语。RIPE RDAP 在https://rdap.db.ripe.net/autnum/201801注册了 AS201801 为 ZEROSPACE，状态活跃，注册事件为 2026 年 1 月 30 日，最后更改事件为 2026 年 3 月 13 日。同一 RDAP 响应中的组织实体是 Christian Wittenberg，以 Zerospace Cloud 名义经营，公共地址标签为荷兰费尔德霍芬。RDAP 响应还将 Zerospace Cloud 网络运营命名为管理和技术联系人，将 Zerospace Cloud 滥用部门命名为滥用联系人。对于小型云或托管提供商来说，这是一个有用的基线：存在一个命名组织、一个命名网络和命名的运营联系人角色。

地址记录与 AS 身份匹配。RIPE RDAP 在https://rdap.db.ripe.net/ip/185.140.53.0/24将 185.140.53.0 到 185.140.53.255 识别为 ZEROSPACE-CLOUD，分配 PA，国家 NL，状态活跃，备注指向 http://download.zerospace.cloud/ipam/geofeed.csv 的 geofeed。RIPE RDAP 在https://rdap.db.ripe.net/ip/2a07:1a84::/44将 2a07:1a84::/44 识别为 ZEROCLOUD，由 LIR 聚合，国家 NL，状态活跃，具有相同的组织和相同的 geofeed 引用。RIPEstat 对https://stat.ripe.net/data/prefix-overview/data.json?resource=185.140.53.0/24的前缀概览将 AS201801 标识为 IPv4 /24 的源持有者。

这些记录并不证明一个成熟的托管资产。它们证明了一个活的路由持有者拥有实时注册资源。年龄很重要。自治系统和 IPv6 聚合于 2026 年 1 月下旬注册，IPv4 /24 于 2026 年 2 月注册。这足够新，客户应将公共运营证据视为仍在形成中。新的基础设施提供商可能很有能力；它们也可能处于路由、品牌、支持流程和物理供应商合同仍在加固的阶段。正确的问题不是 AS201801 是否存在。它存在。正确的问题是哪些客户服务可以安全地放置在其之上。

公共路由信号是活跃的。RIPEstat 在https://stat.ripe.net/data/as-overview/data.json?resource=AS201801的 AS 概览报告持有者为 ZEROSPACE Christian Wittenberg trading as Zerospace Cloud，并且该 AS 在 2026 年 7 月 15 日查询时被宣布。RIPEstat 在https://stat.ripe.net/data/routing-status/data.json?resource=AS201801的路由状态报告了广泛的公共可见性：326 个 IPv4 RIS 对等体中的 324 个和 322 个 IPv6 RIS 对等体中的 322 个看到了路由空间。这不是未使用注册的签名。它是一个小型网络对全球路由系统可见的签名。

对于基础设施买家来说，实时路由可见性是必要但不充分的。一个提供商可以在路由一个 /24 和几个 IPv6 /48 的同时，仍然依赖于租赁的虚拟服务器、经销商托管、单一的远程手供应商或少量上游。路由显示数据包可以找到宣布的前缀。它没有显示客户在驱动器故障后能否获得替换硬件，在时间压力下导出大型数据集，从存储故障中恢复，或者联系到有权力处理电力事件的人员。只有当前缀背后有机架、电力、冷却、硬件库存、访问程序、支持覆盖和退出路径时，托管容量才将路由可见性转化为服务。

路由资产很小，可见且广告不均匀

IPv4 图片紧凑。RIPEstat 的宣布前缀数据在https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS201801显示 185.140.53.0/24 在 2026 年 7 月 1 日至 7 月 15 日期间连续宣布。路由状态将其计为一个 IPv4 前缀和 256 个 IPv4 地址。对于托管或云服务，/24 在运营上可能有用，但它很小。它可以支持集中的任意播类服务、NAT 网关、客户管理端点、一组 VPS 节点或有限数量的直接分配客户地址。它本身并不是大型计算资产的证据。

IPv6 图片在地址数学上更为广阔，在当前可见性上更为细致。RDAP 记录覆盖 2a07:1a84::/44，包含十六个可能的 /48。PeeringDB 的网络对象在https://www.peeringdb.com/api/net?asn=201801列出配置文件中的一个 IPv4 前缀和十六个 IPv6 前缀。然而，RIPEstat 的宣布前缀端点在该回顾窗口期间显示了八个可见的 IPv6 /48：2a07:1a84::/48、:1::/48、:2::/48、:3::/48、:4::/48、:5::/48、:6::/48 和:9::/48。RIPEstat 的 AS 路由一致性视图在https://stat.ripe.net/data/as-routing-consistency/data.json?resource=AS201801添加了有用的细节：2a07:1a84::/44 在 whois 中但本身不在 BGP 中，而几个 /48 同时在 whois 和 BGP 中，其他几个 /48 在 whois 但不在 BGP 中。

这种差异对于已安装容量与可用容量很重要。已安装地址容量是注册的 IPv6 /44 和 PeeringDB 的十六个 IPv6 前缀声明。可用路由容量是在相关期间实际在 BGP 中可见的子集。客户可用容量更窄：客户可以签约、通过已知站点路由、用 RPKI 保护、监控、支持以及在提供商、设施或上游故障时迁移的前缀。一个 /44 可能在纸面上看起来很大，而只有选定的 /48 在公共路由中活跃，只有更小的子集与生产服务相关联。

IPv6 的时间也指向一个正在积极变化的网络。RIPEstat 显示 2a07:1a84::/48 和 2a07:1a84:5::/48 从 7 月初开始可见，:5::/48 在 7 月 3 日至 5 日之间出现短暂间隙。它显示其他几个 /48 从 2026 年 7 月 12 日开始可见。这并不证明在客户影响意义上的不稳定性；新的 IPv6 位置或服务节点经常分批上线。但它确实意味着客户应询问哪些 /48 被认为是生产、哪些是测试或分段分配、哪些与城市标签关联，以及哪些经过了故障转移测试。

源路由验证是 Zerospace 记录中较好的部分之一。RIPEstat 对 185.140.53.0/24 在https://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=185.140.53.0/24返回了有效状态，源 AS201801 和最大长度 /24。它对 2a07:1a84::/48 在https://stat.ripe.net/data/rpki-validation/data.json?resource=201801&prefix=2a07:1a84::/48返回了有效状态，验证了 2a07:1a84::/44 上的 ROA 和最大长度 /48。RPKI 并不能保持服务器运行，但它为路由过滤器提供了一种区分授权源公告和未授权公告的方式。对于一个新创建的小网络来说，这种卫生习惯很重要。

上游图片可见，但设施图片不可见

上游记录比设施记录更清晰。RIPEstat ASN 邻居在https://stat.ripe.net/data/asn-neighbours/data.json?resource=AS201801显示两个观察到的邻居：AS57758 和 AS63473。RIPEstat 的 AS 概览将 AS57758 标识为 CBWS Holding B.V.，将 AS63473 标识为 HostHatch, LLC。whois 视图在https://stat.ripe.net/data/whois/data.json?resource=AS201801也列出了 AS20473、AS63473 和 AS57758 的导入和导出策略条目，而公共邻居观察在检查时显示 AS57758 和 AS63473。AS20473 在 RIPEstat 的 AS 概览中是 The Constant Company, LLC，通常与 Vultr 关联。

这足以描述一个依赖表面，不足以证明多样性。两个观察到的邻居优于一个，如果它们实际上在客户的服务路径中是独立的，存在于不同的设施或故障域中，并且都为客户的前缀配置。但两个 ASN 仍可能共享相同的建筑、相同的会面室、相同的都市光纤、相同的电力事件或相同的远程维护窗口。公共 BGP 数据无法告诉我们 Zerospace 路由器是位于一个机架还是多个站点。它无法告诉我们两个邻居是否都携带所有生产前缀，故障转移是否自动，一个邻居是否仅为备份，或者客户控制平面是否依赖于相同的物理交接。

PeeringDB 加深了这种谨慎。Zerospace Cloud 网络记录在https://www.peeringdb.com/api/net?asn=201801列出 AS201801、网站 https://zerospace.cloud、IRR as-set AS201801:AS-ZEROSPACE-CLOUD、一个 IPv4 前缀、十六个 IPv6 前缀、policy_general Open、状态 ok、创建时间戳 2022 年 10 月和更新时间戳 2026 年 2 月 8 日。但 PeeringDB 的交换 LAN 端点https://www.peeringdb.com/api/netixlan?asn=201801返回了零公共 IX LAN 行，其设施端点https://www.peeringdb.com/api/netfac?net_id=31374返回了零公共设施行。PeeringDB 由运营商维护，可能不完整，因此空的设施列表并不是没有设施存在的证据。它是公共设施证据缺失的证据。

对于云买家来说，缺乏设施证据并非小事。设施是路由承诺变成运营承诺的地方。客户需要知道哪个数据中心托管服务器，哪个实体合同机架，哪个远程手团队可以接触硬件，是否有冗余电源馈线，机柜是否在合同电力限制内，冷却如何供应，以及哪些交叉连接到达哪个上游。没有公共设施列表或第一方设施声明，客户必须直接询问并合同验证。

这对 Zerospace 尤其如此，因为 geofeed 是全球性的，而可见的公共设施证据是为空的。Geofeed 对于内容本地化、欺诈控制、延迟路由和客户期望可能有用。它不能替代设施声明。提供商可能将小地址块定位到某个城市，因为那里有虚拟机、隧道端点、经销商节点、云实例或合作伙伴部署。这并不能证明拥有机架、备用服务器、备用光学器件、带外管理、电池续航时间、发电机覆盖或本地支持。

Geofeed 描述城市标签，而非保证的本地基础设施

https://download.zerospace.cloud/ipam/geofeed.csv的 geofeed 是 Zerospace 记录中最信息丰富的公共工件之一。它将 185.140.53.0/29 映射到阿姆斯特丹，185.140.53.8/29 到伦敦，185.140.53.16/29 到斯德哥尔摩，185.140.53.24/29 到首尔，185.140.53.32/29 到新加坡，185.140.53.40/29 到香港，185.140.53.48 到 185.140.53.55 中的选定 /32 到东京，185.140.53.56/29 到悉尼，185.140.53.64/29 到纽约，185.140.53.72/29 到洛杉矶。它将 IPv6 /48 映射到相同的城市模式：2a07:1a84::/48 到阿姆斯特丹，:1::/48 到伦敦，:2::/48 到斯德哥尔摩，:3::/48 到首尔，:4::/48 到新加坡，:5::/48 到香港，:6::/48 到东京，:7::/48 到悉尼，:8::/48 到纽约，:9::/48 到洛杉矶。

这是一个全球服务区域信号，而不是全球容量证明。在 IPv4 上，大多数城市条目是 /29，意味着每个八个地址。东京 IPv4 条目是单独的 /32 或非常小的分组，geofeed 并未用明确的命名城市覆盖 /24 中的每个地址。RIPEstat 对https://stat.ripe.net/data/geoloc/data.json?resource=185.140.53.0/24的地理位置和 MaxMind GeoLite 视图https://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=185.140.53.0/24反映了类似的分布，但也显示了 IPv4 /24 的很大一部分作为瑞典，在查询的视图中没有城市。这意味着公共地理位置图片是混合的：有些地址片段有精确的城市标签；大部分 IPv4 地址空间并未呈现为详细的逐个城市计算地图。

IPv6 位置视图也需要仔细阅读。RIPEstat 对https://stat.ripe.net/data/geoloc/data.json?resource=2a07:1a84::/44的地理位置和 MaxMind GeoLite 视图https://stat.ripe.net/data/maxmind-geo-lite/data.json?resource=2a07:1a84::/44显示 /44 分布在几个城市标签的 /48 之间，聚合的相当大一部分显示为瑞典且没有城市。Geofeed 列出:7::/48 用于悉尼，:8::/48 用于纽约，而宣布前缀端点在该回顾窗口期间并未将这些 /48 显示在八个可见前缀中。这未必是矛盾；geofeed 条目可以描述预期或注册的位置，而路由可见性随时间变化。它提醒我们，位置声明必须与当前路由状态相关联。

受此区别影响的客户不仅仅是那些城市的最终用户。一家小型云提供商可能服务于 VPN 网关、边缘节点、托管托管、开发者工作负载、备份目标、游戏基础设施、测试环境、小型企业服务或区域接入点。如果标记为阿姆斯特丹的片段故障，欧洲客户可能关心延迟和法律位置。如果香港或新加坡片段故障，亚太用户可能看到更高的延迟或故障转移到另一个区域。如果纽约或洛杉矶片段目前未路由，计划北美部署的客户需要知道该位置是活跃、保留、暂停还是待定。

因此，正确的尽职调查问题不是“我的城市在 geofeed 中吗？”而是“哪个物理或虚拟站点服务于我城市标签的地址，谁运营该站点，哪些上游承载它，背后有什么电力和硬件，以及如何恢复或迁移？”城市标签可以帮助客户决定问什么。它不应被用作 Zerospace 在所有十个城市拥有自有基础设施的证据。

网站和 DNS 记录揭示了另一项可用性依赖性

主站也需要与客户基础设施分开。RIPEstat 的 DNS 链端点https://stat.ripe.net/data/dns-chain/data.json?resource=zerospace.cloud显示 zerospace.cloud 使用 Cloudflare 权威名称服务器，ali.ns.cloudflare.com 和 rudy.ns.cloudflare.com，A 记录 172.67.142.47 和 104.21.87.70，AAAA 记录 2606:4700:3035::ac43:8e2f 和 2606:4700:3036::6815:5746，查询时间 2026 年 7 月 15 日。DNS 链端点https://stat.ripe.net/data/dns-chain/data.json?resource=download.zerospace.cloud显示下载主机的相同 Cloudflare 前端地址。端点https://stat.ripe.net/data/dns-chain/data.json?resource=www.zerospace.cloud返回 Cloudflare 权威名称服务器，但未提供 www.zerospace.cloud 的前向记录。

在 2026 年 7 月 15 日的直接 HTTPS 检查中，https://zerospace.cloud 未能在 15 秒的 curl 超时内返回可用页面。早期的 Cloudflare 前端检查可能暴露 522 样式的源可达性故障，当源未响应 Cloudflare 时。即使不依赖于任何单一的瞬态 HTTP 结果，DNS 证据也显示公共网站路径是 Cloudflare 中介的。这很常见，通常也合理。这也意味着网站的可用性与 AS201801 的路由可用性不同。

这里有两个独立的依赖性。首先，Zerospace 的营销或控制网络存在依赖于 Cloudflare DNS 和代理，加上 Cloudflare 背后的任何源服务。第二，Zerospace 的路由客户前缀依赖于 AS201801、其上游邻居和承载这些前缀的物理或虚拟位置。买家不应急于认为因为网站位于 Cloudflare 后面，客户流量也在 Cloudflare 后面。也不应急于认为因为 AS201801 在 BGP 中可见，客户门户、文档、状态通知或支持路径在网站源故障期间仍将可达。

下载主机很有趣，因为即使主站在检查期间不是可读的公共服务页面，它提供了 geofeed。这表明一些 Cloudflare 前端路径可能可达，而其他则不可达。对于客户运营，问题是关键门户、支持表格、控制面板、状态页面、geofeed 和 API 端点是否独立托管或共享相同的源依赖性。如果唯一的客户支持途径是脆弱源背后的网络表格，那么网络或源故障可能延迟恢复，即使 BGP 路由依然存在。

网站证据也减少了外部方可用的第一方服务细节量。许多提供商在其网站上发布设施页面、产品条款、服务级别目标、支持程序、数据导出条款、备份政策和法律文件。如果主站不可靠地可读，公共尽职调查不得不更依赖注册和路由证据。这对于网络身份文章已经足够。但对于自信的托管容量购买还不够。

物理依赖性大多隐藏在网络层后面

Zerospace 的公共记录提供了路由资源，但没有提供完整的物理图。PeeringDB 没有 AS201801 的公共设施行。在此审查中，主站没有可用的公共设施页面。没有发布的机柜列表、功率密度声明、冷却设计、远程手提供商、硬件库存政策、备份架构、状态页面或迁移指南在可用证据中。这并不意味着这些东西不存在。这意味着它们尚未公开证实。

客户的物理依赖栈仍然是具体的。如果 Zerospace 出售托管容量，某些服务器或虚拟实例必须位于某处。那个某处有机架或主机、电源馈线、冷却路径、管理网络、上游端口、存储依赖性和访问过程。如果磁盘故障，某人或自动程序必须替换或移动工作负载。如果路由器故障，第二条路径必须承载前缀。如果机柜断路器跳闸，必须有该机柜的计划。如果设施有维护窗口，提供商必须知道哪些客户服务暴露。如果城市标签的地址实际上是更大云区域中的虚拟端点，客户也应知道。

电力和冷却是 Zerospace 记录中最不可见的部分。一个 /24 和一个 /44 可以从很少的物理基础设施、租用的虚拟机、合作伙伴主机或少量托管服务器宣布。因此 IP 地址数量几乎没说明电源裕量。客户需要知道安装的功率分配、冗余后的可用功率、每机架的冷却密度、设施的 UPS 和发电机假设，以及单个高密度部署是否可能耗尽提供商当地裕量。没有该信息，买家无法区分城市边缘节点与弹性托管区域。

硬件库存同样不透明。提供商可以全局路由地址，但仍依赖有限的主机池。如果 Zerospace 提供 VPS 或托管服务，买家应询问每个位置背后有多少生产主机，存储是本地还是共享，故障如何疏散，同一位置是否有备用节点，以及是否需要从第三方主机订购替换容量。较小的 IPv4 分配使高效的地址使用成为可能；也意味着公共 IP 稀缺可能影响迁移和扩展计划。

支持仅在网络联系级别可见。RDAP 命名了网络运营和滥用角色，这对路由运营和滥用处理很重要。它没有显示客户支持时间、升级级别、事件响应目标、付费支持层级、语言、票务工具或紧急授权。购买基础设施容量的客户应将网络联系存在视为底线，而不是支持承诺。真正的恢复问题是当路由器会话中断、主机故障、城市端点消失或客户需要在短时间内疏散数据时，谁能采取行动。

故障路径：路由、上游、设施、支持和迁移

第一个故障路径是上游可达性。AS201801 在 RIPEstat 中有两个观察到的邻居，AS57758 和 AS63473，以及一个 whois 策略列表，也列出了 AS20473。如果 AS57758 或 AS63473 丢失会话，结果取决于两个邻居是否都承载受影响的前缀，流量工程是否对称到足以确保返回路径，以及故障是否隔离到单一上游。如果两个会话终止于同一站点或依赖于相同的本地交接，则冗余可能不如 AS 计数所示有用。客户应询问路由图，显示哪个上游承载每个生产前缀以及这些会话所在的位置。

第二个故障路径是路由授权或过滤。IPv4 /24 和 IPv6 /44-to-/48 模式的 RPKI 有效，这很好。但客户仍应询问 Zerospace 是否监视路由泄漏、无效公告、最大长度错误和地理位置漂移。有效的 ROA 可能在提供商后来宣布超出最大长度的更具体路由、上游意外过滤或添加特定城市的 /48 而未匹配路由授权时变得操作上痛苦。当前的 RPKI 状态是积极的控制；它不是变更控制的替代品。

第三个故障路径是设施损失或隐藏的设施集中。由于 PeeringDB 列出零公共设施行，客户无法独立判断多个城市是代表多个设施、单一上游覆盖层还是经销商资产。如果标记为阿姆斯特丹的地址和标记为伦敦的地址都依赖于一个提供商账户、一个计费关系、一个远程支持团队或一个隧道集中器，那么该提供商关系中的故障可能影响不止一个表观区域。多城市 geofeed 条目应针对独立的设施、供应商和路由证据进行验证。

第四个故障路径是控制和支持平面。主域的 Cloudflare 前端 DNS、空的 www 记录以及检查期间主站不可用都指出了了解客户在故障期间如何联系支持的重要性。如果客户门户、状态通知、文档和支持表格共享脆弱的源，提供商可能在网络问题仍在发展时失去通信。基础设施恢复依赖于联系路径和报文一样多。买家应要求带外事件联系，而不仅仅是网络表格。

第五个故障路径是迁移。新网络会变化。Zerospace 的 2026 年注册日期、2026 年 7 月的 IPv6 可见性变化和城市 geofeed 布局表明平台仍在扩展或调整。这可能很有希望，但它使退出权利和迁移路径变得必不可少。客户需要知道他们是否可以导出磁盘映像、快照、数据库转储、日志和 DNS 记录；他们是否可以在迁移期间保留 IPv4 地址；IPv6 /48 分配在 Zerospace 位置之间是否可移植；数据导出需要多长时间；以及如果位置退役或重新路由会发生什么。

已安装容量、可用容量和已购买容量是不同的东西

Zerospace 证据是云容量有三层的一个有用例子。已安装容量是提供商可以合理声称拥有或控制的内容：AS201801、185.140.53.0/24、2a07:1a84::/44、注册路由策略和 PeeringDB 配置文件。可用网络容量是在公共路由中出现且具有有效源授权的内容：一个 IPv4 /24、回顾窗口中的八个可见 IPv6 /48、两个观察到的邻居和广泛的 RIPE RIS 可见性。已购买容量是客户可以根据合同实际消费的内容，附带计算、存储、带宽、支持和迁移条款。

这些层之间的距离正是风险隐藏的地方。客户可能看到十个 geofeed 城市并假设十个生产区域。证据不支持该假设。客户可能看到 PeeringDB 中的十六个 IPv6 前缀并假设所有十六个都活跃。RIPEstat 在此窗口显示了八个可见的 /48，一些 whois 列出的 /48 未出现在 BGP 中。客户可能看到两个观察到的上游邻居并假设路由冗余。只有当两个邻居对于客户的前缀和故障域独立时，这才正确。客户可能看到有效的 RPKI 并假设运营弹性。RPKI 有助于路由真实性，而非服务器修复。

这并不意味着 Zerospace 不可用。它意味着它是一个应该以狭窄证据模型购买的提供商。需要小型路由服务、IPv6 实验室、边缘实验或非关键托管端点的开发者可能发现公共足迹足够，前提是商业条款与风险匹配。移动生产工作负载、客户数据、支付相关系统、健康数据或受监管记录的企业应要求比公共路由证据更多的东西。他们应要求设施细节、支持承诺、备份分离、客户退出条款以及证明所购买的城市或区域实际活跃的证据。

缺乏公共设施行也改变了如何考虑冗余证明。冗余不是城市名称的数量。它是两个故障不共享相同原因的证明。对于 Zerospace，该证明至少需要显示：上游独立性、设施独立性、电力独立性、存储或备份独立性、管理平面独立性和支持升级独立性。如果其中任何一个缺失，那么标记的第二个区域可能与第一个区域一起失败。

已安装与可用容量也影响价格。小型提供商可能因灵活、实惠和技术直接而具有吸引力。但低成本报价可能排除较大云买家假设的备件、员工时间、传输裕量或备份保留。客户应明确地为缺失的部分定价。如果工作负载需要快速恢复，客户应支付并测试该恢复。如果工作负载只需要一个公共端点且可以在别处重建，客户可以接受较轻的服务并保持自己的可移植性。

数据本地性通过 geofeed 声明，但法律和运营本地性仍开放

Geofeed 提供了一个数据本地性信号，但它不是数据主权合同。它告诉地理位置消费者 Zerospace 希望如何解释地址片段。它没有说明磁盘在哪里，备份在哪里，哪家公司运营主机，支持人员位于何处，哪个法律管辖服务，或者哪些分包商可以访问客户数据。这一区别对于欧洲、亚太和北美的客户至关重要，他们可能将阿姆斯特丹、伦敦、香港、东京或纽约解读为合规或延迟声明。

对于欧洲客户，荷兰组织记录和地址记录上的国家代码 NL 有用，但它们并不证明所有客户数据保留在荷兰或欧洲经济区。Geofeed 本身指向欧洲以外的几个片段。对于亚太客户，标签首尔、新加坡、香港、东京和悉尼可能对延迟有用，但客户仍需要知道数据是在本地处理、通过另一个国家代理、备份到别处还是由第三方托管供应商运营。对于美国客户，纽约和洛杉矶标签需要同样的问题。

最安全的解读是 Zerospace 已为地址块声明了网络本地性，而非数据驻留保证。客户应要求区域特定条款，命名托管供应商或设施类别，定义客户数据和备份位于何处，标识支持访问位置，并描述如何处理日志、快照和导出。如果服务只是网络覆盖或小型边缘存在，合同应明确说明。如果 Zerospace 有本地物理基础设施，合同应说明运营边界。

本地性还与故障响应相交织。如果香港标签的地址由香港的合作伙伴服务，修复路径可能依赖于该合作伙伴的支持队列。如果由全球云提供商的虚拟节点服务，修复可能依赖于该提供商账户和区域状态。如果通过来自另一位置的隧道服务，geofeed 标签可能对应用程序有用，但对物理独立性无用。这些模型中没有一个是自动错误的。重要的是披露。客户不能围绕城市名称设计弹性，除非知道城市名称实际上意味着什么。

如果服务故障谁受影响

受影响的用户取决于 Zerospace 实际销售什么。公共证据支持云或托管风格的网络身份，但没有在这里独立可读的产品目录。尽管如此，依赖性类别清楚。使用 Zerospace 用于托管端点、VPS 实例、边缘节点、VPN 网关、DNS 相关服务、小型企业站点或应用后端的客户将受到路由撤回、上游故障、服务器故障、存储损失、支持延迟或网站控制故障的影响。

区域最终用户将首先注意到 geofeed 层。如果意图用于阿姆斯特丹、伦敦或斯德哥尔摩的流量转移到更远的位置，延迟敏感的应用程序可能降级。如果首尔、新加坡、香港或东京片段不可用，亚太用户可能看到更长的路径或服务故障。如果纽约或洛杉矶片段在预期时未路由，北美用户可能得不到商业设计中承诺的本地性。因此 geofeed 地图即使在不证明容量时也创造了期望。

客户也会受到地址稀缺的影响。只有一个 IPv4 /24 可见，IPv4 分配是有限资源。如果客户需要更多公共 IPv4 地址、快速扩展或干净迁移到另一提供商，有限的 IPv4 池成为实际约束。IPv6 更丰富，但 IPv6 的采用仍取决于客户的用户、网络和应用程序。在 IPv6 上运行良好的服务可能仍需要 IPv4 用于客户、邮件、遗留系统或第三方集成。

最暴露的客户是将 Zerospace 视为完整云平台而不测试恢复的客户。如果服务用于非关键边缘实验，客户可以在别处重建。如果它持有主数据库、面向客户的生产服务或不可替代的备份，客户需要更强的证据。公共记录尚未显示足够理由将 AS201801 默认视为成熟的多区域平台。

什么会提高证据等级

Zerospace 可以通过发布带日期的基础设施声明迅速提高证据等级。最有用的公共声明应区分自有基础设施、租用的托管、虚拟化节点和合作伙伴位置。它将映射 geofeed 中每个城市到那里的部署类型，说明在该位置是否提供客户计算，说明 IPv4 和 IPv6 是否都是生产，并解释哪个上游承载每个前缀。它不需要透露敏感细节；它需要将营销地理学与运营依赖性分开。

下一个改进是设施和支持证明。PeeringDB 设施行、公共状态页面、客户支持页面、带外紧急联系人、备份和恢复策略以及迁移或数据导出指南将实质性地提高买家信心。小型提供商可以在不发布每个供应商名称的情况下变得可信，但它应显示客户在主机、路由、设施或账户故障时如何恢复。当前的公共记录严重偏向注册和 BGP 证据。

RPKI 应继续保持为优势。Zerospace 已经拥有审查的 IPv4 和 IPv6 路由的有效源授权。未来的公共证据应在新 /48 出现时保持该纪律。如果:7::/48 和:8::/48 要成为活跃的城市位置，路由可见性和验证应与 geofeed 对齐。如果某些 geofeed 条目是保留或计划的，提供商应说明，而不是让客户从地址位置文件中推断生产本地性。

如果 AS201801 失去广泛的路由可见性，如果 RPKI 变无效，如果 geofeed 继续宣传仍未路由的位置而不作解释，如果网站保持间歇性不可读而没有单独的支持路径，或者如果客户无法获得设施和恢复细节，证据等级将下降。如果提供商在销售多区域弹性的同时依赖于单一账户、单一设施、单一支持队列或单一上游故障域，证据等级也会下降。

依赖运营商的底线

Zerospace Cloud 有足够的公共证据被视为真实的已路由网络，但不足以被视为经过验证的全球托管平台。RIPE 记录将 AS201801、185.140.53.0/24 和 2a07:1a84::/44 与 Christian Wittenberg（以 Zerospace Cloud 名义）关联。RIPEstat 显示该 AS 已宣布，具有广泛的 IPv4 和 IPv6 可见性。RPKI 对审查的 IPv4 和 IPv6 源有效。PeeringDB 列出了 Zerospace Cloud 网络对象。Geofeed 足够详细和当前，以支持关于地理服务设计的严肃问题。

谨慎同样清楚。IPv4 资产是一个 /24。IPv6 可见性在回顾窗口中覆盖八个 /48，而不是 /44 和配置文件所暗示的每个 /48。PeeringDB 没有显示公共设施或 IX 行。主站在检查期间不是服务细节的可靠来源。Geofeed 映射城市，但不证明那些城市中的机架、电力、冷却、硬件、支持或迁移能力。当前上游图片显示两个观察到的邻居，但公共路由数据不证明独立的故障域。

因此，实际买家应仅凭所购买确切服务的明确证据使用 Zerospace。询问工作负载在哪里运行，谁运营设施或主机，哪个上游承载前缀，IPv4 和 IPv6 在请求的位置是否都活跃，如何处理电力和硬件故障，如何在网站故障期间联系支持，如何分离备份，以及如何导出数据。将 geofeed 视为声称的地址本地性地图，而不是保证的云区域地图。

对于非关键工作负载，公共记录可能足以证明测试。对于生产服务，缺失的证据太重要而不能忽视。托管容量总是解决回物理依赖性。在 Zerospace 的案例中，公共互联网可以看到路由；客户仍需要证明背后的机架、上游独立性、支持权限和迁移路径。