Los patrones de reverse proxy de Nginx que de verdad operamos en producción

La mayoría de configs de reverse proxy Nginx en producción son un copia-pega del blog de alguien de 2017. Funciona, más o menos. El keep-alive al backend está apagado, así que cada petición abre una nueva conexión. La cadena X-Forwarded-For está mal, así que la aplicación registra la IP cliente incorrecta. proxy_buffering está activado por defecto, lo que añade latencia en respuestas streameadas. Ninguna es un fallo dramático — son impuestos lentos y constantes que solo notas cuando te sientas a leer lo que has desplegado.

Esta es la config de reverse proxy que copiamos en el edge de cada cliente.

El bloque upstream mínimo viable

upstream app {
    server 10.0.1.10:8080 max_fails=3 fail_timeout=15s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=15s;
    keepalive 32;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}
 
location / {
    proxy_pass http://app;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    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_read_timeout 60s;
}

El keepalive 32 + Connection "" no es negociable. Sin eso, re-haces handshake TCP al backend en cada petición — y para tráfico interno de alto RPS eso duplica la latencia sin razón.

El artículo completo cubre:

• La cadena X-Forwarded-For — y el bloque real_ip_header que hace que la app vea la IP correcta
• proxy_buffering vs respuestas streameadas (Server-Sent Events, descargas grandes)
• Health checks: pasivos (max_fails/fail_timeout) vs activos (Nginx Plus comercial o ngx_http_upstream_check_module)
• proxy_next_upstream — cuándo los retries ayudan y cuándo causan escrituras duplicadas
• Límites de tamaño de body (client_max_body_size) y dónde muerden las subidas
• El patrón TLS-to-backend cuando realmente lo quieres

Entregamos esta config en cada instalación Nginx gestionada.