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.
Actualizado en agosto de 2026 · Equipo Coresis
¿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.