Saltar a contenido

NGINX-MOD

Como sabrás, nuestro repositorio contiene la última versión estable de NGINX y una amplia variedad de módulos dinámicos para él.

Sin embargo, algunas personas orientadas al rendimiento siempre están buscando acelerar lo que ya es rápido, es decir, el propio NGINX.

Existen algunos parches de código abierto para ello, principalmente de Cloudflare, para mejorar aún más las cosas. Para evitar problemas a muchas personas que dependen de una compilación manual, construimos este NGINX mejor parcheado como un paquete que es compatible con todos los módulos de NGINX que tenemos. Su nombre oficial es NGINX-MOD.

NGINX-MOD se basa en el último NGINX estable con las siguientes adiciones:

  • Soporte HTTP/3 sin interrupciones: Experimenta conexiones web más rápidas y fiables con el protocolo HTTP/3 de vanguardia.
  • Compresión HPACK HTTP/2 mejorada: Mejora el rendimiento de tu sitio web a través de una compresión de encabezados optimizada, asegurando una transferencia de datos más rápida.
  • Gestión dinámica de registros TLS: Mejora tanto la seguridad como la velocidad con registros TLS gestionados dinámicamente, adaptándose a las necesidades de tu sitio en tiempo real.
  • Limitación avanzada de tasa: Obtén un control preciso sobre el tráfico con el ngx_http_limit_req_module ampliado, que te permite establecer límites de solicitudes de forma horaria, diaria, semanal o anual.
  • Monitoreo activo de salud: Mantén un alto tiempo de actividad y fiabilidad con verificaciones de salud en tiempo real de tus servidores upstream. Aprende más
  • Características de seguridad mejoradas: Protege la información de tu servidor deshabilitando la visualización del nombre del software NGINX tanto en el encabezado Server: como en las páginas de error.
  • Proxy SSL seguro con el método CONNECT: Maneja y proxy solicitudes SSL utilizando el método CONNECT, asegurando una transmisión de datos segura y eficiente.
  • Soporte para modo oscuro: Soporte automático para el modo oscuro en las páginas de error de NGINX.
  • Emulación del encabezado Host para HTTP/3: El $http_host se inicializa desde la autoridad, proporcionando mejor compatibilidad con aplicaciones que dependen del encabezado Host.

¡Actualiza a GetPageSpeed hoy y aprovecha al máximo estas avanzadas características de NGINX-MOD para optimizar el rendimiento, la seguridad y la fiabilidad de tu sitio web!

Más sobre esos parches en la documentación a continuación.

Cómo instalar NGINX-MOD

dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install dnf-plugins-core
dnf config-manager --disable getpagespeed-extras-mainline
dnf config-manager --enable getpagespeed-extras-nginx-mod
dnf -y install nginx-mod
systemctl enable --now nginx

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install yum-utils
yum-config-manager --disable getpagespeed-extras-mainline
yum-config-manager --enable getpagespeed-extras-nginx-mod
yum -y install nginx-mod
systemctl enable --now nginx

dnf -y install https://extras.getpagespeed.com/release-latest.rpm
amazon-linux-extras install epel
yum -y install yum-utils
yum-config-manager --disable getpagespeed-extras-mainline
yum-config-manager --enable getpagespeed-extras-nginx-mod
yum -y install nginx-mod
systemctl enable --now nginx

Cómo cambiar a NGINX-MOD desde nuestro NGINX regular

Si estabas utilizando nuestra versión regular de NGINX, puedes ejecutar una serie de comandos para actualizar a NGINX-MOD sin afectar los módulos instalados o la configuración:

yum -y install https://extras.getpagespeed.com/release-latest.rpm yum-utils
yum-config-manager --disable getpagespeed-extras-mainline
yum-config-manager --enable getpagespeed-extras-nginx-mod
yum -y update nginx
service nginx upgrade

Módulos para NGINX-MOD

NGINX-MOD es totalmente compatible con más de 50 paquetes de módulos NGINX en nuestro repositorio base. Así que puedes instalarlos como de costumbre, por ejemplo:

dnf -y install nginx-module-pagespeed

Verificaciones de Salud Activas

Características Clave de las Verificaciones de Salud Activas

  • Soporte Multi-Protocolo: HTTP, TCP, SSL Hello, MySQL, AJP, FastCGI.
  • Verificaciones Personalizables: Intervalo, tiempo de espera, umbrales de éxito/fallo.
  • Panel de Estado: Monitoreo en tiempo real a través de HTML, CSV o JSON.
  • Ajustes Dinámicos: Marcar servidores como activos/inactivos según las verificaciones de salud.

Conceptos Básicos de Configuración para Verificaciones de Salud Activas

Ejemplo: Verificación de Salud HTTP

http {
  upstream backend {
    server 192.168.1.10:80;
    server 192.168.1.11:80;

    # Configuración de verificación de salud
    check interval=5s rise=2 fall=3 timeout=4s type=http;
    check_http_send "GET /health HTTP/1.1\r\nHost: example.com\r\n\r\n";
    check_http_expect_alive http_2xx http_3xx;
  }

  server {
    listen 80;
    location / {
      proxy_pass http://backend;
    }

    # Panel de estado de salud (acceso restringido)
    location /status {
      check_status html;
      allow 10.0.0.0/8;  # IPs autorizadas
      deny all;
      access_log off;
    }
  }
}

Explicación:

  • check:
  • interval=5s: Verificar cada 5 segundos.
  • rise=2: Marcar el servidor como "activo" después de 2 éxitos consecutivos.
  • fall=3: Marcar el servidor como "inactivo" después de 3 fallos consecutivos.
  • type=http: Usar verificaciones HTTP.
  • check_http_send: Solicitud HTTP personalizada enviada a los servidores upstream.
  • check_http_expect_alive: Tratar respuestas HTTP 2xx/3xx como saludables.
  • check_status: Expone un panel en /status en formato HTML.

Referencia de Directivas de Verificaciones de Salud Activas

Directivas Básicas

Directiva Sintaxis Predeterminado Descripción
check interval=ms [fall=count] [rise=count] [timeout=ms] [type=protocol] [default_down=true\|false] [port=number] interval=30s fall=5 rise=2 timeout=1s type=tcp default_down=true Configura los parámetros de verificación de salud.
check_http_send "HTTP_REQUEST" "GET / HTTP/1.0\r\n\r\n" Solicitud HTTP personalizada para verificaciones type=http.
check_http_expect_alive http_2xx \| http_3xx \| ... http_2xx \| http_3xx Códigos de estado HTTP que indican un servidor saludable.

Directivas Avanzadas

Directiva Propósito
check_keepalive_requests Número de solicitudes por conexión (predeterminado: 1).
check_fastcgi_param Parámetros personalizados de FastCGI para verificaciones type=fastcgi.
check_shm_size Tamaño de memoria compartida para verificaciones de salud (predeterminado: 1M).

Tipos de Verificaciones de Salud Activas

1. type=http

  • Uso: 
    check type=http;
check_http_send "HEAD /health HTTP/1.1\r\nHost: example.com\r\n\r\n";
check_http_expect_alive http_200 http_302;
  • Códigos de Respuesta: Configura los estados aceptables (por ejemplo, http_2xx).

2. type=tcp

  • Verificación simple de conexión TCP: 
    check interval=10s type=tcp;

3. type=mysql

  • Valida la disponibilidad del servidor MySQL: 
    check type=mysql port=3306;

4. type=fastcgi

  • Parámetros personalizados de FastCGI: 
    check type=fastcgi;
check_fastcgi_param "REQUEST_METHOD" "GET";
check_fastcgi_param "SCRIPT_FILENAME" "index.php";

Configuración de la Página de Estado

Configuración del Endpoint

location /status {
  check_status [html|csv|json];  # Predeterminado: html
  allow 192.168.1.0/24;         # Restringir acceso
  deny all;
}

Parámetros de Consulta

  • format: Sobrescribir el formato de salida (por ejemplo, /status?format=json).
  • status: Filtrar servidores por estado (por ejemplo, /status?status=down).

Salidas de Ejemplo

  • HTML: Tabla interactiva con el estado del servidor.
  • JSON: Formato legible por máquina para automatización.
  • CSV: Valores separados por comas simplificados.

Solución de Problemas y Mejores Prácticas para Verificaciones de Salud Activas

Problemas Comunes

  1. Memoria Compartida Agotada:

  2. Solución: Aumentar check_shm_size en el bloque http: 

    http {
  check_shm_size 10M;  # Predeterminado: 1M
}

  3. Falsos Positivos/Negativos:

  4. Ajustar los umbrales rise/fall y validar las solicitudes de check_http_send.

  5. Errores de Tiempo de Espera:

  6. Aumentar timeout si los servidores upstream responden lentamente.

Consejos de Seguridad

  • Restringir el acceso al endpoint /status utilizando allow/deny.
  • Usar HTTPS para la página de estado si se expone información sensible.

Las verificaciones activas funcionan sin problemas con ip_hash, least_conn y módulos de terceros como sticky o fair.

Parche ngx_http_limit_req_module

Algunos usuarios de NGINX buscan definir la limitación de tasa de una vez al día para recursos específicos. Esto no es posible con el NGINX estándar. Nuestro parche permite una configuración de limitación de tasa más detallada. Ejemplos:

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/h; # 1 solicitud por hora
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/d; # 1 solicitud por día
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/w; # 1 solicitud por semana
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/M; # 1 solicitud por mes
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/Y; # 1 solicitud por año

Es importante notar que el tamaño de memoria de la zona definida debe permitir retener entradas de IP antiguas antes de que se aplique la tasa definida.

Por ejemplo, has definido una zona de 10m y 1r/d para un recurso particular. 10m puede almacenar alrededor de 160,000 direcciones IP. Así que si alguien visita tu recurso limitado por tasa, y tu tráfico hacia él excede 160K visitantes únicos dentro de 24 horas, entonces el mismo visitante teóricamente no puede ser limitado por tasa dentro del mismo día, porque la información sobre su dirección IP será expulsada de la memoria después de que suficientes visitantes hayan visitado el recurso.

Esta nota también se aplica a la configuración del módulo estándar, pero menos.

Así que las reglas generales son:

  • Probablemente necesites aumentar el tamaño de la zona de memoria, si tu tráfico es suficiente para poder expulsar direcciones IP antiguas "demasiado pronto"
  • Esto es más apropiado para limitar la tasa de recursos específicos, no de todo el sitio web

¿Qué es el Parche HPACK?

El parche HPACK implementa HPACK completo en NGINX. En resumen, esto permite comprimir los encabezados HTTP.

¿Qué es el soporte para el método CONNECT?

NGINX-MOD proporciona soporte para la solicitud del método CONNECT. Este método se utiliza principalmente para tunelizar solicitudes SSL a través de servidores proxy.

Para habilitar y configurar, consulta las directivas proxy_connect.

Directivas de Configuración de NGINX-MOD

Hay algunas directivas de configuración en esta versión, que no están disponibles en versiones regulares. Documentémoslas aquí.

El siguiente conjunto de directivas de configuración es añadido por el parche de registros TLS dinámicos.

ssl_dyn_rec_enable on|off

Si habilitar los registros TLS dinámicos.

ssl_dyn_rec_size_lo

El tamaño del registro TLS con el que comenzar. Por defecto es de 1369 bytes (diseñado para que todo el registro quepa en un solo segmento TCP: 1369 = 1500 - 40 (IPv6) - 20 (TCP) - 10 (Tiempo) - 61 (Máximo overhead de TLS)) ssl_dyn_rec_size_hi: el tamaño del registro TLS al que crecer. Por defecto es de 4229 bytes (diseñado para que todo el registro quepa en 3 segmentos TCP).

ssl_dyn_rec_threshold

El número de registros a enviar antes de cambiar el tamaño del registro.

Debido a que construimos con la última versión de OpenSSL:

ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2] [TLSv1.3];

No es una nueva directiva. Pero dado que construimos con la versión más reciente de OpenSSL estable, permite usar el valor TLSv1.3.

Ocultando información del software

Por defecto, NGINX solo admite server_tokens off; que aún muestra nginx en el encabezado Server: y en las páginas de error. Con NGINX-MOD, puedes especificar un nuevo valor none, que hará que NGINX deje de emitir su presencia en el servidor:

server_tokens none;

Verificación

Para verificar cómo te beneficias de NGINX-MOD, puedes realizar algunas pruebas.

Verificar la compresión de encabezados HTTP/2

yum install nghttp2
h2load https://example.com -n 2 | tail -6 | head -1

Salida de ejemplo:

traffic: 71.46KB (73170) total, 637B (637) headers (space savings 78.68%), 70.61KB (72304) data

Si ves un ahorro de espacio del 50% o más, significa que se está utilizando la compresión HPACK completa.

Cómo volver a NGINX estable

Regresar al paquete estable mientras se preserva la configuración existente:

yum-config-manager --disable getpagespeed-extras-nginx-mod
MOD_PKGS=$(rpm -qa --queryformat '%{NAME}\n' | grep nginx-mod | grep -v nginx-module)
rpm --erase --justdb --nodeps ${MOD_PKGS}
STABLE_PKGS=$(echo ${MOD_PKGS} | sed 's@nginx-mod@nginx@g')
yum -y install ${STABLE_PKGS}
yum history sync

Estos comandos deshabilitarán el repositorio NGINX-MOD y reemplazarán cualquier paquete nginx-mod* con sus equivalentes del repositorio base, degradando así a NGINX estable.

Notas de compatibilidad

  • NGINX-MOD actualmente no es compatible con el panel de control Plesk.