NGINX
Es un software de código abierto para servir páginas web, proxy inverso, almacenamiento en caché, balanceo de carga, transmisión de medios y mucho más. Comenzó como un servidor web diseñado para ofrecer el máximo rendimiento y estabilidad. Además de sus capacidades como servidor HTTP, NGINX también puede funcionar como servidor proxy de correo (IMAP, POP3 y SMTP) y como proxy inverso y balanceador de carga para servidores HTTP, TCP y UDP.
Razones para utilizar
NGINX
Entre las empresas de alto perfil que utilizan NGINX se encuentran Autodesk, Atlassian, Intuit, T-Mobile, GitLab, DuckDuckGo, Microsoft, IBM, Google, Adobe, Salesforce, VMWare, Xerox, LinkedIn, Cisco, Facebook, Target, Citrix Systems, Twitter, Apple, Intel y muchas más
Con NGINX, un proceso maestro puede controlar múltiples procesos de trabajo. El proceso maestro mantiene los procesos de trabajo, mientras que estos realizan el procesamiento real. Como NGINX es asíncrono, cada solicitud puede ejecutarse de forma concurrente sin bloquear las demás.
NGINX está diseñado para ofrecer un bajo consumo de memoria y alta concurrencia. En lugar de crear un proceso nuevo para cada solicitud web, NGINX utiliza un enfoque asíncrono y basado en eventos en el que las solicitudes se gestionan en un único hilo.
NGINX fue creado originalmente por Igor Sysoev, con su primera versión pública en octubre de 2004. Igor concibió inicialmente el software como respuesta al problema C10k, relacionado con el reto de rendimiento de manejar 10.000 conexiones concurrentes.
En Coresis usamos NGINX como servidor y proxy inverso para las plataformas Drupal que desarrollamos, incluyendo portales GOV.CO. Su bajo consumo de memoria y su capacidad de balanceo de carga nos permiten dar soporte y mantenimiento a sitios de alto tráfico sin sacrificar rendimiento.
¿Qué función cumple NGINX?
NGINX puede servir contenido web y actuar como proxy inverso delante de una aplicación. En una arquitectura Drupal ayuda a concentrar TLS, compresión, reglas de caché, límites de solicitud y distribución de tráfico, sin trasladar esas responsabilidades al CMS.
Usos frecuentes
- Entregar archivos estáticos y delegar PHP al runtime de la aplicación.
- Aplicar caché donde la personalización y las sesiones lo permiten.
- Balancear solicitudes entre varias instancias.
- Definir encabezados y redirecciones canónicas en un solo borde.
Rendimiento con reglas verificables
Una caché agresiva no siempre es mejor: diferenciamos contenido anónimo, sesiones, formularios y respuestas personalizadas antes de configurar tiempos de vida. El resultado se valida con solicitudes reales y encabezados, junto con la caché interna de Drupal. Más información en nuestros servicios de soporte y la documentación oficial de NGINX.
Guía de decisión
Qué debe resolver NGINX en producción
NGINX es la capa de entrada que puede enrutar solicitudes, servir archivos, aplicar caché y distribuir tráfico antes de que llegue a Drupal, Node.js u otros servicios. Una configuración buena no se mide por cuántas directivas tiene, sino por reglas predecibles, observables y seguras.
Proxy inverso
Un único punto de entrada para enrutar dominios y rutas hacia aplicaciones con tecnologías o ciclos de despliegue distintos.
Caché de contenido
Respuestas públicas que pueden entregarse sin ejecutar de nuevo PHP o consultar el origen en cada visita.
Balanceo y continuidad
Distribución entre instancias con límites, tiempos de espera y comprobaciones alineados con el comportamiento de la aplicación.
Cómo encaja en la arquitectura
Una ruta frecuente es CDN, NGINX y después la aplicación. La CDN absorbe tráfico global; NGINX conserva reglas cercanas al origen; y Drupal o Node.js resuelven sólo lo que no puede servirse antes. Las cookies, encabezados, parámetros y métodos que invalidan o evitan el caché deben quedar documentados para no mostrar contenido privado ni servir páginas obsoletas.
Qué validar antes de adoptarlo
- Definir la clave de caché y todas sus condiciones de exclusión.
- Preservar protocolo, host e IP de cliente mediante encabezados confiables.
- Ajustar límites y tiempos de espera según cada servicio aguas abajo.
- Registrar HIT, MISS, latencia del origen y códigos de respuesta.
Cuándo no elegirlo
NGINX no reemplaza una CDN, un firewall de aplicaciones ni la lógica de autorización. Tampoco arregla una consulta lenta o una página pesada: puede ocultar temporalmente el síntoma en contenido cacheable, pero las rutas autenticadas seguirán exponiendo el problema. Cada capa debe tener una responsabilidad verificable.
Cómo lo aplica Coresis
En Coresis lo usamos como parte de la operación de plataformas Drupal, con reglas de caché que distinguen tráfico público, sesiones editoriales e invalidaciones. Esa configuración se revisa junto con el servicio de soporte Drupal y con la capa de entrega, no como un archivo aislado.
Fuente y tecnologías relacionadas
Contrasta capacidades y límites en la guía oficial de proxy inverso de NGINX.