Tres caídas en tres días en el proveedor de alojamiento Fritz Managed IT: lo que enseña sobre límites de almacenamiento, copias de seguridad, cortafuegos y bots al gestionar un sitio WordPress
- El 29 de octubre de 2026 el software de alojamiento bloqueó el portal financiero steuerratschlag.eu: ocupaba 36,3 GB cuando el paquete permitía 25 GB. La causa fueron copias de seguridad antiguas: un solo archivo pesaba 17,2 GB.
- El 31 de octubre de 2026 todo intento de acceder al panel de WordPress terminaba en «Internal Server Error»: el cortafuegos ModSecurity del proveedor cortaba las páginas de más de 1 MB, después de que un complemento de análisis hinchara el panel.
- Un asistente de IA encontró la causa en el registro de errores; al desactivar el complemento, el acceso volvió a funcionar.
- También el 31 de octubre de 2026 el sitio volvió a caerse de forma intermitente: bots de redes de centros de datos lo consultaban en ocasiones más de diez veces por segundo. Bloquear once redes en el archivo .htaccess del servidor puso fin a la sobrecarga.
El portal financiero steuerratschlag.eu quedó inutilizable tres veces en tres días. Dos veces se activaron mecanismos de protección del proveedor de alojamiento Fritz Managed IT, provocados por la acumulación de datos en el propio sitio. La tercera vez, unos bots sobrecargaron el servidor.
Primero el sitio quedó totalmente fuera de línea, luego desapareció el acceso al panel de WordPress y, finalmente, colapsó bajo peticiones automatizadas masivas. Por transparencia: steuerratschlag.eu pertenece, al igual que NETZ-TRENDS, al editor Dr. K. Korosides. Contamos este caso porque es típico de muchos pequeños sitios WordPress alojados en Alemania, y porque los mensajes de error apenas revelan lo que realmente ocurre.
Caída 1: almacenamiento al 142 %
Al final de la noche del 29 de octubre de 2026, steuerratschlag.eu solo devolvía un error «503 Service Unavailable». Los archivos estáticos como robots.txt seguían llegando, pero WordPress ya no. En el panel de administración Plesk, la suscripción aparecía como «Suspendida».
Plesk es una interfaz de administración de servidores web, un «panel de control». A través de ella, en el navegador, se gestiona lo que de otro modo requeriría comandos en el servidor: crear dominios y buzones de correo, subir, renombrar o borrar archivos en un gestor de archivos, administrar bases de datos, copias de seguridad y certificados de seguridad, leer los registros del servidor web. Una «suscripción» en Plesk es un paquete de alojamiento contratado con límites fijos, por ejemplo de espacio de almacenamiento.
Por qué los proveedores de alojamiento lo necesitan
Un proveedor suele alojar en un mismo servidor cientos de sitios de clientes distintos. Estos no deben tener acceso de administración de todo el servidor (acceso root), pero sí deben poder gestionar su propio espacio sin llamar al soporte por cada detalle. Un panel de control separa de forma clara los espacios de cada cliente, hace cumplir los límites contratados y automatiza tareas rutinarias: crear nuevos paquetes, renovar certificados, instalar actualizaciones de seguridad. Desarrollar un software así internamente solo compensa a los grandes proveedores. Los más pequeños compran por tanto licencias a Plesk o a su competidor cPanel. También existen alternativas gratuitas de código abierto como ISPConfig o Froxlor, que exigen más conocimientos técnicos.
Qué grado de difusión tiene
Según el servicio de estadísticas W3Techs (a 1 de noviembre de 2026), Plesk funciona en el 41,4 % de los sitios web cuyo panel de control es detectable desde fuera. Solo hPanel, la interfaz propia del gran proveedor Hostinger, es más común, con un 54,2 %; cPanel alcanza el 1,8 %. Cuanto más grande es el sitio, más frecuente es Plesk: entre los 1.000 sitios más visitados con panel detectable, su cuota llega al 84,6 %. Pero en la mayoría de los sitios el panel no es detectable en absoluto, así que estas cifras describen solo una parte del mercado. Plesk funciona tanto en servidores Linux como Windows.
Quién está detrás
Plesk nació hacia 1999-2000 en Novosibirsk, Rusia, y posteriormente perteneció, entre otros, a SWsoft y Parallels. Hoy lo desarrolla Plesk International GmbH, con sede en Schaffhausen (Suiza). Pertenece al grupo empresarial WebPros, al que también pertenece cPanel; el propietario mayoritario de WebPros es, desde 2020, el inversor financiero CVC Capital Partners (historia de la empresa, en inglés).
✔ A favor de Plesk
- Manejo completo desde el navegador, sin conocimientos de línea de comandos.
- Muchas herramientas en un solo paquete, incluido un WordPress Toolkit para actualizaciones y copias de seguridad.
- Funciones de protección integradas, como el cortafuegos web ModSecurity y bloqueos automáticos de IP tras accesos sospechosos, justo los mecanismos que se activaron en steuerratschlag.eu.
- Un acceso de emergencia a los archivos cuando el propio WordPress deja de responder: el complemento problemático pudo desactivarse desde el gestor de archivos aunque el panel fuera inaccesible.
✘ Lo que se critica de Plesk
- Precios de licencia al alza: según un análisis del medio especializado webhosting.today (en inglés), los precios de catálogo subieron entre un 50 y un 60 % de 2020 a 2024, según el paquete. El proveedor IONOS introdujo en 2025 una tarifa Plesk de 5 libras al mes para clientes con servidor virtual, alegando un aumento notable de los costes de licencia (The Register, en inglés). Estos costes acaban recayendo en los gestores de los sitios.
- Poca competencia: Plesk y cPanel, los dos paneles con licencia más conocidos, pertenecen al mismo grupo empresarial.
- Fallos de seguridad: un software tan extendido en tantos servidores es un objetivo atractivo. En 2012, unos atacantes explotaron una vulnerabilidad en versiones antiguas de Plesk, afectando según los informes a unos 50.000 dominios.
- Errores poco claros: las funciones de protección se activan automáticamente, pero a menudo no indican por qué. En steuerratschlag.eu, el bloqueo, el corte del cortafuegos y el bloqueo de IP solo mostraron páginas de error sin información; la causa solo aparecía en los registros.
Para steuerratschlag.eu, Plesk fue la herramienta decisiva en las tres caídas: ahí quedaban registrados el uso de almacenamiento y los registros de errores y accesos.
La causa apareció en Plesk: el sitio ocupaba 36,3 GB, contabilizados como 35,4 GB de espacio web en las estadísticas, el 142 % de la cuota de 25 GB del paquete «Web Starter». Plesk puede suspender automáticamente una suscripción al superar el límite, una función estándar del software, configurada por el proveedor para sus paquetes.
El espacio estaba ocupado casi por completo por copias de seguridad: una copia completa realizada el 28 de octubre por la herramienta de Plesk «WP Toolkit», con 17,2 GB, además de copias del complemento UpdraftPlus de 2020 y 2026, que sumaban más de 11 GB. Tras la limpieza del 30 de octubre, el sitio ocupaba solo 4,3 GB, en torno al 17 % de la cuota.
Caída 2: el cortafuegos bloquea el panel
Dos días después, el 31 de octubre, el sitio volvía a cargar con normalidad para los visitantes. Pero el acceso al panel de WordPress fallaba: tras pulsar «Acceder», aparecía una página de error desnuda, «Internal Server Error», que pedía contactar con el administrador en «root@localhost», un mensaje estándar del servidor web Apache que no explica nada.
La causa figuraba en el registro de errores del servidor. El propio acceso funcionaba. Solo al cargar el panel se activaba el cortafuegos web ModSecurity, que corre en el servidor con un conjunto de reglas del proveedor Comodo. Informaba de «Response body too large (over limit of 1048576)»: la página superaba 1 MB y el cortafuegos la cortaba.
El complemento Query Monitor había hinchado el panel. Es una herramienta para desarrolladores que añade a cada página del panel las consultas a la base de datos, los errores PHP y otros datos de diagnóstico. Para los administradores conectados, añade a cada página del panel un gran panel de análisis con todas las consultas a la base de datos, los hooks (puntos de enganche para extensiones) y los scripts. En un sitio con muchos complementos como steuerratschlag.eu, eso supera fácilmente el límite de 1 MB. Los visitantes normales nunca ven ese panel, por lo que el sitio en sí siguió funcionando con normalidad mientras el panel de administración no. Según la fecha del archivo, Query Monitor se había instalado o actualizado el 27 de octubre de 2026, dos días antes de los problemas.
El diagnóstico no estaba claro al principio. Se descartaron los demás sospechosos: la carpeta de complementos must-use (mu-plugins, que WordPress carga siempre automáticamente) solo contenía tres archivos pequeños e inofensivos, y tampoco llamaba la atención nada más en la carpeta de complementos. No se pudo comprobar directamente si Query Monitor estaba activo en ese momento: la base de datos no estaba disponible en Plesk, y el WordPress Toolkit de Plesk no se abría.
El complemento se desactivó sin acceso al panel: Claude renombró, en el gestor de archivos de Plesk, la carpeta «query-monitor» como «query-monitor_deaktiviert». Si WordPress ya no encuentra la carpeta de un complemento, lo desactiva de inmediato, y el paso puede deshacerse en cualquier momento devolviéndole su nombre original. Después, WordPress puede mostrar brevemente un aviso de que el complemento se desactivó porque el archivo no existe; es normal. Por si el acceso seguía bloqueado, Jetpack y Site Kit eran los siguientes sospechosos en la lista. No hizo falta: tras renombrar la carpeta, el acceso volvió a funcionar de inmediato. En el día a día, Query Monitor no es necesario y permanece desactivado.
La configuración de ejemplo de ModSecurity (en inglés) prevé en realidad solo 512 KB, así que el servidor de steuerratschlag.eu permite el doble. Para las páginas que superan el límite, esa configuración de ejemplo recomienda dejar pasar el resto sin comprobarlo («ProcessPartial»), para no romper páginas legítimas. En el servidor de steuerratschlag.eu, según el registro, superar el límite provocó en cambio la interrupción de la petición.
Quien encontró la causa fue Claude, el asistente de IA de la empresa estadounidense Anthropic con el que trabaja la redacción. Primero comprobó si el sitio era accesible desde fuera, después recomendó probar desde otra conexión y, finalmente, leyó el registro de errores en Plesk. Ahí estaba la entrada decisiva.
Durante la búsqueda del fallo, Plesk redirigía repetidamente a su página de acceso, una dirección que a primera vista parece sospechosamente larga. Pero puede leerse: al principio aparece el nombre del servidor del propio proveedor, seguido de «:8443», el puerto habitual para la administración de Plesk, y luego «login_up.php», la página de acceso de Plesk. El largo resto tras «success_redirect_url=» solo indica a Plesk adónde redirigir tras el acceso, por ejemplo al gestor de archivos de una carpeta concreta. Lo decisivo es únicamente que la barra de direcciones muestre exactamente el nombre del servidor del propio proveedor; de lo contrario podría tratarse de una página falsa que busca capturar credenciales.
Caída 3: bots sobrecargan el servidor
En la tarde del 31 de octubre de 2026, steuerratschlag.eu volvió a quedar inaccesible de forma intermitente; aparecía de vez en cuando una página de error 500 y el panel de WordPress respondía extremadamente lento. La sospecha obvia: el almacenamiento vuelve a llenarse. Claude revisó por ello, carpeta por carpeta, los lugares típicos donde se acumulan restos en el gestor de archivos de Plesk. La carpeta de copias de seguridad de WordPress y la papelera de Plesk estaban vacías, la carpeta «wp-snapshots» solo contenía una subcarpeta vacía de 2016, y la carpeta del complemento de copias BackWPup contenía tres archivos minúsculos que sumaban menos de 1 KB.
El espacio ocupado está casi por completo en imágenes desde 2014 enlazadas en artículos y que, por tanto, deben permanecer. Solo 23 temas inactivos (plantillas de diseño), con unos 70 MB, y seis complementos inactivos liberarían algo más de espacio. Con una cuota de 25 GB no es necesario, y nada tuvo que ver con la tercera caída.
La causa figuraba en los registros de acceso del servidor, en Plesk: el sitio estaba siendo consultado masivamente por bots, programas automatizados, en ocasiones con más de diez peticiones por segundo. Destacaban dos grupos:
- Bots de scraping (programas que extraen contenido de forma masiva): cientos de direcciones IP recorrían antiguas páginas de etiquetas (/tag/…), por ejemplo sobre planes de ahorro-vivienda o el fraude fiscal en Société Générale. Las direcciones procedían de unas pocas redes de centros de datos.
- Servidores de la red de Amazon: decenas de máquinas solicitaban una y otra vez los mismos artículos e imágenes nuevos, en parte varias veces por segundo.
Cada una de estas peticiones obliga a WordPress a recalcular la página desde la base de datos. En un paquete de alojamiento pequeño, esa carga basta para tumbar el servidor.
La solución: Claude bloqueó once redes de centros de datos sospechosas en el archivo .htaccess, el archivo de configuración del servidor web Apache. La entrada figura en un bloque marcado «Bot-Sperre» al principio del archivo y puede retirarse en cualquier momento. Los lectores reales y el buscador de Google no se ven afectados. Desde las 17:15, los bots bloqueados ya no aparecen en el registro. Desde entonces, la portada, el acceso y las páginas de etiquetas cargan en uno a tres segundos.
Bloqueos de IP: protección con efectos secundarios
Para el editor se sumó un tercer contratiempo: según cuenta, su propia conexión a internet fue excluida por el servidor dos veces en una semana. El sitio entonces dejaba de cargar desde su propia línea, mientras seguía siendo accesible desde otras conexiones. Solo mediante una VPN (red privada virtual), que enruta el tráfico a través de otro servidor, consiguió volver a acceder al panel.
Este tipo de bloqueos automáticos son habituales en los servidores de alojamiento y tienen buenas razones de ser: repelen ataques contra las páginas de acceso, en los que bots prueban contraseñas en masa. Fritz Managed IT indica en su portal de clientes que utiliza detección basada en comportamiento, antivirus y un equipo de seguridad disponible las 24 horas. Pero quien introduce varias veces credenciales erróneas puede acabar siendo víctima de esas mismas protecciones, y debe entonces solicitar el desbloqueo al soporte, disponible, según el portal de clientes, de lunes a viernes de 9 a 17 horas.
También el 31 de octubre volvió a afectar al editor: mientras steuerratschlag.eu cargaba de nuevo con normalidad desde fuera, las peticiones desde su navegador fallaban de inmediato, mientras netz-trends.de, alojado en otro proveedor, seguía siendo accesible. La explicación más probable: el cortafuegos del proveedor había bloqueado su dirección IP tras las numerosas peticiones del día, por las recargas repetidas del panel y las comprobaciones durante la búsqueda del fallo. Estos bloqueos suelen resolverse solos en 15 a 60 minutos; si no, ayuda un desbloqueo por parte del soporte.
Qué se puede aprender de esto
- No dejar nunca copias de seguridad de forma permanente en el mismo espacio web: guardarlas fuera y conservar solo unas pocas.
- Comprobar con regularidad el uso de almacenamiento en el panel de alojamiento, no solo cuando ya hay un bloqueo.
- Activar complementos de desarrollador como Query Monitor solo para buscar fallos y desactivarlos después.
- Ante un «Internal Server Error», leer primero el registro de errores del servidor: ahí está la causa, no en la página de error.
- Revisar con regularidad los registros de acceso en busca de bots sospechosos y bloquear vía .htaccess las redes de centros de datos que saturan el sitio.
- Desactivar un complemento sospechoso sin acceso al panel: renombrar su carpeta en el gestor de archivos del proveedor; se deshace renombrándola de nuevo.
- Ante la sospecha de un bloqueo de IP, probar el sitio con datos móviles u otra conexión y comunicar la propia dirección IP al soporte.
Las tres caídas ya están resueltas. Aun así, no quedan sin consecuencias para un portal de noticias: mientras el sitio está caído, faltan visitas e ingresos publicitarios.
Preguntas frecuentes
¿Qué significa «503 Service Unavailable»?
El servidor es accesible, pero no puede entregar la página en ese momento. En steuerratschlag.eu se debió al bloqueo automático provocado por superar la cuota de almacenamiento.
¿Qué significa «Internal Server Error»?
El error 500 significa que algo falló al generar la página. En el caso de steuerratschlag.eu, el cortafuegos ModSecurity interrumpió la entrega porque el panel superaba 1 MB.
¿Hay que eliminar Query Monitor?
No. Basta con activar el complemento solo cuando se necesite. En el día a día no hace falta.
¿Cómo se detecta si unos bots sobrecargan un sitio?
En el registro de accesos (access log) del servidor: muchas peticiones por segundo desde unas pocas redes de centros de datos, a menudo dirigidas a antiguas páginas de etiquetas o archivo, son una señal típica. Los lectores normales nunca piden varias páginas por segundo.
Fuentes y fecha
- Estadísticas de Plesk, gestor de archivos y registros de acceso y errores del servidor de steuerratschlag.eu, del 29 al 31 de octubre de 2026 (análisis propio)
- ModSecurity, configuración recomendada (modsecurity.conf-recommended, en inglés)
- Query Monitor en el directorio de complementos de WordPress
- Fritz Managed IT, información del portal de clientes (a 31 de octubre de 2026, en alemán)
- Plesk – sitio del fabricante y entrada de Wikipedia sobre Plesk (consultadas el 1 de noviembre de 2026)
- W3Techs: cuotas de mercado de los paneles web (a 1 de noviembre de 2026)
- webhosting.today: evolución de los precios de licencia de Plesk, 2017–2024
- The Register: IONOS introduce una tarifa Plesk (2 de octubre de 2025)
Investigación y datos a fecha del 31 de octubre de 2026.
Nota de transparencia: en la investigación, la estructuración y la redacción de este artículo se emplearon herramientas asistidas por IA. Las fuentes utilizadas figuran en el artículo. La publicación se realiza solo tras la aprobación editorial manual. Traducción del artículo original en alemán publicado en NETZ-TRENDS.de.
