Resumo

  • O AS30344 está ativo, não apenas registrado. Em 15 de julho de 2026, o RIPEstat mostrou quatro anúncios IPv4 /24 e um IPv6 /40; o bloco IPv4 mais novo, 23.26.1.0/24, foi atribuído à 365.hosting em 6 de maio e apareceu nos dados de roteamento em 7 de maio. Todas as quatro origens IPv4 validaram no RPKI no instantâneo analisado, enquanto a rota IPv6 retornou um estado de validação desconhecido.
  • Observações públicas de rota mostraram um único vizinho, MIRhosting AS52000. Isso representa uma concentração significativa no limite AS visível, mesmo que a MIRhosting tenha múltiplos upstreams, conexões de exchange e instalações. Nenhuma evidência publicada comprova um segundo trânsito AS30344, entradas fisicamente diversas, failover testado ou capacidade de substituição equivalente.
  • A 365.hosting vende VPS e servidores dedicados nos Estados Unidos e nos Países Baixos e afirma usar seus próprios racks em data centers Tier III. Sua página nos EUA ainda identifica o local de Secaucus como vXchnge NJ01, embora a H5 Data Centers agora liste a mesma instalação na 200B Meadowlands Parkway. Sua página de VPS holandesa contém texto legado da WebHOST1 afirmando equipamentos da WebHOST1 na Serverius; a página de transição da Kolo diz que a Serverius agora opera sob o nome Kolo, cujo portfólio atual tem quatro locais holandeses. Nenhuma das superfícies identifica o rack relevante da 365.hosting ou o local da Kolo. A contagem de racks, carga de TI instalada, inventário disponível, ocupação, direito de energia e capacidade de restauração entre locais permanecem não divulgados.

Uma adição de 256 endereços torna a rede mais fácil de ver

A maneira mais útil de acessar a 365.hosting não é a promessa de data centers premium em sua página inicial. É uma pequena e antiga mudança no registro público de endereços.O registro da ARIN para 23.26.1.0/24diz que o bloco de 256 endereços foi atribuído à 365.hosting em 6 de maio de 2026. Umaconsulta de histórico do RIPEstatmostra o AS30344 anunciando-o a partir de 7 de maio. A sequência é excepcionalmente limpa: atribuição em um dia, rota visível no dia seguinte.

Esse novo bloco é importante porque confirma a atividade atual da rede sem exigir um depoimento de cliente ou um lançamento promocional. No instantâneo de 15 de julho, avisão de prefixos anunciadoscontinha quatro /24s IPv4: 23.26.1.0/24, 23.152.200.0/24, 77.91.126.0/24 e 138.124.187.0/24. Também continha 2602:2d3::/40. O total IPv4 é de 1.024 endereços. O /40 IPv6 é uma alocação de roteamento, não uma contagem de servidores, clientes ou máquinas virtuais utilizáveis.

O mesmo instantâneo também estabelece o primeiro limite da história. Avisão de vizinhos AS do RIPEstatencontrou um único vizinho do lado esquerdo, AS52000. Apágina AS30344 do IPinfoclassificou a MIRhosting como o único upstream e chamou o AS30344 de rede stub. Um stub é um AS que origina suas próprias rotas, mas não é observado fornecendo trânsito para redes downstream. Esta é uma forma operacionalmente coerente para uma rede de hospedagem modesta. Não é prova de diversidade de rotas.

A avaliação inicial correta, portanto, não é nem “rede de papel” nem “nuvem resiliente comprovada”. O AS30344 está ativo, seu espaço de endereço é acessível e novos recursos foram colocados em roteamento. Mas sua saída publicamente visível do AS permanece concentrada. Essa distinção será importante sempre que o site de vendas prometer alta disponibilidade, vários países ou serviço 24 horas.

A marca vende mais do que o AS30344 pode descrever

Apágina inicial da 365.hostingapresenta um catálogo de infraestrutura convencional, mas amplo. Ele lista VPS/VDS, servidores dedicados, domínios, certificados SSL, administração de servidores e complementos de segurança. Diz que a empresa opera desde 2022, tem locais nos Estados Unidos, Europa e Ásia, usa “racks próprios” em instalações Tier III mais sites parceiros, suporta mais de 20.000 projetos e pertence ao grupo internacional 365.partners. Também exibe contadores de marketing maiores, incluindo sites ativos e uma alegação de disponibilidade de 99,9% por cinco anos.

Essas declarações estabelecem o que a marca quer que os clientes comprem. Elas não alocam ativos físicos ao AS30344. A alegação de racks próprios não nomeia IDs de rack, contratos de locação, salas de instalação, alimentações de energia ou a empresa que detém o título dos servidores. Os contadores de projetos e sites não explicam se cobrem apenas a 365.hosting, a plataforma WebHOST1 mais antiga, o grupo 365.partners, registros de domínio, contas inativas ou computação paga ativa. O número de disponibilidade não publica um período de medição, denominador de serviço, exclusões de manutenção ou registro de incidentes.

As páginas de produtos são mais tangíveis. Apágina de servidor dedicado nos EUAlistava configurações Intel de soquete duplo, um endereço IPv4, 30 TB de tráfego, um canal nominal de 1 Gbps para a oferta padrão, um tempo de configuração de cinco a dez dias e administração inicial gratuita. Também exibia uma configuração de ponta com um canal de 10 Gbps. Apágina de servidor dedicado nos Países Baixosoferecia similarmente um sistema dual-Xeon, armazenamento NVMe, um endereço IPv4, 30 TB de tráfego, um canal de 1 Gbps e o mesmo intervalo de configuração.

Isso é evidência de uma loja com equipe e produtos definidos. Não é um relatório de inventário ao vivo. Um cartão de plano pode permanecer online enquanto um chassi está sob encomenda, um rack está cheio, um preço está desatualizado ou um local está temporariamente indisponível. O tempo de configuração de cinco a dez dias é especialmente revelador: a capacidade dedicada não é necessariamente um pool provisionado instantaneamente. Pode depender de técnicos, peças de reposição, mãos remotas, montagem de servidor, burn-in, cabeamento e atribuição de endereço.

O produto é uma promessa de entregar hardware após um intervalo, não uma prova de que toda configuração anunciada está instalada e ociosa hoje.

A rede e o catálogo também devem ser mantidos separados. O servidor de um cliente pode usar espaço AS30344, outro ASN do grupo, endereços fornecidos pela instalação ou uma alocação upstream. Por outro lado, um endereço AS30344 pode hospedar infraestrutura que não é vendida sob o atual cartão de produto dos EUA ou dos Países Baixos. Sem um mapeamento publicado entre serviço, prefixo, instalação e contrato, o ASN é a identidade de rede mais clara, mas não um inventário completo da plataforma comercial.

Sheridan é o endereço de registro, não a sala de servidores

Oregistro de sistema autônomo da ARINnomeia 365-HOSTING, marca AS30344 como ativo e o vincula ao handle de organização PARTN-46. Oregistro de organização associado da ARINfornece 30 N Gould Street, Suite R, Sheridan, Wyoming, e o endereço de suporte da 365.hosting. Apágina de contatoda empresa repete o mesmo endereço de Wyoming e número de telefone.

Isso torna Sheridan uma forte localização administrativa e de registro. Não a torna uma localização de data center. Não há alegação de instalação na página de contato, nenhuma descrição de energia ou refrigeração para Wyoming, e nenhuma medição de rota pública colocando o parque de servidores nesse prédio. Tratar um endereço de registro como uma coordenada de rack colapsaria a presença legal e as operações físicas em um único ponto não suportado.

O registro de domínio adiciona uma linha do tempo diferente. Aresposta RDAP da CentralNic para 365.hostingregistra a criação do domínio em julho de 2022 e nomeia ns1.365.hosting e ns2.365.hosting. O DNS público em 15 de julho resolveu o site para 23.152.200.43, dentro de um prefixo AS30344. Os hostnames de correio e serviço de nome também estão dentro de endereços associados à mesma rede. Isso dá à marca uma relação técnica direta com o AS30344, mais forte do que um agregador simplesmente combinando um nome.

No entanto, mesmo isso não estabelece a cadeia corporativa com precisão. A página inicial diz que a 365.hosting faz parte da 365.partners. Apágina de membro do RIPE NCC para 365.partners INCfornece o mesmo endereço de Sheridan, número de telefone e um domínio de email365.hosting, e lista áreas de serviço na Alemanha, Reino Unido, Israel e Países Baixos. Apágina AS198178 do IPinfoassocia essa rede maior da 365.partners à 365.hosting e mostra uma pegada de endereço substancialmente mais ampla do que o AS30344.

Esses identificadores comuns apoiam uma afiliação operacional conforme representada publicamente pela marca e pelos registros. Eles não justificam mesclar AS30344 e AS198178, atribuir todos os prefixos do grupo a esta entidade de diretório ou assumir que um ASN é um backup automático para o outro. Origens de rota separadas podem compartilhar contatos e controle comercial enquanto usam diferentes upstreams, instalações e políticas operacionais. Uma alegação de recuperação precisa de um design de failover declarado, não meramente um nome relacionado.

Os quatro blocos IPv4 não compartilham o mesmo histórico de registro

Os 1.024 endereços IPv4 originados pelo AS30344 parecem uniformes em uma tabela de rota: quatro /24s iguais. Seus históricos de registro não são uniformes. Essa diferença é um aviso útil contra tratar o espaço roteado como um pool único e próprio.

A ARIN alocou diretamente 23.152.200.0/24para a 365.hosting em maio de 2023. O mais novo 23.26.1.0/24 é uma atribuição de um bloco pai maior, registrado em maio de 2026. Aentrada do banco de dados RIPE para 77.91.126.0/24nomeia a redeWebhost_LLC, descreve 365.partners INC nos comentários e carrega o mesmo contato de Sheridan. Aentrada RIPE para 138.124.187.0/24nomeia Webhost LLC em Moscou e diz que a sub-rede é usada para fornecer servidores virtuais e dedicados que são autogerenciados pelos clientes.

Esses registros apoiam um quadro operacional em que a 365.hosting origina uma mistura de recursos de endereço diretamente alocados, atribuídos e relacionados ao grupo. Eles não provam a propriedade de todos os quatro blocos no sentido comum de propriedade. Os recursos de número da Internet são administrados sob políticas de registro e podem ser reatribuídos, subalocados ou roteados sob acordo. As diferentes organizações e comentários fazem parte do limite de controle, não um incômodo burocrático a ser apagado.

O DNS reverso fornece evidência limitada de uso. Avisão do IPinfo de 23.152.200.0/24mostrou a maioria dos endereços com nomes estáticoswebhost1.nete identificou ns1.365.hosting, ns2.365.hosting e o hostname principal da 365.hosting. Suavisão de 77.91.126.0/24incluíavm.365.hostingentre nomes similares dewebhost1.net. Avisão de 138.124.187.0/24mostroumail.365.hostinge mais registros reversos no estilo WebHOST1.

Isso é uma forte evidência de que a marca e o ambiente operacional mais antigo da WebHOST1 compartilham uma superfície de controle. É uma evidência fraca para identidade de cliente individual, contagem de servidores ou localização física. Nomes reversos podem persistir após mudanças, ser gerados automaticamente ou apontar para uma convenção de gerenciamento em vez de um prédio. Eles não devem ser convertidos em um inventário de 1.024 servidores ativos.

Autorização de rota é melhor do que redundância de rota

Os quatro anúncios IPv4 tinham uma propriedade de segurança útil no carimbo de data/hora analisado. O validador RPKI do RIPEstat retornouvalidpara23.152.200.0/24,23.26.1.0/24,77.91.126.0/24e138.124.187.0/24quando originados pelo AS30344. Isso significa que redes confiáveis que usam validação de origem de rota tinham autoridade criptográfica para aceitar este par ASN-prefixo.

A rota IPv6 foi diferente. O validador retornouunknownpara2602:2d3::/40porque não encontrou ROA de validação nessa resposta. Desconhecido não é inválido. Significa que a validação de origem de rota não forneceu autorização positiva para esse par. A distinção é importante para a postura de segurança, mas nem um estado válido nem desconhecido diz algo sobre largura de banda, congestionamento, energia da instalação ou failover do cliente.

O RPKI é, portanto, um controle de integridade de roteamento, não um mecanismo de redundância. Uma rota perfeitamente autorizada ainda pode desaparecer quando um roteador falha, um contrato de trânsito expira, uma fibra é cortada ou uma alteração de manutenção dá errado. Pode permanecer visível enquanto sofre perda de pacotes. Por outro lado, uma rota com um único vizinho visível pode herdar considerável alcance da rede global desse vizinho, mas ainda depende do handoff comercial e técnico entre os dois sistemas.

A topologia pública apoia cautela, não alarme. Os coletores de rota não observam toda interconexão privada, e uma sessão de backup pode estar configurada, mas inativa. Uma segunda operadora também pode existir na Camada 2 enquanto o AS52000 continua sendo o único vizinho BGP. A evidência não pode provar que não há standby oculto ou frio. Pode provar que nenhum segundo vizinho AS estava visível na visão do RIPEstat de 15 de julho e que a empresa não publicou um teste demonstrando um.

MIRhosting é uma rede substancial, mas continua sendo a dobradiça visível

O AS52000 não é um endpoint pequeno de operadora única. Apágina da empresa MIRhostinglista mais de dez locais de data center na Europa, Estados Unidos e Ásia, incluindo Secaucus e 60 Hudson Street em Nova York, vários locais holandeses, Frankfurt e Mumbai. Oregistro AS52000 do PeeringDBdescreve uma rede global com 1-5 Tbps de tráfego, uma política de peering aberta, múltiplas exchanges e instalações, e contatos NOC e abuso 24 horas. OBGP.toolslista vários upstreams, incluindo Arelion, GTT, Cogent e Tata, junto com conexões de exchange.

Essa amplitude reduz a tentação de equiparar “um vizinho AS” a “um cabo físico para toda a internet”. A MIRhosting pode transportar o AS30344 sobre uma rede com seus próprios roteadores, upstreams e sites redundantes. A amostra de traceroute do IPinfo alcançou um endereço AS30344 através de um roteador da MIRhosting identificado perto de Nova York, consistente com um caminho de serviço nos EUA. No entanto, isso não revela quantas portas unem o AS30344 ao AS52000, se essas portas entram em prédios diferentes, ou se os serviços holandeses e americanos usam handoffs separados.

A dobradiça permanece real. Se todo caminho externamente visível para o AS30344 depende do AS52000 aceitar e propagar suas rotas, então um erro de política, suspensão comercial, filtro de vazamento de rota, resposta a DDoS ou falha de plano de controle compartilhado nesse limite pode afetar todos os quatro prefixos IPv4 e o prefixo IPv6 juntos. A diversidade upstream da MIRhosting não protege automaticamente contra uma falha específica do relacionamento AS30344-AS52000.

Os clientes precisam de uma resposta mais precisa do que a palavra “redundante”. Uma prova útil incluiria um segundo AS de trânsito ativo, histórico de coletor de rota mostrando ambos os caminhos, cross-connects de instalação separados, capacidade de porta, datas de teste de failover e evidência de que os prefixos de serviço permanecem acessíveis após qualquer handoff ser desabilitado. Nada disso foi encontrado no material público analisado para este perfil. A rede deve, portanto, ser descrita como ativa e globalmente acessível, com apenas um relacionamento upstream observado publicamente.

O rótulo Secaucus sobreviveu ao operador

O produto dos Estados Unidos é fisicamente específico em um aspecto. Oanúncio de Nova Jersey da 365.hosting, datado de 7 de março de 2026, diz que seus servidores em nuvem NVMe estão na “vXchnge Secaucus” e descreve uma instalação de 54.121 pés quadrados perto da cidade de Nova York. A página de servidor dedicado chama o local de vXchnge NJ01. Isso dá aos clientes mais do que uma região genérica “EUA”: aponta para Secaucus, Nova Jersey.

O nome do operador está desatualizado, mas a própria data de aquisição pública precisa de uma ressalva. Oanúncio de aquisição ao vivo da H5é datado de 31 de janeiro de 2021, enquanto aconfirmação contemporânea do Data Center Dynamicsé datada de 31 de janeiro de 2022. O conflito de fonte de um ano impede uma alegação de idade mais exata; ambas as datas ainda precedem o aviso de lançamento de 7 de março de 2026 da 365.hosting em pelo menos quatro anos. Apágina atual da instalação da H5lista seu data center de Nova Jersey na 200B Meadowlands Parkway, Secaucus, descreve-o como uma instalação Tier III de mais de 38.000 pés quadrados e o comercializa para continuidade de negócios em Nova York. Oregistro de instalação do PeeringDBchama-o de H5 Data Centers Secaucus (NJ01), fornece o mesmo endereço e preserva “vXchnge Secaucus (NJ01)” apenas como um nome histórico alternativo.

A incompatibilidade não prova que os servidores da 365.hosting deixaram o prédio ou que o serviço está indisponível. Um contrato de cliente e rack podem sobreviver a uma venda de instalação. Isso mostra que a descrição pública da empresa não foi atualizada para o operador atual. Isso enfraquece a confiança em alegações adjacentes que são mais difíceis de verificar, como qual parte fornece mãos remotas, qual acordo de nível de serviço se aplica, quem recebe uma escalada durante um incidente na instalação e se os 54.121 pés quadrados citados descrevem a pegada do prédio, a área comercializada anteriormente ou o espaço vendável atual.

Também altera a dependência contratual. Se a H5 agora controla o local enquanto a 365.hosting controla servidores ou racks e a MIRhosting fornece o caminho de rede visível, então um cliente depende de pelo menos três camadas operacionais. A H5 mantém o acesso ao prédio, energia, refrigeração e procedimentos da instalação. A 365.hosting provisiona e suporta o serviço de servidor. A MIRhosting transporta o relacionamento BGP visível. Fornecedores adicionais de hardware, processadores de pagamento e plataformas de gerenciamento ficam atrás dessas camadas.

Nenhum contrato público revisado aqui mostra qual camada deve ao cliente final um remédio quando duas camadas discordam sobre a causa de uma interrupção.

A declaração de localização mais segura é estreita: a 365.hosting comercializa publicamente servidores nos EUA em uma instalação de Secaucus historicamente conhecida como vXchnge NJ01; a H5 atualmente apresenta o local da 200B Meadowlands Parkway como sua instalação em Nova Jersey. A evidência pública não identifica o rack da 365.hosting, carga instalada, gaiola, cross-connects atuais ou capacidade vendável restante dentro dela.

O local holandês é nomeado apenas para o grupo de instalação

A oferta dos Países Baixos é similarmente real, mas menos precisa geograficamente. Oaviso de lançamento nos Países Baixos da 365.hosting, também datado de 7 de março, diz que os servidores virtuais se tornaram disponíveis em um data center da Serverius. Apágina de VPS dos Países Baixoscontém texto legado da WebHOST1: diz que a WebHOST1 oferece o serviço e usa seu próprio equipamento em um data center da Serverius. Essa é uma alegação da WebHOST1 exposta na superfície da 365.hosting, não uma prova de que a 365.hosting possui o equipamento. A página também descreve virtualização KVM, armazenamento SSD com RAID10, um canal de plano de 100 Mbps e um reembolso de 30 dias. A página de servidor dedicado eleva o canal anunciado para 1 Gbps para seu hardware listado.

A Serverius também não é mais o rótulo público independente atual. Apágina de transição da Kolodiz que a Serverius e a Fuzion agora operam sob o nome Kolo, com os mesmos locais e serviços, e diz que a marca unificada entra ao vivo oficialmente em 17 de julho. Oportfólio da Kolo nos Países Baixoslista quatro locais: NL1 Dronten, NL2 Meppel, NL3 Apeldoorn e NL4 Amsterdam. Essas são alegações da plataforma Kolo, não um mapa do equipamento da 365.hosting. A página da 365.hosting não diz qual instalação, sala ou rack detém o serviço relevante, e nenhum registro público de cross-connect liga o AS30344 a um local específico da Kolo.

Essa falta de identificador de local limita tanto a análise de localidade quanto a recuperação. Um cliente escolhendo “Países Baixos” pode razoavelmente esperar processamento de dados no país quando o serviço está operando conforme comercializado. A página pública não divulga se os backups permanecem no mesmo prédio, em outro local da Serverius, nos Estados Unidos ou em uma plataforma de gerenciamento em outro lugar. Não diz se um host holandês com falha pode ser restaurado em Secaucus, se o consentimento do cliente é necessário para tal movimento, ou quanto tempo levaria a transferência de imagem e dados.

Osavisos de NOC ainda servidos no domínio Serveriusilustram por que essas distinções são importantes e já usam rótulos KoloDC. Em 2026, o site publicou manutenção de refrigeração em NL1 Dronten e trabalho em fibra escura entre NL1 Dronten e NL2 Meppel, explicando que fibras alternativas devem assumir enquanto alerta para possível latência ou perda de pacotes durante a reconvergência de rota. Essa é uma divulgação operacional saudável pela rede da instalação. Não prova que a 365.hosting ocupou qualquer um dos locais afetados ou participou do caminho alternativo. Simplesmente mostra o tipo de manutenção física que um rótulo “Países Baixos” esconde.

A nota de evidência holandesa é, portanto, média para disponibilidade de serviço em nível de país e fraca para posicionamento exato de ativos. As páginas de produto tornam a oferta crível, enquanto a transição Serverius-para-Kolo estabelece a identidade atual da plataforma de instalação sem localizar o serviço. As fontes não estabelecem um endereço, inventário instalado, direito de energia, propriedade de rack ou replicação entre locais para a 365.hosting.

Cartões de capacidade não são uma declaração de capacidade

A loja virtual publica unidades comerciais úteis: tipo de processador, memória, disco, canal, franquia de tráfego, contagem de IPv4, tempo de configuração e período de faturamento. Esses são direitos do cliente se fornecidos sob o contrato aplicável. Eles não podem ser somados para calcular a capacidade do provedor porque o site não publica o número de servidores disponíveis ou hosts de virtualização por trás de cada cartão.

Um plano holandês de VPS foi exibido como fora de estoque quando revisado. Esse é um sinal operacional pequeno, mas valioso. Sugere que o catálogo pode expor um estado de disponibilidade em vez de aceitar todas as configurações sem limite. Também demonstra por que uma especificação de plano não é capacidade instalada. Um direito de disco de 20 GB e uma porta de 100 Mbps em um plano indisponível não fornecem serviço utilizável a um novo cliente.

As páginas de servidor dedicado declaram um tempo de configuração de cinco a dez dias. Isso pode representar provisionamento normal em vez de escassez, mas expõe o papel do inventário de hardware e mão de obra. Se um servidor de produção falhar, a questão relevante não é se um SKU correspondente existe no site. É se um chassi equivalente, conjunto de memória, dispositivo NVMe, alocação de energia e técnico estão disponíveis no mesmo local sob um objetivo de substituição acordado.

Nenhuma página revisada divulgou contagem de racks, contagem de servidores, contagem de hipervisores, núcleos de CPU agregados, armazenamento instalado, estoque de drives sobressalentes, capacidade energizada, largura de banda comprometida, superassinatura, porcentagem vendida ou inventário reservado. A alegação da página inicial de racks próprios permanece não quantificada. O tamanho da instalação da H5 e a escala da plataforma Kolo pertencem a esses operadores de instalação; eles não podem ser atribuídos à 365.hosting.

Um inquilino pode ocupar um armário em um grande data center, e o tamanho do prédio não diz nada sobre a capacidade livre do inquilino.

Mesmo os 1.024 endereços IPv4 roteados não são um limite de servidor. Um host pode carregar muitos endereços; um endereço pode servir muitos hosts virtuais; endereços podem ser reservados, roteados mas não utilizados, usados para appliances de rede ou atribuídos a clientes. Oresumo AS30344 do IP2Locationcorrobora os quatro /24s e o único upstream MIRhosting, mas seu total de endereços é uma medida de recurso de rede, não uma medida de computação.

A conclusão sobre capacidade é, portanto, explícita: as ofertas atuais e os recursos roteados demonstram um serviço operacional, mas a capacidade instalada, vendida, sobressalente e em condições de falha não são quantificadas publicamente. Qualquer número mais forte seria inventado.

Uma alegação de 99,9% precisa de um denominador

A página inicial da 365.hosting diz que alcançou 99,9% de disponibilidade ao longo de cinco anos, embora a mesma página diga que a marca opera desde 2022. Em julho de 2026, uma medição completa de cinco anos sob essa marca se estenderia antes da data de operação declarada. O número pode incluir um histórico de serviço mais antigo da WebHOST1, pode ser uma cópia de marketing arredondada, ou pode usar outro ponto de partida. A página não explica o denominador.

Em 99,9%, a aritmética permite cerca de 8 horas e 46 minutos de inatividade em um ano de 365 dias se medido continuamente. Esse cálculo não é evidência de inatividade real. Apenas mostra por que o escopo é importante. Disponibilidade do site, disponibilidade do painel de controle, acessibilidade da rede, estado de energia da VM e resposta do aplicativo podem cada um produzir uma porcentagem diferente. Manutenção planejada, força maior e incidentes causados pelo cliente podem ser excluídos de um SLA contratual mesmo quando permanecem visíveis aos usuários.

Apágina de trabalhos técnicospública não apresentou um arquivo de incidentes em inglês claro na visualização revisada. A página de contato diz que os clientes obtêm a resposta mais rápida através do sistema de pedidos do painel de faturamento e menciona separadamente um chat de suporte online das 9h às 21h, enquanto páginas mais amplas anunciam suporte 24/7. Essas declarações podem coexistir se os tickets forem monitorados 24 horas por dia, mas o chat não. Elas não publicam metas de resposta inicial ou restauração.

Sem um histórico de incidentes e SLA específico do serviço, a alegação de disponibilidade deve permanecer atribuída. Não pode ser usada para inferir que ambos os países, todos os produtos, o AS30344 ou a plataforma de gerenciamento alcançaram o mesmo resultado. Também não pode demonstrar recuperação dos modos de falha mais relevantes aqui: perder o AS52000, perder uma alimentação de rack, substituir um servidor dedicado, restaurar uma imagem de cliente ou mover uma carga de trabalho através das fronteiras.

Uma divulgação operacional útil publicaria disponibilidade de serviço por região, exclusões de manutenção, horários de início e término de incidentes, componentes afetados, causa raiz, remediação e se créditos contratuais foram emitidos. Essa evidência estava indisponível. A ausência não significa que ocorreram interrupções. Significa que a porcentagem anunciada não pode carregar o peso analítico de um registro de confiabilidade medido.

O plano de controle remonta à WebHOST1

O site público expõe uma segunda concentração que é mais fácil de perder do que o BGP. SeuHTML da página inicialpré-conecta aapi.webhost1.ru, seu conteúdo e navegação reutilizam rotas da WebHOST1, e grandes partes de seus dados de produto e referências de gerenciamento carregam hostnames WebHOST1. O DNS reverso em todo o AS30344 também usa repetidamentewebhost1.net. Ositemap da 365.hostingaponta para páginaswebhost1.ruem vez de um conjunto limpo de URLs específicos da marca.

Isso apoia a continuidade com uma plataforma operacional estabelecida. Pode permitir que a 365.hosting reuse sistemas de faturamento, provisionamento, conhecimento de suporte e gerenciamento de servidores em vez de construí-los do zero. Também cria um limite de falha e governança. Um cliente pode ter uma VM em execução cujos pacotes públicos fluem através do AS30344 enquanto ainda depende de outro domínio e plataforma para pedidos, pagamento, redefinição de senha, tickets, acesso ao console ou automação.

Apágina de documentos da 365.hostingexibiu links para uma oferta pública, limites de carregamento de conta e termos de dados pessoais, mas a página em inglês revisada não expôs um nome de empresa completo e prontamente auditável e um cronograma de serviço. A seção de detalhes bancários da página de contato também apareceu não preenchida na visualização em inglês renderizada. Isso torna difícil determinar a partir da superfície pública em inglês qual entidade legal exata fatura um cliente, quais termos regem os produtos dos EUA e dos Países Baixos, e se a Webhost LLC, 365.partners INC ou outra afiliada executa uma obrigação específica.

Isso não é evidência de que os contratos estão ausentes; os clientes podem receber termos completos durante o checkout. É evidência de que um cliente externo não pode verificar a cadeia contratual completa antes de entrar no fluxo de compra privado. Para soberania de dados, escalada de incidentes e planejamento de insolvência, essa distinção é importante. A parte que opera o painel de controle pode não ser a parte que detém o contrato de aluguel do rack ou a parte que origina a rota.

Um plano de saída robusto deve considerar ambos os planos. Backups de dados sem credenciais, imagens, zonas DNS e acesso à transferência de domínio podem não ser suficientes. Por outro lado, o acesso ao painel de controle é de valor limitado se a única cópia dos dados do cliente permanecer em armazenamento indisponível. O material público não especifica formatos de exportação, garantias de API, procedimentos de entrega de conta ou acesso de emergência se a plataforma normal falhar.

A falha começa onde a propriedade muda de mãos

O primeiro caminho de falha é o limite de rota visível. Se o AS30344 perder seu relacionamento com o AS52000, todos os cinco anúncios observados podem se tornar inacessíveis juntos, a menos que um alternativo não divulgado assuma. Clientes usando endereços originados em outro lugar podem se comportar de forma diferente, e é por isso que o mapeamento serviço-para-prefixo é importante. O registro público não o fornece.

O segundo caminho é específico da instalação. Em Secaucus, a H5 controla a camada de prédio agora atribuída a um nome histórico vXchnge. Nos Países Baixos, a oferta ainda diz Serverius enquanto a plataforma de instalação pública está se movendo sob o nome Kolo, e o local exato não é divulgado. Uma interrupção de utilidade, falha de UPS, problema de refrigeração, restrição de acesso ou manutenção da instalação pode afetar o serviço do cliente mesmo quando a própria equipe e roteadores da 365.hosting estão saudáveis.

O terceiro é falha de rack e hardware. “Racks próprios” concentra controle útil, mas também cria responsabilidade pela distribuição de energia, comutação de topo de rack, hipervisores, drives e peças sobressalentes. Uma janela de configuração de novo servidor de cinco a dez dias não pode ser tratada como um objetivo de substituição. Os clientes precisam saber se discos com falha são espelhados, se um host com falha aciona reinicialização automática de VM em outro lugar, se os dados de backup estão em um domínio de falha separado e quão rapidamente um servidor dedicado pode ser reconstruído.

O quarto é suporte operacional. A cópia pública promete ajuda 24 horas por dia, enquanto os horários de chat são mais restritos e as metas de ticket são não publicadas. Um incidente grave pode ser prolongado quando o provedor de hospedagem, upstream e operador da instalação esperam pelo diagnóstico de outra parte. Caminhos de escalada nomeados e procedimentos conjuntos de incidentes são mais valiosos do que um crachá de suporte genérico.

O quinto é faturamento e controle de conta. Infraestrutura WebHOST1 compartilhada, scripts de pagamento de terceiros e painéis de faturamento privados podem se tornar dependências de serviço. Uma disputa de pagamento, retenção por fraude, cartão expirado ou comprometimento de conta pode remover o acesso de gerenciamento mesmo enquanto o hardware funciona. As páginas públicas não declaram um período de carência, sequência de suspensão, contato de emergência ou direito de exportação.

O sexto é migração. O site anuncia migração gratuita e reembolso de 30 dias para alguns serviços. Isso reduz o custo inicial de troca, mas não prova saída rápida. Grandes conjuntos de dados, configurações privadas, reputação de IP dedicado, tempo de DNS e dependências de aplicativos podem tornar a migração mais lenta do que o provisionamento de servidor. Nenhuma página revisada promete imagens de VM portáteis, largura de banda de exportação em massa, snapshots retidos após o cancelamento ou evacuação assistida durante um problema na instalação.

Estas não são alegações de falha. São a cadeia de dependências criada pelo acordo operacional público. O ponto fraco não é necessariamente um componente; é o handoff entre componentes cujos contratos e comportamento de recuperação testado não são divulgados.

Dois países de vendas ainda não formam um par de recuperação

A presença de ofertas nos EUA e nos Países Baixos convida a uma suposição comum: se um local falhar, as cargas de trabalho podem se mover para o outro. As páginas públicas não fazem essa promessa. Elas vendem locais independentemente. Não descrevem serviço ativo-ativo, armazenamento replicado, orquestração compartilhada, rede privada comum, failover de DNS ou capacidade de espera reservada.

A recuperação entre locais também cruzaria uma fronteira legal e de latência. Mover dados dos Países Baixos para Nova Jersey pode alterar a jurisdição aplicável, obrigações de notificação ao cliente, mecanismo de transferência e atraso de ida e volta. Um cliente que selecionou os Países Baixos para processamento europeu não pode assumir que a restauração nos EUA é aceitável. O tópico controlado de soberania de dados é relevante precisamente porque a localização faz parte do produto, não porque a evidência prova uma violação de conformidade.

Mesmo dentro dos Países Baixos, as quatro instalações listadas da Kolo não podem ser contadas como redundância da 365.hosting. A Kolo anuncia opções de resiliência em vários locais, mas a 365.hosting não identifica sua instalação nem afirma que os dados do cliente são replicados para outra. Um hall neutro em termos de operadora cria opções; não cria um segundo serviço contratado automaticamente.

Da mesma forma, as instalações da MIRhosting em ambos os países não provam que o AS30344 tem handoffs independentes em ambos. A visão BGP de um vizinho pode cobrir múltiplos links físicos para o mesmo AS, ou pode cobrir um. Os dados públicos não os distinguem. Uma declaração de redundância crível nomearia os locais, circuitos e teste de falha, preservando detalhes de segurança legítimos.

Os clientes devem, portanto, tratar o menu de países como uma escolha de posicionamento, não uma arquitetura de recuperação. Aqueles que precisam de continuidade em caso de perda de local devem projetá-la e adquiri-la explicitamente: replicação de aplicativo, credenciais separadas, DNS independente, backups fora da conta principal, restauração testada, reservas de capacidade e uma base legal para o local secundário. O material público do provedor não mostra que esses controles estão incluídos por padrão.

Quem está exposto quando o sistema falha

A alegação da página inicial de “20.000+ projetos” implica uma base de usuários significativa, mas nenhum detalhamento independente conecta esse número aos serviços atuais do AS30344. Observações de DNS reverso e domínios hospedados confirmam que o espaço roteado carrega sistemas voltados para a internet. Eles não revelam se esses sistemas pertencem a pequenos sites, agências, serviços de software, servidores de jogos, lojas, ferramentas corporativas internas ou revendedores de infraestrutura.

A linguagem do produto aponta para vários grupos afetados. Clientes VPS podem perder aplicativos web, bancos de dados, VPNs e ambientes de desenvolvimento quando um host ou rota falha. Clientes de servidor dedicado podem enfrentar uma substituição de hardware mais longa porque seu ambiente está vinculado a um chassi específico. Clientes de domínio e DNS podem ser afetados em uma camada de controle mesmo que seu conteúdo esteja hospedado em outro lugar. Revendedores podem amplificar um incidente upstream em muitos clientes finais que talvez nunca tenham ouvido falar da 365.hosting.

O impacto no cliente também depende da continuidade do endereço. Mover uma carga de trabalho para outro provedor sem reter o mesmo IP pode interromper listas de permissões, reputação de correio, cache DNS, integrações de API e regras de segurança. Os quatro /24s são, portanto, ativos operacionais além de seu tamanho numérico. No entanto, nenhuma política de portabilidade pública diz se um cliente pode trazer um endereço, anunciar seu próprio prefixo, reter um IP durante a migração ou obter serviço BGP.

Perda de dados e indisponibilidade são resultados separados. Uma falha de rota pode tornar dados intactos inacessíveis. Uma falha de armazenamento pode destruir dados enquanto a rede permanece saudável. Um bloqueio de faturamento pode bloquear o controle enquanto os serviços públicos continuam temporariamente. O planejamento de recuperação deve identificar qual estado está sendo protegido: acessibilidade de pacotes, energia da VM, durabilidade dos dados, acesso de gerenciamento ou correção do aplicativo.

A divulgação limitada significa que os clientes devem fornecer grande parte dessa resiliência por conta própria. Backups fora do provedor, etapas de reconstrução documentadas, DNS secundário, credenciais de domínio independentes, monitoramento de mais de uma rede e migração ensaiada reduzem a dependência de alegações que não podem ser verificadas externamente. A necessidade é maior para clientes cujos próprios usuários assumem que comprar um serviço de “nuvem” inclui failover invisível.

O que a evidência apoia, e o que não apoia

A evidência apoia chamar a 365.hosting de um provedor de hospedagem operacional associado a um sistema autônomo ativo registrado nos EUA. Seu domínio resolve dentro do AS30344. Seus prefixos IPv4 estão sendo anunciados, o bloco mais novo entrou em roteamento imediatamente após a atribuição, o DNS reverso mostra uso de hospedagem, e as páginas de produto aceitam um vocabulário comercial detalhado de processadores, discos, canais e locais. Isso é materialmente mais forte do que um cartão de diretório construído apenas a partir de um nome.

Também apoia uma descoberta de concentração específica. No instantâneo de 15 de julho, todas as rotas AS30344 observadas tinham um único vizinho AS, MIRhosting AS52000. Quatro origens IPv4 eram válidas no RPKI; a origem IPv6 era desconhecida, não inválida. A evidência de rota não diz nada sobre links de backup ocultos, mas nenhuma prova pública de um segundo trânsito ou failover testado foi encontrada.

A evidência física apoia Secaucus em nível de cidade e histórico de instalação para a oferta dos EUA, com uma correção: a H5, não a vXchnge, agora apresenta a instalação da 200B Meadowlands Parkway. Para a oferta holandesa, apoia um rótulo de produto legado Serverius e uma plataforma Kolo atual com quatro locais holandeses, sem identificar Dronten, Meppel, Apeldoorn ou Amsterdã como o local da 365.hosting. Não apoia Wyoming como localização de servidor.

A evidência de capacidade apoia especificações atuais de plano e uma janela de provisionamento dedicado de cinco a dez dias. Não divulga contagens de servidores instalados ou disponíveis, ocupação de rack, largura de banda agregada, energia, inventário sobressalente, porcentagem vendida ou capacidade utilizável após uma falha. As métricas de 99,9% e cliente/projeto permanecem alegações de marketing sem detalhes de medição publicados.

A evidência corporativa apoia uma afiliação pública entre 365.hosting, 365.partners e WebHOST1 através de contatos, domínios, infraestrutura de página e registros compartilhados. Não torna cada recurso AS198178 parte do AS30344 nem prova que outra rede do grupo é um standby. Tampouco divulga qual entidade deve a cada cliente o serviço completo.

Esta é uma descoberta de rede de intensidade média e uma divulgação de infraestrutura de fraca a média. O rebaixamento é deliberado. A origem da rota e a loja são reais; os limites operacionais e de recuperação exatos permanecem muito opacos para uma conclusão de resiliência mais forte.

A próxima prova deve ser operacional, não promocional

A correção mais fácil é editorial: atualizar o nome da instalação de Secaucus e identificar a H5 como a operadora atual, enquanto explica o papel da 365.hosting e da MIRhosting. Um cliente não deve ter que reconciliar um post de lançamento de 2026 com a identidade atual do site da H5 e fontes de aquisição que datam a transação em 2021 ou 2022. A página dos Países Baixos deve atualizar o rótulo Serverius para a transição Kolo e identificar o código da instalação e cidade relevantes da Kolo.

O próximo passo é uma matriz serviço-para-infraestrutura. Para cada família de produtos dos EUA e dos Países Baixos, a 365.hosting poderia declarar o operador da instalação, entidade contratante, origem da rota, upstreams, local de backup, canal de suporte e SLA aplicável. Não precisa revelar números de rack ou topologia sensível. Deve deixar claro se o cliente compra uma VM, chassi dedicado ou serviço gerenciado e quais componentes são compartilhados.

Para resiliência de rede, uma nota de failover datada resolveria grande parte da incerteza: o número de relacionamentos de trânsito do AS30344, se eles terminam em instalações separadas, se IPv4 e IPv6 têm a mesma proteção, e o último teste de retirada de rota bem-sucedido. A visão de vizinho único seria então interpretável como limitação do coletor, design intencional ou concentração genuína.

Para capacidade, as métricas úteis não são a contagem total de endereços ou a metragem quadrada da instalação. São hosts instalados, racks energizados, configurações disponíveis, hardware sobressalente, largura de banda agregada comprometida e objetivos de substituição. O status deve distinguir capacidade projetada, instalada, energizada, em serviço, vendida, reservada e disponível. Um provedor pode divulgar faixas ou porcentagens quando números exatos são comercialmente sensíveis.

Para recuperação, os clientes precisam de objetivos de ponto e tempo de restauração, domínios de falha de backup, formatos de exportação de imagem e um caminho documentado para fora da plataforma. A recuperação entre fronteiras deve ser opt-in e legalmente explícita. Um reembolso de 30 dias é uma garantia comercial; não é um design de recuperação de desastre.

Finalmente, o registro público de status deve conter incidentes e manutenção em inglês consistente, com local afetado, serviço, horário de início e término, impacto, causa e remediação. A Serverius já demonstra o valor dessa prática em seus próprios avisos de NOC. Estender essa clareza à camada de cliente da 365.hosting faria mais pela confiança do que outro crachá genérico de disponibilidade.

Até que essas provas apareçam, a leitura mais precisa permanece estreita. A 365.hosting colocou espaço de endereço real em serviço, incluindo um /24 recém-atribuído. Ela vende hardware identificável em dois países e parece embutida em um grupo de hospedagem mais amplo. Mas na visão revisada de 15 de julho, a rota mais nova ainda encontrava a internet pública através de um único upstream visível, o rótulo da instalação nos EUA estava pelo menos quatro anos atrasado em relação ao registro do operador, e o rótulo holandês não se resolvia para um dos quatro locais da Kolo.

Nem o catálogo de vendas nem a tabela de rota provam quanta capacidade sobrevive à falha de um rack, local, contrato ou plano de controle.