Síntoma
Cuando un sistema externo (por ejemplo, un Dolibarr alojado en otro servidor, una herramienta de sincronización, un CRM, una pasarela o un servidor de tu empresa) necesita comunicarse con tu PrestaShop, WordPress, Moodle o con la base de datos MySQL de tu hosting en Tropical Server, no es raro que sus peticiones empiecen a fallar con tiempos de espera o conexiones rechazadas aunque hayas añadido la IP de origen a la lista blanca de Imunify360.
Esto ocurre porque Imunify360 es solo una de las capas de protección del servidor. Por debajo y en paralelo trabajan otros sistemas (LiteSpeed, control de bases de datos remotas, cortafuegos del servidor, etc.) que también pueden estar rechazando esa IP por su cuenta.
Cómo identificar este escenario
Has añadido la IP de origen a la lista blanca de Imunify360 sin caducidad.
cPHulk está desactivado y firewalld no se está ejecutando.
No hay coincidencias en iptables ni en nftables.
No aparecen entradas para esa IP en los logs de Apache, ModSecurity, LiteSpeed, domlogs, Exim ni Dovecot.
El puerto correspondiente (por ejemplo, 443 para HTTPS o 3306 para MySQL) está escuchando correctamente.
El proveedor remoto te dice que tu servidor está rechazando sus peticiones.
Capas que también pueden estar bloqueando la IP
1. Configuración de LiteSpeed
El servidor web LiteSpeed que se usa en los planes de hosting compartido y cloud de Tropical Server lleva su propio listado de IPs aceptadas para determinadas conexiones internas (server-to-server, peticiones de API, etc.). Aunque Imunify360 deje pasar el tráfico, LiteSpeed puede descartarlo si la IP no está incluida en su configuración.
2. Conexiones remotas a la base de datos (MySQL)
Por defecto, cPanel solo permite conexiones a MySQL desde el propio servidor (localhost). Cualquier IP que necesite conectarse a la base de datos desde fuera debe darse de alta de forma explícita en:
cPanel > Bases de datos > MySQL remoto
Si esto no se hace, la conexión externa fallará incluso con la IP en la lista blanca de Imunify360.
3. Cortafuegos perimetral del servidor
En servidores cloud y dedicados puede haber un cortafuegos adicional a nivel de red (CSF, ipset, reglas del propio centro de datos) que filtre la IP antes de que la petición llegue siquiera a Imunify360.
Pasos recomendados para resolverlo
Confirma que el bloqueo no es por exceso de conexiones desde la IP origen (consulta el artículo sobre Error 403 por exceso de conexiones si la conexión llega a iniciarse y se cae a los pocos segundos).
Añade la IP a la lista blanca de Imunify360 sin caducidad. Esto debería ser el primer paso, pero rara vez es suficiente por sí solo para tráfico server-to-server.
Abre un ticket en soporte indicando la IP exacta y para qué se va a usar (acceso al sitio, API de PrestaShop, conexión a la base de datos, etc.). Soporte añadirá la IP en:
La configuración de LiteSpeed.
cPanel > MySQL remoto si necesita acceder a la base de datos.
Cualquier capa adicional aplicable según el plan contratado (CSF, ipsets, etc.).
Verifica la conexión desde el origen. Una vez aplicadas todas las capas, las peticiones legítimas dejan de descartarse.
Qué información facilitar al abrir el ticket
IP pública exacta del sistema externo (no rangos amplios).
Servicio al que necesita acceder (HTTPS, MySQL, API, FTP, etc.) y el puerto.
Propósito de la conexión (sincronización, integración, backups, etc.).
Si se trata de una IP fija o dinámica: las dinámicas no son adecuadas para listas blancas porque cambian con frecuencia.
Buenas prácticas
Usa siempre IPs fijas para integraciones entre servidores.
Documenta qué integraciones tienes activas y desde qué IP, para revisarlas cuando una conexión falle.
Aplica el principio de mínimo privilegio: abre solo el puerto y la base de datos que realmente necesite el sistema externo, no acceso completo.
Si la integración es puntual, desactiva la entrada en cuanto deje de ser necesaria.