Testbed de 25 Gbps do TEAMFELNULL em Tóquio é visível; sua capacidade hospedada não é

Resumo

• O fato de infraestrutura mais claro do TEAMFELNULL atualmente é uma conexão operacional de 25 Gbps para AS58790 no INIXP em Tóquio; isso é capacidade de borda de rede, não prova de 25 Gbps de tráfego de clientes, inventário de servidores, armazenamento ou capacidade de nuvem comercializável.
• Quatro listagens de instalações em Tóquio tornam o testbed fisicamente plausível, mas não estabelecem quatro racks independentes, quatro implantações energizadas, domínios de falha separados ou qualquer direito à resiliência anunciada pelos operadores de data center subjacentes.
• A superfície de serviço pública é uma comunidade de servidores de jogos, projetos de software e um bot do Discord, enquanto termos comerciais, garantias de suporte, backups, metas de restauração, proteções de faturamento e exportação de dados hospedados permanecem não documentados; os usuários devem tratar o ambiente como um testbed educacional, a menos que evidências privadas provem o contrário.

Um porto de 25 Gbps, quatro nomes de instalações e um silêncio importante

O número mais forte associado ao TEAMFELNULL é 25 Gbps. Ele aparece no registro atual doPeeringDB para AS58790, onde "SERVER-G TestBed TeamFelNull" é mostrado com uma conexão operacional ao Japan Community IX, ou INIXP. Apágina do próprio exchange no PeeringDBrepete a entrada de 25 Gbps ao lado de AS58790, com um endereço IPv4 e um IPv6 de exchange. Umavisão do Internet Society Pulse da mesma associação ao exchangecaracteriza a rede como educacional ou de pesquisa e também relata um porto de 25 Gbps. Esses registros são incomumente concretos para uma pegada pública tão pequena.

Também são fáceis de interpretar mal. A velocidade de um porto é a taxa nominal de uma conexão de exchange. Não é uma medição de tráfego sustentado, um compromisso disponível ao cliente ou a taxa de transferência das máquinas atrás do roteador. Não diz nada sobre quantos servidores físicos estão instalados, quanto armazenamento está saudável, quanta energia de rack foi reservada ou se algum host pode aceitar outra máquina virtual. O PeeringDB deixa explicitamente não divulgados o nível de tráfego, a proporção de tráfego e o escopo geográfico de AS58790.

Ele relata fatos de família de endereços e interconexão, mas nenhuma carga vendida, curva de utilização ou compromisso de nível de serviço.

O mesmo perfil lista quatro instalações, todas em Tóquio: AT TOKYO CC1/CC2, Equinix TY8, NTT DATA Otemachi Building e Otemachi Place West Tower. Isso cria um contorno convincente de uma rede metropolitana. No entanto, ainda é um contorno. Uma listagem de instalação em um banco de dados de interconexão pode refletir um porto físico, uma interligação, acesso por meio de terceiros ou um serviço entregue remotamente. Não revela, por si só, um servidor de propriedade do TEAMFELNULL, um rack completo alugado, um circuito de energia, uma réplica de armazenamento em cada lugar.

O registro não publica identificadores de porto, quantidades de rack, consumo de energia, contrapartes de locação ou números de série de servidores.

Essa distinção é o centro da história. O TEAMFELNULL tem evidências de rede visíveis suficientes para mostrar que AS58790 não é apenas um nome em uma página da web abandonada. Não tem evidências operacionais públicas suficientes para apoiar uma leitura convencional de provedor de nuvem. Um cliente de nuvem compra a parte utilizável de uma cadeia: computação, memória, armazenamento, energia, resfriamento, caminhos de rede, hardware de reposição, mão de obra de suporte, continuidade de faturamento e uma maneira de recuperar ou migrar. O número de 25 Gbps descreve apenas um elo nessa cadeia.

O silêncio é, portanto, mais importante que o número destacado. Nenhuma página pública revisada para este perfil fornece um catálogo atual de planos de VPS, bare-metal ou hospedagem gerenciada sob o nome TEAMFELNULL. Nenhuma declara um tempo de atividade garantido, tempo de resposta do suporte, ponto de recuperação, tempo de recuperação, política de peças de reposição, limite de backup, formato de exportação de dados, período de aviso de manutenção ou regra de compensação. Essa ausência não prova que esses arranjos não existam privadamente.

Significa que um usuário em potencial não pode derivá-los das evidências públicas e não deve tratar um rótulo de porto de exchange como substituto.

O nome descreve um testbed, não um fornecedor de nuvem convencional

A identidade pública de AS58790 contém seu rótulo de aviso mais útil: "TestBed." O PeeringDB classifica como rede educacional/de pesquisa e o coloca sob a organização SERVER-G Group, com TeamFelNull como nome alternativo. Apágina inicial pública do TeamFelNulldescreve uma comunidade que executa servidores sazonais de Minecraft modificados, joga, desenvolve modificações e adapta software de código aberto. É um relato de experimentação e diversão compartilhadas, não um discurso de vendas voltado para empresas que movimentam cargas de trabalho de produção.

A linguagem do grupo mais amplo reforça essa leitura. Apágina do grupo SERVER-Gdiz que fornece ambientes para jogar, aprender e desenvolver a longo prazo. Chama AS63800 de rede principal e descreve TeamFelNull como um grupo parceiro que recebe recursos de rede e servidor para desenvolvimento, operações e jogo. Essa redação é importante porque separa pelo menos três coisas que podem se confundir: o grupo guarda-chuva, a atividade do backbone AS63800 e o testbed TeamFelNull associado a AS58790. Registros públicos mostram afiliação e suporte de recursos; não revelam um contrato que transfira a propriedade de racks, roteadores ou servidores para o TeamFelNull.

Ahistória pública de AS63800do SERVER-G chama o backbone de uma rede sem fins lucrativos construída para aprender tecnologia de internet. Sua cronologia é franca sobre experimentação: obtenção de recursos de endereço, encontrar upstreams, tentar exchanges comunitários, mudar conectividade e construir ferramentas de monitoramento de rotas. Apágina sobre o grupodiz que sua principal localização de atividade é Tóquio e declara propósitos incluindo conectividade, aprendizado, construção e desenvolvimento técnico. Essas páginas dizem respeito a AS63800 e SERVER-G Group, não a um balanço corporativo documentado separadamente para AS58790. Elas ajudam a explicar o ambiente em torno do TEAMFELNULL, mas não provam que todos os ativos ou políticas de AS63800 pertencem ao testbed.

Esse limite é importante sempre que a palavra "grupo" é confundida com uma garantia legal ou operacional. O site público do TEAMFELNULL usa "TeamFelNull" e "FelNull"; registros de roteamento usam "TeamFelNull," "SERVER-G Group" e "SERVER-G TestBed TeamFelNull." Os termos do bot descrevem FelNull como uma organização. Nenhuma das páginas revisadas identifica um registro de empresa de hospedagem convencional, um nome legal contratante para serviço de infraestrutura, um endereço de faturamento ou a parte que deveria créditos de serviço a um cliente. Seria inseguro inferir esses detalhes apenas da marca.

Até adescrição do backbonedo SERVER-G traça uma linha entre a atividade comunitária e o uso comercial limitado. Diz que a rede é liderada por estudantes e basicamente sem fins lucrativos, cita limites financeiros e observa que algum uso de endereço ajuda a financiar atividades e operações. Também diz que esses endereços comerciais não são propagados ou usados a partir de AS63800. Isso é evidência de um contexto econômico misto, não evidência de que AS58790 oferece um produto de hospedagem comercial padrão. Torna o esclarecimento em nível de contrato mais necessário: quem fatura, quem possui o hardware, de quem é a rede que carrega o serviço e quem permanece responsável quando uma parte falha?

Um testbed pode ser tecnicamente competente e útil. Pode fornecer conectividade real, hospedar serviços valiosos e ensinar lições que provedores polidos obscurecem. Mas sua alocação de risco é diferente. Suporte informal pode ser rápido quando voluntários estão disponíveis e lento quando estudo, trabalho ou vida intervêm. Hardware pode ser comprado oportunisticamente. Caminhos de rede podem mudar à medida que patrocínios ou relacionamentos comunitários mudam. Usuários que entendem esse acordo podem achá-lo totalmente apropriado.

Usuários que assumem continuidade empresarial porque viram "25G" e quatro nomes de instalações estariam comprando uma promessa que o registro público não faz.

O que o TeamFelNull realmente coloca na frente dos usuários

Os serviços mais visíveis são específicos e voltados para a comunidade. O site do TeamFelNull apresenta servidores sazonais de mods do Minecraft, desenvolvimento de software e pequenos projetos públicos. Suapágina do bot de voz do Discordanuncia múltiplas instâncias de um bot de texto-para-fala, enquanto suapágina Reversioferece uma atividade de jogo para o Discord. São superfícies de usuário reais: pessoas se conectam, enviam conteúdo, esperam que o estado persista por algum período e notam quando o serviço desaparece. São melhores evidências de um propósito operacional do que uma alegação genérica de "nuvem."

Ostermos e aviso de privacidadedo bot fornecem uma visão rara do limite de dados. Eles dizem que identificadores de usuário, servidor e canal podem ser armazenados para manter o serviço funcionando; nomes de usuário, apelidos e mensagens podem ser coletados para gerar fala e retidos apenas pelo período necessário. O aviso promete medidas de proteção razoáveis, mas isenta segurança completa, permite que o serviço ou termos mudem sem aviso e isenta responsabilidade por danos. Essas disposições se aplicam a esse bot, não automaticamente a cada servidor ou serviço de rede, mas revelam o estilo do único contrato público de usuário localizado aqui: ampla discrição operacional, garantia limitada e nenhum compromisso quantificado de restauração.

O lado do software é mais documentado do que o lado da hospedagem. Umtutorial do launcher do TeamFelNullexplica um launcher de jogo personalizado e descreve a verificação de antivírus durante seu processo de construção. Osite de documentação do SERVER-Gfoca nesse launcher, instalação e manipulação de instâncias de jogo. Isso mostra um grupo capaz de produzir instruções para usuários. O contraste é revelador: existe orientação pública para software cliente, enquanto páginas equivalentes para provisionamento de máquina virtual, durabilidade de armazenamento, backup de servidor, tratamento de abuso, status de incidente e encerramento de conta não são visíveis.

Uma listagem histórica e não oficial doJapan Minecraft Serversregistra um "TeamFelNull-24h-Server", submetido em 2019, com um tempo de atividade muito baixo registrado e um status dizendo que estava offline. Essa entrada não pode estabelecer o estado de AS58790 em 2026. Pode descrever uma máquina, endereço e período de operação diferentes, e sondas de terceiros podem falhar por muitas razões. É útil apenas como um sinal de mercado: o nome TeamFelNull foi anexado a um servidor de jogo público e pelo menos um endpoint antigo não permaneceu continuamente acessível. Monitoramento atual, um arquivo de incidentes ou uma declaração do operador seriam necessários para conectar essa história ao testbed de hoje.

Os serviços públicos também expõem diferentes padrões de dependência. Um servidor de jogo precisa de computação, memória, armazenamento, software compatível com a versão e uma rota estável; um bot de voz depende adicionalmente do Discord e de mecanismos de fala fora do controle do TeamFelNull. Um launcher pode permanecer utilizável no computador de uma pessoa mesmo que o servidor comunitário desapareça, mas downloads, pacotes de mods ou dependências de autenticação podem não. Agrupar tudo isso como "hospedagem" esconde quem controla qual falha.

TEAMFELNULL pode operar o aplicativo e alguns servidores enquanto SERVER-G ou outra parte controla o roteamento, uma instalação controla a energia e plataformas externas controlam identidade e distribuição.

É por isso que "capacidade voltada ao cliente" deve ser interpretada estritamente aqui. Há evidência de que recursos são disponibilizados a usuários e comunidades parceiras. Não há contagem pública de clientes pagantes, instâncias ativas, servidores gerenciados, volumes de armazenamento ou núcleos reservados. O quadro operacional correto é um conjunto de aplicações comunitárias apoiadas por uma rede educacional, com um pool não quantificado de recursos físicos e virtuais. Qualquer afirmação mais forte precisa de um inventário atual e dos contratos que conectam esse inventário à identidade de rede.

Onde o sistema físico pode tocar Tóquio

O rastro de instalações de AS58790 é inteiramente metropolitano. As páginas individuais de instalações do PeeringDB listam o testbed emAT TOKYO CC1/CC2,Equinix TY8,NTT DATA Otemachi BuildingeOtemachi Place West Tower. Esses registros corroboram os quatro nomes no perfil de rede, mas sua precisão termina na presença. Eles não mostram qual edifício em um rótulo de campus combinado é usado, se a conexão é física ou remotamente estendida, ou se há computação instalada ao lado do porto de rede.

As instalações subjacentes são substanciais. Orelato da própria AT TOKYOdiz que CC1 tem 140.000 metros quadrados de área total e descreve múltiplas alimentações de energia, UPS, geração de emergência e monitoramento 24 horas em suas instalações. Aespecificação da Equinix para TY8fornece um endereço em Tóquio, 40.418 pés quadrados de espaço, redundância de energia N+1 e redundância de resfriamento N+20%. Atabela de cobertura operacionalda Equinix diz que TY8 tem cobertura no local 24/7.

No Otemachi Place, adescrição do site New Otemachida BroadBand Tower anuncia um padrão de 6 kVA de energia de rack real, linhas duplas de 200 volts 30 amps, geradores N+1 capazes de operar por até 72 horas sem reabastecimento, múltiplas opções de conectividade e suporte remoto. Suapágina separada de serviços de redeoferece suporte de design e operação para roteadores, redes de armazenamento e conexões de nuvem. Essas são capacidades do operador da instalação disponíveis no edifício. Elas não mostram que TEAMFELNULL compra um rack completo, dois circuitos, mãos remotas ou qualquer serviço específico da BroadBand Tower.

Este é o limite de propriedade em termos práticos. O operador da instalação controla a casca do edifício, entrada de utilidades, geradores, planta de resfriamento, controle de acesso e as condições sob as quais técnicos alcançam um rack. Um cliente de colocation controla apenas o que contratou: talvez um gabinete, um rack fracionário, uma interligação ou um porto entregue remotamente. O operador de rede controla sua configuração de roteador e anúncios de endereço. O grupo de aplicação controla o software e o estado do usuário na medida em que tem acesso.

O design resiliente de uma instalação não pode compensar uma única fonte de alimentação em um servidor do cliente, uma interligação não paga, um disco falhado sem substituição ou um banco de dados de aplicação sem restauração testada.

A alegação geográfica é, portanto, ao mesmo tempo mais forte e mais estreita que "global." Os serviços podem ser acessíveis de todo o mundo, e as rotas de internet são globais por natureza. A evidência física revisada aqui aponta para Tóquio, Japão. Não estabelece racks operados pela empresa na Europa, América do Norte, outras metrópoles asiáticas ou mesmo Osaka. Nem quatro nomes em Tóquio criam necessariamente proteção contra um desastre metropolitano, uma falha comum de upstream ou um único erro administrativo.

A localidade dos dados para a infraestrutura visível deve ser tratada como centrada em Tóquio até que um registro de ativos atual prove o contrário.

Para os usuários, essa localidade tem duas consequências. Primeiro, a latência dependerá da distância até Tóquio e do caminho upstream selecionado; a palavra "global" não pode apagar a física. Segundo, os arranjos reguladores para acesso físico, energia e quaisquer dados armazenados são provavelmente japoneses na prática, mesmo que usuários remotos se conectem de outro lugar. O aviso público do bot não declara onde seu banco de dados está hospedado, e as listagens de instalações não vinculam um aplicativo específico a um edifício específico.

Um usuário que precisa de garantia de residência precisaria de detalhes escritos de colocação, replicação e subcontratados, em vez de uma cidade inferida de registros de roteamento.

Por que quatro registros de instalações não equivalem a quatro locais independentes

Redundância começa com independência, não com contagem. Quatro nomes de instalações podem representar quatro domínios de falha, mas também podem representar um roteador alcançado através de várias fibras de interconexão, um serviço estendido entre edifícios, interligações dormentes ou registros mantidos para acesso planejado. O PeeringDB é um banco de dados valioso da indústria, mas as entradas de rede e instalações são contribuídas por participantes.

O registro de AS58790 diz que suas informações de instalação foram atualizadas em fevereiro de 2026, o que apoia a atualidade; ainda assim não expõe as ordens de circuito subjacentes ou ocupação de rack.

A própria geografia convida à cautela. Duas listagens estão em Otemachi, uma é um rótulo de campus AT TOKYO cobrindo CC1/CC2, e uma é Equinix TY8 em Shinagawa. A entrada do Otemachi Place no PeeringDB observa uma interconexão óptica para NTT DATA Otemachi Building. Esse link pode ser operacionalmente útil, mas também significa que dois nomes em um banco de dados podem ser acessíveis por meio de uma extensão física, em vez de duas implantações TEAMFELNULL com energia separada. Nenhuma rota exata deve ser inferida dessa possibilidade. O registro estabelece interconexão disponível entre os edifícios, não o caminho ou topologia de AS58790.

A conexão INIXP adiciona outra camada. O exchange está presente em várias instalações em Tóquio e Osaka, mas a listagem de AS58790 não publica uma localização de porto em seu perfil de rede. Uma conexão de exchange de 25 Gbps poderia ser entregue em um local e transportada por uma rede parceira ou circuito metropolitano. Sem uma carta de autorização, registro de interligação, diagrama em nível de dispositivo e declaração de diversidade de circuito, o handoff físico permanece desconhecido. Os dois endereços de exchange provam uma conexão lógica; eles não localizam o porto do switch com precisão suficiente para mapear um cabo.

A verdadeira resiliência de computação em múltiplos locais exigiria mais evidências. No mínimo, um inventário atual mostraria servidores energizados ou armazenamento em pelo menos dois locais; a replicação teria uma direção e latência conhecidas; o failover de DNS ou roteamento teria um gatilho testado; os usuários saberiam quais serviços podem reiniciar em outro lugar; e o design de recuperação evitaria um plano de gerenciamento compartilhado. Nada nas páginas públicas afirma que os ambientes Minecraft, dados do bot do Discord ou serviços de desenvolvimento são replicados entre instalações. É possível que sejam. Não está demonstrado.

A mesma cautela se aplica à diversidade de upstream. Um roteador pode ouvir múltiplos caminhos enquanto todo o tráfego do cliente ainda depende de um provedor de transporte, um endpoint de túnel, um tail metropolitano ou uma autoridade de configuração. A história pública do SERVER-G descreve múltiplos relacionamentos ao longo do tempo e a retirada de alguns exchanges comunitários estrangeiros em dezembro de 2024. Sua política de peering permite explicitamente túneis GRE, SIT e WireGuard, bem como conexões em exchanges.

Túneis são ferramentas legítimas para um testbed, mas um vizinho BGP logicamente separado sobre o mesmo circuito de acesso subjacente não é diversidade física.

Uma declaração rigorosa de redundância identificaria a camada em que a independência existe. Sessões BGP separadas protegem contra falha de vizinho apenas se outro caminho utilizável permanecer. Alimentações de energia separadas da instalação protegem um rack apenas se o servidor tiver fontes duais conectadas corretamente. Edifícios separados protegem aplicações apenas se dados atuais existirem em ambos e os operadores puderem redirecionar usuários. Contatos de suporte separados protegem a recuperação apenas se mais de uma pessoa tiver credenciais e acesso físico.

As evidências públicas do TEAMFELNULL confirmam nenhuma dessas combinações ponta a ponta, então quatro rótulos de instalações devem ser lidos como alcance de interconexão, não continuidade de serviço em quatro locais.

Capacidade: o único número concreto está na borda do exchange

Capacidade não é um número. É uma pilha de limites, e o limite ativo mais baixo governa o serviço. O porto de exchange de 25 Gbps é capacidade de rede lógica instalada em uma interconexão. O PeeringDB rotula a conexão como operacional, o que é mais forte que um plano futuro. Mas a taxa de transferência utilizável pode ser menor devido a limites de encaminhamento do roteador, política de upstream, congestionamento, transporte entre o rack e o exchange, tamanho de pacote, ataques ou gargalos de aplicação. A capacidade vendida pode ser ainda menor—ou inexistente se o testbed não estiver vendendo largura de banda.

Espaço de endereço é outro tipo de capacidade. O PeeringDB lista cinco prefixos IPv4 e 50 prefixos IPv6 para AS58790, enquanto avisão geral de AS do Cloudflare Radaridentifica a rede no Japão e expõe visualizações de tráfego quando observações suficientes existem. Umavisão de roteamento separada do Cloudflareapresenta espaço de endereço anunciado, conexões, status RPKI e atividade BGP. Contagens de prefixo descrevem granularidade de roteamento, não servidores. Um /24 pode numerar 256 endereços IPv4, mas um endereço pode estar não utilizado, identificar um roteador, ser atribuído virtualmente ou servir muitos domínios atrás de um host.

Conjuntos de dados de terceiros ilustram por que uma data e definição devem viajar com cada número. Apágina de AS58790 do IPinfoatualmente lista dois blocos /24—44.30.37.0/24 e 44.30.62.0/24—junto com vários upstreams observados e um punhado de endereços que responderam a sondas. Umavisão do CIDR Reporttambém mostra dois anúncios /24 e 512 endereços IPv4 originados em sua visão de coletor. Essas observações suportam o roteamento IPv4 atual, mas nenhuma nos diz quantas máquinas existem ou se uma resposta veio de computação do cliente.

Outros agregadores entram em conflito. Umapágina de registro espelhadareproduz o nome AS da JPNIC e um intervalo IPv6 2401:d20:1020::/44, mas não relata intervalo IPv4. Apágina de AS do IP2Locationmostra um /24 e um IPv6 /46, enquanto apágina do IPGeolocationrelata zero rotas apesar de reproduzir a identidade AS. Essas não são instantâneos equivalentes; datas de coleta, visibilidade de rota e métodos de classificação diferem. A contradição é evidência sobre os limites dos dados do agregador, não uma razão para fazer média dos números.

Nenhuma fonte pública revisada declara núcleos de CPU, memória, nós bare-metal, máquinas virtuais, capacidade de disco, redundância de armazenamento, energia reservada, consumo médio de energia ou unidades de rack livres. Nenhuma fonte separa capacidade de projeto de capacidade instalada, energizada, operacional e utilizável pelo cliente. Números de toda a instalação não podem preencher a lacuna. Os 40.418 pés quadrados da Equinix no TY8 pertencem à instalação, não a AS58790. A especificação de rack padrão de 6 kVA da BroadBand Tower é uma característica de produto disponível, não prova de um rack TEAMFELNULL ou direito.

A capacidade economicamente significativa é o que pode sobreviver a uma falha enquanto honra compromissos. Se um serviço precisa de 16 núcleos e 64 GB de memória, um host sobressalente conta apenas se for compatível, energizado, conectado e já não reservado. Se o armazenamento é replicado, a segunda cópia conta apenas se for recente e independentemente recuperável. Se 25 Gbps alcançam um exchange, mas o servidor tem uma interface de 1 Gbps, o aplicativo não tem 25 Gbps. Até que o TEAMFELNULL publique ou forneça privadamente esses números de camada inferior, sua capacidade de hospedagem comercializável permanece desconhecida.

A história do upstream é real, mas não documentada de forma limpa

AS58790 é visível como uma origem, e várias visões públicas veem rotas alcançando-o. Isso é evidência operacional significativa. IPinfo lista Hurricane Electric, SDCC Japan-West Area e SERVER-G Group como upstreams ou peers, enquanto seu traço de sonda de junho de 2026 para 44.30.37.1 atravessou redes japonesas antes de alcançar AS58790. A visão do coletor do CIDR Report mostrou AS38074 diretamente adjacente a AS58790 para os dois /24s visíveis. A página de roteamento do Cloudflare fornece outro ponto de observação ao vivo. Juntas, essas fontes suportam acessibilidade, mas não concordam em um grafo de provedor estável.

Há várias razões benignas. BGP é observado de coletores particulares em momentos particulares. Um relacionamento que parece upstream de um caminho pode ser um peer, um caminho de servidor de rotas ou um serviço carregado por outra rede. IPv4 e IPv6 podem usar provedores diferentes. Uma sessão pode ser configurada mas ociosa, seletiva ou visível apenas de alguns locais. O registro de exchange do PeeringDB mostra a conexão INIXP, mas marca AS58790 como não usando o servidor de rotas lá. Isso significa que a presença sozinha não revela quais sessões bilaterais realmente carregam tráfego de produção.

A história mais ampla do SERVER-G é informativa, mas não pode ser simplesmente atribuída a AS58790. Ela registra relacionamentos de AS63800 com Vultr, Hurricane Electric, SDCC e outras redes em várias datas, juntamente com retiradas e adições posteriores. Apolítica de peeringde AS63800 exige números AS globais, tamanhos mínimos de prefixo, ROAs, registros IRR e contatos PeeringDB; também diz que alguma instabilidade é tolerada porque a rede é experimental. Essas são políticas declaradas para AS63800. Elas sugerem a cultura em torno do testbed, não uma promessa vinculante de tempo de atividade para AS58790.

A questão da propriedade está dentro da questão do roteamento. O PeeringDB coloca AS58790 sob SERVER-G Group e usa felnull.dev como seu site. A página pública do grupo diz que AS63800 é a rede principal e fornece ao TeamFelNull recursos. É, portanto, razoável ver AS58790 como um testbed do TeamFelNull apoiado pelo SERVER-G. Não é razoável assumir que o TeamFelNull possui cada contrato de upstream, cada interligação ou os recursos de endereço que origina. Um cliente precisa saber qual parte pode renovar, cancelar ou reconfigurar cada dependência.

A diversidade de rotas também tem um componente de plano de controle. Se uma pessoa, uma configuração de roteador ou um conjunto de credenciais controla cada sessão, múltiplos upstreams não protegem contra um filtro de rota errôneo ou retirada acidental. Um vazamento de rota, origem inválida, autorização de rota expirada ou filtro excessivamente amplo pode tornar servidores saudáveis inalcançáveis. As visões públicas mostram que o roteamento existe; elas não publicam controle de mudanças, acesso fora de banda, backups de configuração, roteadores duais, reversão automática ou uma escala de operações de rede 24 horas.

O que resolveria a questão é específico e modesto: cartas ou faturas atuais estabelecendo trânsito e transporte ativos; uma topologia mostrando quais conexões são físicas, virtuais ou tuneladas; evidência de coletor para ambas as famílias de endereço; registros de autorização de rota válidos; e um teste de failover demonstrando que o tráfego permanece utilizável quando o caminho primário é retirado. Até lá, a evidência de upstream merece uma confiança média como instantâneo e uma confiança baixa como garantia de redundância.

Energia, hardware e mãos são a superfície de controle oculta

Registros de rede tendem a dominar porque são públicos. A maioria das falhas de hospedagem, no entanto, é resolvida em uma camada muito menos visível: alguém encontra a fonte de alimentação, disco, módulo de memória, óptica, ventilador ou cabo falhado e o substitui. TEAMFELNULL não publica inventário de hardware, política de ciclo de vida ou estoque de peças de reposição. Um porto de 25 Gbps pode permanecer perfeitamente saudável enquanto um único servidor de aplicação está offline por falta de um componente compatível.

A resiliência da instalação ajuda apenas até o handoff do cliente. AT TOKYO anuncia múltiplas alimentações, UPS, geradores e monitoramento 24 horas. Equinix anuncia energia N+1 no TY8 e cobertura operacional 24 horas. BroadBand Tower anuncia alimentações duais de rack, geração N+1 e suporte remoto no New Otemachi. Esses controles reduzem o risco em nível de edifício para clientes que os compram e usam corretamente. Eles não revelam se o equipamento de AS58790 tem fontes de alimentação duais, se ambas as alimentações são contratadas, se o suporte remoto é autorizado ou quão rápido o TeamFelNull pode aprovar trabalho.

A mão de obra de suporte é em si capacidade. Apágina de contatodo TeamFelNull direciona consultas para o Discord. Isso pode ser conveniente para uma comunidade, mas não fornece uma escala de gravidade pública, compromisso de tempo de resposta, escalação telefônica, escala de plantão nomeada ou canal alternativo se o Discord estiver indisponível. As páginas do SERVER-G fornecem caminhos de e-mail ou Discord para peering, mas não há balcão de incidentes público que prometa especificamente restauração para serviços hospedados. Quando uma máquina falha às 03:00, a diferença entre "alguém pode notar" e "um técnico autorizado deve responder em 30 minutos" é o serviço.

A falha de estoque de hardware é especialmente importante para um testbed pequeno. Grandes provedores distribuem peças de reposição e pessoal entre muitos servidores; um operador comunitário pode ter máquinas únicas compradas em momentos diferentes. Sem uma lista de compatibilidade e substituições estocadas, uma placa-mãe falhada pode transformar uma troca de rotina em aquisição, viagem e reconstrução. Nenhuma evidência pública diz se os servidores usam unidades de inicialização espelhadas, armazenamento hot-swap, gerenciamento fora de banda, interfaces de rede duais ou imagens padronizadas.

Seria errado assumir tanto design empresarial robusto quanto hardware improvisado.

Faturamento e contratos de provedor podem criar a mesma paralisação sem nenhum equipamento quebrado. Um pagamento de colocation atrasado, recurso patrocinado expirado, acordo de transporte cancelado, problema de renovação de domínio ou lista de acesso de instalação alterada pode desconectar um serviço saudável. A declaração do SERVER-G sobre limites financeiros torna essa dependência digna de exame, mas não prova qualquer dificuldade atual. Evidência exigiria contratos atuais, datas de renovação, partes responsáveis e um plano de reserva ou sucessão. Em sua ausência, a continuidade financeira é simplesmente desconhecida.

Os usuários são afetados de forma diferente. Um jogador pode perder acesso a um mundo sazonal; um desenvolvedor pode perder um serviço de construção; uma comunidade do Discord pode perder saída de voz; um projeto patrocinado pode perder um endereço ou rota. O custo pode ser inconveniência em vez de receita, mas a perda de dados ainda pode ser pessoal e irreversível. O padrão de resiliência correto deve seguir o uso prometido.

Um mundo de teste pode tolerar inatividade se os usuários forem avisados; um banco de dados coletando identificadores ou um mundo comunitário de longa duração precisa de backup, retenção e regras de restauração mesmo quando nenhum dinheiro muda de mãos.

Falha começa com ambiguidade antes de chegar ao rack

O primeiro caminho de falha não é necessariamente técnico. É ambiguidade sobre o que foi prometido. Se os usuários ouvem "recursos de servidor" e veem nomes de data centers, podem assumir backups, hosts sobressalentes e recuperação gerenciada. Se os operadores significam acesso de melhor esforço para jogar e aprender, ambos os lados podem se comportar razoavelmente e ainda colidir após uma interrupção. A redução de risco mais rápida é uma descrição de serviço simples que diz o que está hospedado, quem opera, o que é melhor esforço, o que tem backup e o que os usuários devem copiar por conta própria.

No rack, a sequência é familiar. Uma alimentação ou fonte de alimentação falha; um porto de switch, óptica ou placa de rede cai; um disco ou controlador corrompe estado; a proteção de resfriamento desliga o hardware; ou o trabalho programado requer uma reinicialização. O monitoramento da instalação pode identificar alarmes ambientais, mas a recuperação da aplicação permanece com o cliente, a menos que serviços gerenciados tenham sido adquiridos. Nenhuma das páginas públicas vincula TEAMFELNULL a um pacote específico de suporte remoto, loja de peças de reposição ou janela de manutenção.

Na camada de rede, um porto de exchange, circuito metropolitano, endpoint de túnel, sessão upstream ou anúncio de rota pode falhar. As quatro entradas de instalação não revelam se esses elementos são diversos. Um porto INIXP de 25 Gbps é um caminho útil, mas o exchange se descreve como melhor esforço sem termos de serviço divulgados em sua listagem pública. Peering bilateral em um exchange não é o mesmo que trânsito de internet completo, e uma conexão de exchange não pode alcançar todos os destinos sem peers adequados ou um upstream.

Um serviço voltado ao usuário pode, portanto, falhar para algumas redes enquanto permanece acessível de outras.

Na camada de aplicação, atualizações criam suas próprias janelas de reparo. TeamFelNull trabalha com Minecraft modificado e launchers personalizados, onde versões de servidor e cliente devem alinhar. Uma atualização falhada pode deixar usuários presos mesmo quando roteamento e hardware estão saudáveis. A documentação do launcher mostra atenção à instalação e migração, mas não há cronograma público para manutenção de servidor, reversão, compatibilidade de banco de dados ou retenção de mundos mais antigos. O estado da aplicação é frequentemente a parte mais difícil de reconstruir porque uma nova máquina não pode recriar a história perdida.

Plataformas externas adicionam dependências correlacionadas. O bot de voz depende do Discord para identidade, eventos e acesso do usuário, e pode depender de um ou mais mecanismos de fala. Uma interrupção ou mudança de política nesses serviços pode tornar o bot indisponível sem qualquer falha em AS58790. O contato também depende do Discord, então o serviço e seu canal de suporte público principal podem falhar juntos. Uma página de status em um domínio hospedado independentemente, além de escalação por e-mail, separaria esses caminhos.

A população afetada não é quantificada. A página inicial convida uma comunidade; a página do bot mostra múltiplas instâncias; a listagem antiga de jogos registra um endpoint público. Nenhum fornece usuários atuais, picos de sessão ou o número de projetos dependentes. Isso impede uma estimativa numérica de impacto. O impacto qualitativo é claro: acesso comunitário, identificadores armazenados, estado do jogo, distribuição de software e recursos patrocinados podem ser interrompidos. Um plano de incidentes honesto nomearia essas classes sem reivindicar um número de clientes que não foi divulgado.

Recuperação e portabilidade param no limite da aplicação

Recuperação tem duas questões separadas: o operador pode restaurar o serviço, e o usuário pode sair? O registro público não responde a nenhuma das duas para computação hospedada. Não há frequência de backup publicada, período de retenção, cópia externa, teste de restauração, ponto de recuperação ou tempo de recuperação para servidores TeamFelNull. Também não há exportação documentada para uma máquina virtual, banco de dados, mundo de jogo, registro de conta ou volume hospedado. Um usuário não pode dizer se um disco falhado significa minutos de reversão, dias de reconstrução ou perda permanente.

Há uma exceção útil e estreita no lado do cliente. A documentação do launcher fornece umprocedimento de exportação de instânciaque cria um ZIP a partir de arquivos locais selecionados, e umguia de migração do launcherseparado explica como copiar pastas de instância locais entre versões. Essas instruções melhoram a portabilidade para o ambiente cliente de um jogador. Elas não exportam mundos no lado do servidor, bancos de dados de bots, credenciais, DNS, endereços IP ou máquinas virtuais.

Esse limite é fácil de perder. Um jogador pode preservar mods e configuração mas ainda perder o mundo compartilhado. Um administrador de bot pode reter uma comunidade do Discord mas perder preferências armazenadas. Um desenvolvedor pode manter código fonte mas perder artefatos de compilação ou segredos de implantação. Um usuário de rede pode manter uma imagem de aplicação mas ser incapaz de reter endereços se os direitos de recurso pertencem a outra parte. Cada camada precisa de seu próprio método de exportação e restauração.

A recuperação em múltiplos locais é igualmente não comprovada. A lista de instalações oferece locais plausíveis dos quais a resiliência poderia ser construída, mas nenhuma evidência pública mapeia um serviço para dois locais ativos ou relata latência de replicação. Mesmo que uma segunda máquina exista, o failover bem-sucedido requer dados atuais, segredos, roteamento, DNS, capacidade e pessoas autorizadas. Um sobressalente frio sem restauração testada pode levar mais tempo do que reparar o primário. Uma réplica quente compartilhando a mesma conta administrativa pode falhar durante um comprometimento.

A escalação de suporte deve fazer parte do design de recuperação, não uma reflexão tardia. Contato apenas pelo Discord pode funcionar durante o uso comunitário comum, mas um evento grave precisa de um caminho independente, uma pessoa responsável, autorização da instalação e uma regra de decisão para gastar dinheiro em peças ou transporte. Sucessão também importa: mais de um operador de confiança deve ser capaz de renovar domínios, acessar roteadores, contatar instalações e descriptografar backups. Nenhuma página pública estabelece essa cobertura, então permanece uma questão em vez de uma acusação.

O pacote de portabilidade mínimo crível seria simples: uma lista de dados de propriedade do usuário; formatos de exportação; limites de backup e retenção; tempo de exclusão; aviso antes de fechamento planejado; um procedimento para obter a cópia mais recente; e um teste mostrando que a cópia pode ser restaurada em outro lugar. Para serviços de jogo, isso pode ser um arquivo de mundo mais manifesto de versão. Para um bot, pode ser uma exportação de configurações estruturadas e confirmação de exclusão. Para um servidor virtual, pode ser uma imagem de disco padrão e registro de configuração.

Sem esses compromissos, os usuários devem manter suas próprias cópias sempre que tecnicamente possível.

Localidade dos dados é centrada em Tóquio, mas os dados da aplicação permanecem não mapeados.

A evidência de roteamento e instalação aponta para o Japão, especialmente Tóquio. AS58790 está registrado com uma identidade japonesa em conjuntos de dados de roteamento, as instalações de interconexão listadas estão em Tóquio, e os endereços IPv4 observados são geralmente geolocalizados no Japão. Isso apoia uma avaliação física centrada em Tóquio. Não prova que cada byte de dados de aplicação permanece em Tóquio, porque dependências de software, backups, entrega de conteúdo e serviços de terceiros podem cruzar fronteiras.

O bot é o exemplo mais claro. Seus termos dizem que identificadores podem ser armazenados e mensagens podem ser processadas para geração de fala, mas não nomeiam um local de hospedagem, provedor de banco de dados, provedor de fala ou jurisdição de backup. O Discord em si é uma plataforma externa. A presença de instalação de AS58790 não pode responder onde o Discord armazena dados ou onde uma solicitação de fala é processada. Uma alegação de residência de dados exigiria documentação em nível de aplicação, não meramente um código de país de sistema autônomo.

Serviços de jogo e desenvolvimento têm incerteza semelhante. Um processo de servidor pode rodar em uma máquina em Tóquio enquanto downloads de mods vêm de outra plataforma, código fonte está em um repositório global e backups—se existirem—estão em outro lugar. Inversamente, um endereço originado por AS58790 poderia alcançar equipamento entregue remotamente por meio de outra rede. A geolocalização de IP é uma estimativa, não prova de um rack. O IPinfo adverte explicitamente que local registrado ou inferido nem sempre iguala uso real, e a discórdia entre agregadores de roteamento mostra quão rapidamente classificações divergem.

Isso importa mesmo para um serviço comunitário. Os usuários podem se importar com acesso legal, exclusão, resposta a violações ou simplesmente a latência de uma dependência distante. O aviso de privacidade público dá categorias amplas de dados coletados e um conceito de retenção necessária, mas não uma duração fixa de retenção ou local. Também permite mudanças sem aviso prévio. Esses termos podem ser proporcionais a um bot gratuito, mas não atendem à necessidade de um comprador por soberania ou localidade contratada.

O rótulo de área de serviço "Global" deve, portanto, ser lido como alcance, não pegada. Um site, servidor de jogo ou bot do Discord pode atender pessoas internacionalmente a partir de Tóquio. Isso não faz do TEAMFELNULL um provedor multirregional. O registro físico suporta um cluster metropolitano; o registro da aplicação não mapeia fluxos de dados. Qualquer organização com requisitos de residência deve pedir um mapa de dados específico do serviço nomeando o host primário, réplicas, backups, processadores externos e caminho de exclusão.

Há também uma troca de resiliência. Manter todas as cópias em Tóquio pode simplificar a localidade, mas expô-las a uma interrupção metropolitana. Replicar no exterior pode melhorar a recuperação de desastres, mas mudar jurisdição e latência. Nenhuma escolha é inerentemente correta. O problema é que a evidência pública atual não revela a escolha. Uma resposta confiável declararia onde cada cópia reside, por quê, com que frequência é atualizada e quem pode recuperá-la.

O que os clientes devem exigir—e o veredito de due diligence

O primeiro pedido deve ser um cronograma de ativos e serviços, não um mapa de rede bonito. Deve identificar a parte contratante, o serviço oferecido, se envolve pagamento e o recurso exato: núcleos, memória, armazenamento, espaço de endereço, largura de banda e suporte. Deve distinguir recursos dedicados de compartilhados e declarar quais quantidades estão instaladas, energizadas, operacionais, reservadas e ainda disponíveis. Um porto de exchange nominal de 25 Gbps pertence ao cronograma, mas apenas como um componente de interconexão.

O segundo pedido deve mapear responsabilidade. Qual organização possui ou aluga cada servidor? Qual detém a conta da instalação, circuito de transporte e acordo de upstream? Quem controla os roteadores de AS58790, DNS, credenciais de aplicação e faturamento? Qual instalação pode aceitar uma solicitação de suporte de qual pessoa nomeada? A afiliação SERVER-G e TeamFelNull é visível, mas as transferências não são. Uma tabela de responsabilidade de uma página removeria grande parte da incerteza atual.

O terceiro pedido deve ser uma topologia baseada em evidências. Deve mostrar instalações com precisão de nível de cidade, evitar expor detalhes sensíveis de rack e marcar circuitos físicos, circuitos virtuais e túneis de forma diferente. Deve identificar tails metropolitanos compartilhados e dependências de gerenciamento, além do local que hospeda cada serviço crítico. Um teste de failover deve então demonstrar o que acontece quando um upstream, porto de exchange, roteador, servidor ou local é removido. Sozinha, presença de marketing não é resultado de teste.

O quarto pedido deve cobrir energia e reparo. Os usuários precisam saber se os servidores têm fontes duais, se ambas as alimentações da instalação são usadas, se peças de reposição estão disponíveis e se suporte remoto é contratado. O documento deve incluir aviso de manutenção, níveis de gravidade, metas de resposta e um canal de escalação independente. Suporte de melhor esforço pode ser aceitável se for declarado claramente; o risco vem de deixar os usuários inferirem cobertura empresarial das capacidades dos operadores da instalação.

O quinto pedido deve cobrir dados. Deve declarar frequência de backup, retenção, criptografia, teste de restauração, exportação do usuário, exclusão e o que está excluído. Deve nomear plataformas externas e a localidade das cópias primárias e de backup. Para mundos de jogo de longa duração ou bancos de dados comunitários, o operador deve fornecer uma exportação recente antes do fechamento planejado. Para serviços experimentais, a regra honesta mais simples pode ser "sem backup; mantenha sua própria cópia", desde que os usuários possam realmente fazê-lo.

Finalmente, o usuário deve pedir prova operacional atual em vez de marca histórica. Itens úteis incluem um histórico de status recente, observações de rota datadas, uma atestação de inventário, um aviso de incidente de amostra e um registro de restauração bem-sucedido. Nenhum precisa revelar segredos. Juntos, mostrariam que a capacidade existe abaixo do porto de exchange e que a recuperação é mais que uma intenção. Se esses itens não estiverem disponíveis, a classificação racional permanece testbed educacional, e as cargas de trabalho devem ser escolhidas de acordo.

O veredito: testbed útil, plataforma de hospedagem não comprovada.

O TEAMFELNULL SERVER-G Group tem mais substância do que sua pegada empresarial esparsa sugere inicialmente. AS58790 tem uma identidade PeeringDB atual, uma conexão operacional de 25 Gbps no INIXP, atualizações recentes de instalação e rotas globalmente visíveis. TeamFelNull mantém projetos públicos, termos de usuário e documentação. SERVER-G descreve uma rede educacional contínua e reconhece abertamente seu caráter estudantil, sem fins lucrativos e limites financeiros. Esses são sinais de atividade, não um registro vazio.

A evidência ainda fica aquém no ponto onde um serviço hospedado se torna confiável. Quatro listagens de instalações não provam quatro implantações. Um porto de 25 Gbps não prova taxa de transferência de servidor ou capacidade sobressalente. Anúncios de endereço não contam máquinas. Resiliência de instalação não passa automaticamente por um design de rack desconhecido. Múltiplos upstreams observados não provam transporte fisicamente diverso. Exportações de jogo do lado do cliente não protegem dados do lado do servidor. Contato pelo Discord não cria uma garantia de resposta.

O grau de evidência de rede apropriado é fraco, não negativo. "Negativo" ignoraria a conexão de exchange ativa, rotas e serviços públicos. "Médio" implicaria que a cadeia operacional é suficientemente descrita para avaliar capacidade e recuperação. Não é. A evidência mais forte está na borda lógica; a mais fraca está onde os usuários suportam perda: inventário de hardware, direito a energia, durabilidade de armazenamento, mão de obra de suporte, contratos, backups e migração.

Para hobby, aprendizado e uso comunitário explicitamente de melhor esforço, isso pode ser um acordo perfeitamente sensato. Testbeds pequenos criam espaço para aprender BGP, executar jogos especializados e construir ferramentas sem a economia de uma nuvem comercial. Seu valor não deve ser medido apenas por burocracia empresarial. A condição essencial é consentimento informado: os usuários devem saber que infraestrutura experimental pode mudar, que o suporte pode depender de uma equipe pequena e que precisam de suas próprias cópias recuperáveis.

Para cargas de trabalho pagas ou consequenciais, a verificação privada é necessária antes da confiança. O operador precisaria mostrar a alocação de recursos, contraparte legal, instalação ativa e arranjos de upstream, design multissite ou de restauração e termos de portabilidade de dados. Um comprador deve testar a recuperação, não apenas a conectividade. Se essas provas existirem, a avaliação pública pode ser atualizada. Até lá, TEAMFELNULL é melhor compreendido como uma rede educacional centrada em Tóquio com serviços comunitários reais e uma borda de exchange impressionante—não como uma nuvem multissite documentada.

Essa conclusão respeita ambos os lados da evidência. Não transforma divulgação ausente em alegação de falha, e não transforma um roteador bem conectado em um rack de computação resiliente. O porto visível de 25 Gbps é o começo da questão de capacidade. Para os usuários do TEAMFELNULL, os fatos decisivos permanecem atrás dele: quais máquinas estão energizadas, quais dados podem ser restaurados, qual caminho sobrevive e quem agirá quando a janela de reparo abrir.