Resumen
- Network LIGA HOSTING LTD es la identidad de infraestructura del negocio de alojamiento público de LIGA HOSTING LTD. El registro de Companies House recoge el número de empresa 17069738 como una sociedad limitada privada activa en Inglaterra y Gales, constituida el 4 de marzo de 2026 con el código SIC 63110, mientras que los propios términos de la empresa indican que la operación de alojamiento está activa desde 2019 y presta servicio a clientes en más de 30 países.
- La superficie de servicio público es lo suficientemente real como para probarla: LigaHosting anuncia VPS Estándar en Tulcea y Fráncfort, VPS de Rendimiento Ryzen 9 9950X en Fráncfort, alojamiento web con cPanel y copias de seguridad diarias de siete días, y alojamiento de juegos bajo la marca rumana. El mismo sitio afirma tener AS201131, protección DDoS, enlaces ascendentes de 10-40 Gbps, aprovisionamiento de VPS en menos de 60 segundos y un SLA mensual del 99,9% para red e infraestructura central.
- AS201131 es actualmente visible. La consulta RDAP de RIPE identifica AS201131 como LGH-Network, registrado a nombre de LIGA HOSTING LTD el 3 de marzo de 2026; la vista más reciente del estado de enrutamiento de RIPEstat muestra tres /24 de IPv4 y dos /48 de IPv6 con visibilidad total o casi total en RIS. Los tres pares de prefijo-origen IPv4 verificados pasan la validación RPKI, mientras que los dos /48 de IPv6 actuales devolvieron validación desconocida en la vista de RIPEstat consultada.
- El grado de evidencia esMedio. Las pruebas de enrutamiento público, productos, estado y contratos avalan una operación de alojamiento en funcionamiento, pero el registro aún no demuestra la propiedad de los bastidores, los operadores de las instalaciones, las rutas de alimentación redundantes, el hardware de repuesto, la diversidad de rutas dentro de cada centro, las restauraciones probadas ni los derechos de migración de los clientes.
Una nueva empresa británica envuelta en una historia de alojamiento más antigua
El primer hecho que hay que separar es la identidad legal del historial operativo.El registro de Companies Houserecoge LIGA HOSTING LTD con el número de empresa 17069738, activa, constituida el 4 de marzo de 2026, con domicilio social en 3rd Floor, 86-90 Paul Street, Londres, EC2A 4NE y naturaleza del negocio 63110, procesamiento de datos, alojamiento y actividades relacionadas. Lapágina de directivosindica que Ionel-Florin Florin Moisa es director activo, nombrado en la fecha de constitución. Elregistro de personas con control significativomuestra a Ionel-Florin Moisa con propiedad de acciones y derechos de voto del 75% o más, además del derecho a nombrar o destituir directores.
Esto hace que la empresa sea visible, pero joven. Sus primeras cuentas no vencen hasta diciembre de 2027 y su primera declaración de confirmación no vence hasta marzo de 2027. Por lo tanto, los clientes aún no pueden consultar un historial de presentaciones consolidado, un registro contable extenso ni una secuencia larga de eventos corporativos. Esto importa cuando un comprador evalúa si un servidor de bajo coste es una contraparte duradera o una marca de alojamiento de rápida rotación que podría cambiar de forma jurídica, de acuerdos de recursos de direcciones o de proveedores operativos.
El sitio público cuenta una historia comercial más larga. Lostérminos de LigaHosting, actualizados por última vez el 29 de abril de 2026, indican que LIGA HOSTING LTD opera las marcas ligahosting.com para VPS internacional y alojamiento web cPanel, y ligahosting.ro para alojamiento de juegos, que está activa desde 2019, presta servicio a clientes en más de 30 países y gestiona infraestructura de VPS en Rumanía y Alemania. Esa declaración de historia más antigua bien podría describir la marca o la operación comercial antes de que se constituyera la empresa británica. No debe interpretarse como un historial de Companies House para el número de empresa 17069738.
La distinción no es pedante. Si un servicio tiene clientes antiguos, paneles más veteranos o contratos de infraestructura anteriores, una empresa nueva puede heredar algunas prácticas operativas sin heredar un historial legal extenso. Si la empresa es un envoltorio formalizado recientemente alrededor de un negocio de alojamiento rumano o europeo ya existente, los clientes deberían preguntar qué entidad jurídica firma el contrato actual, qué entidad posee o alquila el hardware, qué entidad tiene las cuentas de proveedor y qué ocurre con los servicios existentes si otra marca, cuenta de revendedor o panel antiguo permanece en la cadena.
Tampoco la sede social de Londres es una afirmación de centro de datos. La dirección de Companies House y los datos estructurados de organización del sitio identifican un domicilio corporativo, no una ubicación de bastidor. Es coherente con una empresa británica que vende infraestructura rumana y alemana. No establece que los datos de los clientes se procesen en el Reino Unido, que el personal de soporte esté en Londres o que la empresa posea una instalación en el Reino Unido. La historia del alojamiento debe contrastarse con las páginas de producto, las páginas de estado, las tablas de enrutamiento y los términos.
Lo que vende la superficie de producto público
Las páginas de producto muestran un servicio dirigido a compradores de alojamiento pequeños y medianos, en lugar de a una nube a hiperescala. Elsitio principal de LigaHostinganuncia "VPS Estándar y de Rendimiento", protección DDoS, despliegue instantáneo, conectividad de red prémium, hardware empresarial y alcance europeo en Rumanía y Alemania. Indica que AS201131 es la red troncal propia de la empresa y afirma que el aprovisionamiento de VPS tarda menos de 60 segundos. También anuncia enlaces ascendentes de 10-40 Gbps y respuestas de soporte en menos de 15 minutos. Son afirmaciones comerciales, pero lo suficientemente concretas como para traducirse en preguntas físicas.
Lapágina de VPS Estándarmenciona dos nodos de infraestructura: Tulcea, Rumanía, descrito como Estándar sobre hardware dual Intel Xeon Gold 6254, y Fráncfort, Alemania, descrito como Estándar sobre AMD EPYC 7702. Las tarjetas de planes abarcan desde instancias pequeñas de VPS hacia arriba e incluyen una dirección IPv4 y protección DDoS. Lapágina de VPS de Rendimientoconcentra el nivel de alta frecuencia en Fráncfort sobre procesadores AMD Ryzen 9 9950X, con planes que escalan desde 1 vCPU, 2 GB de RAM y 100 GB NVMe hasta 12 vCPU, 64 GB de RAM y 1,6 TB NVMe. Es una historia de computación concreta, no solo una etiqueta vacía de "nube".
Lapágina de alojamiento webañade una superficie de producto diferente: alojamiento cPanel, almacenamiento SSD, SSL gratuito, cuentas de correo y copias de seguridad diarias. Web Starter anuncia 20 GB de almacenamiento SSD y un sitio web. Web Pro amplía el almacenamiento y el alcance de las cuentas. Web Business anuncia almacenamiento SSD ilimitado, sitios web ilimitados y una IP dedicada gratuita. El cambio importante de dependencia es que el alojamiento cPanel concentra múltiples cuentas en servidores compartidos y sistemas administrativos compartidos, mientras que el alojamiento VPS otorga al comprador acceso root, pero también traslada más responsabilidad de copias de seguridad y configuración al comprador.
La marca rumana de alojamiento de juegos añade otra señal.LigaHosting.roanuncia alojamiento de servidores de juegos en Rumanía y Alemania, un objetivo de tiempo de actividad del 99,9%, soporte 24/7 y un panel de infraestructura que muestra Rumanía en 5.180.33.0/24 y Alemania en 163.5.26.0/24. Indica que la computación en Rumanía es una plataforma Intel Core i9-14900K con 192 GB DDR5 y 2 TB NVMe, mientras que Alemania es una plataforma AMD Ryzen 9 9950X con 128 GB DDR5 y 2 TB NVMe. Estas afirmaciones de las páginas coinciden con dos de los prefijos IPv4 visibles de AS201131, pero aún no identifican al operador de la instalación ni demuestran capacidad sobrante.
Lapágina de estadotambién es útil porque nombra las ubicaciones de servicio en términos operativos: Tulcea, Rumanía para VPS Estándar, y Fráncfort, Alemania para VPS Estándar, VPS de Rendimiento y Alojamiento Web. Mostraba "Todos los sistemas operativos" y ningún incidente activo en el momento de la consulta, con ambas ubicaciones marcadas como operativas. Una página de estado en verde en el momento actual no es un archivo de tiempo de actividad, pero indica a los clientes cuáles son los componentes que el proveedor considera como sus servicios públicos.
Esta evidencia es suficiente para afirmar que LigaHosting no es meramente una empresa fantasma inactiva. Tiene un catálogo público, ubicaciones de servicio activas, afirmaciones de procesador concretas, una página de estado para clientes, términos y una red en funcionamiento. No es suficiente para afirmar que la empresa es propietaria de los bastidores, controla los edificios o puede mover todas las cargas de trabajo entre regiones. Un comprador de VPS ve un nombre de plan, una familia de CPU y una dirección IP. La decisión sobre la resiliencia depende de lo que haya detrás de esas etiquetas.
AS201131 es visible, pero la visibilidad no equivale al control en todas partes
La evidencia técnica más sólida es la red.La consulta RDAP de RIPE para AS201131identifica AS201131 como LGH-Network, registrado el 3 de marzo de 2026 y modificado por última vez el 15 de junio de 2026, con LIGA HOSTING LTD como organización titular y contacto de abuso [email protected].El resumen de AS de RIPEstatidentifica al titular como "LGH-Network LIGA HOSTING LTD" y marca el ASN como anunciado. Esto alinea la afirmación del sitio con la evidencia de enrutamiento público.
El conjunto actual de rutas es compacto. Lavista de estado de enrutamiento de RIPEstatmostraba, para la última consulta del 12 de julio de 2026, tres prefijos IPv4 que sumaban 768 direcciones IPv4 y dos /48 de IPv6. Informaba de visibilidad IPv4 completa entre los pares RIS y visibilidad IPv6 casi completa. Lavista de prefijos anunciados de RIPEstattambién mostraba que varios /48 de IPv6 habían aparecido durante las dos semanas anteriores, pero ya no estaban en el conjunto de alta visibilidad actual al 12 de julio. Esto es bastante normal para una red pequeña, pero significa que los compradores deben distinguir entre las rutas de producción actuales y la visibilidad de rutas recientes o experimentales.
Los tres prefijos IPv4 actuales coinciden con la geografía de los productos.5.180.33.0/24,163.5.26.0/24y146.19.215.0/24eran visibles con AS201131 como origen en las vistas de resumen de prefijo de RIPEstat consultadas. El sitio rumano de juegos asigna explícitamente 5.180.33.0/24 a Rumanía y 163.5.26.0/24 a Alemania. Las páginas oficiales de productos y la página de estado sitúan los servicios de VPS y alojamiento web en Rumanía y Alemania. Esto ofrece una geografía plausible: Rumanía y Alemania son las regiones de servicio de cara al cliente, con la empresa británica como contraparte legal.
La seguridad del origen de ruta es un punto positivo para IPv4. Las validaciones RPKI de RIPEstat para5.180.33.0/24,163.5.26.0/24y146.19.215.0/24devolvieron válido para AS201131. Un RPKI válido no hace que un servidor sea fiable, pero reduce una clase de fallos de enrutamiento al indicar a las redes que realizan validación de origen que AS201131 está autorizado para anunciar esos prefijos.
La situación de IPv6 es más débil. Las comprobaciones de resumen de prefijo actuales para2a06:9801:c2::/48y2a06:9801:22c::/48los mostraban anunciados por AS201131, pero las URL de validación RPKI consultadas devolvieron desconocido en lugar de válido. Desconocido no es inválido. Significa que la vista consultada no encontró una autorización de origen de ruta validante para el par prefijo-origen consultado. Para los clientes que requieren IPv6 nativo y garantía de origen de ruta, esa es una cuestión que debe resolverse antes de la contratación.
La evidencia de los proveedores ascendentes requiere un lenguaje cuidadoso. Elregistro aut-num de la base de datos RIPEenumera políticas de importación y exportación que involucran a AS209735, AS58061, AS58212, AS213323 y AS207841. Lavista de vecinos ASN de RIPEstatobservó cuatro vecinos en el último momento comprobado: AS213323, AS397373, AS58061 y AS58212.CAIDA AS Rankveía AS201131 como un AS pequeño con tres proveedores, sin clientes observados y sin pares observados en su conjunto de datos. Los nombres y roles exactos difieren entre los registros de políticas de enrutamiento y los conjuntos de datos de observación, lo cual es esperable en BGP. La conclusión conservadora es que AS201131 está multiconectado en la observación pública, pero el registro público no prueba qué proveedores ascendentes dan servicio a cada ubicación, si ambos están activos en cada región o si las rutas de fibra y los pares de enrutadores son físicamente diversos.
PeeringDB añade una ausencia más. Laconsulta a la API de PeeringDB para AS201131no devolvió ningún objeto de red al ser comprobada. No es un defecto; muchas redes pequeñas no mantienen un perfil en PeeringDB. Sí significa que los clientes no pueden usar PeeringDB para confirmar presencias en instalaciones, LAN de intercambio, política pública de peering o niveles de tráfico. Para un operador que utiliza el lenguaje de "red troncal propia", publicar un perfil de interconexión básico haría que la superficie de control fuera más fácil de verificar.
La historia del bastidor se silencia en el punto más importante
Un servidor alojado se vende como un objeto software, pero falla como un objeto físico. El sitio puede aprovisionar un VPS en segundos solo porque un servidor real ya está alimentado, refrigerado, conectado y colocado en un bastidor. Un servidor de juegos puede anunciar baja latencia solo porque los paquetes se mueven a través de conmutación en la parte superior del bastidor, enrutadores de borde, proveedores de tránsito y mitigación DDoS. Una cuenta cPanel puede prometer copias de seguridad solo porque los trabajos de almacenamiento y copia de seguridad se ejecutan en algún lugar con suficiente disco, ancho de banda y atención del operador.
Para LigaHosting, las ubicaciones visibles son Tulcea y Fráncfort. Eso es mejor que una vaga afirmación de "Europa". La laguna restante es la identidad de la instalación. Las fuentes públicas revisadas para este artículo no identificaban al operador del centro de datos en Tulcea, la instalación de Fráncfort, la propiedad de los bastidores, el número de armarios, el diseño de la alimentación eléctrica, el proveedor de manos remotas, el alcance de la extinción de incendios, la redundancia de refrigeración, la sala de encuentro de operadores o el proceso de sustitución de hardware.
El sitio público dice "infraestructura cloud europea en Rumanía y Alemania"; no dice si LIGA HOSTING LTD posee hardware en bastidores coubicados, alquila servidores dedicados, revende una plataforma o mezcla esos modelos por producto.
Esto importa porque una instalación, un bastidor y un clúster de virtualización son capas diferentes. Un centro de datos en Fráncfort puede tener múltiples acometidas eléctricas, sistemas UPS y generadores, mientras que un inquilino sigue conectando un servidor con un solo cable a una regleta de alimentación. Un bastidor puede estar en una buena instalación mientras su conmutador en la parte superior del bastidor sigue siendo un único punto de fallo. Un servidor puede tener dos dispositivos NVMe mientras las instantáneas residen en el mismo nodo.
Un indicador verde a nivel de sitio puede coexistir con un host fallido o un conjunto de almacenamiento sobrecargado.
La evidencia del producto apunta a una plataforma compacta. La página de VPS Estándar menciona nodos Tulcea dual Intel Xeon Gold 6254 y Fráncfort AMD EPYC 7702. La página de Rendimiento menciona Fráncfort Ryzen 9 9950X. El sitio de juegos menciona plataformas Rumanía Core i9-14900K y Alemania Ryzen 9 9950X. Son clases de servidores de alojamiento conocidas, y pueden ofrecer una excelente relación precio-rendimiento para cargas de trabajo pequeñas. Por sí solos no demuestran la conmutación por error del clúster, la migración en vivo, el almacenamiento distribuido ni los servidores de repuesto.
Ladefinición de computación en la nube del NISTes útil aquí porque separa un verdadero conjunto de recursos elásticos de las máquinas virtuales alojadas ordinarias. Un producto VPS puede ofrecer amplio acceso a la red y cierto aprovisionamiento de autoservicio sin demostrar elasticidad rápida, servicio medido, agrupación entre hosts ni resiliencia en múltiples ubicaciones. La palabra "nube" en el pie de página de un sitio de alojamiento no determina la arquitectura. La prueba es si un cliente puede perder un nodo, bastidor o sitio y recuperarse dentro de un plazo conocido.
Para un proveedor pequeño, esta laguna no es inusual. Muchos negocios de alojamiento reales no publican contratos de instalaciones ni diagramas de bastidores. La cuestión no es que la información esté ausente de la página de inicio. La cuestión es que los clientes que compran cargas de trabajo de producción necesitan preguntar porque la evidencia no puede inferirse. ¿Qué productos son de un solo nodo? ¿Cuáles utilizan almacenamiento replicado? ¿Cuáles tienen instantáneas? ¿Son Rumanía y Alemania dominios de fallo independientes o simplemente ubicaciones de producto separadas? ¿Puede la máquina virtual de un cliente moverse entre ellas?
¿Se mueve la dirección IP con ella? Esas respuestas deciden si el producto es capacidad barata o capacidad resiliente.
La capacidad instalada no es capacidad recuperable
La tabla de enrutamiento da un límite superior de algunos recursos de red, no de computación. Tres /24 de IPv4 proporcionan 768 direcciones IPv4 en el conjunto de origen público actual. Un plan de una IPv4 por VPS puede consumir esas direcciones rápidamente, pero el recuento de direcciones no indica cuántos hosts físicos existen. Un servidor puede albergar muchas instancias de VPS de gama baja. Un cliente puede consumir muchas direcciones. Algunas direcciones quedan reservadas para infraestructura, sustitución por abuso, pruebas de enrutamiento o crecimiento futuro.
Por lo tanto, el recuento de IPv4 es una restricción, no un registro de capacidad.
Lo mismo se aplica a los procesadores anunciados. Un host Ryzen 9 9950X puede ser atractivo para cargas de trabajo de juegos de alta frecuencia y VPS de rendimiento. También puede convertirse en un dominio de fallo crítico si muchos servidores sensibles a la latencia comparten una misma máquina física. Un nodo AMD EPYC o Xeon dual puede albergar muchas instancias de VPS estándar, pero la capacidad sobrante depende del margen de memoria, del margen de almacenamiento, de la sobreasignación de CPU y de si hay otro nodo compatible disponible.
Las páginas públicas indican las especificaciones de los planes, no las ratios de sobreasignación ni los conjuntos de repuesto en caliente.
El almacenamiento es el otro límite oculto. NVMe puede significar unidades locales rápidas en un host, almacenamiento local reflejado, un servidor de almacenamiento separado o un sistema de almacenamiento distribuido. Cada diseño tiene un comportamiento de fallo diferente. El NVMe local puede ser extremadamente rápido hasta que falla una unidad, controladora o host. El almacenamiento local reflejado puede sobrevivir al fallo de una unidad, pero no a todos los fallos del host.
El almacenamiento distribuido puede tolerar la pérdida de nodos solo si las réplicas residen en máquinas independientes, el quórum sobrevive y el tráfico de reconstrucción no satura la red. Las páginas públicas de LigaHosting anuncian almacenamiento NVMe y SSD, pero no describen la arquitectura de durabilidad para los planes de VPS.
El producto de alojamiento web es más claro porque los términos dicen que los planes de alojamiento web cPanel reciben copias de seguridad automáticas diarias retenidas durante siete días. Es útil, pero no es lo mismo que la replicación continua o la copia de seguridad externa inmutable. Protege a algunos clientes de la pérdida del servidor y de errores comunes, siempre que las copias de seguridad se completen, sigan siendo legibles y se almacenen fuera del fallo que dañó el servidor principal.
Los términos dicen explícitamente que las copias de seguridad internas son para recuperación ante desastres a nivel de servidor y que el proveedor no garantiza su integridad o disponibilidad. Es una limitación cuidadosa, y los clientes deberían leerla como una advertencia para mantener sus propias copias.
El producto VPS es más claro en la dirección opuesta: las copias de seguridad no están incluidas por defecto. Los términos dicen que los clientes de VPS son responsables de sus propias copias de seguridad y que las instantáneas o copias de seguridad adicionales pueden estar disponibles por un cargo. Este es un límite honesto, pero cambia el producto de "el host restaurará mi servidor" a "el host puede mantener la VM funcionando, pero yo tengo la responsabilidad de la recuperabilidad a menos que compre y pruebe más".
Cualquier comprador que trate un VPS por defecto como infraestructura con copia de seguridad ha malinterpretado el acuerdo operativo.
El SLA del 99,9% del proveedor también debe leerse como un mecanismo de crédito, no como una garantía de recuperación.Los términosdefinen una disponibilidad mensual del 99,9% para la red y la infraestructura central, unos 43 minutos de tiempo de inactividad no planificado al mes, con exclusiones para mantenimiento planificado, ataques DDoS que superen la capacidad de mitigación, fuerza mayor, código del cliente y software de terceros. Si no se cumple el SLA, el recurso del cliente es un crédito en la cuenta vinculado al pago mensual, con un tope del 50%. Eso no reconstruye una base de datos, no devuelve una reputación de IP perdida ni compensa una interrupción del negocio más allá de la tarifa del servicio.
Esto es normal en la economía del alojamiento. Los precios mensuales bajos dependen de una responsabilidad limitada, sistemas compartidos, automatización y responsabilidad del cliente. La pregunta práctica es si los clientes han ajustado su propio riesgo a ese acuerdo. Un servidor de juegos para aficionados puede aceptar unas horas de inactividad y una restauración desde una copia local. Una agencia que aloja sitios de clientes, una aplicación orientada a pagos o un servidor de correo con listas blancas de IP deberían tratar el producto por defecto como solo un componente dentro de un plan de recuperación más amplio.
La diversidad de tránsito debe probarse dentro de cada ubicación de servicio
El enrutamiento público de AS201131 es una de las mejores partes del registro. Está activo, es compacto y visible. Las tres rutas IPv4 se validan, y RIPEstat observa múltiples vecinos. El sitio afirma tener enlaces ascendentes de 10-40 Gbps, conectividad europea prémium y protección DDoS en el borde de la red. Estos hechos respaldan una operación de red real. No prueban que cada ubicación tenga rutas físicas independientes.
La diferencia importa durante un fallo. Un servidor rumano puede tener una dirección de AS201131 mientras depende de un solo enlace ascendente local, un conmutador o una interconexión de instalación. Un nodo de rendimiento en Fráncfort puede estar detrás de una combinación de tránsito más sólida, pero seguir teniendo un solo par de enrutadores de cara al cliente. El filtrado DDoS puede funcionar bien hasta que el tamaño del ataque supere la capacidad contratada o el filtrado desvíe tráfico de manera que aumente la latencia para los servidores de juegos.
Una tabla BGP muestra la alcanzabilidad desde los colectores de rutas, no la ruta del cable a través de un edificio.
LaRFC 7454describe controles operativos como el filtrado de prefijos, controles de ruta AS, límites de prefijos máximos e higiene de políticas de enrutamiento. La validación RPKI complementa eso respondiendo si un origen de ruta está autorizado. El estado de origen de ruta IPv4 verificado de LigaHosting es positivo, pero la higiene BGP no es lo mismo que la ingeniería de disponibilidad. Una ruta válida puede seguir siendo retirada accidentalmente, filtrada por un proveedor ascendente, enviada a un agujero negro durante la mitigación o varada detrás de una interconexión fallida.
El registro de políticas de enrutamiento también muestra por qué los clientes deberían hacer preguntas directas. El aut-num de RIPE enumera importaciones de varios ASN, y RIPEstat observa un conjunto activo diferente. Esto no es sospechoso por sí mismo. Es como los registros de rutas y el BGP en vivo suelen diferir. Sin embargo, para la compra en producción, la pregunta relevante no es "¿cuántos nombres hay en el objeto de política?", sino "¿qué proveedores ascendentes transportan activamente el prefijo de este cliente desde este sitio, y qué ocurre si uno falla?".
La divulgación más útil sería una simple declaración de conectividad sitio por sitio: Rumanía tiene estos proveedores ascendentes, Fráncfort tiene estos otros, ambos están monitorizados, la mitigación DDoS se encuentra aquí, el mantenimiento planificado se anuncia a través de estos canales, y los cambios de ruta de emergencia son autorizados por estas personas. Los nombres de las instalaciones y las direcciones de los enrutadores no necesitan ser públicos. El objetivo es mostrar si la red anunciada como red troncal tiene rutas independientes donde realmente se ejecuta el servidor del cliente.
Para el alojamiento de juegos, la calidad de la ruta no es solo el tiempo de actividad. La latencia y la fluctuación importan. Una ruta que se mantiene activa pero se desvía a través de otro país puede hacer que un servidor parezca roto para los jugadores. El sitio de juegos mide la latencia desde el dispositivo del usuario y muestra sondeos de región, lo cual es útil en el momento de la compra. No sustituye los datos históricos de latencia, los informes de pérdida de paquetes ni las notas de incidentes.
Los clientes con cargas de trabajo competitivas o comunitarias deberían realizar sus propios sondeos desde las geografías de jugadores que importan.
La facturación y el control de cuenta son parte de la superficie de interrupción
Los términos hacen que una ruta de fallo sea inusualmente explícita. Los servicios se facturan por adelantado. Si una factura permanece impagada, se envían correos electrónicos de recordatorio durante los días uno y dos posteriores al vencimiento, el servicio se suspende automáticamente el día tres, aparece un aviso de terminación final el día siete, y el día catorce el servicio se termina y todos los datos se eliminan permanentemente. Los términos dicen que los datos eliminados no se pueden recuperar y que la reactivación después de la terminación requiere un nuevo pedido y no garantiza la misma IP, nombre de host ni datos.
Eso no es solo lenguaje financiero. Es una dependencia operativa. Un servidor en funcionamiento puede dejar de estar disponible porque una tarjeta falló, una cuenta de PayPal se bloqueó, la confirmación de criptomoneda se retrasó, el correo de factura fue a spam, un empleado de la agencia se fue o una cuenta del lado del cliente fue comprometida. Desde el exterior, el servicio está caído aunque el bastidor, la energía y la ruta estén en buen estado. El equipo técnico más rápido no puede restaurar una VM terminada cuyos datos han sido eliminados deliberadamente según las reglas de facturación.
La regla de eliminación en el día 14 también afecta a la migración. Si un cliente espera hasta que ya ha comenzado una disputa o un período de impago, el tiempo restante para exportar datos, reducir los valores de tiempo de vida de DNS, replicar bases de datos y probar otro proveedor puede ser corto. Si el titular de la cuenta está ausente, es posible que el propietario del servicio ni siquiera reciba los recordatorios. Por lo tanto, el acceso multipersonal a la cuenta, los contactos de facturación monitorizados y las copias de seguridad independientes son controles de tiempo de actividad, no minucias administrativas.
Los términos de reembolso refuerzan la misma economía. La garantía de devolución de 30 días se aplica a un primer pedido de servicio de alojamiento para nuevos clientes, no a dominios, tarifas de configuración marcadas como no reembolsables, servidores dedicados o hardware personalizado, renovaciones, cuentas canceladas por violaciones de los términos o ciertos casos de reembolso de criptomonedas. Eso es normal en el alojamiento. También significa que los clientes no deberían usar la reembolsabilidad como sustituto de las pruebas.
Una carga de trabajo debería ser evaluada, respaldada y restaurada en otro lugar durante el primer mes, cuando la fricción de salida es más baja.
El control de la cuenta también puede afectar la continuidad de la IP. Los términos no prometen que un servicio restaurado o reactivado conserve la misma dirección IP después de la terminación. Muchas cargas de trabajo alojadas pueden moverse detrás de DNS si el cliente controla la zona. Algunas no pueden. Las integraciones de pago, las listas blancas de seguridad, la reputación de correo, las comunidades de servidores de juegos y las API de socios a menudo dependen de IP estables. Un cliente que use LigaHosting debería documentar qué dependencias pueden tolerar un cambio de IP y cuáles requieren notificación previa o un segundo proveedor.
Las ventanas de mantenimiento y las pruebas de restauración deciden el producto real
Los términos públicos se comprometen a que el mantenimiento planificado se anuncie con al menos 48 horas de antelación y quede excluido del SLA. Es un estándar de notificación al cliente razonable, pero aún deja preguntas prácticas. ¿A través de qué canal se transmite el aviso? ¿Aparece en la página de estado, por correo electrónico, en el área de cliente o en Discord? ¿El aviso nombra la ubicación, el nodo o el producto afectado? ¿Puede un cliente posponer un reinicio? ¿Se maneja el mantenimiento de emergencia de manera diferente?
La página de estado actual muestra el estado en vivo, no un archivo de mantenimiento, por lo que un comprador todavía no puede inspeccionar cómo se comunicaron los trabajos anteriores.
Las ventanas de reparación son especialmente importantes para los proveedores de alojamiento pequeños porque el fallo a menudo cruza las fronteras de los proveedores. Si un nodo falla en Tulcea, el proveedor puede necesitar manos locales. Si una interconexión de Fráncfort falla, la instalación o el operador deben actuar. Si un proveedor de DDoS envía un destino a un agujero negro, el operador de red debe coordinar el filtrado. Si un nodo de rendimiento Ryzen tiene un fallo en la placa base, la sustitución depende de tener stock compatible.
Los clientes no necesitan todos los nombres de los proveedores, pero sí necesitan una expectativa de quién puede actuar y con qué rapidez.
Laguía de ransomware de CISArecomienda copias de seguridad cifradas fuera de línea, pruebas periódicas de disponibilidad e integridad, imágenes doradas y considerar un segundo proveedor de nube. La guía está escrita para incidentes cibernéticos, pero la misma disciplina de recuperación se aplica a la pérdida de almacenamiento, la suspensión de cuentas y el hardware fallido. Una copia de seguridad que nunca se ha restaurado es una esperanza, no un control.
Elmaterial de planificación de contingencias del NISTenmarca la recuperación en torno a equipos alternativos, ubicaciones alternativas, almacenamiento alternativo y telecomunicaciones. Para un cliente de LigaHosting, la versión práctica es sencilla: exporte la aplicación, restáurela en un proveedor diferente, apunte un nombre de host de prueba a ella, confirme la autenticación y el correo electrónico, y cronometre el ejercicio. Si la restauración requiere que el VPS original esté en línea, el plan de recuperación depende demasiado del sistema fallido.
Para los usuarios de cPanel, la ventana de copia de seguridad de siete días del proveedor es útil pero corta. Puede proteger contra una actualización rota descubierta rápidamente, pero puede no cubrir una corrupción lenta, un compromiso que permaneció oculto durante semanas o un cliente que solicita la recuperación después de que la cuenta haya sido cancelada. Para los usuarios de VPS, la situación por defecto es más cruda: no se incluyen copias de seguridad.
Las instantáneas pueden ayudar con una reversión inmediata, pero las instantáneas bajo la misma cuenta de proveedor no protegen contra el cierre de la cuenta, la eliminación por parte del proveedor o un incidente de servicio a nivel regional.
El patrón limpio para el cliente es, por lo tanto, escalonado. Mantenga las instantáneas del proveedor si son asequibles y están probadas. Mantenga copias de seguridad independientes fuera de la cuenta. Mantenga el DNS y el registro de dominio bajo el control del cliente. Almacene las notas de despliegue, las credenciales y la configuración en un sistema separado. Pruebe la restauración en una pequeña VM en otra ubicación. Para cargas de trabajo donde la propia dirección IP es parte del servicio, mantenga un plan de comunicación para cambiar listas blancas y una ruta de respaldo a través de otro proveedor.
La localidad se divide entre la constitución en el Reino Unido y la infraestructura de la UE
La empresa está constituida en Inglaterra y Gales. Las ubicaciones de servicio público son Rumanía y Alemania. La marca de alojamiento de juegos está orientada al mercado rumano y el texto del producto es bilingüe o multilingüe en la superficie pública. Este es un acuerdo de alojamiento europeo viable, pero significa que "local" depende de la pregunta del comprador. Un cliente del Reino Unido puede tener una contraparte legal británica y computación ubicada en la UE. Una comunidad de juegos rumana puede tener una región de servicio en Rumanía pero un contrato con una empresa británica.
Un cliente alemán de VPS de rendimiento puede preocuparse menos por el domicilio de la empresa que por el enrutamiento de Fráncfort y el manejo de datos.
Los datos personales convierten esto en una cuestión de contrato y mapeo. Laguía de transferencias internacionales de la ICOexplica que las organizaciones deben comprender cuándo se transfiere o se hace accesible información personal a través de las fronteras. Laguía de responsables y encargados del tratamiento de la ICOexplica por qué el rol de cada parte afecta a las obligaciones. Un cliente de alojamiento no puede responder a esas preguntas basándose solo en un código de país de IP.
La relación UE-Reino Unido tampoco es lo mismo que "en cualquier lugar de Europa es igual". Lainformación de adecuación de la Comisión Europeaexplica el mecanismo por el cual la Comisión puede decidir que un país no perteneciente a la UE ofrece una protección adecuada, y la Comisión anunció en enero de 2026 que renovó las decisiones de adecuación para el Reino Unido. Eso facilita los flujos de datos entre la UE y el Reino Unido, pero no resuelve todas las transferencias posteriores, el acceso de soporte remoto, el acceso de subcontratistas, las copias de seguridad o los registros.
La legislación de ciberseguridad de la UE añade otra perspectiva. LaDirectiva NIS 2cubre categorías importantes de infraestructura digital, incluidos los servicios de computación en la nube y los centros de datos, sujetos a la implementación nacional y a umbrales de tamaño o rol. Una pequeña empresa de alojamiento puede o no estar dentro de un ámbito nacional concreto, y este artículo no es una evaluación legal. El punto operativo es que los clientes deben identificar qué entidad presta el servicio, dónde se almacenan los datos y las copias de seguridad, y qué subcontratistas pueden acceder a los sistemas.
La soberanía de los datos también incluye el manejo de fallos. Si una copia de seguridad se copia a otro país, si el personal de soporte puede acceder a una consola desde otra jurisdicción, si la mitigación DDoS desvía el tráfico a través de otra red, o si los registros se conservan en un servicio SaaS de terceros, el mapa de datos práctico es más amplio que la ubicación anunciada del VPS.
Los términos públicos de LigaHosting dicen que el contenido del cliente sigue siendo propiedad del cliente y otorgan al proveedor un derecho limitado para almacenar, copiar para copias de seguridad y redundancia, y transmitir contenido para prestar los servicios. Los términos no publican un mapa de subencargados o ubicaciones de copia de seguridad desglosado por país.
Para cargas de trabajo ordinarias de bajo riesgo, la estructura Reino Unido-Rumanía-Alemania puede ser suficiente si el cliente la comprende. Para datos personales regulados, comunidades sensibles, cargas de trabajo del sector público o clientes con compromisos de localidad estrictos, el comprador debería solicitar un acuerdo de procesamiento de datos por escrito, un mapa de ubicaciones para los datos de producción y copia de seguridad, controles de acceso de soporte, normas de eliminación y detalles de subcontratistas. El sitio público ofrece un punto de partida, no una respuesta completa sobre soberanía.
Quién se ve afectado cuando el sistema falla
Los usuarios probablemente expuestos no son solo las personas cuyos nombres figuran en las facturas. Una pequeña agencia puede alojar muchos sitios de clientes en un solo plan cPanel o en varias instancias de VPS. Un propietario de un servidor de juegos puede dar soporte a una gran comunidad que solo conoce un nombre de dominio y un canal de Discord. Un desarrollador puede ejecutar una API para usuarios de pago. Una empresa puede alojar el correo electrónico en un plan compartido y descubrir durante una interrupción que los restablecimientos de contraseñas, las facturas y las comunicaciones de soporte dependen todas del mismo proveedor.
Para los clientes de VPS, los modos de fallo directo son familiares: un nodo host se bloquea, un dispositivo de almacenamiento falla, un filtro DDoS reacciona de forma exagerada, un proveedor ascendente cambia de política o un evento de facturación suspende el acceso. Los fallos indirectos suelen ser peores. Un cliente no tiene una copia de seguridad externa actualizada. El DNS está en la misma cuenta. El único administrador utiliza un buzón de correo electrónico en el servidor fallido. La aplicación depende de una IP codificada de forma rígida. Existe una instantánea pero no se puede descargar ni restaurar en otro lugar.
En cada caso, la ventana de recuperación del proveedor se convierte solo en una parte de la interrupción.
Para los clientes de alojamiento web, el riesgo del servidor compartido es diferente. Una cuenta abusiva o comprometida puede afectar la reputación del servidor, la entregabilidad del correo o los límites de recursos. Los términos se reservan el derecho de limitar, solicitar actualizaciones o suspender servicios que afecten a otros clientes en el mismo servidor físico. Eso es necesario para el alojamiento compartido, pero significa que el cliente no controla completamente el entorno de rendimiento.
La expresión "ilimitado" en el ancho de banda y el almacenamiento está limitada por el uso normal y excluye la distribución de archivos grandes, la transmisión de medios, los servidores de descarga o el uso similar a una CDN en el alojamiento compartido.
Para el alojamiento de juegos, el impacto es tanto social como técnico. Las comunidades de jugadores notan el retraso, la pérdida de paquetes, los reinicios y los cambios de región de inmediato. Un nodo que técnicamente está en línea pero congestionado puede igualmente vaciar un servidor. Un cambio de IP puede romper las listas de servidores, los favoritos guardados y las instrucciones de la comunidad.
El sitio rumano proporciona información útil sobre la región y el hardware, pero los clientes que gestionan comunidades serias deberían preguntar cómo se hacen copias de seguridad de los paneles de juegos, los directorios de datos, los paquetes de mods y las bases de datos, y con qué rapidez se puede mover un servidor entre Rumanía y Alemania.
Para las tres familias de productos, el control más fuerte del cliente es la portabilidad. Mantenga los nombres de dominio independientes. Mantenga los contactos de pago y soporte monitorizados por más de una persona. Mantenga la configuración de la aplicación fuera del servidor. Mantenga las copias de seguridad en otra cuenta y otro proveedor. Pruebe una restauración antes del primer incidente grave. No son señales de desconfianza. Son la división normal de responsabilidades en el alojamiento económico y de gama media.
Qué evidencia justificaría un veredicto más sólido
Network LIGA HOSTING LTD podría pasar de una evidencia media a una evidencia sólida sin exponer detalles internos sensibles. La primera mejora sería una declaración de infraestructura concisa: qué ciudades están activas, si la empresa posee hardware o alquila capacidad dedicada en cada ciudad, qué familias de productos se ejecutan en cada sitio, si cada sitio tiene al menos dos rutas ascendentes y si el espacio IP del cliente puede moverse durante un fallo del proveedor. Un registro público en PeeringDB ayudaría, pero incluso una página de red en texto plano haría que la afirmación de red troncal fuera más fácil de verificar.
La segunda mejora sería el contexto de la instalación y la energía. Los clientes no necesitan números de bastidor. Sí necesitan saber si los servidores se encuentran en centros de datos profesionales, si la alimentación es redundante, si los hosts son de un solo cable o de dos, si hay manos remotas contratadas, si hay piezas de repuesto almacenadas localmente y si el mantenimiento planificado de la instalación tiene un diseño sin tiempo de inactividad o una ventana de reinicio para el cliente. Elmaterial de niveles del Uptime Institutees un recordatorio de que la capacidad de la instalación y la topología del inquilino no son idénticas; un edificio certificado no certifica automáticamente cada nodo alojado.
La tercera mejora sería la evidencia de copias de seguridad y restauración. Los términos ya trazan un límite claro alrededor de las copias de seguridad de cPanel y la responsabilidad por defecto del VPS. El siguiente paso más sólido serían los objetivos de restauración específicos del producto: tiempo de solicitud de restauración de cPanel, opciones de retención de instantáneas, opciones de ubicación de copias de seguridad externas, formatos de descarga/exportación y el resultado del último ejercicio de restauración realizado por el proveedor.
Para VPS, un producto de copia de seguridad de pago debería indicar si se almacena fuera del nodo, fuera del bastidor o fuera del sitio.
La cuarta mejora sería el historial de estado. Una página verde en un momento dado es útil; un historial de incidentes y mantenimiento es más útil. Los clientes deberían poder ver con qué frecuencia Rumanía y Fráncfort tuvieron trabajos planificados, si algún incidente afectó a varias regiones, cuánto tardó la restauración y qué se cambió después. Esto no es solo teatro de transparencia. Permite a los compradores comparar el objetivo mensual del 99,9% declarado con el comportamiento operativo real.
La quinta mejora serían los derechos de salida. Los términos ya establecen que los servicios cancelados pueden no conservar las IP, los nombres de host o los datos. Un proveedor favorable a la producción aún puede publicar cómo los clientes exportan imágenes de VPS, recuperan copias de seguridad de cPanel, reducen la dependencia del DNS, transfieren dominios y solicitan acceso de emergencia a los datos antes de la eliminación. El bloqueo del alojamiento suele aparecer durante un fallo, no durante la compra.
Veredicto: capacidad de alojamiento visible, resiliencia profunda no probada
Network LIGA HOSTING LTD es un sujeto de alojamiento mejor evidenciado de lo que sugería la instantánea inicial y escasa del directorio. La empresa británica existe y coincide con el código SIC de alojamiento. El sitio público y los términos describen servicios concretos de VPS, cPanel y alojamiento de juegos. La página de estado nombra las ubicaciones de servicio de Tulcea y Fráncfort. AS201131 está registrado a nombre de LIGA HOSTING LTD, activo en el enrutamiento público y actualmente origina tres /24 de IPv4 más dos /48 de IPv6 visibles. El estado de origen de ruta IPv4 verificado es válido.
Estos puntos respaldan una huella operativa real.
El techo es igualmente importante. La empresa es de reciente constitución. El registro público no nombra las instalaciones, la propiedad de los bastidores, el proveedor de manos remotas, las interconexiones, el stock de hardware de repuesto, la combinación exacta de proveedores ascendentes por ubicación, la capacidad DDoS, el diseño de replicación de almacenamiento, el historial de pruebas de restauración ni los derechos de migración de los clientes. El SLA es principalmente una promesa de crédito de servicio. Las copias de seguridad de VPS no se incluyen por defecto.
Las normas de facturación pueden suspender el servicio el día tres y eliminar los datos el día catorce. Estos no son defectos por sí mismos; son la forma real de la dependencia.
Para un uso experimental de VPS, comunidades de juegos con sus propias copias de seguridad, sitios web pequeños y cargas de trabajo que se pueden mover mediante DNS, la evidencia pública de LigaHosting puede ser suficiente si el precio, la latencia y el soporte encajan. Para datos regulados, alojamiento de producción de clientes, aplicaciones críticas para los ingresos o servicios con objetivos de recuperación estrictos, el comprador debería tratar la plataforma como capacidad alojada que aún necesita un diseño de recuperación independiente. Pida evidencia del sitio, de las copias de seguridad y de las rutas.
Pruebe la restauración fuera de la cuenta. Sea dueño del DNS y del registro de dominio. Sepa qué ocurre si falla una factura, un bastidor, un nodo, un proveedor ascendente o el contrato del proveedor.
El hecho central no es que AS201131 exista, ni que Tulcea y Fráncfort aparezcan en una página de estado. Es que cada servidor virtual vendido bajo esa superficie se resuelve en una pequeña cadena de dependencias físicas y contractuales: un servidor, un bastidor, energía, refrigeración, tránsito, mitigación DDoS, mano de obra de soporte, estado de facturación y una ruta de salida. Network LIGA HOSTING LTD tiene suficiente evidencia pública para ser tomado en serio como un host operativo. Todavía no ha publicado suficiente evidencia para permitir a los clientes externalizar la resiliencia al proveedor.