Le banc d'essai 25 Gbps de TEAMFELNULL à Tokyo est visible; sa capacité hébergée ne l'est pas

Résumé

• Le fait d'infrastructure le plus clair de TEAMFELNULL est une connexion opérationnelle de 25 Gbps pour AS58790 à INIXP à Tokyo; il s'agit d'une capacité en bordure de réseau, pas d'une preuve de 25 Gbps de trafic client, d'inventaire de serveurs, de stockage ou de capacité cloud vendable.
• Quatre listings de centres de données à Tokyo rendent le banc d'essai physiquement plausible, mais ils n'établissent pas quatre racks indépendants, quatre déploiements alimentés, des domaines de panne séparés, ni aucun droit à la résilience annoncée par les opérateurs de centres de données sous-jacents.
• La surface de service publique est une communauté de serveurs de jeux, de projets logiciels et d'un bot Discord, tandis que les conditions commerciales, les garanties de support, les sauvegardes, les objectifs de restauration, les protections de facturation et l'exportation des données hébergées restent non documentés; les utilisateurs doivent traiter l'environnement comme un banc d'essai éducatif à moins que des preuves privées n'en montrent davantage.

Un port 25 Gbps, quatre noms de centres de données et un silence important

Le chiffre le plus fort associé à TEAMFELNULL est 25 Gbps. Il apparaît dans l'enregistrement PeeringDB actuel pourAS58790, où « SERVER-G TestBed TeamFelNull » est montré avec une connexion opérationnelle à Japan Community IX, ou INIXP. Lapage PeeringDB de l'échangerépète l'entrée 25 Gbps à côté d'AS58790, avec une adresse IPv4 et une adresse IPv6 d'échange. Unevue Internet Society Pulsede la même adhésion à l'échange caractérise le réseau comme éducatif ou de recherche et rapporte également un port 25 Gbps. Ces enregistrements sont inhabituellement concrets pour une empreinte publique aussi réduite.

Ils sont aussi faciles à mal interpréter. Une vitesse de port est le débit nominal d'une connexion d'échange. Ce n'est pas une mesure du trafic soutenu, d'un engagement client disponible, ou du débit des machines derrière le routeur. Cela ne dit rien sur le nombre de serveurs physiques installés, la quantité de stockage en bon état, la puissance rack réservée, ou si un hôte peut accepter une autre machine virtuelle. PeeringDB laisse explicitement non divulgués le niveau de trafic, le ratio de trafic et la portée géographique d'AS58790.

Il rapporte des faits sur les familles d'adresses et l'interconnexion, mais aucune charge vendue, courbe d'utilisation ou engagement de niveau de service.

Le même profil liste quatre centres de données, tous à Tokyo: AT TOKYO CC1/CC2, Equinix TY8, NTT DATA Otemachi Building et Otemachi Place West Tower. Cela crée une esquisse convaincante d'un réseau métropolitain. Pourtant, cela reste une esquisse. Un listing de centre de données dans une base de données d'interconnexion peut refléter un port physique, une interconnexion, un accès via un tiers, ou un service livré à distance. Il ne révèle pas, par lui-même, un serveur appartenant à TEAMFELNULL, un rack complet loué, un circuit électrique, ou une réplique de stockage à chaque endroit.

L'enregistrement ne publie pas d'identifiants de port, de quantités de racks, de consommation électrique, de contreparties de location ou de numéros de série de serveurs.

Cette distinction est au centre de l'histoire. TEAMFELNULL a suffisamment de preuves réseau visibles pour montrer qu'AS58790 n'est pas simplement un nom sur une page web abandonnée. Il n'a pas suffisamment de preuves opérationnelles publiques pour soutenir une lecture de fournisseur cloud conventionnel. Un client cloud achète la partie utilisable d'une chaîne: calcul, mémoire, stockage, alimentation, refroidissement, chemins réseau, matériel de remplacement, main-d'œuvre de support, continuité de facturation et un moyen de récupérer ou de migrer. Le chiffre de 25 Gbps ne décrit qu'un maillon de cette chaîne.

Le silence est donc plus important que le chiffre phare. Aucune page publique examinée pour ce profil ne donne un catalogue actuel de plans VPS, bare-metal ou d'hébergement géré sous le nom TEAMFELNULL. Aucune ne déclare une disponibilité garantie, un temps de réponse du support, un point de récupération, un temps de récupération, une politique de pièces de rechange, une limite de sauvegarde, un format d'exportation de données, un délai de préavis de maintenance ou une règle de compensation. Cette absence ne prouve pas que ces arrangements n'existent pas en privé.

Cela signifie qu'un utilisateur potentiel ne peut pas les déduire des preuves publiques et ne devrait pas traiter une étiquette de port d'échange comme un substitut.

Le nom décrit un banc d'essai, pas un fournisseur cloud conventionnel

L'identité publique d'AS58790 contient son étiquette d'avertissement la plus utile: « TestBed ». PeeringDB le classe comme un réseau éducatif/de recherche et le place sous l'organisation SERVER-G Group, avec TeamFelNull comme nom alternatif. Lapage d'accueil publique de TeamFelNulldécrit une communauté qui gère des serveurs Minecraft moddés saisonniers, joue à des jeux, développe des modifications et adapte des logiciels open-source. C'est un récit d'expérimentation et de plaisir partagés, pas un argumentaire de vente destiné aux entreprises déplaçant des charges de travail de production.

Le langage du groupe plus large renforce cette lecture. Lapage du groupe SERVER-Gdit qu'il fournit des environnements pour jouer, apprendre et développer sur le long terme. Il appelle AS63800 le réseau central et décrit TeamFelNull comme un groupe partenaire recevant des ressources réseau et serveur pour le développement, les opérations et le jeu. Cette formulation est importante car elle sépare au moins trois choses qui peuvent autrement se brouiller: le groupe parapluie, l'activité dorsale AS63800 et le banc d'essai TeamFelNull associé à AS58790. Les archives publiques montrent une affiliation et un support de ressources; elles ne divulguent pas de contrat transférant la propriété des racks, routeurs ou serveurs à TeamFelNull.

L'historique public d'AS63800de SERVER-G appelle la dorsale un réseau à but non lucratif construit pour apprendre la technologie Internet. Sa chronologie est franche sur l'expérimentation: obtenir des ressources d'adresses, trouver des fournisseurs d'accès, essayer des échanges communautaires, changer de connectivité et construire des outils de surveillance de routage. Lapage à propos du groupeindique que son lieu d'activité principal est Tokyo et énonce des objectifs incluant la connectivité, l'apprentissage, la construction et le développement technique. Ces pages concernent AS63800 et SERVER-G Group, pas un bilan comptable d'entreprise documenté séparément pour AS58790. Elles aident à expliquer l'environnement autour de TEAMFELNULL, mais elles ne prouvent pas que chaque actif ou politique d'AS63800 appartient au banc d'essai.

Cette frontière importe chaque fois que le mot « groupe » est pris pour une garantie légale ou opérationnelle. Le site public de TEAMFELNULL utilise « TeamFelNull » et « FelNull »; les enregistrements de routage utilisent « TeamFelNull », « SERVER-G Group » et « SERVER-G TestBed TeamFelNull ». Les conditions du bot décrivent FelNull comme une organisation. Aucune des pages examinées n'identifie un enregistrement conventionnel de société d'hébergement, un nom légal contractuel pour le service d'infrastructure, une adresse de facturation, ou la partie qui devrait des crédits de service à un client.

Il serait dangereux de déduire ces détails de la seule marque.

Même ladescription de la dorsalede SERVER-G trace une ligne entre l'activité communautaire et l'usage commercial limité. Elle dit que le réseau est dirigé par des étudiants et essentiellement à but non lucratif, cite des limites financières, et note que certains usages d'adresses aident à financer les activités et opérations. Elle dit aussi que ces adresses commerciales ne sont pas propagées ou utilisées depuis AS63800. C'est la preuve d'un contexte économique mixte, pas la preuve qu'AS58790 propose un produit d'hébergement commercial standard. Cela rend la clarification contractuelle plus nécessaire: qui facture, qui possède le matériel, quel réseau transporte le service, et qui reste responsable quand une partie tombe en panne?

Un banc d'essai peut être techniquement compétent et utile. Il peut fournir une connectivité réelle, héberger des services appréciés et enseigner aux opérateurs des leçons que les fournisseurs polis obscurcissent. Mais sa répartition des risques est différente. Le support informel peut être rapide quand des bénévoles sont disponibles et lent quand les études, le travail ou la vie interviennent. Le matériel peut être acheté de manière opportuniste. Les chemins réseau peuvent changer à mesure que les parrainages ou les relations communautaires évoluent. Les utilisateurs qui comprennent ce compromis peuvent le trouver tout à fait approprié.

Les utilisateurs qui supposent une continuité d'entreprise parce qu'ils ont vu « 25G » et quatre noms de centres de données achèteraient une promesse que le dossier public ne fait pas.

Ce que TeamFelNull met réellement à disposition des utilisateurs

Les services les plus visibles sont spécifiques et destinés à la communauté. Le site de TeamFelNull présente des serveurs Minecraft moddés saisonniers, du développement logiciel et de petits projets publics. Sapage de bot vocal Discordannonce plusieurs instances d'un bot de synthèse vocale, tandis que sapage Reversipropose une activité de jeu pour Discord. Ce sont de véritables surfaces utilisateur: les gens se connectent, soumettent du contenu, s'attendent à ce que l'état persiste pendant une certaine période et remarquent quand le service disparaît. Ils constituent une meilleure preuve d'un but opérationnel qu'une revendication générique de « cloud ».

Lesconditions d'utilisation et l'avis de confidentialitédu bot offrent un rare aperçu de la frontière des données. Ils disent que les identifiants d'utilisateur, de serveur et de canal peuvent être stockés pour maintenir le fonctionnement du service; les noms d'utilisateur, les pseudonymes et les messages peuvent être collectés pour générer de la parole et conservés uniquement pour la période nécessaire. L'avis promet des mesures de protection raisonnables mais décline toute sécurité complète, permet au service ou aux conditions de changer sans préavis, et décline toute responsabilité pour les dommages. Ces dispositions s'appliquent à ce bot, pas automatiquement à chaque service serveur ou réseau, mais elles révèlent le style du seul contrat utilisateur public trouvé ici: une large discrétion opérationnelle, une assurance limitée et aucun engagement de restauration quantifié.

Le côté logiciel est documenté plus complètement que le côté hébergement. Untutoriel du lanceur TeamFelNullexplique un lanceur de jeu personnalisé et décrit une analyse antivirus pendant son processus de construction. Lesite de documentation SERVER-Gse concentre sur ce lanceur, l'installation et la gestion des instances de jeu. Cela montre un groupe capable de produire des instructions pour les utilisateurs. Le contraste est révélateur: des conseils publics existent pour le logiciel client, tandis que les pages équivalentes pour le provisionnement de machines virtuelles, la durabilité du stockage, la sauvegarde de serveur, le traitement des abus, l'état des incidents et la résiliation de compte ne sont pas visibles.

Unlisting historique non officielde serveurs Minecraft japonais enregistre un « TeamFelNull-24h-Server », soumis en 2019, avec un temps de disponibilité enregistré très faible et un statut indiquant qu'il était hors ligne. Cette entrée ne peut pas établir l'état d'AS58790 en 2026. Elle peut décrire une machine, une adresse et une période d'exploitation différentes, et les sondes tierces peuvent échouer pour de nombreuses raisons. Elle n'est utile que comme signal de marché: le nom TeamFelNull a été attaché à un serveur de jeu public, et au moins un ancien point d'accès n'est pas resté continuellement accessible. Une surveillance actuelle, une archive d'incidents ou une déclaration de l'opérateur seraient nécessaires pour relier cette histoire au banc d'essai d'aujourd'hui.

Les services publics exposent également différents modèles de dépendance. Un serveur de jeu a besoin de calcul, mémoire, stockage, logiciel compatible avec la version et une route stable; un bot vocal dépend en plus de Discord et des moteurs de synthèse vocale en dehors du contrôle de TeamFelNull. Un lanceur peut rester utilisable sur l'ordinateur d'une personne même si le serveur communautaire disparaît, mais les téléchargements, les packs de mods ou les dépendances d'authentification peuvent ne pas le suivre. Regrouper tout cela sous « hébergement » cache qui contrôle quelle panne.

TEAMFELNULL peut exploiter l'application et certains serveurs tandis que SERVER-G ou une autre partie contrôle le routage, un centre de données contrôle l'alimentation, et les plateformes externes contrôlent l'identité et la distribution.

C'est pourquoi la « capacité orientée client » doit être interprétée étroitement ici. Il y a des preuves que des ressources sont mises à disposition des utilisateurs et des communautés partenaires. Il n'y a aucun décompte public de clients payants, d'instances actives, de serveurs gérés, de volumes de stockage ou de cœurs réservés. L'image opérationnelle correcte est un ensemble d'applications communautaires soutenues par un réseau éducatif, avec un pool non quantifié de ressources physiques et virtuelles. Toute affirmation plus forte nécessite un inventaire actuel et les contrats qui relient cet inventaire à l'identité réseau.

Où le système physique peut toucher Tokyo

La piste de centres de données d'AS58790 est entièrement métropolitaine. Les pages individuelles de centres de données de PeeringDB listent le banc d'essai àAT TOKYO CC1/CC2,Equinix TY8,NTT DATA Otemachi BuildingetOtemachi Place West Tower. Ces enregistrements corroborent les quatre noms sur le profil réseau, mais leur précision s'arrête à la présence. Ils ne montrent pas quel bâtiment dans une étiquette de campus combinée est utilisé, si la connexion est physique ou étendue à distance, ou si du calcul est installé à côté du port réseau.

Les centres de données sous-jacents sont substantiels. Lepropre compte d'AT TOKYOdit que CC1 a 140 000 mètres carrés de surface totale et décrit plusieurs alimentations électriques, onduleurs, générateurs de secours et une surveillance 24h/24 et 7j/7 dans ses installations. Laspécification d'Equinix TY8donne une adresse à Tokyo, 40 418 pieds carrés d'espace, une redondance d'alimentation N+1 et une redondance de refroidissement N+20 %. Letableau de couverture opérationnelled'Equinix indique que TY8 dispose d'une couverture sur site 24h/24 et 7j/7.

À Otemachi Place, ladescription du site New Otemachide BroadBand Tower annonce une puissance rack standard de 6 kVA, des lignes doubles de 200 volts 30 ampères, des générateurs N+1 capables de fonctionner jusqu'à 72 heures sans ravitaillement, de multiples options de connectivité et un support à distance. Sapage de services réseauséparée propose un support de conception et d'exploitation pour les routeurs, les réseaux de stockage et les connexions cloud. Ce sont des capacités d'opérateur de centre de données disponibles dans le bâtiment. Elles ne montrent pas que TEAMFELNULL achète un rack complet, deux circuits, des mains à distance ou un service particulier auprès de BroadBand Tower.

C'est la frontière de propriété en termes pratiques. L'opérateur du centre de données contrôle la coque du bâtiment, l'alimentation électrique, les générateurs, le système de refroidissement, le contrôle d'accès et les conditions dans lesquelles les techniciens accèdent à un rack. Un client de colocation ne contrôle que ce qu'il a contracté: peut-être une armoire, un rack fractionnaire, une interconnexion ou un port livré à distance. L'opérateur réseau contrôle sa configuration de routeur et ses annonces d'adresses. Le groupe d'applications contrôle les logiciels et l'état utilisateur dans la mesure où il y a accès.

La conception résiliente d'un centre de données ne peut pas compenser une seule alimentation dans un serveur client, une interconnexion impayée, un disque défaillant sans remplacement, ou une base de données applicative sans restauration testée.

La revendication géographique est donc à la fois plus forte et plus étroite que « global ». Les services peuvent être accessibles depuis le monde entier, et les routes Internet sont globales par nature. Les preuves physiques examinées ici pointent vers Tokyo, au Japon. Elles n'établissent pas de racks exploités par l'entreprise en Europe, Amérique du Nord, autres métropoles asiatiques ou même Osaka. Quatre noms tokyoïtes ne créent pas nécessairement une protection contre une catastrophe métropolitaine, une panne d'amont commune ou une seule erreur administrative.

La localité des données pour l'infrastructure visible doit être traitée comme centrée sur Tokyo jusqu'à ce qu'un registre d'actifs actuel prouve le contraire.

Pour les utilisateurs, cette localité a deux conséquences. Premièrement, la latence dépendra de la distance par rapport à Tokyo et du chemin d'accès amont choisi; le mot « global » ne peut pas effacer la physique. Deuxièmement, les arrangements régissant l'accès physique, l'alimentation et toute donnée stockée sont susceptibles d'être japonais dans la pratique, même si les utilisateurs distants se connectent depuis ailleurs. L'avis public du bot ne précise pas où sa base de données est hébergée, et les listes de centres de données ne lient pas une application particulière à un bâtiment particulier.

Un utilisateur qui a besoin d'une assurance de résidence aurait besoin de détails écrits sur le placement, la réplication et les sous-traitants plutôt qu'une ville déduite des enregistrements de routage.

Pourquoi quatre enregistrements de centres de données ne signifient pas quatre sites indépendants

La redondance commence par l'indépendance, pas par le comptage. Quatre noms de centres de données peuvent représenter quatre domaines de panne, mais ils peuvent aussi représenter un routeur atteint via plusieurs tissus d'interconnexion, un service étendu entre bâtiments, des interconnexions dormantes, ou des enregistrements maintenus pour un accès planifié. PeeringDB est une base de données industrielle précieuse, mais les entrées de réseau et de centres de données sont contribuées par les entités.

L'enregistrement AS58790 dit que ses informations sur les centres de données ont été mises à jour en février 2026, ce qui soutient la récence; il n'expose toujours pas les commandes de circuits sous-jacentes ou l'occupation des racks.

La géographie elle-même invite à la prudence. Deux listes sont à Otemachi, une est une étiquette de campus AT TOKYO couvrant CC1/CC2, et une est Equinix TY8 à Shinagawa. L'entrée PeeringDB d'Otemachi Place note une interconnexion optique vers NTT DATA Otemachi Building. Ce lien peut être utile opérationnellement, mais cela signifie aussi que deux noms dans une base de données peuvent être atteints via une extension physique plutôt que deux déploiements TEAMFELNULL alimentés séparément. Aucune route exacte ne doit être déduite de cette possibilité.

L'enregistrement établit une interconnexion disponible entre les bâtiments, pas le chemin ou la topologie d'AS58790.

La connexion INIXP ajoute une autre couche. L'échange est présent dans plusieurs centres de données à Tokyo et Osaka, mais le listing AS58790 ne publie pas d'emplacement de port sur son profil réseau. Une connexion d'échange 25 Gbps pourrait être livrée sur un site et transportée via un réseau partenaire ou un circuit métropolitain. Sans lettre d'autorisation, enregistrement d'interconnexion, diagramme au niveau des dispositifs et déclaration de diversité de circuit, le point de remise physique reste inconnu.

Les deux adresses d'échange prouvent une connexion logique; elles ne localisent pas le port de commutateur avec suffisamment de précision pour cartographier un câble.

Une véritable résilience de calcul multi-sites nécessiterait plus de preuves. Au minimum, un inventaire actuel montrerait des serveurs ou du stockage alimentés dans au moins deux sites; la réplication aurait une direction et un retard connus; le basculement DNS ou de routage aurait un déclencheur testé; les utilisateurs sauraient quels services peuvent redémarrer ailleurs; et la conception de récupération éviterait un plan de gestion partagé. Rien dans les pages publiques n'indique que les environnements Minecraft, les données du bot Discord ou les services de développement sont répliqués entre les centres de données.

Il est possible qu'ils le soient. Ce n'est pas démontré.

La même prudence s'applique à la diversité amont. Un routeur peut entendre plusieurs chemins alors que tout le trafic client dépend encore d'un fournisseur de transport, d'un point de terminaison de tunnel, d'une queue métropolitaine ou d'une autorité de configuration. L'historique public de SERVER-G décrit plusieurs relations au fil du temps et le retrait de certains échanges communautaires outre-mer en décembre 2024. Sa politique de peering autorise explicitement les tunnels GRE, SIT et WireGuard ainsi que les connexions aux échanges.

Les tunnels sont des outils légitimes pour un banc d'essai, mais un voisin BGP logiquement séparé sur le même circuit d'accès sous-jacent n'est pas une diversité physique.

Une déclaration de redondance rigoureuse identifierait la couche à laquelle l'indépendance existe. Des sessions BGP séparées protègent contre une panne de voisin seulement si un autre chemin utilisable reste. Des alimentations de centre de données séparées protègent un rack seulement si le serveur a des alimentations doubles connectées correctement. Des bâtiments séparés protègent les applications seulement si des données actuelles existent dans les deux et si les opérateurs peuvent rediriger les utilisateurs. Des contacts de support séparés protègent la récupération seulement si plus d'une personne a des identifiants et un accès physique.

Les preuves publiques de TEAMFELNULL ne confirment aucune de ces combinaisons de bout en bout, donc quatre étiquettes de centres de données doivent être lues comme une portée d'interconnexion, pas une continuité de service sur quatre sites.

Capacité: le seul chiffre concret est à la bordure de l'échange

La capacité n'est pas un seul chiffre. C'est une pile de limites, et la limite active la plus basse gouverne le service. Le port d'échange 25 Gbps est une capacité réseau logique installée à une interconnexion. PeeringDB étiquette la connexion comme opérationnelle, ce qui est plus fort qu'un plan futur. Mais le débit utilisable pourrait être inférieur en raison des limites de transfert du routeur, de la politique amont, de la congestion, du transport entre un rack et l'échange, de la taille des paquets, des attaques ou des goulots d'étranglement de l'application.

La capacité vendue pourrait être encore plus faible—ou inexistante si le banc d'essai ne vend pas de bande passante.

L'espace d'adressage est un autre type de capacité. PeeringDB liste cinq préfixes IPv4 et 50 préfixes IPv6 pour AS58790, tandis quel'aperçu AS de Cloudflare Radaridentifie le réseau au Japon et expose des vues de trafic lorsque des observations suffisantes existent. Unevue de routage Cloudflareséparée présente l'espace d'adressage annoncé, les connexions, le statut RPKI et l'activité BGP. Les comptages de préfixes décrivent la granularité du routage, pas les serveurs. Un /24 peut numéroter 256 adresses IPv4, mais une adresse peut être inutilisée, identifier un routeur, être attribuée virtuellement, ou servir de nombreux domaines derrière un seul hôte.

Les ensembles de données tiers illustrent pourquoi une date et une définition doivent accompagner chaque chiffre. Lapage AS58790 d'IPinfoliste actuellement deux blocs /24—44.30.37.0/24 et 44.30.62.0/24—ainsi que plusieurs amonts observés et une poignée d'adresses ayant répondu aux sondes. Unevue CIDR Reportmontre également deux annonces /24 et 512 adresses IPv4 originaires dans sa vue de collecteur. Ces observations soutiennent le routage IPv4 actuel, mais ni l'une ni l'autre ne nous dit combien de machines existent ou si une réponse provient d'un calcul client.

D'autres agrégateurs entrent en conflit. Unepage d'enregistrement miroirreproduit le nom AS JPNIC et une plage IPv6 2401:d20:1020::/44 mais ne signale aucune plage IPv4. Lapage AS d'IP2Locationmontre un /24 et un IPv6 /46, tandis que lapage d'IPGeolocationsignale zéro route malgré la reproduction de l'identité AS. Ce ne sont pas des instantanés équivalents; les dates de collecte, la visibilité des routes et les méthodes de classification diffèrent. La contradiction est une preuve des limites des données d'agrégateur, pas une raison de faire la moyenne des chiffres.

Aucune source publique examinée n'indique de cœurs CPU, mémoire, nœuds bare-metal, machines virtuelles, capacité disque, redondance de stockage, puissance réservée, consommation électrique moyenne ou unités de rack libres. Aucune source ne sépare la capacité de conception de la capacité installée, alimentée, opérationnelle et utilisable par le client. Les chiffres à l'échelle du centre de données ne peuvent pas combler le fossé. Les 40 418 pieds carrés d'Equinix à TY8 appartiennent au centre de données, pas à AS58790.

La spécification de rack standard de 6 kVA de BroadBand Tower est une caractéristique de produit disponible, pas une preuve d'un rack TEAMFELNULL ou d'un droit.

La capacité économiquement significative est celle qui peut survivre à une panne tout en honorant les engagements. Si un service a besoin de 16 cœurs et 64 Go de mémoire, un hôte de rechange ne compte que s'il est compatible, alimenté, connecté et non déjà réservé. Si le stockage est répliqué, la seconde copie ne compte que si elle est récente et récupérable indépendamment. Si 25 Gbps atteignent un échange mais que le serveur a une interface 1 Gbps, l'application ne dispose pas de 25 Gbps. Tant que TEAMFELNULL ne publie pas ou ne fournit pas privément ces chiffres de couche inférieure, sa capacité d'hébergement vendable reste inconnue.

L'histoire amont est réelle mais pas proprement documentée

AS58790 est visible comme origine, et plusieurs vues publiques voient des routes l'atteindre. C'est une preuve opérationnelle significative. IPinfo liste Hurricane Electric, SDCC Japan-West Area et SERVER-G Group comme amonts ou pairs, tandis que son traçage de sonde de juin 2026 vers 44.30.37.1 a traversé des réseaux japonais avant d'atteindre AS58790. La vue de collecteur CIDR Report a montré AS38074 directement adjacent à AS58790 pour les deux /24 visibles. La page de routage Cloudflare fournit un autre point de vue en direct.

Ensemble, ces sources soutiennent l'accessibilité, mais elles ne s'accordent pas sur un graphe de fournisseur stable.

Il y a plusieurs raisons bénignes. BGP est observé depuis des collecteurs particuliers à des moments particuliers. Une relation qui ressemble à un amont depuis un chemin peut être un pair, un chemin de route-server, ou un service transporté via un autre réseau. IPv4 et IPv6 peuvent utiliser différents fournisseurs. Une session peut être configurée mais inactive, sélective, ou visible seulement depuis certains endroits. L'enregistrement d'échange de PeeringDB montre la connexion INIXP, mais il marque AS58790 comme n'utilisant pas le route-server là-bas.

Cela signifie que la présence seule ne révèle pas quelles sessions bilatérales transportent réellement le trafic de production.

L'historique plus large de SERVER-G est informatif mais ne peut pas simplement être assigné à AS58790. Il enregistre les relations AS63800 avec Vultr, Hurricane Electric, SDCC et d'autres réseaux à différentes dates, ainsi que des retraits et ajouts ultérieurs. Lapolitique de peeringd'AS63800 exige des numéros AS globaux, des tailles de préfixe minimales, des ROA, des enregistrements IRR et des contacts PeeringDB; elle dit aussi qu'une certaine instabilité est tolérée parce que le réseau est expérimental. Ce sont des politiques déclarées pour AS63800. Elles suggèrent la culture entourant le banc d'essai, pas une promesse de disponibilité contraignante pour AS58790.

La question de propriété se situe à l'intérieur de la question de routage. PeeringDB place AS58790 sous SERVER-G Group et utilise felnull.dev comme site web. La page publique du groupe dit qu'AS63800 est le réseau central et fournit à TeamFelNull des ressources. Il est donc raisonnable de voir AS58790 comme un banc d'essai TeamFelNull soutenu par SERVER-G. Il n'est pas raisonnable de supposer que TeamFelNULL possède chaque contrat amont, chaque interconnexion ou les ressources d'adresses qu'il origines. Un client a besoin de savoir quelle partie peut renouveler, annuler ou reconfigurer chaque dépendance.

La diversité des routes a aussi une composante plan de contrôle. Si une personne, une configuration de routeur ou un ensemble d'identifiants contrôle chaque session, plusieurs amonts ne protègent pas contre un filtre de route erroné ou un retrait accidentel. Une fuite de route, une origine invalide, une autorisation de route expirée ou un filtre trop large peuvent rendre des serveurs sains inaccessibles.

Les vues publiques montrent que le routage existe; elles ne publient pas le contrôle des changements, l'accès hors bande, les sauvegardes de configuration, les routeurs doubles, le retour automatique ou un roulement d'opérations réseau 24 heures sur 24.

Ce qui réglerait la question est spécifique et modeste: des lettres ou factures actuelles établissant un transport et un transit actifs; une topologie montrant quelles connexions sont physiques, virtuelles ou tunnelisées; des preuves de collecteur pour les deux familles d'adresses; des enregistrements valides d'autorisation de route; et un test de basculement démontrant que le trafic reste utilisable lorsque le chemin principal est retiré. Jusque-là, la preuve amont mérite une confiance moyenne comme instantané et une confiance faible comme garantie de redondance.

Alimentation, matériel et mains sont la surface de contrôle cachée

Les enregistrements réseau ont tendance à dominer parce qu'ils sont publics. La plupart des pannes d'hébergement, cependant, sont résolues à une couche beaucoup moins visible: quelqu'un trouve l'alimentation, le disque, le module mémoire, l'optique, le ventilateur ou le câble défaillant et le remplace. TEAMFELNULL ne publie aucun inventaire matériel, politique de cycle de vie ou stock de pièces de rechange. Un port 25 Gbps peut rester parfaitement sain tandis qu'un seul serveur d'application est hors ligne faute d'un composant compatible.

La résilience du centre de données n'aide que jusqu'à la remise au client. AT TOKYO annonce plusieurs alimentations, onduleurs, générateurs et une surveillance 24 heures sur 24. Equinix annonce une alimentation N+1 à TY8 et une couverture opérationnelle 24h/24 et 7j/7. BroadBand Tower annonce des alimentations rack doubles, une génération N+1 et un support à distance à New Otemachi. Ces contrôles réduisent le risque au niveau du bâtiment pour les clients qui les achètent et les utilisent correctement.

Ils ne révèlent pas si l'équipement AS58790 a des alimentations doubles, si les deux alimentations sont sous contrat, si le support à distance est autorisé, ou à quelle vitesse TeamFelNull peut approuver des travaux.

La main-d'œuvre de support est elle-même une capacité. Lapage de contactde TeamFelNull dirige les demandes vers Discord. Cela peut être pratique pour une communauté, mais cela ne fournit pas d'échelle de gravité publique, d'engagement de temps de réponse, d'escalade téléphonique, de roulement de service nommé ou de canal alternatif si Discord est indisponible. Les pages de SERVER-G fournissent des chemins email ou Discord pour le peering, mais il n'y a pas de bureau d'incident public promettant spécifiquement la restauration des services hébergés. Quand une machine tombe en panne à 3h00, la différence entre « quelqu'un peut remarquer » et « un technicien autorisé doit répondre dans les 30 minutes » est le service.

La panne de stock matériel est particulièrement importante pour un petit banc d'essai. Les grands fournisseurs répartissent les pièces de rechange et le personnel sur de nombreux serveurs; un opérateur communautaire peut avoir des machines uniques achetées à différents moments. Sans liste de compatibilité et remplacements stockés, une carte mère défaillante peut transformer un échange de routine en approvisionnement, déplacement et reconstruction. Aucune preuve publique ne dit si les serveurs utilisent des disques de démarrage en miroir, du stockage à chaud, une gestion hors bande, des interfaces réseau doubles ou des images standardisées.

Il serait faux de supposer soit une conception d'entreprise robuste, soit un matériel improvisé.

Les contrats de facturation et de fournisseur peuvent créer la même panne sans équipement cassé. Un paiement de colocation en retard, une ressource parrainée expirée, un accord de transport annulé, un problème de renouvellement de domaine ou une liste d'accès au centre de données modifiée peuvent déconnecter un service sain. La déclaration de SERVER-G sur les limites financières rend cette dépendance digne d'examen, mais elle ne prouve aucune détresse actuelle. Les preuves nécessiteraient des contrats actuels, des dates de renouvellement, des parties responsables et un plan de réserve ou de succession.

En leur absence, la continuité financière est simplement inconnue.

Les utilisateurs sont affectés différemment. Un joueur peut perdre l'accès à un monde saisonnier; un développeur peut perdre un service de construction; une communauté Discord peut perdre la sortie vocale; un projet parrainé peut perdre une adresse ou une route. Le coût peut être un inconvénient plutôt qu'un revenu, mais la perte de données peut encore être personnelle et irréversible. Le bon standard de résilience devrait suivre l'usage promis.

Un monde de test peut tolérer des temps d'arrêt si les utilisateurs sont informés; une base de données collectant des identifiants ou un monde communautaire de longue durée a besoin de règles de sauvegarde, de rétention et de restauration même lorsque aucun argent ne change de mains.

La panne commence par l'ambiguïté avant d'atteindre le rack

Le premier chemin de panne n'est pas nécessairement technique. C'est l'ambiguïté sur ce qui a été promis. Si les utilisateurs entendent « ressources serveur » et voient des noms de centres de données, ils peuvent supposer des sauvegardes, des hôtes de rechange et une récupération gérée. Si les opérateurs entendent un accès au meilleur effort pour jouer et apprendre, les deux parties peuvent se comporter raisonnablement et encore entrer en collision après une panne.

La réduction de risque la plus rapide est une description de service simple qui dit ce qui est hébergé, qui l'exploite, ce qui est au meilleur effort, ce qui est sauvegardé et ce que les utilisateurs doivent copier eux-mêmes.

Au rack, la séquence est familière. Une alimentation ou une source d'alimentation tombe en panne; un port de commutateur, une optique ou une carte réseau chute; un disque ou un contrôleur corrompt l'état; la protection de refroidissement arrête le matériel; ou un travail planifié nécessite un redémarrage. La surveillance du centre de données peut identifier des alarmes environnementales, mais la récupération de l'application reste avec le client à moins que des services gérés aient été achetés.

Aucune des pages publiques ne lie TEAMFELNULL à un package de support à distance particulier, un magasin de pièces de rechange ou une fenêtre de maintenance.

À la couche réseau, un port d'échange, un circuit métropolitain, un point de terminaison de tunnel, une session amont ou une annonce de route peut échouer. Les quatre entrées de centres de données ne révèlent pas si ces éléments sont diversifiés. Un port INIXP 25 Gbps est un chemin utile, mais l'échange se décrit comme au meilleur effort sans conditions de service divulguées sur son listing public. Le peering bilatéral à un échange n'est pas la même chose qu'un transit Internet complet, et une connexion d'échange ne peut pas atteindre toutes les destinations sans pairs appropriés ou un amont.

Un service orienté utilisateur peut donc échouer pour certains réseaux tout en restant accessible depuis d'autres.

À la couche applicative, les mises à jour créent leurs propres fenêtres de réparation. TeamFelNull travaille avec Minecraft moddé et des lanceurs personnalisés, où les versions serveur et client doivent s'aligner. Une mise à jour échouée peut bloquer les utilisateurs même lorsque le routage et le matériel sont sains. La documentation du lanceur montre une attention à l'installation et à la migration, mais il n'y a pas de calendrier public pour la maintenance du serveur, le retour arrière, la compatibilité des bases de données ou la conservation des mondes plus anciens.

L'état de l'application est souvent la partie la plus difficile à reconstruire car une nouvelle machine ne peut pas recréer l'histoire perdue.

Les plateformes externes ajoutent des dépendances corrélées. Le bot vocal repose sur Discord pour l'identité, les événements et l'accès utilisateur, et il peut dépendre d'un ou plusieurs moteurs de synthèse vocale. Une panne ou un changement de politique à ces services peut rendre le bot indisponible sans aucun défaut dans AS58790. Le contact repose également sur Discord, donc le service et son canal de support public principal peuvent tomber ensemble. Une page de statut sur un domaine hébergé indépendamment, plus une escalade par email, séparerait ces chemins.

La population affectée n'est pas quantifiée. La page d'accueil invite une communauté; la page du bot montre plusieurs instances de bot; l'ancien listing de jeu enregistre un point d'accès public. Aucun ne donne d'utilisateurs actifs actuels, de sessions de pointe ou le nombre de projets dépendants. Cela empêche une estimation numérique de l'impact. L'impact qualitatif est clair: l'accès communautaire, les identifiants stockés, l'état du jeu, la distribution de logiciels et les ressources parrainées peuvent tous être interrompus. Un plan d'incident véridique nommerait ces classes sans revendiquer un nombre de clients qui n'a pas été divulgué.

La récupération et la portabilité s'arrêtent à la frontière de l'application

La récupération a deux questions distinctes: l'opérateur peut-il restaurer le service, et l'utilisateur peut-il partir? Le dossier public ne répond à aucune des deux pour le calcul hébergé. Il n'y a pas de fréquence de sauvegarde publiée, de période de rétention, de copie hors site, de test de restauration, de point de récupération ou de temps de récupération pour les serveurs TeamFelNull. Il n'y a pas non plus d'export documenté pour une machine virtuelle, une base de données, un monde de jeu, un enregistrement de compte ou un volume hébergé.

Un utilisateur ne peut pas dire si un disque défaillant signifie des minutes de retour arrière, des jours de reconstruction ou une perte permanente.

Il y a une exception étroite et utile du côté client. La documentation du lanceur fournit uneprocédure d'export d'instancequi crée un ZIP à partir de fichiers locaux sélectionnés, et unguide de migration du lanceurséparé explique comment copier des dossiers d'instance locaux entre versions. Ces instructions améliorent la portabilité pour l'environnement client d'un joueur. Elles n'exportent pas les mondes côté serveur, les bases de données de bot, les identifiants, le DNS, les adresses IP ou les machines virtuelles.

Cette frontière est facile à manquer. Un joueur peut préserver les mods et la configuration mais perdre quand même le monde partagé. Un administrateur de bot peut conserver une communauté Discord mais perdre les préférences stockées. Un développeur peut garder le code source mais perdre les artefacts de construction ou les secrets de déploiement. Un utilisateur réseau peut conserver une image d'application mais être incapable de conserver les adresses si les droits de ressource appartiennent à une autre partie. Chaque couche a besoin de sa propre méthode d'export et de restauration.

La récupération multi-sites est également non prouvée. La liste de centres de données offre des endroits plausibles à partir desquels la résilience pourrait être construite, mais aucune preuve publique ne mappe un service vers deux sites actifs ou ne rapporte un retard de réplication. Même si une deuxième machine existe, un basculement réussi nécessite des données actuelles, des secrets, du routage, du DNS, de la capacité et des personnes autorisées. Un spare à froid sans restauration testée peut prendre plus de temps que la réparation du primaire. Une réplique chaude partageant le même compte administratif peut échouer lors d'un compromis.

L'escalade de support devrait faire partie de la conception de récupération, pas une considération après coup. Le contact uniquement par Discord peut fonctionner pendant l'utilisation communautaire ordinaire, mais un événement grave nécessite un chemin indépendant, une personne responsable, une autorisation du centre de données et une règle de décision pour dépenser de l'argent en pièces ou en transport. La succession compte aussi: plus d'un opérateur de confiance devrait pouvoir renouveler les domaines, accéder aux routeurs, contacter les centres de données et décrypter les sauvegardes.

Aucune page publique n'établit cette couverture, donc cela reste une question plutôt qu'une accusation.

Le package de portabilité minimum crédible serait simple: une liste des données appartenant à l'utilisateur; les formats d'export; les limites de sauvegarde et de rétention; le moment de la suppression; un préavis avant la fermeture planifiée; une procédure pour obtenir la dernière copie; et un test montrant que la copie peut être restaurée ailleurs. Pour les services de jeu, cela peut être une archive du monde plus un manifeste de version. Pour un bot, cela peut être une exportation structurée des paramètres et une confirmation de suppression.

Pour un serveur virtuel, cela peut être une image disque standard et un enregistrement de configuration. Sans ces engagements, les utilisateurs devraient conserver leurs propres copies partout où c'est techniquement possible.

La localité des données est centrée sur Tokyo, mais les données d'application restent non cartographiées

Les preuves de routage et de centres de données pointent vers le Japon, en particulier Tokyo. AS58790 est enregistré avec une identité japonaise dans les ensembles de données de routage, les installations d'interconnexion listées sont à Tokyo, et les adresses IPv4 observées sont généralement géolocalisées au Japon. Cela soutient une évaluation physique centrée sur Tokyo. Cela ne prouve pas que chaque octet de données d'application reste à Tokyo, car les dépendances logicielles, les sauvegardes, la livraison de contenu et les services tiers peuvent traverser les frontières.

Le bot est l'exemple le plus clair. Ses conditions disent que des identifiants peuvent être stockés et des messages peuvent être traités pour la génération vocale, mais ils ne nomment pas un emplacement d'hébergement, un fournisseur de base de données, un fournisseur vocal ou une juridiction de sauvegarde. Discord lui-même est une plateforme externe. La présence de centre de données d'AS58790 ne peut pas répondre où Discord stocke les données ou où une demande vocale est traitée. Une revendication de résidence des données nécessiterait une documentation au niveau de l'application, pas simplement un code de pays de système autonome.

Les services de jeu et de développement ont une incertitude similaire. Un processus serveur peut s'exécuter sur une machine à Tokyo tandis que les téléchargements de mods proviennent d'une autre plateforme, le code source se trouve sur un dépôt global et les sauvegardes—si elles existent—se trouvent ailleurs. Inversement, une adresse originaire d'AS58790 pourrait atteindre un équipement livré à distance via un autre réseau. La géolocalisation IP est une estimation, pas une preuve d'un rack.

IPinfo met explicitement en garde que l'emplacement enregistré ou déduit ne correspond pas toujours à l'utilisation réelle, et le désaccord entre les agrégateurs de routage montre à quelle vitesse les classifications dérivent.

Cela importe même pour un service communautaire. Les utilisateurs peuvent se soucier de l'accès légal, de la suppression, de la réponse aux violations ou simplement de la latence d'une dépendance lointaine. L'avis de confidentialité public donne des catégories larges de données collectées et un concept de rétention nécessaire, mais pas une durée de rétention ou un emplacement fixes. Il permet également des modifications sans préavis. Ces conditions peuvent être proportionnées à un bot gratuit, mais elles ne répondent pas au besoin d'un acheteur en matière de souveraineté ou de localité contractuelle.

L'étiquette de zone de service « Global » doit donc être lue comme une portée, pas une empreinte. Un site web, un serveur de jeu ou un bot Discord peut servir des personnes internationalement depuis Tokyo. Cela ne fait pas de TEAMFELNULL un fournisseur multi-régions. Le dossier physique soutient un cluster métropolitain; le dossier applicatif ne cartographie pas les flux de données. Toute organisation ayant des exigences de résidence devrait demander une carte de données spécifique au service nommant l'hôte principal, les répliques, les sauvegardes, les processeurs externes et le chemin de suppression.

Il y a aussi un compromis de résilience. Garder toutes les copies à Tokyo peut simplifier la localité mais les exposer à une perturbation à l'échelle métropolitaine. Répliquer à l'étranger peut améliorer la reprise après sinistre mais changer la juridiction et la latence. Aucun choix n'est intrinsèquement correct. Le problème est que les preuves publiques actuelles ne révèlent pas le choix. Une réponse digne de confiance indiquerait où réside chaque copie, pourquoi, à quelle fréquence elle est mise à jour et qui peut la récupérer.

Ce que les clients devraient exiger—et le verdict de diligence raisonnable

La première demande devrait être un calendrier d'actifs et de services, pas une carte réseau brillante. Il devrait identifier la partie contractante, le service offert, si un paiement est impliqué, et la ressource exacte: cœurs, mémoire, stockage, espace d'adressage, bande passante et support. Il devrait distinguer les ressources dédiées des ressources partagées et indiquer quelles quantités sont installées, alimentées, opérationnelles, réservées et encore disponibles. Un port d'échange nominal de 25 Gbps appartient au calendrier, mais seulement comme composant d'interconnexion.

La deuxième demande devrait cartographier la responsabilité. Quelle organisation possède ou loue chaque serveur? Laquelle détient le compte de centre de données, le circuit de transport et l'accord amont? Qui contrôle les routeurs d'AS58790, le DNS, les identifiants d'application et la facturation? Quel centre de données peut accepter une demande de support de quelle personne nommée? L'affiliation SERVER-G et TeamFelNull est visible, mais les remises ne le sont pas. Un tableau de responsabilité d'une page supprimerait une grande partie de l'incertitude actuelle.

La troisième demande devrait être une topologie basée sur des preuves. Elle devrait montrer les centres de données avec une précision au niveau de la ville, éviter de révéler des détails sensibles sur les racks, et marquer différemment les circuits physiques, les circuits virtuels et les tunnels. Elle devrait identifier les queues métropolitaines partagées et les dépendances de gestion, ainsi que le site qui héberge chaque service critique. Un test de basculement devrait ensuite démontrer ce qui se passe lorsqu'un amont, un port d'échange, un routeur, un serveur ou un site est retiré. La seule présence marketing n'est pas un résultat de test.

La quatrième demande devrait couvrir l'alimentation et la réparation. Les utilisateurs ont besoin de savoir si les serveurs ont des alimentations doubles, si les deux alimentations du centre de données sont utilisées, si des pièces de rechange sont disponibles, et si un support à distance est sous contrat. Le document devrait inclure le préavis de maintenance, les niveaux de gravité, les objectifs de réponse et un canal d'escalade indépendant.

Le support au meilleur effort peut être acceptable s'il est clairement énoncé; le risque vient du fait de laisser les utilisateurs déduire une couverture d'entreprise des capacités des opérateurs de centres de données.

La cinquième demande devrait couvrir les données. Elle devrait indiquer la fréquence des sauvegardes, la rétention, le chiffrement, les tests de restauration, l'exportation utilisateur, la suppression et ce qui est exclu. Elle devrait nommer les plateformes externes et la localité des copies primaires et de sauvegarde. Pour les mondes de jeu de longue durée ou les bases de données communautaires, l'opérateur devrait fournir une exportation récente avant la fermeture planifiée.

Pour les services expérimentaux, la règle honnête la plus simple pourrait être « pas de sauvegarde; gardez votre propre copie », à condition que les utilisateurs puissent effectivement le faire.

Enfin, l'utilisateur devrait demander une preuve opérationnelle actuelle plutôt qu'un branding historique. Les éléments utiles incluent un historique de statut récent, des observations de route datées, une attestation d'inventaire, un avis d'incident type et un enregistrement de restauration réussi. Aucun n'a besoin de divulguer des secrets. Ensemble, ils montreraient que la capacité existe sous le port d'échange et que la récupération est plus qu'une intention. Si ces éléments ne sont pas disponibles, la classification rationnelle reste banc d'essai éducatif, et les charges de travail doivent être choisies en conséquence.

Le verdict: banc d'essai utile, plateforme d'hébergement non prouvée

TEAMFELNULL SERVER-G Group a plus de substance que sa faible empreinte d'entreprise ne le suggère initialement. AS58790 a une identité PeeringDB actuelle, une connexion opérationnelle 25 Gbps à INIXP, des mises à jour récentes de centres de données et des routes globalement visibles. TeamFelNull maintient des projets publics, des conditions d'utilisation et de la documentation. SERVER-G décrit un réseau éducatif continu et reconnaît ouvertement son caractère dirigé par des étudiants, principalement à but non lucratif et ses limites financières. Ce sont des signes d'activité, pas d'un enregistrement vide.

Les preuves restent insuffisantes au point où un service hébergé devient fiable. Quatre listes de centres de données ne prouvent pas quatre déploiements. Un port 25 Gbps ne prouve pas le débit du serveur ou la capacité de réserve. Les annonces d'adresses ne comptent pas les machines. La résilience du centre de données ne se transmet pas automatiquement à travers une conception de rack inconnue. De multiples amonts observés ne prouvent pas un transport physiquement diversifié. Les exportations de jeux côté client ne protègent pas les données côté serveur. Le contact Discord ne crée pas de garantie de réponse.

La note appropriée pour les preuves réseau est faible, pas négative. « Négative » ignorerait la connexion d'échange en direct, les routes et les services publics. « Moyenne » impliquerait que la chaîne opérationnelle est suffisamment décrite pour évaluer la capacité et la récupération. Ce n'est pas le cas. Les preuves les plus fortes se situent à la bordure logique; les plus faibles se situent là où les utilisateurs subissent des pertes: inventaire matériel, droit à l'alimentation, durabilité du stockage, main-d'œuvre de support, contrats, sauvegardes et migration.

Pour un usage de loisir, d'apprentissage et communautaire explicitement au meilleur effort, cela peut être un compromis parfaitement sensé. Les petits bancs d'essai créent un espace pour apprendre BGP, exécuter des jeux spécialisés et construire des outils sans l'économie d'un cloud commercial. Leur valeur ne doit pas être mesurée uniquement par la paperasse d'entreprise. La condition essentielle est le consentement éclairé: les utilisateurs doivent savoir que l'infrastructure expérimentale peut changer, que le support peut dépendre d'une petite équipe, et qu'ils ont besoin de leurs propres copies récupérables.

Pour des charges de travail payantes ou conséquentes, une vérification privée est nécessaire avant de s'appuyer. L'opérateur devrait montrer l'allocation de ressources, la contrepartie légale, les arrangements actifs de centre de données et d'amont, la conception multi-site ou de restauration, et les conditions de portabilité des données. Un acheteur devrait tester la récupération, pas seulement la connectivité. Si ces preuves existent, l'évaluation publique peut être améliorée.

Jusque-là, TEAMFELNULL est mieux compris comme un réseau éducatif centré sur Tokyo avec de vrais services communautaires et une bordure d'échange impressionnante—pas comme un cloud multi-sites documenté.

Cette conclusion respecte les deux côtés des preuves. Elle ne transforme pas l'absence de divulgation en une affirmation d'échec, et elle ne transforme pas un routeur bien connecté en un rack de calcul résilient. Le port 25 Gbps visible est le début de la question de capacité. Pour les utilisateurs de TEAMFELNULL, les faits décisifs restent derrière lui: quelles machines sont alimentées, quelles données peuvent être restaurées, quel chemin survit, et qui agira lorsque la fenêtre de réparation s'ouvrira.

La localité des données est centrée sur Tokyo, mais les données d'application restent non cartographiées.

Le routage et les preuves de centres de données pointent vers le Japon, surtout Tokyo. AS58790 est enregistré avec une identité japonaise, les installations listées sont à Tokyo, et les adresses IPv4 observées sont généralement géolocalisées au Japon. Cela soutient une évaluation physique centrée sur Tokyo. Cela ne prouve pas que chaque octet de données d'application reste à Tokyo.

Le bot est l'exemple le plus clair. Ses conditions disent que des identifiants peuvent être stockés et des messages traités, mais ne nomment pas d'emplacement d'hébergement, de fournisseur de base de données ou de juridiction. Discord est une plateforme externe. La présence de centre de données d'AS58790 ne peut déterminer où Discord stocke les données. Une revendication de résidence nécessite une documentation au niveau de l'application.

Les services de jeu ont une incertitude similaire. Un serveur peut s'exécuter à Tokyo tandis que les téléchargements de mods viennent d'ailleurs. La géolocalisation IP est une estimation. IPinfo prévient que l'emplacement déduit n'est pas toujours égal à l'utilisation réelle. Le désaccord entre agrégateurs montre des classifications changeantes.

Cela importe: les utilisateurs peuvent se soucier de l'accès légal ou de la latence. L'avis de confidentialité donne des catégories larges mais pas de durée ou d'emplacement fixes, et permet des changements sans préavis. Ces termes peuvent convenir à un bot gratuit mais ne fournissent pas de souveraineté contractuelle.

L'étiquette « Global » doit être lue comme portée, pas empreinte. Un site web peut servir internationalement depuis Tokyo sans faire de TEAMFELNULL un fournisseur multi-régions.

Il y a un compromis: garder toutes les copies à Tokyo simplifie la localité mais expose à une perturbation métropolitaine. Répliquer à l'étranger change juridiction et latence. Les preuves publiques ne révèlent pas le choix actuel.