NGINX Plus vs NGINX Open Source: diferencias y cuándo elegir

NGINX existe en dos ediciones: NGINX Open Source, gratuita y con licencia BSD, y NGINX Plus, la versión comercial de F5 que se vende por suscripción. Ambas comparten el mismo núcleo y la misma sintaxis de configuración, así que la pregunta real es si las funciones exclusivas de Plus compensan su coste en tu caso o si puedes cubrirlas con la edición libre y alguna herramienta adicional. Esta guía compara las dos ediciones con ejemplos de configuración concretos y termina con una recomendación según el tipo de despliegue.

Resumen de diferencias

La edición libre recibe funciones de Plus de vez en cuando: la resolución dinámica de nombres en los bloques upstream pasó a NGINX Open Source en la versión 1.27.3. Comprueba la versión que tienes instalada con nginx -v antes de descartar una función.

Health checks: pasivos frente a activos

Esta es la diferencia que más se nota en producción.

NGINX Open Source: health checks pasivos

La edición libre solo detecta que un backend está caído cuando una petición real falla contra él. Tras max_fails fallos dentro de fail_timeout, deja de enviarle tráfico durante fail_timeout y después vuelve a probar con peticiones reales:

upstream app_backend {
    zone app_backend 256k;
    server 10.0.0.11:8080 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:8080 max_fails=3 fail_timeout=30s;
}

server {
    listen 80;
    server_name your_domain;

    location / {
        proxy_pass http://app_backend;
        proxy_next_upstream error timeout http_502 http_503;
        proxy_next_upstream_tries 2;
    }
}

proxy_next_upstream reintenta la petición en otro servidor cuando falla, de modo que el cliente normalmente no ve el error. Aun así, algunos usuarios reciben respuestas lentas mientras NGINX descubre el fallo, y un backend que devuelve 200 con contenido erróneo nunca se marca como caído.

NGINX Plus: health checks activos

Plus consulta cada backend de forma periódica e independiente del tráfico, y puede validar el código de estado, cabeceras y cuerpo de la respuesta:

upstream app_backend {
    zone app_backend 256k;
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
}

match app_ok {
    status 200;
    body ~ "\"status\":\"ok\"";
}

server {
    listen 80;
    server_name your_domain;

    location / {
        proxy_pass http://app_backend;
        health_check uri=/health interval=5s fails=2 passes=2 match=app_ok;
    }
}

Con esta configuración un backend se retira tras dos comprobaciones fallidas y vuelve tras dos correctas, antes de que ningún cliente llegue a notarlo. La directiva zone es obligatoria: los health checks guardan el estado en memoria compartida entre los procesos worker.

Alternativa gratuita: si necesitas health checks activos sin Plus, HAProxy los incluye en su edición libre (option httpchk), y es habitual colocarlo delante o en lugar de NGINX para el balanceo.

Monitorización

NGINX Open Source: stub_status

La edición libre expone siete contadores globales con el módulo stub_status, incluido en los paquetes de Ubuntu y de nginx.org. Publícalo solo en local:

server {
    listen 127.0.0.1:8081;

    location = /nginx_status {
        stub_status;
    }
}

curl http://127.0.0.1:8081/nginx_status

Active connections: 3
server accepts handled requests
 1542 1542 4817
Reading: 0 Writing: 1 Waiting: 2

No hay métricas por upstream ni por servidor virtual. Para llevarlas a Prometheus existe el exportador oficial nginx-prometheus-exporter, y para análisis por backend lo habitual es añadir $upstream_response_time y $upstream_addr al log_format y procesar los logs.

NGINX Plus: API y dashboard

Plus incluye una API REST con métricas detalladas por zona, upstream y servidor (peticiones, códigos de respuesta, tiempos, estado de los health checks) y un dashboard web que la consume:

server {
    listen 8080;
    allow 10.0.0.0/8;
    deny all;

    location /api/ {
        api write=on;
    }

    location = /dashboard.html {
        root /usr/share/nginx/html;
    }
}

Con write=on, la misma API permite añadir, retirar o drenar servidores de un upstream sin recargar NGINX, algo muy útil cuando un orquestador o un script de despliegue gestiona los backends. Restringe siempre el acceso a la API con allow/deny o autenticación, porque con escritura activada cualquiera que llegue a ella puede modificar el balanceo.

Sesiones persistentes

Las aplicaciones que guardan la sesión en memoria necesitan que cada usuario vaya siempre al mismo backend.

NGINX Plus lo resuelve con sticky, que inserta su propia cookie:

upstream app_backend {
    zone app_backend 256k;
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
    sticky cookie srv_id expires=1h path=/ httponly secure;
}

En NGINX Open Source puedes aproximarlo con hash sobre una cookie que ya emita tu aplicación, con consistent para que añadir o quitar un servidor solo redistribuya una parte de las sesiones:

upstream app_backend {
    hash $cookie_sessionid consistent;
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
}

La diferencia práctica: las peticiones sin la cookie (la primera visita) se reparten en round robin, y cuando la aplicación crea la sesión, el hash de la cookie nueva puede apuntar a un servidor distinto del que la creó, así que el usuario pierde la sesión en su segunda petición. ip_hash evita ese problema pero agrupa a todos los usuarios que salen por la misma IP (oficinas, redes móviles con CGNAT). La solución más robusta, independiente de la edición, es guardar las sesiones en un almacén compartido como Redis y no depender de la persistencia en el balanceador.

Autenticación con JWT

NGINX Plus valida tokens JWT en el propio proxy, antes de que la petición llegue a la aplicación:

location /api/ {
    auth_jwt "api";
    auth_jwt_key_file /etc/nginx/jwks.json;
    proxy_pass http://app_backend;
}

En NGINX Open Source las opciones son validar el token en la aplicación, usar auth_request para delegar la comprobación en un pequeño servicio de autenticación, o escribir la validación en JavaScript con el módulo njs. Las tres funcionan, pero requieren código propio que en Plus es una directiva.

Licencia, precio e instalación

• NGINX Open Source se instala desde los repositorios de Ubuntu (sudo apt install nginx) o desde el repositorio oficial de nginx.org si quieres la rama mainline con las últimas funciones.
• NGINX Plus se instala desde el repositorio privado de F5 con un certificado y una clave de cliente que se obtienen al contratar. Desde la versión R33 también exige un archivo de licencia (license.jwt) en el servidor y envía informes de uso a F5; sin un archivo de licencia válido, NGINX Plus no arranca.
• F5 no publica una tarifa: el precio se negocia por instancia y año, y suele incluir soporte técnico. Existe una prueba gratuita de 30 días para evaluar la edición.

Ten en cuenta el coste total: con varias instancias por entorno (producción, staging, réplicas en otra región), la suscripción se multiplica por cada una.

Cuándo elegir cada edición

Elige NGINX Open Source si:

• Sirves sitios web o haces de proxy inverso para pocos backends estables.
• Puedes cubrir la monitorización con stub_status, logs y Prometheus.
• Las sesiones de tu aplicación están en un almacén compartido, o hash/ip_hash te bastan.
• Tu equipo puede resolver incidencias con la documentación y la comunidad.

Elige NGINX Plus si:

• Necesitas health checks activos y reconfiguración de upstreams por API sin añadir otra pieza como HAProxy.
• Quieres validar JWT o usar sesiones persistentes con cookie directamente en el balanceador.
• Operas varios nodos de NGINX que deben compartir estado (zone_sync) para límites de tasa o sesiones.
• Tu organización exige soporte comercial con acuerdos de nivel de servicio.

Para la mayoría de proyectos alojados en uno o varios VPS, NGINX Open Source combinado con health checks pasivos, sesiones en Redis y Prometheus cubre las necesidades sin coste de licencia. Si lo que te falta son health checks activos y balanceo avanzado, prueba antes HAProxy, que los ofrece gratis, y reserva Plus para cuando el soporte del fabricante o sus funciones de API sean requisitos reales.

Conclusión

NGINX Plus no es un servidor distinto, sino NGINX Open Source con funciones de balanceo, observabilidad y seguridad pensadas para entornos grandes y dinámicos, más soporte de F5. Revisa qué funciones de la tabla necesitas de verdad y si ya existe una alternativa libre para cada una. Como siguientes pasos, puedes configurar NGINX como balanceador de carga con health checks pasivos, exponer stub_status a Prometheus con nginx-prometheus-exporter o comparar el balanceo de NGINX con el de HAProxy.