Proxy inverso y balanceo de carga

Un proxy directo se coloca delante de los clientes. Los equipos de una empresa o un colegio se configuran para enviarle todas sus peticiones, y él las hace en su nombre. La web de destino ve la IP del proxy, no la de cada empleado.

Se usa para filtrar qué webs se pueden visitar, registrar el tráfico, guardar en caché lo que se descarga mucho o salir a internet desde una red que no tiene acceso directo.

Un proxy inverso se coloca delante de los servidores. El navegador cree que habla con mitienda.com, pero en realidad habla con Nginx, que reenvía cada petición a la app que corresponda dentro de tu red y devuelve su respuesta. Los clientes nunca ven las máquinas de detrás.

Es el sitio natural para todo lo que es común a tus apps: terminar TLS, comprimir, cachear, limitar peticiones, repartir la carga y dirigir cada ruta a un servicio distinto. Nginx, HAProxy, Traefik, Caddy y Envoy son proxies inversos, igual que los balanceadores de los proveedores cloud o una CDN.

Dentro de un location, proxy_pass http://127.0.0.1:3000; hace que Nginx abra una conexión con tu app, le envíe la petición, espere la respuesta y se la devuelva al cliente. El destino puede ser una dirección y un puerto, un socket local o el nombre de un grupo upstream, que verás enseguida.

Un detalle importa mucho: si la dirección no lleva ruta, Nginx pasa la ruta original tal cual; si lleva una, aunque sea solo una / final, sustituye el prefijo del location por esa ruta.

Para tu app, la petición llega desde Nginx: la IP de origen es la del proxy y la conexión es HTTP aunque el usuario usara HTTPS. Además, Nginx envía por defecto como Host el nombre del destino de proxy_pass, no el dominio original. Las cabeceras recuperan esa información.

Host lleva el dominio que pidió el usuario, X-Forwarded-For la lista de IP por las que ha pasado la petición, empezando por la del cliente, y X-Forwarded-Proto si usó http o https. Existe también una cabecera estándar, Forwarded, menos extendida.

En el bloque http declaras upstream app { … } con una línea server por cada copia de tu app, y luego usas proxy_pass http://app;. Nginx reparte las peticiones entre ellos según el algoritmo que elijas, que por defecto es round robin.

Cada server admite parámetros: weight para el peso, max_fails y fail_timeout para detectar caídas, backup para un servidor de reserva que solo recibe tráfico si fallan los demás, y down para sacarlo del reparto a mano.

Es el algoritmo por defecto: la primera petición va al primer servidor, la segunda al segundo, la tercera al tercero y la cuarta, de nuevo, al primero. Es sencillo, predecible y reparte bien cuando todos los servidores son iguales y todas las peticiones cuestan más o menos lo mismo.

Con weight=3, un servidor recibe el triple de peticiones que uno con el peso por defecto, que es 1. Nginx no las agrupa (tres seguidas a uno y luego una a cada otro), sino que las intercala para que la carga sea uniforme en el tiempo.

Los pesos también sirven para meter una versión nueva con cuidado: le das un peso pequeño, miras si da errores y vas subiéndolo.

Con least_conn;, Nginx cuenta cuántas peticiones tiene en curso con cada servidor y manda la nueva al que menos tiene. Si una máquina está atascada con peticiones lentas, deja de recibir más hasta que se libere. En caso de empate, reparte por turnos.

Con ip_hash;, Nginx calcula un hash a partir de la IP del cliente y lo usa para elegir el servidor. Como el hash siempre da lo mismo para la misma IP, ese cliente cae siempre en la misma máquina: lo que se llama sesiones pegajosas (sticky sessions). En IPv4 solo usa los tres primeros números, así que 83.45.12.7 y 83.45.12.200 van juntos.

Si su servidor no está disponible, el cliente pasa a otro. Para sacar uno en mantenimiento sin descolocar a los demás clientes, márcalo con down en vez de borrarlo.

El Nginx de código abierto hace comprobaciones pasivas: no pregunta a los servidores, sino que observa las peticiones reales. Si un servidor acumula max_fails fallos (por defecto 1) dentro del periodo fail_timeout (por defecto 10 segundos), lo da por no disponible durante ese mismo fail_timeout. Pasado ese tiempo, lo vuelve a probar con una petición real: si responde, vuelve al reparto.

Qué cuenta como fallo y cuándo reintentar la petición en otro servidor lo decide proxy_next_upstream: por defecto, los errores de conexión y los tiempos de espera agotados. Así el usuario no nota el fallo, porque su petición se repite en otra máquina.

Con proxy_cache_path defines dónde se guardan las respuestas en el disco y una zona de memoria para el índice; con proxy_cache la activas en un location. La primera petición llega a la app (un MISS) y Nginx guarda la respuesta; las siguientes, mientras sea válida, se sirven desde la caché (un HIT) sin tocar la app.

Por defecto respeta las cabeceras de caché de tu app, solo guarda peticiones GET y HEAD, y no guarda respuestas que crean una cookie. Con proxy_cache_use_stale puede incluso servir una copia caducada si la app está caída.

limit_req_zone define una zona con una clave (normalmente la IP del cliente) y un ritmo máximo, como 5r/m (cinco por minuto) o 10r/s. limit_req lo aplica en un location. Funciona como un cubo que gotea: las peticiones salen al ritmo fijado, y las que llegan de más esperan en una cola de tamaño burst o se rechazan.

Con nodelay, las peticiones que caben en el burst se atienden al momento en lugar de esperar. Las que no caben reciben un error, por defecto un 503; limit_req_status 429 lo cambia por el más correcto «429 Too Many Requests».