摘要
- TEAMFELNULL 目前最清晰的基础设施事实是，在东京 INIXP 为 AS58790 运营一条 25 Gbps 的连接；这是网络边缘容量，并不能证明存在 25 Gbps 的客户流量、服务器库存、存储或可销售的云容量。
- 四个东京设施列表使测试平台在物理层面具有可信度，但这并未确立四个独立机架、四个通电部署、独立故障域，或底层数据中心运营商所宣传的任何弹性权利。
- 公共服务面包括游戏服务器社区、软件项目和一个 Discord 机器人，而商业条款、支持保证、备份、恢复目标、计费保护和托管数据导出仍然没有记录；用户应将此环境视为教育测试平台，除非有非公开证据证明更多。
一个 25 Gbps 端口、四个设施名称与一次重要沉默
与 TEAMFELNULL 相关的最强有力的数字是 25 Gbps。该数字出现在当前的AS58790 的 PeeringDB 记录中，其中显示“SERVER-G TestBed TeamFelNull”与 Japan Community IX（即 INIXP）有一条运营中的连接。该交换中心自身的 PeeringDB 页面在 AS58790 旁重复了 25 Gbps 条目，并附有一个 IPv4 和一个 IPv6 交换地址。Internet Society Pulse 对同一交换成员资格的视角将网络描述为教育或研究性质，同样报告了 25 Gbps 端口。这些记录对于如此小的公开足迹而言异常具体。
但它们也容易被误读。端口速度是交换连接的标称速率。它并非持续流量的测量值、可用客户承诺或路由器背后机器的吞吐量。它未说明安装了多少台物理服务器、多少存储处于健康状态、预留了多少机架电力，或任何主机是否可以接受另一台虚拟机。PeeringDB 明确未披露 AS58790 的流量水平、流量比率和地理范围。它报告了地址族和互联事实，但未报告已售负载、利用率曲线或服务水平承诺。
同一个网络档案列出了四个设施，全部位于东京：AT TOKYO CC1/CC2、Equinix TY8、NTT DATA Otemachi Building 和 Otemachi Place West Tower。这勾勒出一个令人信服的城市网络轮廓。然而，这仍然只是一个轮廓。互联数据库中的设施列表可能反映物理端口、交叉连接、通过另一方的接入或远程交付的服务。它本身并不能揭示 TEAMFELNULL 拥有的服务器、租用的完整机架、电源电路或存储副本。该记录未发布端口标识符、机架数量、功耗、租用对手方或服务器序列号。
这一区别是整个故事的核心。TEAMFELNULL 拥有足够的可见网络证据，表明 AS58790 并非仅仅是一个废弃网页上的名称。但它没有足够的公开运营证据来支持传统的云服务商解读。云客户购买的是链条中可用的部分：计算、内存、存储、电力、冷却、网络路径、替换硬件、支持劳动力、计费连续性以及恢复或迁移的方式。25 Gbps 这个数字仅描述了该链条中的一个环节。
因此，沉默比标题数字更为重要。本次档案审查中，没有公开页面列出 TEAMFELNULL 名下当前的 VPS、裸机或托管方案。没有页面说明有保证的正常运行时间、支持响应时间、恢复点、恢复时间、备件政策、备份边界、数据导出格式、维护通知期或补偿规则。这种缺失并不证明这些安排私下不存在。它意味着潜在用户无法从公开证据中推导出这些信息，不应将交换端口标签视为替代。
名称描述的是测试平台，而非传统云服务商
AS58790 的公共身份包含其最有用的警告标签：“TestBed”。PeeringDB 将其归类为教育/研究网络，并将其置于 SERVER-G Group 组织下，TeamFelNull 则为备用名称。公开的TeamFelNull 主页描述了一个运行季节性模组 Minecraft 服务器、玩游戏、开发修改和适配开源软件的社区。这是关于共同实验和享受的说明，而非面向企业生产工作负载的销售宣传。
更广泛群体自身的语言强化了这种解读。SERVER-G 群体页面表示其提供长期用于游戏、学习和开发的环境。它称 AS63800 为核心网络，并将 TeamFelNull 描述为接收网络和服务器资源用于开发、运营和游戏的合作伙伴群体。这种措辞很重要，因为它至少区分了三件原本可能模糊的事：母群体、AS63800 骨干活动以及与 AS58790 关联的 TeamFelNull 测试平台。公开记录显示了关联和资源支持；但它们并未披露将机架、路由器或服务器所有权转移给 TeamFelNull 的合同。
SERVER-G 的AS63800 公开历史称骨干网是一个为学习互联网技术而建立的非营利网络。其年表坦率地描述了实验：获取地址资源、寻找上游、尝试社区交换、更改连接以及构建路由监控工具。群体的关于页面称其主要活动地点是东京，并陈述了目的包括连接、学习、构建和技术开发。这些页面涉及 AS63800 和 SERVER-G Group，而非 AS58790 单独记录的企业资产负债表。它们有助于解释 TEAMFELNULL 周围的环境，但并不能证明每个 AS63800 资产或策略都属于该测试平台。
这个边界很重要，每当“群体”一词被误认为法律或运营承诺时。TEAMFELNULL 的公开网站使用“TeamFelNull”和“FelNull”；路由记录使用“TeamFelNull”、“SERVER-G Group”和“SERVER-G TestBed TeamFelNull”。机器人条款将 FelNull 描述为一个组织。所有经审查的页面均未指明治安规的企业注册信息、基础设施服务的合同法律名称、账单地址或应为客户服务积分负责的方。仅从品牌推断这些细节是不安全的。
即使是 SERVER-G 的骨干网描述也划清了社区活动与有限商业使用之间的界限。它表示网络由学生主导且基本为非营利性质，提到了财务限制，并指出某些地址的使用有助于资助活动与运营。它还说明这些商业地址不会从 AS63800 传播或使用。这是混合经济背景的证据，而非 AS58790 提供标准商业托管产品的证据。它使得合同层面的澄清更为必要：由谁开票、谁拥有硬件、谁的网络承载服务、以及当某一部分故障时谁仍负责？
测试平台可以在技术上胜任且有用。它可以提供真实的连接、托管有价值的服务，并让运营者学到精炼提供商掩盖的经验。但其风险分配是不同的。非正式支持在志愿者有空时可能很快，但在学习、工作或生活介入时可能很慢。硬件可能是机会性购买的。网络路径可能随着赞助或社区关系的变化而改变。理解这一交易的用户可能会发现完全合适。那些因为看到“25G”和四个设施名称而假设企业连续性的用户，将购买公开记录并未做出的承诺。
TeamFelNull 实际面向用户提供什么
最可见的服务是特定且面向社区的。TeamFelNull 的网站呈现季节性 Minecraft 模组服务器、软件开发和小型公共项目。其Discord 语音机器人页面宣传了多个文本转语音机器人实例，而其Reversi 页面则提供了一个 Discord 游戏活动。这些是真实的用户界面：人们连接、提交内容、期望状态持续一段时间，并在服务消失时注意到。它们比泛泛的“云”声明更好地证明了运营目的。
机器人的条款与隐私通知提供了数据边界的罕见视角。它们说明用户、服务器和频道标识符可能会被存储以保持服务运行；用户名、昵称和消息可能会被收集以生成语音，并仅在必要期间内保留。通知承诺合理的保护措施，但免除了完全安全性，允许服务或条款在未通知的情况下更改，并免除损害赔偿责任。这些条款适用于该机器人，而非自动适用于每项服务器或网络服务，但它们揭示了在此找到的唯一公共用户合同的风格：广泛的运营裁量权、有限的保证和无量化的恢复承诺。
软件方面比托管方面记录得更完整。TeamFelNull 启动器教程解释了自定义游戏启动器，并描述了其构建过程中的防病毒扫描。SERVER-G 文档站点侧重于该启动器、安装和游戏实例处理。这表明该群体能够为用户生成指南。对比令人深思：客户端工具存在公共指南，而虚拟机模板、存储耐久性、服务器备份、滥用处理、事件状态和账户终止的等效页面则不可见。
一个历史性、非官方的日本 Minecraft 服务器列表记录了一个“TeamFelNull-24h-Server”，提交于 2019 年，正常运行时间非常低，状态显示为关闭。该条目无法确定 AS58790 在 2026 年的状态。它可能描述了不同的机器、地址和运营时期，第三方探测可能因多种原因失败。它仅作为市场信号有用：TeamFelNull 名称与一个公共游戏服务器关联，至少一个旧端点未能持续可达。需要当前监控、事件档案或运营商声明才能将该历史与今天的测试平台联系起来。
公共服务器也暴露了不同的依赖模式。游戏服务器需要计算、内存、存储、版本兼容的软件和稳定路由；语音机器人额外依赖 Discord 和 TEAMFELNULL 控制之外的语音引擎。即使社区服务器消失，启动器在个人电脑上仍可继续使用，但下载、模组包或认证依赖可能不行。将所有这些归入“托管”掩盖了谁控制哪个故障。TEAMFELNULL 可能运营应用和某些服务器，而 SERVER-G 或其他方控制路由，设施控制电力，外部平台控制身份和分发。
这就是为什么“面向客户的容量”在此应狭义解释。有证据表明资源可供用户和合作伙伴社区使用。但不存在付费客户、活跃实例、托管服务器、存储卷或预留核心的公开计数。正确的运营图景是由教育网络支持的一组社区应用，具有未量化的物理和虚拟资源池。任何更强的表述都需要当前的清单以及将该清单连接到网络身份的合同。
物理系统可能触及东京的哪些位置
AS58790 的设施轨迹完全是都市级别的。PeeringDB 的个别设施页面列出了测试平台位于AT TOKYO CC1/CC2、Equinix TY8、NTT DATA Otemachi Building和Otemachi Place West Tower。这些记录证实了网络档案中的四个名称，但其精确性止步于存在。它们并未显示在合并校园标签中使用的是哪座建筑，连接是物理的还是远程延伸的，或者计算设备是否安装在网络端口旁边。
底层设施是庞大的。AT TOKYO 自身的说明表示 CC1 总建筑面积 140,000 平方米，并描述了多个电源馈线、UPS、应急发电和全天候监控。Equinix 的 TY8 规格提供了东京地址、40,418 平方英尺空间、N+1 电源冗余和 N+20% 冷却冗余。Equinix 的运营覆盖表称 TY8 拥有 24/7 现场覆盖。
在 Otemachi Place，BroadBand Tower 的新大手町站点描述宣传了标准 6 kVA 实际机架电源、双 200 伏 30 安培线路、可运行长达 72 小时无需加油的 N+1 发电机、多种连接选项和远程支持。其单独的网络服务页面提供路由器、存储网络和云连接的设计与运营支持。这些是设施运营商的可用能力。它们并未显示 TEAMFELNULL 从 BroadBand Tower 购买完整机架、两条电路、远程手或其他任何特定服务。
这是实际中的所有权边界。设施运营商控制建筑外壳、公共设施接入、发电机、冷却设备、门禁控制以及技术人员接触机架的条件。托管客户仅控制其合同约定的内容：可能是一个机柜、一个部分机架、交叉连接或远程交付的端口。网络运营商控制其路由器配置和地址通告。应用群体控制软件和用户状态，程度取决于其访问权限。设施的弹性设计无法补偿客户服务器中的单一电源、未支付的交叉连接、没有替换件的故障磁盘，或未经测试恢复的应用数据库。
因此，地理主张既更强大也更狭窄；全球？服务可以从世界各地访问，互联网路由本质上是全球性的。此处审查的物理证据指向日本东京。它并未建立公司在欧洲、北美、其他亚洲城市甚至大阪运营的机架。也不是四个东京名称必然提供应对都市级灾难、共同上游故障或单一管理错误的保护。可见基础设施的数据本地性应视为以东京为中心，除非当前资产登记册证明相反。
对用户而言，这种本地性有两个后果。首先，延迟将取决于到东京的距离和所选的上游路径；“全球”一词无法消除物理规律。其次，物理访问、电力以及任何存储的数据的治理安排在实际中很可能是日本的，即使远程用户从其他地方连接。公共机器人通知未说明其数据库托管在何处，设施列表也未将特定应用关联到特定建筑。需要书面放置、复制和分包商细节，而非从路由记录推断的城市，才能获得驻地保证。
为何四个设施记录不等于四个独立站点
冗余始于独立性，而非计数。四个设施名称可以代表四个故障域，但它们也可以代表通过多个互联织物到达的一台路由器、建筑之间延伸的一项服务、休眠的交叉连接，或为计划内访问维护的记录。PeeringDB 是一个有价值的行业数据库，但网络和设施条目由参与者贡献。AS58790 记录称其设施信息于 2026 年 2 月更新，这支持近期性；但它仍然未披露底层电路订单或机架占用情况。
地理本身也应引起谨慎。两个列表位于大手町，一个是涵盖 CC1/CC2 的 AT TOKYO 校园标签，另一个是品川的 Equinix TY8。大手町广场的 PeeringDB 条目注明了到 NTT DATA 大手町大楼的光纤互联。该链接在运营上可能有用，但这也意味着数据库中的两个名称可以通过一个物理延伸而非两个独立供电的 TEAMFELNULL 部署到达。不应从这种可能性推断出确切路由。该记录确立了建筑之间的可用互联，而非 AS58790 的路径或拓扑。
INIXP 连接增加了另一层。交换中心存在于多个东京和大阪设施中，但 AS58790 列表未在其网络档案中发布端口位置。25 Gbps 交换附件可以在一个站点交付，并通过合作伙伴网络或都市电路传输。没有授权书、交叉连接记录、设备级图表和电路多样性声明，物理交接点仍然未知。两个交换地址证明了逻辑附件；它们没有足够精确地定位交换机端口以映射电缆。
真正的多站点计算弹性需要更多证据。至少，当前清单会在至少两个站点显示通电服务器或存储；复制将具有已知方向和延迟；DNS 或路由故障转移将具有经过测试的触发器；用户将知道哪些服务可以在其他地方重启；恢复设计将避免共享管理平面。公开页面中没有任何内容说明 Minecraft 环境、Discord 机器人数据或开发服务在设施之间复制。它们可能是。但并未得到证明。
同样的谨慎适用于上游多样性。一台路由器可以听到多条路径，而所有客户流量仍然依赖一个传输提供商、一个隧道端点、一个都市尾纤或一个配置权限。SERVER-G 的公开历史描述了随时间变化的多种关系，以及 2024 年 12 月从某些海外社区交换中退出。其对等策略明确允许 GRE、SIT 和 WireGuard 隧道以及交换中心连接。隧道是测试平台的合法工具，但通过相同底层接入电路的逻辑分离 BGP 邻居并非物理多样性。
严格的冗余声明将识别独立性所在的层级。单独的 BGP 会话仅在另一条可用路径保留时才会防止邻居故障。单独的设施电源馈线仅在服务器正确连接双电源时才保护机架。单独的建筑仅当当前数据存在于两者中且运营者可以重定向用户时才保护应用。单独的支持联系人仅在多于一人拥有凭证和物理访问时才保护恢复。TEAMFELNULL 的公开证据未确认任何这些端到端组合，因此四个设施标签应解读为互联范围，而非四站点服务连续性。
容量：唯一硬数字在交换边缘
容量并非一个数字。它是一堆限制，最低的活动限制决定服务。25 Gbps 交换端口是在一个互联处安装的逻辑网络容量。PeeringDB 将该连接标记为运营中，这比未来计划更强。但可用吞吐量可能因路由器转发限制、上游策略、拥塞、机架与交换之间的传输、数据包大小、攻击或应用瓶颈而更低。已售容量可能更低——或根本不存在，如果测试平台不销售带宽。
地址空间是另一种容量。PeeringDB 为 AS58790 列出五个 IPv4 前缀和 50 个 IPv6 前缀，而Cloudflare Radar 的 AS 概览将该网络识别为位于日本，并在存在足够观测时展示流量视图。单独的Cloudflare 路由视图展示已通告地址空间、连接、RPKI 状态和 BGP 活动。前缀计数描述路由粒度，而非服务器。一个 /24 可以编号 256 个 IPv4 地址，但一个地址可能未被使用、标识路由器、被虚拟分配，或在一台主机后服务多个域。
第三方数据集说明了为什么每个数字必须附有日期和定义。IPinfo 的 AS58790 页面当前列出两个 /24 块——44.30.37.0/24 和 44.30.62.0/24——以及几个观察到的上游和少数响应探测的地址。CIDR Report 视图在其收集器视图中也显示两个 /24 通告和 512 个源 IPv4 地址。这些观测支持当前的 IPv4 路由，但两者都不能告诉我们存在多少台机器，或者响应是否来自客户计算。
其他聚合器存在冲突。镜像注册页面复制了 JPNIC AS 名称和 2401:d20:1020::/44 IPv6 范围，但未报告 IPv4 范围。IP2Location 的 AS 页面显示一个 /24 和一个 IPv6 /46，而IPGeolocation 的页面报告零条路由，尽管复制了 AS 身份。这些并非等效快照；收集日期、路由可见性和分类方法不同。矛盾是聚合器数据限制的证据，而非对数字进行平均的理由。
审查的公开来源中没有报告 CPU 核心、内存、裸机节点、虚拟机、磁盘容量、存储冗余、预留电力、平均功耗或空闲机架单元。没有来源将设计容量与已安装、通电、运营和客户可用容量区分开来。设施范围的数字无法填补空白。Equinix 在 TY8 的 40,418 平方英尺属于设施，而非 AS58790。BroadBand Tower 的标准 6 kVA 机架规格是可用产品特性，而非 TEAMFELNULL 机架或权利的证据。
经济上有意义的容量是能够在履行承诺的同时承受故障的容量。如果服务需要 16 核心和 64 GB 内存，备用主机仅在其兼容、通电、连接且未被预留时才计数。如果存储被复制，第二副本仅在其最近且可独立恢复时才计数。如果 25 Gbps 到达交换中心但服务器有 1 Gbps 接口，则应用没有 25 Gbps。除非 TEAMFELNULL 公开或私下提供这些更低层的数字，否则其可销售托管容量仍然未知。
上游故事真实但记录不清晰
AS58790 作为起源可见，多个公开视图看到路由到达它。这是有意义的运营证据。IPinfo 将 Hurricane Electric、SDCC Japan-West Area 和 SERVER-G Group 列为上游或对等体，而其 2026 年 6 月对 44.30.37.1 的探测路径在到达 AS58790 之前穿越了日本网络。CIDR Report 的收集器视图显示 AS38074 直接与 AS58790 相邻，对于两个可见的 /24。Cloudflare 的路由页面提供了另一个实时视角。共同地，这些来源支持可达性，但它们并不趋于一个稳定的提供商图谱。
存在几个良性原因。BGP 是在特定时间从特定收集器观察的。从一个路径看来的上游关系可能是对等体、路由服务器路径或通过另一个网络承载的服务。IPv4 和 IPv6 可能使用不同的提供商。会话可以已配置但空闲、有选择性，或仅从某些位置可见。PeeringDB 的交换记录显示了 INIXP 附件，但它标记 AS58790 未使用那里的路由服务器。这意味着仅存在本身并不能揭示哪些双边会话实际承载生产流量。
更广泛的 SERVER-G 历史提供了信息，但不能简单归因于 AS58790。它记录了与 Vultr、Hurricane Electric、SDCC 和其他网络在不同日期的 AS63800 关系，以及后来的退出和添加。AS63800 的对等策略要求全局 AS 编号、最小前缀大小、ROA、IRR 记录和 PeeringDB 联系人；它还说明由于网络是实验性质的，某些不稳定性是可容忍的。这些是针对 AS63800 的既定策略。它们暗示了测试平台周围的文化，而非 AS58790 的绑定正常运行时间承诺。
所有权问题位于路由问题内部。PeeringDB 将 AS58790 置于 SERVER-G Group 下，并使用 felnull.dev 作为其网站。公共群体页面称 AS63800 为核心网络，并向 TeamFelNull 提供资源。因此，将 AS58790 视为由 SERVER-G 支持的 TeamFelNull 测试平台是合理的。但不能合理假设 TeamFelNull 拥有每个上游合同、每个交叉连接或它起源的地址资源。客户需要知道哪个方可以续约、取消或重新配置每个依赖项。
路由多样性也有控制平面组件。如果一个人、一个路由器配置或一组凭证控制每个会话，多个上游不能防止错误的路由过滤器或意外撤回。路由泄露、无效起源、过期的路线授权或过于宽泛的过滤器可能使健康服务器不可达。公开视图显示路由存在；它们未发布变更控制、带外访问、配置备份、双路由器、自动回滚或 24 小时网络运营轮值。
能够解决该问题的是具体而适度的：当前的信件或发票证明活跃的中继和传输；显示哪些连接是物理的、虚拟的或隧道的拓扑；两个地址族的收集器证据；有效的路线授权记录；以及在撤回主要路径时流量保持可用的故障转移测试。在此之前，上游证据作为快照值得中等信任，作为冗余保证则信任水平低。
电力、硬件和人工是隐藏的控制面
网络记录往往占主导地位，因为它们是公开的。然而，大多数托管故障是在一个不那么可见的层面解决的：有人找到故障的电源、磁盘、内存模块、光模块、风扇或电缆并更换。TEAMFELNULL 不发布硬件清单、生命周期政策或备件库存。一个 25 Gbps 端口可以完全健康，而单个应用服务器因缺少一个兼容组件而离线。
设施弹性仅在客户交接点之前起作用。AT TOKYO 宣传多个电源馈线、UPS、发电机和 24 小时监控。Equinix 宣传 TY8 的 N+1 电源和全天候运营覆盖。BroadBand Tower 在 New Otemachi 宣传双机架电源馈线、N+1 发电和远程支持。这些控制措施降低了购买并正确使用它们的客户的建筑级风险。它们并未揭示 AS58790 设备是否具有双电源、是否合同规定双电源馈线、是否授权远程支持，或者 TeamFelNull 多快能批准工作。
支持劳动力本身就是容量。TeamFelNull 的联系页面将查询引导至 Discord。这对社区可能方便，但它不提供公开的严重性等级、响应时间承诺、电话升级、命名值班轮值或 Discord 不可用时的替代渠道。SERVER-G 的页面为对等提供了电子邮件或 Discord 路径，但不存在专门承诺托管服务恢复的公开事件台。当机器在凌晨 3 点故障时，“可能有人注意到”与“授权技术员必须在 30 分钟内响应”之间的区别就是服务。
硬件库存故障对于小型测试平台尤为重要。大型提供商将备件和人员分散在多台服务器上；社区运营商可能拥有在不同时间购买的独特机器。没有兼容性列表和库存替换件，故障主板可能将常规更换变成采购、旅行和重建过程。没有公开证据说明服务器是否使用镜像启动盘、热插拔存储、带外管理、双网络接口或标准化镜像。假设企业级健壮设计或临时硬件都是错误的。
计费和提供商合同可以在没有任何设备故障的情况下造成同样的中断。延迟的托管付款、过期的赞助资源、取消的传输协议、域名续费问题或更改的设施访问列表可能断开健康服务。SERVER-G 关于财务限制的声明使得这种依赖值得审视，但它并不证明任何当前困境。证据将需要当前合同、续约日期、负责方以及储备或继任计划。在其缺席的情况下，财务连续性仅仅是未知的。
用户受到不同的影响。玩家可能失去对季节性世界的访问；开发者可能失去构建服务；Discord 社区可能失去语音输出；赞助项目可能失去地址或路由。代价可能是不便而非收入，但数据丢失仍可能是个人的且不可逆。正确的弹性标准应遵循承诺的用途。测试世界可以容忍停机（如果用户被告知）；收集标识符的数据库或长期存在的社区世界需要备份、保留和恢复规则，即使没有金钱易手。
故障始于歧义，然后才到机架
第一条故障路径不一定是技术性的。它关于所承诺内容的歧义。如果用户听到“服务器资源”并看到数据中心名称，他们可能假设备份、备用主机和管理恢复。如果运营商意味着尽最大努力访问以进行游戏和学习，双方都可能合理行事，但在中断后仍然冲突。最快的风险降低是简单的服务描述，说明托管什么、谁运营、什么是尽最大努力、什么被备份以及用户必须自行复制什么。
在机架层，序列是熟悉的。电源馈线或电源故障；交换机端口、光模块或网卡故障；磁盘或控制器损坏状态；冷却保护关闭硬件；或计划内工作需要重启。设施监控可能识别环境警报，但应用恢复仍然由客户负责，除非购买了管理服务。公开页面中没有任何内容将 TEAMFELNULL 与特定的远程支持包、备件库或维护窗口关联起来。
在网络层，交换端口、都市电路、隧道端点、上游会话或路由公告可能失败。四个设施条目并未揭示这些元素是否多样化。25 Gbps INIXP 端口是一个有用的路径，但交换中心在其公开列表上将其描述为尽最大努力，没有披露服务条款。交换中心的双边对等不等同于完整的互联网传输，并且交换连接无法在没有合适对等体或上游的情况下到达每个目的地。因此，面向用户的服务可能对某些网络失败，同时从其他网络保持可达。
在应用层，更新创造了它们自己的修复窗口。TeamFelNull 使用模组 Minecraft 和定制启动器，其中服务器和客户端版本必须对齐。失败的更新可能即使路由和硬件健康也让用户陷入困境。启动器文档显示了对安装和迁移的关注，但没有服务器维护、回滚、数据库兼容性或旧世界保留的公开计划。应用状态通常是最难重建的部分，因为新机器无法重新创建丢失的历史。
外部平台增加了相关依赖。语音机器人依赖 Discord 进行身份、事件和用户访问，并且可能依赖一个或多个语音引擎。这些服务的中断或策略变化可能使机器人不可用，而 AS58790 没有任何故障。联系也依赖 Discord，因此服务及其主要公共支持渠道可能同时失败。在独立托管域上的状态页面，加上电子邮件升级，将分离这些路径。
受影响的人群未被量化。主页邀请社区；机器人页面显示多个机器人实例；旧游戏列表记录了一个公共端点。没有给出当前活跃用户、峰值会话或依赖项目的数量。这阻止了数值影响估计。定性影响是明确的：社区访问、存储的标识符、游戏状态、软件分发和赞助资源都可能被中断。一个真实的事件计划将命名这些类别，而不声称未披露的客户数量。
恢复和可移植性止于应用边界
恢复有两个不同的问题：运营商能否恢复服务，用户能否离开？公开记录对托管计算这两个问题都没有回答。没有已发布的备份频率、保留期、异地副本、恢复测试、恢复点或 TeamFelNull 服务器的恢复时间。也没有虚拟机、数据库、游戏世界、账户记录或托管卷的文档化导出。用户无法判断故障磁盘意味着几分钟的回滚、几天的重建还是永久性丢失。
在客户端存在一个狭窄、有用的例外。启动器文档提供了一个实例导出流程，从选定的本地文件创建 ZIP，以及单独的启动器迁移指南，解释如何在版本之间复制本地实例文件夹。这些说明提高了玩家客户端环境的可移植性。它们不导出服务器端世界、机器人数据库、凭证、DNS、IP 地址或虚拟机。
这个边界很容易被忽视。玩家可能保留模组和配置，但仍然失去共享世界。机器人管理员可能保留 Discord 社区，但仍然失去存储的偏好。开发者可能保留源代码，但失去构建工件或部署秘密。网络用户可能保留应用镜像，但如果资源权利属于另一方，则无法保留地址。每一层都需要自己的导出和恢复方法。
多站点恢复同样未经验证。设施列表提供了可能构建弹性的地点，但没有公开证据将服务映射到两个活动站点或报告复制延迟。即使存在第二台机器，成功的故障转移需要当前数据、秘密、路由、DNS、容量和执行个。没有经过测试的恢复的冷备件可能比修复主节点花费更长时间。共享同一管理账户的热副本可能在入侵期间失败。
支持升级应是恢复设计的一部分，而非事后考虑。仅限 Discord 的接触可能在普通社区使用期间有效，但严重事件需要独立路径、负责人、设施授权以及为零件或运输花费资金的决策规则。继任也很重要：多于一个可信操作员应能够续约域名、访问路由器、联系设施和解密备份。没有公开页面确立这种覆盖，因此它仍然是一个问题而非指控。
最低可信可移植包将是简单的：用户拥有数据的列表；导出格式；备份和保留边界；删除时间；计划关闭前的通知；获取最新副本的程序；以及表明副本可以在别处恢复的测试。对于游戏服务，这可能是世界归档加版本清单。对于机器人，可能是结构化设置导出和删除确认。对于虚拟服务器，可能是标准磁盘映像和配置记录。没有这些承诺，用户应在技术上可能的地方保留自己的副本。
数据本地性以东京为中心，但应用数据仍未被映射。
路由和设施证据指向日本，尤其是东京。AS58790 在路由数据集中注册为日本身份，列出的互联设施位于东京，观察到的 IPv4 地址通常地理位置定位到日本。这支持以东京为中心的物理评估。它并不证明每个应用数据字节都留在东京，因为软件依赖、备份、内容分发和第三方服务可能跨越边界。
机器人是最清晰的例子。其条款说明标识符可以被存储，消息可以被处理以生成语音，但它们没有命名托管位置、数据库提供商、语音提供商或备份管辖区。Discord 本身是一个外部平台。AS58790 的设施存在无法回答 Discord 将数据存储在哪里或语音请求在哪里被处理。数据驻留声明需要应用级文档，而不仅仅是自治系统国家代码。
游戏和开发服务具有类似的不确定性。服务器进程可能在东京机器上运行，而模组下载来自另一个平台，源代码位于全局存储库，备份（如果有）位于别处。相反，由 AS58790 起源的地址可能到达通过另一个网络远程交付的设备。IP 地理位置是估计，而非机架的证据。IPinfo 明确警告注册或推断的位置并不总是等于实际使用，而路由聚合器之间的不一致显示了分类漂移的速度。
即使对于社区服务，这一点也很重要。用户可能关心法律访问、删除、违规响应或仅仅是远方依赖的延迟。公共隐私通知给出了收集数据的广泛类别和必要保留的概念，但没有固定保留期限或位置。它还允许在没有事先通知的情况下更改。这些条款对于免费机器人可能相称，但它们不能满足买家对合同主权或本地性的需求。
因此，“全球”服务区域标签应解读为范围而非足迹。网站、游戏服务器或 Discord 机器人可以从东京为全球人员服务。这不会使 TEAMFELNULL 成为多区域提供商。物理记录支持一个都市集群；应用记录未映射数据流。任何具有驻留要求的组织应询问服务特定数据地图，命名主主机、副本、备份、外部处理器和删除路径。
还有一个弹性权衡。将所有副本留在东京可能简化本地性，但使其暴露于都市级中断。在海外复制可能改善灾难恢复，但改变管辖权和延迟。没有固有正确选择。问题在于当前公开证据未揭示选择。可信答案将说明每个副本位于何处、为什么、更新频率以及谁能检索。
客户应要求什么——以及尽职调查结论
第一个请求应是资产和服务计划，而非光鲜的网络地图。它应标识合同方、所提供服务的类型、是否涉及付款以及确切的资源：核心、内存、存储、地址空间、带宽和支持。它应区分专用和共享资源，并说明哪些数量是已安装、通电、运营、预留和仍然可用的。名义上的 25 Gbps 交换端口属于计划，但仅作为互联组件。
第二个请求应映射责任。哪个组织拥有或租赁每台服务器？哪个持有设施账户、传输电路和上游协议？谁控制 AS58790 的路由器、DNS、应用凭证和计费？哪个设施可以接受来自哪个具名人员的支持请求？SERVER-G 和 TeamFelNull 的关联是可见的，但交接点不是。一页责任表将消除当前大部分不确定性。
第三个请求应是证据支持的拓扑。它应以城市级精度显示设施，避免暴露敏感机架细节，并不同地标记物理电路、虚拟电路和隧道。它应标识共享的都市尾纤和管理依赖，以及承载每个关键服务的站点。然后应进行故障转移测试，展示当一个上游、交换端口、路由器、服务器或站点被移除时会发生什么。营销存在本身不是测试结果。
第四个请求应涵盖电力和维修。用户需要知道服务器是否具有双电源、是否使用两个设施馈线、现场是否有备件、以及是否合同规定了远程支持。文件应包括维护通知、严重性级别、响应目标和独立升级渠道。尽最大努力支持可以接受，如果明确说明；风险来自于让用户从设施运营商的能力推断企业覆盖。
第五个请求应涵盖数据。它应说明备份频率、保留、加密、恢复测试、用户导出、删除以及排除项。它应命名外部平台以及主副本和备份副本的本地性。对于长期存在的游戏世界或社区数据库，运营商应在计划关闭前提供最近的导出。对于实验性服务，最简单的诚实规则可能是“无备份；保留自己的副本”，前提是用户实际上可以这样做。
最后，用户应请求当前运营证明而非历史品牌。有用的项目包括近期状态历史、带日期的路由观察、清单证明、样本事件通知和成功的恢复记录。都不需要披露秘密。它们共同将表明容量存在于交换端口之下，并且恢复不仅仅是一种意图。如果这些项目不可用，合理的分类仍是教育测试平台，工作负载应相应选择。
结论：有用的测试平台，未经验证的托管平台。
TEAMFELNULL SERVER-G Group 比其稀疏的公司足迹最初暗示的更具实质性。AS58790 拥有当前的 PeeringDB 身份、运营中的 25 Gbps INIXP 附件、近期的设施更新和全球可见的路由。TeamFelNull 维护公共项目、用户条款和文档。SERVER-G 描述了一个持续的教育网络，并公开承认其由学生主导、基本非营利的性质和财务限制。这些是活动迹象，而非空注册。
证据仍然在托管服务变得可靠的点上存在不足。四个设施列表不能证明四个部署。25 Gbps 端口不能证明服务器吞吐量或备用容量。地址通告不能计数机器。设施弹性不会自动通过未知机架设计传递。多个观察到的上游不能证明物理多样化的传输。客户端游戏导出不能保护服务器端数据。Discord 联系不能创建响应保证。
适当的网络证据等级是弱，而非负面。“负面”将忽略实时交换连接、路由和公共服务。“中等”将意味着运营链已足够描述以评估容量和恢复。事实并非如此。最强的证据位于逻辑边缘；最弱的位于用户承担损失的地方：硬件库存、电力权利、存储耐久性、支持劳动力、合同、备份和迁移。
对于爱好、学习和明确尽最大努力的社区使用，这可能是一个完全合理的交易。小型测试平台为学习 BGP、运行特殊游戏和构建工具创造了空间，无需商业云的经济规律。其价值不应仅以企业文书来衡量。基本条件是知情同意：用户应知道实验性基础设施可能变化，支持可能依赖小型团队，并且他们需要自己的可恢复副本。
对于付费或重要工作负载，在依赖之前需要私有验证。运营商需要显示资源分配、法律对手方、活跃设施和上游安排、多站点或恢复设计以及数据可移植性条款。买家应测试恢复，而不仅仅是连接性。如果这些证明存在，则公开评估可以升级。在此之前，TEAMFELNULL 最好被理解为一个以东京为中心的教育网络，具有真实的社区服务和令人印象深刻的交换边缘——而非一个文档化的多站点云。
该结论尊重证据的双方。它不将缺失的披露转化为失败的声明，也不将连接良好的路由器转化为弹性计算机架。可见的 25 Gbps 端口是容量问题的起点。对于 TEAMFELNULL 的用户，决定性的事实仍然在它后面：哪些机器已通电，哪些数据可以恢复，哪条路径幸存，以及当修复窗口打开时谁会行动。