"Mi IA dice que activéis Redis / PHP-FPM / Nginx": cómo es realmente el entorno técnico de los servidores de Tropical Server

Por qué los checklists genéricos de ChatGPT y otras IA no encajan con nuestros servidores

Cada vez es más habitual que un cliente nos pida revisar su web con una lista de comprobaciones generada por ChatGPT, Gemini u otra IA: que si PHP-FPM tiene tales límites, que si conviene activar Redis para PrestaShop, que si Nginx está bien configurado, que si HTTP/2 y Brotli están activos, etc.

El problema es que esas IA no conocen el entorno real del servidor donde está alojada tu web. Te recomiendan ajustes pensados para una pila Apache + Nginx + PHP-FPM, cuando lo que tenemos montado es distinto. Si pides "activar PHP-FPM" en un servidor que no usa PHP-FPM, la recomendación no se puede aplicar y, sobre todo, puede llevar a discusiones absurdas que retrasan el diagnóstico real de cualquier problema que tengas.

Este artículo resume cómo es el entorno técnico real de la mayoría de nuestros hostings y servidores cloud, para que sepas qué preguntar y qué descartar antes de aplicar consejos que no aplican.

Servidor web: LiteSpeed Enterprise, no Apache ni Nginx

Nuestros servidores corren LiteSpeed Web Server Enterprise. Es compatible con la sintaxis de Apache (.htaccess, reglas de reescritura, etc.) pero internamente es mucho más eficiente. Lo importante:

No usamos normalmente Apache como servidor web frontal salvo algunas excepciones, aunque puedas ver referencias a httpd o apache en algunos paneles. Esa es la nomenclatura interna; el motor real es LiteSpeed.
No usamos Nginx. Las recetas de "configurar Nginx como reverse proxy" no son aplicables.
HTTP/2 o mejor HTTP/3 está activo de serie en todos los dominios con SSL.
La compresión está activa por defecto (Gzip y, en versiones modernas, también Brotli para los tipos de contenido habituales).

PHP: LSAPI con LSPHP, no PHP-FPM

LiteSpeed no ejecuta PHP a través de PHP-FPM. Utiliza una interfaz propia llamada LSAPI, con binarios lsphp (por ejemplo lsphp80, lsphp82, lsphp84). Cosas importantes a tener en cuenta:

No verás procesos php-fpm ni un servicio php-fpm que reiniciar. Verás procesos lsphp.
El control de cuántos hijos PHP puede levantar el servidor se hace con la variable PHP_LSAPI_CHILDREN en la configuración de LiteSpeed. Las recomendaciones del tipo "ajusta pm.max_children" no aplican.
Cada cuenta cPanel tiene asignada su versión de PHP desde el selector del panel. Puedes cambiarla por dominio sin tocar ninguna configuración global.
OPcache está activado y configurado de fábrica en todas las versiones de PHP soportadas. No necesitas habilitarlo manualmente.

Aislamiento de cuentas: CloudLinux + CageFS, no contenedores genéricos

Cada cuenta cPanel se ejecuta dentro de su propio CageFS de CloudLinux. Eso significa que:

Los procesos de tu cuenta no ven los de otros clientes y viceversa.
Los límites por cuenta (CPU, RAM, procesos, entrada/salida, número de procesos PHP simultáneos) los gestiona LVE de CloudLinux. Se ven y diagnostican desde cPanel → Métricas → Uso de recursos.
Si superas esos límites durante el día, se aplica una "penalización temporal" de recursos que provoca lentitud o errores 503 puntuales. Esa penalización se libera sola al cabo de un rato o, si necesitas que la reiniciemos a mano, podemos hacerlo desde soporte.

Base de datos: MySQL/MariaDB optimizado, sin Redis nativo

El motor de base de datos viene preconfigurado por nuestro equipo para los CMS habituales (WordPress, PrestaShop, Joomla, Moodle). En particular:

Redis no está instalado en los planes compartidos. PrestaShop y otros CMS habituales no son compatibles de forma nativa con Redis sin instalar módulos adicionales y reconfigurarlos. Activarlo "por defecto" porque "mejora el rendimiento" puede romper carrito, sesiones o caché de la tienda.
En servidores cloud privados sí podemos plantear Redis o Memcached si el proyecto lo justifica, pero siempre tras una prueba específica con esa instalación concreta.
Las copias de seguridad de bases de datos se hacen cada 2 horas con JetBackup y se almacenan en Storage S3 externo.

Seguridad: Imunify360 y CSF, no soluciones a medida

Como capa de seguridad y antimalware usamos Imunify360 a nivel de cuenta y CSF como cortafuegos. Esto cubre la mayoría de bloqueos que verás en logs:

Bloqueos por IP con captcha → Imunify360.
Bloqueos directos sin respuesta → habitualmente CSF o reglas de geobloqueo a nivel de servidor.
Reglas de ModSecurity integradas con Imunify360 protegen contra ataques en URLs.

Las recomendaciones de "instalar fail2ban", "configurar iptables manualmente" o "añadir Nginx como WAF" no aplican en nuestro entorno porque ya está cubierto con estas piezas.

Qué te conviene preguntar antes de aplicar consejos de IA

Si tu IA te ha dado una lista de cambios para tu web alojada con nosotros, antes de pedirnos aplicarlos:

Pregúntanos qué hay activo realmente (versión de PHP, OPcache, LSAPI, MySQL, HTTP/2, Imunify, etc.) en tu plan concreto.
Si te recomienda configurar PHP-FPM, Nginx, Redis o cualquier servicio que no se menciona en este artículo, lo más probable es que no aplique tal cual.
Si lo que buscas es diagnóstico de rendimiento, podemos hacerlo desde soporte (en planes compartidos forma parte del servicio para casos puntuales; en cuentas cloud o cuando se trata de un informe formal de optimización, lo facturamos por horas).

De este modo, partimos del entorno real de tu servidor y no perdemos tiempo aplicando recetas pensadas para una arquitectura distinta.