NGINX es un servidor web de código abierto que también puede actuar como proxy inverso, balanceador de carga y caché de contenido. Se utiliza para recibir conexiones de visitantes de forma eficiente y puede trabajar solo o delante de otro servidor, como Apache.
Su presencia no significa automáticamente que todas las páginas estén almacenadas en caché. Cada función debe estar configurada por el administrador de la infraestructura. En un hosting compartido, el usuario normalmente administra su sitio desde cPanel y no modifica la configuración global de NGINX.
Qué sucede cuando una persona visita un sitio
Al ingresar una dirección en el navegador, se envía una solicitud HTTP o HTTPS al servidor. Si NGINX es el punto de entrada, recibe esa solicitud y decide cómo atenderla según su configuración: puede entregar un archivo directamente, devolver una respuesta almacenada o reenviar la petición a otro servicio.
Este proceso es transparente para el visitante. La dirección del sitio no cambia y, si la infraestructura está configurada correctamente, las distintas capas trabajan como un único servicio.
NGINX como servidor de contenido estático
Imágenes, hojas de estilo CSS, archivos JavaScript, fuentes y documentos descargables son ejemplos de contenido estático. NGINX puede entregarlos sin ejecutar PHP ni consultar una base de datos. Esto reduce trabajo innecesario y deja más capacidad disponible para las solicitudes dinámicas.
El contenido estático no debe confundirse con una copia en caché de una página. Un archivo de imagen existe físicamente en el sitio; una página almacenada en caché es una respuesta guardada temporalmente para evitar generarla nuevamente.
Qué es un proxy inverso
Como proxy inverso, NGINX se ubica delante del servidor que genera la respuesta final. Recibe la conexión pública y la reenvía hacia un servicio interno, llamado servidor de origen o backend. Ese destino puede ser Apache, PHP-FPM, una aplicación desarrollada en otro lenguaje o incluso un grupo de servidores.
El proxy puede agregar o conservar encabezados, controlar tiempos de espera, comprimir respuestas y administrar la comunicación con el backend. La configuración debe mantener correctamente datos importantes como el dominio solicitado, el protocolo HTTPS y la dirección IP real del visitante.
NGINX y Apache pueden trabajar juntos
No siempre es necesario elegir entre NGINX y Apache. En muchas arquitecturas NGINX recibe las conexiones y Apache procesa las reglas o aplicaciones que dependen de él. En cPanel, una implementación habitual utiliza NGINX delante de Apache como proxy inverso.
Esta combinación permite aprovechar la eficiencia de NGINX para conexiones y contenido, mientras Apache mantiene compatibilidad con funciones tradicionales del hosting, incluidas ciertas reglas de .htaccess. El comportamiento exacto depende de cómo haya sido configurado el servidor.
Cuándo interviene PHP
Una página de WordPress normalmente necesita ejecutar PHP y consultar MariaDB o MySQL. NGINX puede enviar esa solicitud a Apache o PHP-FPM y luego devolver la respuesta al visitante. Si existe una copia válida en caché, es posible que la página se entregue sin repetir todo el procesamiento.
Por eso, un problema de lentitud no siempre tiene su origen en NGINX. También puede deberse a un plugin, una consulta de base de datos, tareas programadas, falta de recursos, servicios externos o código que tarda demasiado.
Caché de contenido
Cuando la caché está habilitada, NGINX puede guardar respuestas del backend y reutilizarlas durante un período definido. Esto disminuye el tiempo de respuesta y reduce la carga, especialmente en páginas públicas que reciben muchas visitas.
No todas las respuestas deberían almacenarse. Carritos de compra, áreas privadas, paneles de administración y páginas personalizadas requieren exclusiones para evitar mostrar información incorrecta. Además, una instalación puede utilizar NGINX únicamente como proxy, sin caché activa.
Si un cambio no aparece, seguí la guía para identificar y limpiar la caché de NGINX sin borrar archivos del sistema.
Balanceo de carga y alta disponibilidad
NGINX también puede distribuir solicitudes entre varios servidores internos. Esta capacidad se utiliza en proyectos que necesitan escalar, repartir trabajo o mantener servicios disponibles si un nodo deja de responder. No es una función que deba estar presente en todos los planes de hosting.
Relación entre NGINX y Cloudflare
Cloudflare funciona fuera del servidor de origen y puede agregar otra capa de proxy y caché. En ese caso, una solicitud puede pasar primero por Cloudflare, luego por NGINX y finalmente por Apache o la aplicación. Cada capa tiene su propia configuración y puede conservar contenido durante tiempos diferentes.
Para conocer esa capa externa, consultá qué es Cloudflare y cuáles son sus ventajas. Purgar Cloudflare no limpia necesariamente la caché de NGINX, y viceversa.
Cómo saber si un sitio utiliza NGINX
Las cabeceras HTTP pueden ofrecer indicios, aunque no siempre muestran toda la arquitectura. Un proxy o CDN podría ocultar o modificar el encabezado del servidor. En una cuenta administrada, la confirmación más fiable es la información proporcionada por el proveedor o una herramienta específica del panel.
No conviene instalar plugins o ejecutar comandos suponiendo que existe una caché determinada. Primero hay que identificar qué capa está sirviendo la respuesta desactualizada.
Qué puede administrar el usuario de un hosting
En hosting compartido, la configuración global de NGINX pertenece al administrador. El usuario puede administrar su aplicación, archivos, reglas permitidas, caché de WordPress y opciones disponibles en cPanel. No debe intentar modificar directorios del sistema o reiniciar servicios mediante scripts.
En un VPS con acceso root, la administración es diferente: instalar NGINX implica configurar seguridad, virtual hosts, certificados, registros, actualizaciones, caché y comunicación con los backends. Si el servicio es administrado, conviene coordinar esos cambios con soporte.
Ventajas y límites
NGINX puede mejorar la eficiencia y aportar flexibilidad, pero no corrige por sí solo una aplicación lenta ni reemplaza la optimización del sitio. Un buen resultado depende del conjunto: código actualizado, consultas eficientes, recursos suficientes, caché correctamente excluida y monitoreo.
La plataforma funciona sobre el sistema operativo del servidor y junto con los demás servicios de hosting. Comprender esas capas permite diagnosticar mejor los problemas sin atribuirlos automáticamente a un único componente.
