Le nouveau 23.26.1.0/24 de 365.hosting se trouve derrière un seul fournisseur amont visible et une étiquette périmée de Secaucus

Résumé

• AS30344 est actif, pas seulement enregistré. Le 15 juillet 2026, RIPEstat montrait quatre annonces IPv4 /24 et une IPv6 /40; le bloc IPv4 le plus récent, 23.26.1.0/24, a été attribué à 365.hosting le 6 mai et est apparu dans les données de routage le 7 mai. Les quatre origines IPv4 étaient valides selon RPKI dans l'instantané examiné, tandis que la route IPv6 renvoyait un état de validation inconnu.
• Les observations de routes publiques ont montré un seul voisin, MIRhosting AS52000. Cela constitue une concentration significative à la frontière AS visible, même si MIRhosting lui-même dispose de multiples fournisseurs amont, connexions d'échange et installations. Aucune preuve publiée ne démontre un second transit AS30344, des entrées physiquement diverses, un basculement testé ou une capacité de remplacement équivalente.
• 365.hosting vend des serveurs VPS et dédiés aux États-Unis et aux Pays-Bas et déclare utiliser ses propres racks dans des centres de données Tier III. Sa page américaine identifie toujours le site de Secaucus comme vXchnge NJ01, bien que H5 Data Centers répertorie désormais le même site du 200B Meadowlands Parkway. Sa page VPS néerlandaise contient un texte hérité de WebHOST1 affirmant que l'équipement de WebHOST1 se trouve chez Serverius; la page de transition de Kolo indique que Serverius opère désormais sous le nom de Kolo, dont le portefeuille actuel comprend quatre sites néerlandais. Aucune des deux ne mentionne le rack correspondant de 365.hosting ou le site de Kolo. Le nombre de racks, la charge IT installée, l'inventaire disponible, le taux d'occupation, la capacité électrique et la capacité de restauration intersite restent non divulgués.

L'ajout de 256 adresses rend le réseau plus facile à voir

Le moyen le plus utile d'aborder 365.hosting n'est pas la promesse de centres de données premium de sa page d'accueil. C'est un petit changement daté dans le registre d'adresses public.L'enregistrement d'ARIN pour 23.26.1.0/24indique que le bloc de 256 adresses a été attribué à 365.hosting le 6 mai 2026. Unerequête d'historique RIPEstatmontre AS30344 l'annonçant à partir du 7 mai. La séquence est inhabituellement nette: attribution un jour, route visible le lendemain.

Ce nouveau bloc est important car il confirme une activité réseau actuelle sans nécessiter un témoignage client ou un lancement promotionnel. Le 15 juillet, lavue des préfixes annoncéscontenait quatre /24 IPv4: 23.26.1.0/24, 23.152.200.0/24, 77.91.126.0/24 et 138.124.187.0/24. Elle contenait également 2602:2d3::/40. Le total IPv4 est de 1 024 adresses. Le /40 IPv6 est une allocation de routage, pas un décompte de serveurs, clients ou machines virtuelles utilisables.

Ce même instantané fixe également la première limite de l'histoire.La vue des voisins AS de RIPEstata trouvé un voisin du côté gauche, AS52000.La page AS30344 d'IPinfoa de même classé MIRhosting comme le seul fournisseur amont et qualifié AS30344 de réseau stub. Un stub est un AS qui annonce ses propres routes mais qui n'est pas observé en train de fournir du transit à des réseaux en aval. C'est une forme opérationnelle cohérente pour un réseau d'hébergement modeste. Ce n'est pas une preuve de diversité de routes.

L'évaluation initiale correcte n'est donc ni « réseau de papier » ni « cloud résilient prouvé ». AS30344 est actif, son espace d'adressage est joignable et de nouvelles ressources ont été mises en routage. Mais sa sortie publiquement visible de l'AS reste concentrée. Cette distinction comptera chaque fois que le site de vente promet haute disponibilité, plusieurs pays ou service 24h/24.

La marque vend plus que ce qu'AS30344 peut décrire

Lapage d'accueil de 365.hostingprésente un catalogue d'infrastructure conventionnel mais large. Elle liste les VPS/VDS, serveurs dédiés, domaines, certificats SSL, administration de serveurs et modules de sécurité. Elle indique que l'entreprise opère depuis 2022, a des implantations aux États-Unis, en Europe et en Asie, utilise « ses propres racks » dans des installations Tier III ainsi que des sites partenaires, prend en charge plus de 20 000 projets et fait partie du groupe international 365.partners. Elle affiche également de grands compteurs marketing, notamment des sites Web actifs et une revendication de disponibilité de 99,9 % sur cinq ans.

Ces déclarations établissent ce que la marque veut que les clients achètent. Elles n'allouent pas de ressources physiques à AS30344. L'affirmation de racks propres ne précise pas les identifiants de racks, les baux, les halls d'installation, les alimentations électriques ou la société propriétaire des serveurs. Les compteurs de projets et de sites Web n'expliquent pas s'ils couvrent uniquement 365.hosting, l'ancienne plateforme WebHOST1, le groupe 365.partners, les enregistrements de domaines, les comptes dormants ou le calcul payant en direct.

Le chiffre de disponibilité ne divulgue pas la période de mesure, le dénominateur de service, les exclusions de maintenance ou le journal des incidents.

Les pages produits sont plus tangibles.La page des serveurs dédiés aux États-Unislistait des configurations Intel double socket, une adresse IPv4, 30 To de trafic, un canal nominal de 1 Gbps pour l'offre standard, un délai de mise en service de cinq à dix jours et une administration initiale gratuite. Elle affichait également une configuration haut de gamme avec un canal de 10 Gbps.La page des serveurs dédiés aux Pays-Basproposait de même un système double Xeon, stockage NVMe, une adresse IPv4, 30 To de trafic, un canal de 1 Gbps et le même délai de mise en service.

Ce sont des preuves d'une boutique en ligne dotée de personnel et de produits définis. Ce n'est pas un rapport d'inventaire en temps réel. Une fiche de forfait peut rester en ligne alors qu'un châssis est en commande, qu'un rack est plein, qu'un prix est obsolète ou qu'un emplacement est temporairement indisponible. Le délai de mise en service de cinq à dix jours est particulièrement révélateur: la capacité dédiée n'est pas nécessairement un pool instantanément provisionné. Elle peut dépendre de techniciens, de pièces détachées, de mains supplémentaires, d'assemblage de serveurs, de rodage, de câblage et d'attribution d'adresses.

Le produit est une promesse de livrer du matériel après un délai, pas la preuve que toutes les configurations annoncées sont installées et inactives aujourd'hui.

Le réseau et le catalogue doivent également être séparés. Le serveur d'un client pourrait utiliser l'espace AS30344, un autre ASN de groupe, des adresses fournies par l'installation ou une allocation du fournisseur amont. Inversement, une adresse AS30344 peut héberger de l'infrastructure qui n'est pas vendue sous la fiche produit américaine ou néerlandaise actuelle. Sans un mappage publié entre service, préfixe, installation et contrat, l'ASN est l'identité réseau la plus claire mais pas un inventaire complet de la plateforme commerciale.

Sheridan est l'adresse du registre, pas la salle des serveurs

Leregistre ARIN du système autonomenomme 365-HOSTING, marque AS30344 comme actif et le lie au handle d'organisation PARTN-46. Leregistre ARIN de l'organisationassocié donne 30 N Gould Street, Suite R, Sheridan, Wyoming, et l'adresse de support de 365.hosting. Lapage de contactde l'entreprise répète la même adresse au Wyoming et le même numéro de téléphone.

Cela fait de Sheridan un lieu administratif et de registre solide. Cela n'en fait pas un emplacement de centre de données. Il n'y a aucune mention d'installation sur la page de contact, aucune description de l'alimentation ou du refroidissement pour le Wyoming, et aucune mesure de route publique plaçant les serveurs dans ce bâtiment. Traiter une adresse d'enregistrement comme coordonnée de rack réduirait la présence légale et les opérations physiques à un seul point non étayé.

Le domaine ajoute une chronologie différente. Laréponse RDAP de CentralNic pour 365.hostingenregistre la création du domaine en juillet 2022 et nomme ns1.365.hosting et ns2.365.hosting. Le DNS public du 15 juillet résolvait le site en 23.152.200.43, dans un préfixe AS30344. Les noms d'hôte de messagerie et de services de noms se situent également dans des adresses associées au même réseau. Cela donne à la marque une relation technique directe avec AS30344, plus forte qu'un agrégateur associant simplement un nom.

Mais même cela n'établit pas précisément la chaîne corporative. La page d'accueil indique que 365.hosting fait partie de 365.partners. Lapage membre RIPE NCC de 365.partners INCdonne la même adresse à Sheridan, le même numéro de téléphone et un domaine de messagerie365.hosting, et liste des zones de service en Allemagne, au Royaume-Uni, en Israël et aux Pays-Bas.La page AS198178 d'IPinfoassocie ce plus grand réseau de 365.partners à 365.hosting et montre une empreinte d'adresses considérablement plus large qu'AS30344.

Ces identifiants communs soutiennent une affiliation opérationnelle telle que représentée publiquement par la marque et les registres. Ils ne justifient pas de fusionner AS30344 et AS198178, d'attribuer chaque préfixe du groupe à cette entité d'annuaire, ou de supposer qu'un ASN est une sauvegarde automatique pour l'autre. Des origines de routes séparées peuvent partager des contacts et un contrôle commercial tout en utilisant différents fournisseurs amont, installations et politiques d'exploitation. Une revendication de rétablissement nécessite une conception de basculement déclarée, pas seulement un nom apparenté.

Les quatre blocs IPv4 ne partagent pas le même historique de registre

Les 1 024 adresses IPv4 annoncées par AS30344 semblent uniformes dans une table de routage: quatre /24 identiques. Leurs historiques d'enregistrement ne sont pas uniformes. Cette différence est un avertissement utile contre le fait de considérer l'espace routé comme un pool unique et détenu.

ARIN a directement alloué 23.152.200.0/24à 365.hosting en mai 2023. Le plus récent 23.26.1.0/24 est une attribution d'un bloc parent plus grand, enregistrée en mai 2026.L'entrée de la base RIPE pour 77.91.126.0/24nomme le réseauWebhost_LLC, décrit 365.partners INC dans les remarques et porte le même contact Sheridan.L'entrée RIPE pour 138.124.187.0/24nomme Webhost LLC à Moscou et indique que le sous-réseau est utilisé pour fournir des serveurs virtuels et dédiés gérés par les clients eux-mêmes.

Ces enregistrements soutiennent une image opérationnelle dans laquelle 365.hosting annonce un mélange de ressources d'adresses directement allouées, attribuées et liées au groupe. Ils ne prouvent pas la propriété des quatre blocs au sens ordinaire de la propriété. Les ressources numériques Internet sont administrées selon les politiques des registres et peuvent être réattribuées, sous-allouées ou routées par accord. Les différentes organisations et remarques font partie de la frontière de contrôle, pas une nuisance administrative à effacer.

Le DNS inverse fournit des preuves limitées d'utilisation.La vue d'IPinfo de 23.152.200.0/24montrait la plupart des adresses avec des noms statiqueswebhost1.netet identifiait ns1.365.hosting, ns2.365.hosting et le nom d'hôte principal de 365.hosting. Savue 77.91.126.0/24incluaitvm.365.hostingparmi des noms similaireswebhost1.net. Lavue 138.124.187.0/24montraitmail.365.hostinget d'autres enregistrements inverses de style WebHOST1.

Ce sont des preuves solides que la marque et l'ancien environnement d'exploitation WebHOST1 partagent une surface de contrôle. Ce sont de faibles preuves pour l'identité individuelle des clients, le nombre de serveurs ou l'emplacement physique. Les noms inversés peuvent persister après des déménagements, être générés automatiquement, ou pointer vers une convention de gestion plutôt qu'un bâtiment. Ils ne doivent pas être convertis en un inventaire de 1 024 serveurs actifs.

L'autorisation de route vaut mieux que la redondance de route

Les quatre annonces IPv4 avaient une propriété de sécurité utile au moment de l'examen. Le validateur RPKI de RIPEstat a retournévalidpour23.152.200.0/24,23.26.1.0/24,77.91.126.0/24et138.124.187.0/24lorsqu'ils sont annoncés par AS30344. Cela signifie que les réseaux utilisant la validation d'origine de route avaient l'autorité cryptographique pour accepter cet appariement ASN-préfixe.

La route IPv6 était différente. Le validateur a retournéunknownpour2602:2d3::/40car il n'a trouvé aucune ROA validante dans cette réponse. Inconnu n'est pas invalide. Cela signifie que la validation d'origine de route n'a fourni aucune autorisation positive pour cette paire. La distinction importe pour la posture de sécurité, mais un état valide ou inconnu ne dit rien sur la bande passante, la congestion, l'alimentation de l'installation ou le basculement client.

RPKI est donc un contrôle d'intégrité du routage, pas un mécanisme de redondance. Une route parfaitement autorisée peut encore disparaître lorsqu'un routeur tombe en panne, qu'un contrat de transit expire, qu'une fibre est coupée ou qu'une modification de maintenance échoue. Elle peut rester visible mais subir des pertes de paquets. Inversement, une route avec un seul voisin visible peut hériter d'une portée considérable du réseau mondial de ce voisin, mais elle dépend toujours de l'interface commerciale et technique entre les deux systèmes.

La topologie publique incite à la prudence plutôt qu'à l'alarme. Les collecteurs de routes n'observent pas toutes les interconnexions privées, et une session de sauvegarde peut être configurée mais inactive. Un second opérateur peut également exister au niveau 2 tandis qu'AS52000 reste le seul voisin BGP. Les preuves ne peuvent pas prouver qu'il n'y a pas de veille cachée ou froide. Elles peuvent prouver qu'aucun second voisin AS n'était visible dans la vue RIPEstat du 15 juillet et que l'entreprise n'avait pas publié de test en démontrant un.

MIRhosting est un réseau important, mais il reste le point de jonction visible

AS52000 n'est pas une petite terminaison mono-opérateur.La page société de MIRhostingliste plus de dix emplacements de centres de données en Europe, aux États-Unis et en Asie, notamment Secaucus et 60 Hudson Street à New York, plusieurs sites néerlandais, Francfort et Bombay.L'enregistrement PeeringDB d'AS52000décrit un réseau mondial avec 1-5 Tbps de trafic, une politique de peering ouverte, plusieurs échanges et installations, et des contacts NOC et abus 24h/24.BGP.toolsliste plusieurs fournisseurs amont, dont Arelion, GTT, Cogent et Tata, ainsi que des connexions d'échange.

Cette étendue réduit la tentation d'assimiler « un voisin AS » à « un câble physique vers tout Internet ». MIRhosting peut acheminer AS30344 via un réseau doté de ses propres routeurs redondants, fournisseurs amont et sites. L'échantillon de traceroute d'IPinfo atteignait une adresse AS30344 via un routeur MIRhosting identifié près de New York, cohérent avec un chemin de service américain. Cependant, cela ne révèle pas combien de ports relient AS30344 à AS52000, si ces ports entrent dans différents bâtiments, ou si les services néerlandais et américains utilisent des points d'interconnexion séparés.

La jonction reste réelle. Si chaque chemin externe visible pour AS30344 dépend de l'acceptation et de la propagation de ses routes par AS52000, alors une erreur de politique, une suspension commerciale, un filtre de fuite de route, une réponse DDoS ou une défaillance du plan de contrôle partagé à cette frontière peut affecter les quatre préfixes IPv4 et le préfixe IPv6 ensemble. La diversité des fournisseurs amont de MIRhosting ne protège pas automatiquement contre une panne spécifique à la relation AS30344-AS52000.

Les clients ont besoin d'une réponse plus précise que le mot « redondant ». Une preuve utile inclurait un second AS de transit actif, un historique de collecteur de routes montrant les deux chemins, des interconnexions d'installation séparées, la capacité des ports, des dates de test de basculement et la preuve que les préfixes de service restent joignables après la désactivation de l'une ou l'autre interconnexion. Rien de cela n'a été trouvé dans les documents publics examinés pour ce profil. Le réseau doit donc être décrit comme actif et accessible mondialement, avec une seule relation de fournisseur amont observée publiquement.

L'étiquette Secaucus a survécu à l'opérateur

Le produit américain est physiquement spécifique sur un point.L'annonce de 365.hosting pour le New Jersey, datée du 7 mars 2026, indique que ses serveurs cloud NVMe se trouvent dans « vXchnge Secaucus » et décrit une installation de 54 121 pieds carrés près de New York. La page des serveurs dédiés appelle le site vXchnge NJ01. Cela donne aux clients plus qu'une simple région « USA »: cela pointe vers Secaucus, New Jersey.

Le nom de l'opérateur est obsolète, mais la date publique d'acquisition elle-même nécessite une mise en garde.L'annonce d'acquisition en direct de H5est datée du 31 janvier 2021, tandis quela confirmation contemporaine de centres de données Dynamicsest datée du 31 janvier 2022. Le conflit sur la source d'un an empêche une déclaration d'âge plus précise; les deux dates précèdent l'avis de lancement du 7 mars 2026 de 365.hosting d'au moins quatre ans.La page actuelle des installations de H5liste son centre de données du New Jersey au 200B Meadowlands Parkway, Secaucus, le décrit comme une installation Tier III de plus de 38 000 pieds carrés et le commercialise pour la continuité d'activité new-yorkaise.L'enregistrement d'installation PeeringDBl'appelle H5 Data Centers Secaucus (NJ01), donne la même adresse et ne conserve « vXchnge Secaucus (NJ01) » que comme nom historique alternatif.

Le décalage ne prouve pas que les serveurs de 365.hosting ont quitté le bâtiment ou que le service est indisponible. Un contrat client et un rack peuvent survivre à une vente d'installation. Il montre que la description publique de l'entreprise n'a pas été mise à jour vers l'opérateur actuel.

Cela affaiblit la confiance dans les affirmations adjacentes plus difficiles à vérifier, comme quelle partie fournit les mains supplémentaires, quel accord de niveau de service s'applique, qui reçoit une escalade lors d'un incident d'installation et si les 54 121 pieds carrés cités décrivent l'empreinte du bâtiment, la surface commercialisée antérieurement ou l'espace vendable actuel.

Cela modifie également la dépendance contractuelle. Si H5 contrôle désormais le site tandis que 365.hosting contrôle les serveurs ou racks et MIRhosting fournit le chemin réseau visible, alors un client dépend d'au moins trois couches opérationnelles. H5 maintient l'accès au bâtiment, l'alimentation, le refroidissement et les procédures d'installation. 365.hosting provisionne et prend en charge le service serveur. MIRhosting assure la relation BGP visible. Des fournisseurs de matériel supplémentaires, des processeurs de paiement et des plateformes de gestion se situent derrière ces couches.

Aucun contrat public examiné ici ne montre quelle couche doit un recours au client final lorsque deux couches ne s'accordent pas sur la cause d'une panne.

La déclaration de localisation la plus sûre est étroite: 365.hosting commercialise publiquement des serveurs américains dans une installation à Secaucus historiquement connue sous le nom de vXchnge NJ01; H5 présente actuellement le site du 200B Meadowlands Parkway comme son installation dans le New Jersey. Les preuves publiques n'identifient pas le rack de 365.hosting, la charge installée, la cage, les interconnexions actuelles ou la capacité vendable restante à l'intérieur.

L'emplacement néerlandais n'est nommé qu'au niveau du groupe d'installations

L'offre néerlandaise est également réelle mais moins précise géographiquement.L'avis de lancement de 365.hosting aux Pays-Bas, également daté du 7 mars, indique que les serveurs virtuels sont devenus disponibles dans un centre de données de Serverius.La page VPS Pays-Bascontient du texte hérité de WebHOST1: elle indique que WebHOST1 propose le service et utilise son propre équipement dans un centre de données Serverius. C'est une affirmation de WebHOST1 exposée sur la surface de 365.hosting, pas la preuve que 365.hosting possède l'équipement. La page décrit également la virtualisation KVM, le stockage SSD avec RAID10, un canal de 100 Mbps pour le forfait et un remboursement sous 30 jours. La page dédiée élève le canal annoncé à 1 Gbps pour son matériel listé.

Serverius n'est plus non plus l'étiquette publique autonome actuelle.La page de transition de Koloindique que Serverius et Fuzion opèrent désormais sous le nom de Kolo, avec les mêmes emplacements et services, et que la marque unifiée est officiellement lancée le 17 juillet.Le portefeuille néerlandais de Kololiste quatre sites: NL1 Dronten, NL2 Meppel, NL3 Apeldoorn et NL4 Amsterdam. Ce sont des affirmations de la plateforme Kolo, pas une carte de l'équipement de 365.hosting. La page de 365.hosting ne dit pas quelle installation, salle ou rack détient le service concerné, et aucun enregistrement public d'interconnexion ne relie AS30344 à un site Kolo spécifique.

Ce manque d'identifiant de site limite à la fois l'analyse de localité et de rétablissement. Un client choisissant « Pays-Bas » peut raisonnablement s'attendre à un traitement des données dans le pays lorsque le service fonctionne comme commercialisé. La page publique ne divulgue pas si les sauvegardes restent dans le même bâtiment, un autre site Serverius, les États-Unis ou une plateforme de gestion ailleurs. Elle ne dit pas si un hôte néerlandais défaillant peut être restauré à Secaucus, si le consentement du client est requis pour un tel déplacement, ou combien de temps prendraient le transfert d'image et de données.

Lesavis NOC toujours servis sur le domaine Serveriusillustrent pourquoi ces distinctions importent et utilisent déjà les étiquettes KoloDC. En 2026, le site a publié une maintenance du refroidissement au NL1 Dronten et des travaux de fibre noire entre NL1 Dronten et NL2 Meppel, expliquant que des fibres alternatives devraient prendre le relais tout en avertissant d'une possible latence ou perte de paquets pendant la reconvergence des routes. C'est une divulgation opérationnelle saine de la part du réseau d'installations. Cela ne prouve pas que 365.hosting occupait l'un ou l'autre site affecté ou participait au chemin alternatif. Cela montre simplement le type de maintenance physique que cache une étiquette « Pays-Bas ».

Le niveau de preuve néerlandais est donc moyen pour la disponibilité du service au niveau national et faible pour le placement exact des actifs. Les pages produits rendent l'offre crédible, tandis que la transition Serverius vers Kolo établit l'identité actuelle de la plateforme d'installation sans localiser le service. Les sources n'établissent pas une adresse, un inventaire installé, une capacité électrique, une propriété de rack ou une réplication intersite pour 365.hosting.

Les fiches de capacité ne sont pas une déclaration de capacité

La boutique publie des unités commerciales utiles: type de processeur, mémoire, disque, canal, volume de trafic, nombre d'IPv4, délai de mise en service et période de facturation. Ce sont des droits du client s'ils sont fournis dans le cadre du contrat applicable. Ils ne peuvent pas être additionnés pour calculer la capacité du fournisseur car le site ne publie pas le nombre de serveurs disponibles ou d'hôtes de virtualisation derrière chaque fiche.

Un forfait VPS néerlandais était affiché comme indisponible lors de l'examen. C'est un petit signal opérationnel mais précieux. Il suggère que le catalogue peut exposer un état de disponibilité plutôt que d'accepter chaque configuration sans limite. Il démontre également pourquoi une spécification de forfait n'est pas une capacité installée. Un droit à un disque de 20 Go et un port 100 Mbps sur un forfait indisponible ne fournissent aucun service utilisable à un nouveau client.

Les pages de serveurs dédiés indiquent un délai de mise en service de cinq à dix jours. Cela peut représenter un provisionnement normal plutôt qu'une pénurie, mais cela expose le rôle de l'inventaire matériel et de la main-d'œuvre. Si un serveur de production tombe en panne, la question pertinente n'est pas de savoir si une référence correspondante existe sur le site Web. C'est de savoir si un châssis équivalent, un jeu de mémoire, un périphérique NVMe, une allocation électrique et un technicien sont disponibles sur le même site selon un objectif de remplacement convenu.

Aucune page examinée n'a divulgué le nombre de racks, le nombre de serveurs, le nombre d'hyperviseurs, le total de cœurs CPU, le stockage installé, le stock de disques de rechange, la capacité sous tension, la bande passante engagée, le sur-abonnement, le pourcentage vendu ou l'inventaire réservé. L'affirmation de la page d'accueil concernant les racks propres reste non quantifiée. La taille de l'installation H5 et l'échelle de la plateforme Kolo appartiennent à ces opérateurs d'installations; elles ne peuvent pas être attribuées à 365.hosting.

Un locataire peut occuper une armoire dans un grand centre de données, et la taille du bâtiment ne dit rien sur la capacité libre du locataire.

Même les 1 024 adresses IPv4 routées ne sont pas une limite de serveurs. Un hôte peut porter de nombreuses adresses; une adresse peut faire face à de nombreux hôtes virtuels; les adresses peuvent être réservées, routées mais inutilisées, utilisées pour des équipements réseau ou attribuées à des clients. Lerésumé IP2Location AS30344corrobore les quatre /24 et le seul fournisseur amont MIRhosting, mais son total d'adresses est une mesure de ressource réseau, pas une mesure de calcul.

La conclusion sur la capacité est donc explicite: les offres actuelles et les ressources routées démontrent un service en fonctionnement, mais la capacité installée, vendue, de réserve et en condition de panne n'est pas quantifiée publiquement. Tout chiffre plus fort serait inventé.

Un chiffre de 99,9 % a besoin d'un dénominateur

La page d'accueil de 365.hosting indique avoir atteint 99,9 % de disponibilité sur cinq ans, alors que la même page indique que la marque opère depuis 2022. En juillet 2026, une mesure complète de cinq ans sous cette marque s'étendrait avant la date de début annoncée. Le chiffre peut inclure un historique de service plus ancien de WebHOST1, être une copie marketing arrondie, ou utiliser un autre point de départ. La page n'explique pas le dénominateur.

À 99,9 %, l'arithmétique permet environ 8 heures et 46 minutes de panne sur une année de 365 jours en cas de mesure continue. Ce calcul n'est pas une preuve d'indisponibilité réelle. Il montre seulement pourquoi le périmètre importe. La disponibilité du site Web, la disponibilité du panneau de contrôle, l'accessibilité réseau, l'état d'alimentation des VM et la réponse de l'application peuvent chacun produire un pourcentage différent. La maintenance planifiée, les cas de force majeure et les incidents causés par le client peuvent être exclus d'un SLA contractuel même lorsqu'ils restent visibles pour les utilisateurs.

Lapage des travaux techniquespublique ne présentait pas d'archive d'incidents claire en anglais dans la vue examinée. La page de contact indique que les clients obtiennent la réponse la plus rapide via le système de demande du panneau de facturation et mentionne séparément un chat de support en ligne de 9 h à 21 h, tandis que des pages plus larges annoncent un support 24h/24 et 7j/7. Ces déclarations peuvent coexister si les tickets sont surveillés 24h/24 mais pas le chat. Elles ne publient pas d'objectifs de réponse initiale ou de rétablissement.

Sans historique d'incidents et SLA spécifique au service, la revendication de disponibilité doit rester attribuée. Elle ne peut pas être utilisée pour déduire que les deux pays, chaque produit, AS30344 ou la plateforme de gestion ont obtenu le même résultat. Elle ne peut pas non plus démontrer le rétablissement après les modes de panne les plus pertinents ici: perte d'AS52000, perte d'une alimentation de rack, remplacement d'un serveur dédié, restauration d'une image client ou déplacement d'une charge de travail au-delà des frontières.

Une divulgation opérationnelle utile publierait la disponibilité du service par région, les exclusions de maintenance, les heures de début et de fin d'incident, les composants affectés, la cause racine, la correction et si des crédits contractuels ont été émis. Cette preuve n'était pas disponible. L'absence ne signifie pas que des pannes se sont produites. Cela signifie que le pourcentage annoncé ne peut pas supporter le poids analytique d'un enregistrement de fiabilité mesuré.

Le plan de contrôle remonte jusqu'à WebHOST1

Le site public expose une deuxième concentration plus facile à manquer que BGP. SonHTML de la page d'accueilse préconnecte àapi.webhost1.ru, son contenu et sa navigation réutilisent les routes WebHOST1, et de grandes parties de ses données produit et références de gestion portent des noms d'hôte WebHOST1. Le DNS inverse sur AS30344 utilise également de manière répétéewebhost1.net. Lesitemap de 365.hostingpointe vers des pageswebhost1.ruplutôt que vers un ensemble d'URL propres et spécifiques à la marque.

Cela soutient la continuité avec une plateforme d'exploitation établie. Cela peut permettre à 365.hosting de réutiliser les systèmes de facturation, de provisionnement, de support et de gestion des serveurs plutôt que de les construire à partir de zéro. Cela crée également une frontière de défaillance et de gouvernance. Un client peut avoir une VM en fonctionnement dont les paquets publics transitent par AS30344 tout en dépendant d'un autre domaine et d'une autre plateforme pour la commande, le paiement, la réinitialisation du mot de passe, les tickets, l'accès à la console ou l'automatisation.

Lapage de documents de 365.hostingaffichait des liens pour une offre publique, des limites de charge du compte et des conditions relatives aux données personnelles, mais la page anglaise examinée n'exposait pas un nom d'entreprise complet et facilement vérifiable ni un calendrier de service. La section des coordonnées bancaires de la page de contact semblait également non remplie dans la vue anglaise rendue. Cela rend difficile la détermination, à partir de la surface anglaise publique, de la personne morale exacte qui facture un client, quelles conditions régissent les produits américains et néerlandais, et si Webhost LLC, 365.partners INC ou une autre filiale exécute une obligation particulière.

Ce n'est pas la preuve que les contrats sont absents; les clients peuvent recevoir des conditions complètes lors du paiement. C'est la preuve qu'un client externe ne peut pas vérifier la chaîne contractuelle complète avant d'entrer dans le flux d'achat privé. Pour la souveraineté des données, l'escalade des incidents et la planification de l'insolvabilité, cette distinction importe. La partie qui exploite le panneau de contrôle peut ne pas être la partie qui détient le bail du rack ou la partie qui annonce la route.

Un plan de sortie robuste doit tenir compte des deux plans. Les sauvegardes de données sans identifiants, images, zones DNS et accès au transfert de domaine peuvent ne pas suffire. Inversement, l'accès au panneau de contrôle a une valeur limitée si la seule copie des données client reste sur un stockage indisponible. Les documents publics ne précisent pas les formats d'exportation, les garanties API, les procédures de transfert de compte ou l'accès d'urgence si la plateforme normale tombe en panne.

La défaillance commence là où la propriété change de mains

Le premier chemin de défaillance est la frontière de route visible. Si AS30344 perd sa relation avec AS52000, les cinq annonces observées pourraient devenir toutes injoignables à moins qu'un alternatif non divulgué ne prenne le relais. Les clients utilisant des adresses annoncées ailleurs pourraient se comporter différemment, ce qui explique pourquoi le mappage service-à-préfixe est important. Le dossier public ne le fournit pas.

Le deuxième chemin est spécifique à l'installation. À Secaucus, H5 contrôle la couche du bâtiment désormais attribuée à un nom historique vXchnge. Aux Pays-Bas, l'offre mentionne encore Serverius tandis que la plateforme d'installation publique se déplace sous le nom de Kolo, et le site exact n'est pas divulgué. Une interruption de service public, un défaut d'onduleur, un problème de refroidissement, une restriction d'accès ou une maintenance de l'installation peuvent affecter le service client même lorsque le personnel et les routeurs de 365.hosting sont en bonne santé.

Le troisième est la défaillance du rack et du matériel. « Nos propres racks » concentre un contrôle utile mais crée également une responsabilité pour la distribution d'énergie, la commutation en tête de rack, les hyperviseurs, les disques et les pièces de rechange. Un délai de mise en service de cinq à dix jours pour un nouveau serveur ne peut pas être traité comme un objectif de remplacement.

Les clients doivent savoir si les disques défaillants sont en miroir, si un hôte défaillant déclenche un redémarrage automatique de VM ailleurs, si les données de sauvegarde se trouvent dans un domaine de défaillance séparé et à quelle vitesse un serveur dédié peut être reconstruit.

Le quatrième est le support opérationnel. Les textes publics promettent une aide 24h/24, tandis que les heures de chat sont plus restreintes et les objectifs de tickets ne sont pas publiés. Un incident grave peut se prolonger lorsque le fournisseur d'hébergement, le fournisseur amont et l'opérateur de l'installation attendent chacun le diagnostic de l'autre partie. Des voies d'escalade nommées et des procédures d'incident conjointes sont plus précieuses qu'un badge de support général.

Le cinquième est la facturation et le contrôle du compte. L'infrastructure partagée WebHOST1, les scripts de paiement tiers et les panneaux de facturation privés peuvent devenir des dépendances de service. Un litige de paiement, un blocage pour fraude, une carte expirée ou un compromis de compte peut supprimer l'accès à la gestion même si le matériel fonctionne. Les pages publiques ne définissent pas de période de grâce, de séquence de suspension, de contact d'urgence ou de droit d'exportation.

Le sixième est la migration. Le site fait la promotion d'une migration gratuite et d'un remboursement sous 30 jours pour certains services. Cela réduit le coût initial de changement, mais ne prouve pas une sortie rapide. Les grands ensembles de données, les configurations privées, la réputation dédiée des IP, le timing DNS et les dépendances applicatives peuvent rendre la migration plus lente que le provisionnement des serveurs. Aucune page examinée ne promet d'images VM portables, de bande passante d'exportation en vrac, d'instantanés conservés après l'annulation ou d'évacuation assistée lors d'un problème d'installation.

Ce ne sont pas des allégations de défaillance. C'est la chaîne de dépendance créée par l'arrangement opérationnel public. Le point faible n'est pas nécessairement un composant; c'est l'interface entre les composants dont les contrats et le comportement de rétablissement testé ne sont pas divulgués.

Deux pays de vente ne font pas encore une paire de rétablissement

La présence d'offres américaines et néerlandaises invite à une hypothèse courante: si un site tombe en panne, les charges de travail peuvent passer à l'autre. Les pages publiques ne font pas cette promesse. Elles vendent les emplacements indépendamment. Elles ne décrivent pas un service actif-actif, un stockage répliqué, une orchestration partagée, un réseau privé commun, un basculement DNS ou une capacité de veille réservée.

Le rétablissement intersite franchirait également une frontière légale et de latence. Le déplacement des données des Pays-Bas vers le New Jersey peut modifier la juridiction applicable, les obligations d'information du client, le mécanisme de transfert et le délai aller-retour. Un client qui a choisi les Pays-Bas pour un traitement européen ne peut pas supposer que la restauration américaine est acceptable. Le sujet contrôlé de la souveraineté des données est pertinent précisément parce que la localisation fait partie du produit, pas parce que les preuves établissent une violation de conformité.

Même aux Pays-Bas, les quatre installations listées de Kolo ne peuvent pas être comptées comme une redondance de 365.hosting. Kolo fait la promotion d'options de résilience multisite, mais 365.hosting n'identifie pas son installation ni ne déclare que les données des clients sont répliquées vers une autre. Un hall neutre crée des options; il ne crée pas automatiquement un second service contracté.

De même, les installations de MIRhosting dans les deux pays ne prouvent pas qu'AS30344 dispose de points d'interconnexion indépendants aux deux endroits. La vue BGP à un seul voisin peut couvrir plusieurs liens physiques vers le même AS, ou elle peut en couvrir un seul. Les données publiques ne les distinguent pas. Une déclaration de redondance crédible nommerait les sites, les circuits et le test de défaillance tout en préservant les détails de sécurité légitimes.

Les clients doivent donc traiter le menu des pays comme un choix d'emplacement, pas une architecture de rétablissement. Ceux qui ont besoin de continuité en cas de perte de site doivent la concevoir et l'acheter explicitement: réplication d'application, identifiants séparés, DNS indépendant, sauvegardes en dehors du compte principal, restauration testée, réservations de capacité et une base juridique pour l'emplacement secondaire. Les documents publics du fournisseur ne montrent pas que ces contrôles sont inclus par défaut.

Qui est exposé en cas de panne du système

La revendication de la page d'accueil de « 20 000+ projets » implique une base d'utilisateurs significative, mais aucune ventilation indépendante ne relie ce nombre aux services actuels d'AS30344. Les observations de DNS inverse et de domaines hébergés confirment que l'espace routé transporte des systèmes accessibles sur Internet. Elles ne révèlent pas si ces systèmes appartiennent à de petits sites Web, des agences, des services logiciels, des serveurs de jeux, des boutiques, des outils internes d'entreprise ou des revendeurs d'infrastructure.

Le langage des produits pointe vers plusieurs groupes affectés. Les clients VPS peuvent perdre des applications Web, des bases de données, des VPN et des environnements de développement lorsqu'un hôte ou une route tombe en panne. Les clients de serveurs dédiés peuvent faire face à un remplacement matériel plus long car leur environnement est lié à un châssis spécifique. Les clients de domaines et DNS peuvent être affectés au niveau de la couche de contrôle même si leur contenu est hébergé ailleurs. Les revendeurs peuvent amplifier un incident en amont sur de nombreux clients finaux qui n'ont peut-être jamais entendu parler de 365.hosting.

L'impact sur le client dépend également de la continuité des adresses. Le déplacement d'une charge de travail vers un autre fournisseur sans conserver la même IP peut perturber les listes blanches, la réputation du courrier, la mise en cache DNS, les intégrations API et les règles de sécurité. Les quatre /24 sont donc des actifs opérationnels au-delà de leur taille numérique. Pourtant, aucune politique de portabilité publique ne dit si un client peut apporter une adresse, annoncer son propre préfixe, conserver une IP pendant la migration ou obtenir un service BGP.

La perte de données et l'indisponibilité sont des résultats distincts. Une panne de route peut rendre des données intactes inaccessibles. Une panne de stockage peut détruire des données alors que le réseau reste sain. Un verrouillage de facturation peut bloquer le contrôle tandis que les services publics continuent temporairement. La planification du rétablissement doit identifier quel état est protégé: l'accessibilité des paquets, l'alimentation des VM, la durabilité des données, l'accès à la gestion ou la correction de l'application.

La divulgation limitée signifie que les clients doivent fournir eux-mêmes une grande partie de cette résilience. Les sauvegardes hors fournisseur, les étapes de reconstruction documentées, le DNS secondaire, les identifiants de domaine indépendants, la surveillance depuis plus d'un réseau et une migration répétée réduisent la dépendance aux affirmations qui ne peuvent pas être vérifiées extérieurement. Le besoin est le plus grand pour les clients dont les propres utilisateurs supposent que l'achat d'un service « cloud » inclut un basculement invisible.

Ce que les preuves soutiennent, et ce qu'elles ne soutiennent pas

Les preuves soutiennent le fait de qualifier 365.hosting de fournisseur d'hébergement en activité associé à un système autonome actif enregistré aux États-Unis. Son domaine résout à l'intérieur d'AS30344. Ses préfixes IPv4 sont annoncés, le bloc le plus récent est entré en routage immédiatement après attribution, le DNS inverse montre une utilisation d'hébergement, et les pages produits utilisent un vocabulaire commercial détaillé de processeurs, disques, canaux et emplacements. C'est matériellement plus fort qu'une carte d'annuaire construite uniquement à partir d'un nom.

Elle soutient également une constatation de concentration spécifique. Le 15 juillet, toutes les routes AS30344 observées avaient un voisin AS visible, MIRhosting AS52000. Les quatre origines IPv4 étaient valides RPKI; l'origine IPv6 était inconnue plutôt qu'invalide. Les preuves de routage ne disent rien sur les liens de sauvegarde cachés, mais aucune preuve publique d'un second transit ou d'un basculement testé n'a été trouvée.

Les preuves physiques soutiennent Secaucus au niveau de la ville et de l'historique d'installation pour l'offre américaine, avec une correction: H5, et non vXchnge, présente désormais l'installation du 200B Meadowlands Parkway. Pour l'offre néerlandaise, elles soutiennent une étiquette produit héritée de Serverius et une plateforme Kolo actuelle avec quatre sites néerlandais, sans identifier Dronten, Meppel, Apeldoorn ou Amsterdam comme l'emplacement de 365.hosting. Elles ne soutiennent pas le Wyoming comme emplacement de serveur.

Les preuves de capacité soutiennent les spécifications actuelles des forfaits et un délai de provisionnement dédié de cinq à dix jours. Elles ne divulguent pas le nombre de serveurs installés ou disponibles, l'occupation des racks, la bande passante totale, l'alimentation, l'inventaire des pièces de rechange, le pourcentage vendu ou la capacité utilisable après une panne. Les chiffres de 99,9 % et de clients/projets restent des affirmations marketing sans détail de mesure publié.

Les preuves corporatives soutiennent une affiliation publique entre 365.hosting, 365.partners et WebHOST1 via des contacts partagés, des domaines, une infrastructure de page et des enregistrements de registre. Elles ne font pas de chaque ressource AS198178 une partie d'AS30344 ni ne prouvent qu'un autre réseau du groupe est une veille. Elles ne divulguent pas non plus quelle entité doit à chaque client le service complet.

C'est une conclusion réseau de force moyenne et une divulgation d'infrastructure faible à moyenne. La dégradation est délibérée. L'origine de route et la boutique sont réelles; les limites exactes d'exploitation et de rétablissement restent trop opaques pour une conclusion plus forte sur la résilience.

La prochaine preuve devrait être opérationnelle, pas promotionnelle

La correction la plus simple est éditoriale: mettre à jour le nom de l'installation de Secaucus et identifier H5 comme l'opérateur actuel, tout en expliquant le rôle de 365.hosting et MIRhosting. Un client ne devrait pas avoir à concilier un article de lancement de 2026 avec l'identité actuelle du site de H5 et des sources d'acquisition qui datent la transaction de 2021 ou 2022. La page néerlandaise devrait mettre à jour l'étiquette Serverius pour la transition Kolo et identifier le code d'installation Kolo pertinent et la ville.

L'étape suivante est une matrice service-infrastructure. Pour chaque famille de produits américains et néerlandais, 365.hosting pourrait indiquer l'opérateur d'installation, l'entité contractante, l'origine de route, les fournisseurs amont, l'emplacement de sauvegarde, le canal de support et le SLA applicable. Il n'est pas nécessaire de révéler les numéros de racks ou la topologie sensible. Il devrait préciser si le client achète une VM, un châssis dédié ou un service géré et quels composants sont partagés.

Pour la résilience réseau, une note de basculement datée dissiperait une grande partie de l'incertitude: le nombre de relations de transit d'AS30344, si elles se terminent dans des installations séparées, si IPv4 et IPv6 ont la même protection, et le dernier test de retrait de route réussi. La vue à voisin unique serait alors interprétable comme une limitation du collecteur, une conception intentionnelle ou une concentration réelle.

Pour la capacité, les mesures utiles ne sont pas le nombre total d'adresses ou la superficie de l'installation. Ce sont les hôtes installés, les racks sous tension, les configurations disponibles, le matériel de rechange, la bande passante totale engagée et les objectifs de remplacement. Le statut devrait distinguer la capacité conçue, installée, sous tension, en service, vendue, réservée et disponible. Un fournisseur peut divulguer des fourchettes ou des pourcentages lorsque les chiffres exacts sont commercialement sensibles.

Pour le rétablissement, les clients ont besoin d'objectifs de point de restauration et de temps de restauration, de domaines de défaillance de sauvegarde, de formats d'exportation d'images et d'une voie documentée de sortie de la plateforme. Le rétablissement transfrontalier devrait être facultatif et juridiquement explicite. Un remboursement sous 30 jours est une garantie commerciale; ce n'est pas une conception de reprise après sinistre.

Enfin, le registre de statut public devrait comporter les incidents et la maintenance dans un anglais cohérent, avec l'emplacement affecté, le service, l'heure de début et de fin, l'impact, la cause et la correction. Serverius démontre déjà la valeur de cette pratique dans ses propres avis NOC. Étendre cette clarté à la couche client de 365.hosting ferait plus pour la confiance qu'un autre badge générique de disponibilité.

Jusqu'à ce que ces preuves apparaissent, la lecture la plus précise reste étroite. 365.hosting a mis en service un espace d'adressage réel, dont un /24 nouvellement attribué. Il vend du matériel identifiable dans deux pays et semble intégré dans un groupe d'hébergement plus large. Mais dans la vue du 15 juillet examinée, la route la plus récente rencontrait encore Internet public via un seul fournisseur amont visible, l'étiquette de l'installation américaine avait au moins quatre ans de retard sur son enregistrement d'exploitant, et l'étiquette néerlandaise ne se résolvait pas à l'un des quatre sites de Kolo.

Ni le catalogue de vente ni la table de routage ne prouvent la capacité qui survit à la défaillance d'un rack, d'un site, d'un contrat ou du plan de contrôle.