Servidores proxy: Parte 2 — Nginx

Nginx — servidor web y proxy inverso de código abierto (licencia BSD). Desde 2019 el proyecto pertenece a la empresa F5. Además de la versión gratuita existe Nginx Plus comercial. Nginx sirve archivos estáticos, acepta HTTPS, proxya solicitudes a las aplicaciones y distribuye la carga entre varios servidores. En esta parte se analiza su funcionamiento como proxy inverso.

Qué ofrece la versión gratuita de nginx

• Proxy HTTP — reenvía solicitudes a aplicaciones mediante HTTP, FastCGI (PHP-FPM), uwsgi, gRPC.
• Terminación TLS — acepta HTTPS y HTTP/2, y en versiones nuevas también HTTP/3.
• Balanceo — algoritmos round-robin (por defecto), least_conn, ip_hash, hash, con pesos para servidores.
• Comprobaciones de estado pasivas — si un servidor no responde max_fails veces durante fail_timeout, nginx deja temporalmente de enviarle solicitudes.
• Caché de respuestas en disco (proxy_cache).
• Limitación de la tasa de solicitudes (limit_req) y del número de conexiones (limit_conn).
• WebSocket — se proxya desde la versión 1.3.13.
• TCP y UDP — módulo stream, disponible desde la versión 1.9.0. Está incluido en la versión gratuita; al compilar desde el código fuente se habilita con la opción --with-stream, en los paquetes oficiales de nginx.org ya viene compilado, y en Debian y Ubuntu se instala con el paquete libnginx-mod-stream.

Nginx Plus añade comprobaciones activas de estado de los servidores (nginx consulta periódicamente su estado), modificación de la composición de servidores vía API sin reinicio, estadísticas ampliadas y soporte técnico. En la versión gratuita no hay comprobaciones activas — esta es una de las razones para elegir HAProxy si el balanceo es lo más importante.

Ejemplo: sitio con HTTPS y WebSocket

La aplicación escucha en el puerto 3000 en el mismo servidor, el certificado lo emite Let’s Encrypt. La configuración se coloca en /etc/nginx/conf.d/example.ru.conf:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

upstream app {
    server 127.0.0.1:3000;
}

server {
    listen 80;
    server_name example.ru;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;
    http2 on;
    server_name example.ru;

    ssl_certificate     /etc/letsencrypt/live/example.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;

    client_max_body_size 20m;

    location / {
        proxy_pass http://app;
        proxy_http_version 1.1;

        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        proxy_set_header Upgrade    $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_read_timeout 1h;
    }
}

Qué es importante aquí:

• el bloque map elige el valor del encabezado Connection: upgrade para WebSocket y close para solicitudes normales. Los encabezados Upgrade y Connection no se transmiten a la aplicación automáticamente; hay que especificarlos explícitamente;
• la directiva http2 on apareció en la versión 1.25.1; en versiones más antiguas HTTP/2 se activa con el parámetro listen 443 ssl http2;
• proxy_http_version 1.1 es necesaria para WebSocket en versiones de nginx anteriores a la 1.29.7, en las que por defecto se usa HTTP/1.0 hacia la aplicación;
• proxy_read_timeout 1h evita que nginx cierre la conexión WebSocket: por defecto se corta si la aplicación no envía nada durante 60 segundos.

Antes de aplicar la configuración se verifica y luego se recarga sin detener el servidor:

nginx -t && systemctl reload nginx

Balanceo entre varios servidores

upstream app {
    least_conn;
    server 10.0.0.11:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.12:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.13:3000 backup;
}

least_conn envía la solicitud al servidor con el menor número de conexiones activas. Un servidor con tres fallos en 30 segundos se excluye durante los mismos 30 segundos. El servidor backup recibe solicitudes solo cuando los principales no están disponibles. Si la aplicación guarda sesiones en la memoria del proceso, hay que fijar al usuario en un solo servidor (ip_hash o hash $cookie_...), o mejor mover las sesiones a un almacenamiento compartido, por ejemplo Redis.

Limitación de la frecuencia de solicitudes

# en el contexto http
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

# en server
location /login {
    limit_req zone=login burst=5 nodelay;
    limit_req_status 429;
    proxy_pass http://app;
}

Desde una misma dirección IP se permiten cinco solicitudes por minuto a la página de inicio de sesión con una reserva temporal de otras cinco. Las restantes reciben respuesta 429. Esta regla dificulta considerablemente los ataques de fuerza bruta para adivinar contraseñas.

Caché de respuestas de la aplicación

Si la aplicación devuelve respuestas idénticas a distintos visitantes, por ejemplo un catálogo o una API pública, nginx puede almacenarlas en disco y no consultar a la aplicación en cada petición:

# en el contexto http
proxy_cache_path /var/cache/nginx/app levels=1:2 keys_zone=app_cache:10m
                 max_size=1g inactive=60m use_temp_path=off;

# en server
location /catalog/ {
    proxy_cache app_cache;
    proxy_cache_valid 200 301 10m;
    proxy_cache_valid 404 1m;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    add_header X-Cache-Status $upstream_cache_status;
    proxy_pass http://app;
}

proxy_cache_use_stale permite servir una copia obsoleta mientras la aplicación está inaccesible o está actualizando la respuesta. El encabezado X-Cache-Status muestra si la respuesta vino del caché (HIT) o de la aplicación (MISS). Por defecto nginx no cachea respuestas en las que la aplicación establece cookies o prohíbe el cacheo mediante encabezados Cache-Control. Esto protege frente a que la página personal de un usuario llegue a otro. Desactivar estas comprobaciones solo es recomendable si se está completamente seguro de que la respuesta no contiene datos personales.

Protección mínima

• server_tokens off; quita el número de versión de nginx de los encabezados y de las páginas de error;
• el acceso a direcciones de administración se limita con las directivas allow y deny o con contraseña (auth_basic);
• no conviene servir dominios desconocidos por defecto: un bloque server separado con listen 443 ssl default_server y return 444; cierra la conexión para peticiones con nombres ajenos o vacíos. Para ese bloque aún se necesita certificado, por ejemplo autofirmado, o la directiva ssl_reject_handshake on; (desde la versión 1.19.4).

Proxy TCP: módulo stream

El bloque stream se coloca en el nivel superior de nginx.conf, junto al bloque http, y no dentro de él. Ejemplo — acceso a PostgreSQL con un servidor de respaldo:

stream {
    upstream postgres {
        server 10.0.0.21:5432;
        server 10.0.0.22:5432 backup;
    }

    server {
        listen 5432;
        proxy_pass postgres;
        proxy_connect_timeout 5s;
        proxy_timeout 10m;
    }
}

UDP se proxya de la misma forma, añadiendo el parámetro udp en la directiva listen. El módulo ssl_preread permite en el modo stream leer el nombre del sitio desde el apretón de manos TLS y dirigir la conexión al servidor correcto sin descifrarla. Así, en un mismo puerto 443 se pueden atender varios servicios con sus propios certificados.

Errores típicos

• No se pasó Host. Por defecto nginx sustituye en el encabezado Host el nombre del proxy_pass (por ejemplo, app), y la aplicación con varios dominios responde con el sitio equivocado. Hace falta la línea proxy_set_header Host $host.
• No se pasó X-Forwarded-Proto. La aplicación piensa que fue abierta por HTTP y redirige infinitamente a HTTPS o genera enlaces con http://.
• Slash final en proxy_pass. proxy_pass http://app/; dentro de location /api/ recorta /api/ de la ruta de la solicitud, mientras que proxy_pass http://app; transmite la ruta completa. Esta es una causa frecuente de errores 404 tras la configuración.
• Bufferización de respuestas en streaming. Por defecto nginx bufferiza la respuesta de la aplicación. Para transmisión en streaming (Server-Sent Events, salida gradual de respuestas de modelos de IA) se desactiva la bufferización: proxy_buffering off; en el location necesario o con el encabezado X-Accel-Buffering: no desde la aplicación.
• Error 413. Por defecto el tamaño del cuerpo de la solicitud está limitado a 1 MB, y la subida de archivos se interrumpe. El límite se establece con client_max_body_size.
• Error 504. La aplicación responde en más de 60 segundos —el valor por defecto de proxy_read_timeout. Se incrementa el tiempo para el location concreto, no para todo el sitio.
• Dirección del cliente incorrecta detrás de un segundo proxy. Si delante de nginx hay otro proxy o CDN, la dirección real se restaura con el módulo realip: set_real_ip_from con las direcciones de ese proxy y real_ip_header X-Forwarded-For.

Forks: freenginx y Angie

• freenginx — fork fundado en febrero de 2024 por Maksim Dunin, uno de los desarrolladores principales de nginx, tras desacuerdos con F5 sobre la política de seguridad. El proyecto busca mantener plena compatibilidad con nginx.
• Angie — fork creado por exdesarrolladores de nginx; la base de código se separó de nginx 1.23.1, licencia BSD. El desarrollador es la empresa rusa «Web-Server». Angie añade estadísticas integradas, comprobaciones activas de estado de los servidores y otras capacidades que no están en el nginx gratuito. La versión comercial Angie PRO está incluida en el registro de software ruso.

En la mayoría de los casos las configuraciones de nginx se trasladan a ambos forks sin cambios.

Cuándo elegir nginx

Nginx es una buena elección por defecto si hay que publicar un sitio o una aplicación: al mismo tiempo sirve archivos estáticos, acepta HTTPS y proxya solicitudes, y hay ejemplos de configuración para casi cualquier software. Si la tarea principal es balancear entre muchos servidores con comprobaciones activas, estadísticas detalladas y reglas finas para TCP, HAProxy suele ser más conveniente.