Proxy inverso: qué es y cómo configurarlo en Nginx

Un proxy inverso es un servidor que se planta delante de tus backends y recibe las solicitudes de los clientes en su nombre. A diferencia del forward proxy, que protege al que navega, el reverse proxy protege al servidor: oculta su IP real, reparte la carga y termina el SSL antes de que el tráfico toque tu aplicación.

Un proxy inverso es un componente de red que intercepta las peticiones HTTP entrantes y las redirige a uno o más servidores backend, devolviendo la respuesta al cliente como si la hubiera generado él. Se usa para balanceo de carga, caché, terminación SSL y seguridad perimetral. En 2026, las implementaciones más comunes siguen siendo Nginx, Apache y Caddy.

Hosting es el servicio que almacena los archivos de un sitio web en servidores de internet, desarrollado por empresas de hosting especializadas. Permite que los sitios sean accesibles públicamente y funcionen continuamente.

¿Qué es un proxy en desarrollo web?

Un proxy es un intermediario. Punto. Toma tu solicitud, la lleva hasta el destino y te trae la respuesta de vuelta, pero la otra punta nunca habla directamente con vos.

La analogía más fácil es la VPN. Cuando usás una, tu pedido no va directo a la web: pasa primero por el servidor de la VPN, que lo reenvía por vos y devuelve lo que llega. Ese servidor es el intermediario. Eso, en esencia, es un proxy. La diferencia entre los dos tipos que veremos no está en qué hacen, sino en a quién protegen. Esto se conecta con lo que analizamos en infraestructura de cloud.

Ahora bien, no todo intermediario es bueno. Un intermediario malicioso que se mete a espiar tus datos tiene nombre propio: ataque Man-in-the-Middle. La diferencia es la confianza. En infraestructura web usamos proxies que controlamos nosotros, justamente para que la comunicación entre servicios sea más segura y prolija (no para chusmear tráfico ajeno).

¿Cuál es la diferencia entre forward proxy y reverse proxy?

El flujo es el mismo: cliente, intermediario, servidor. Lo que cambia es de qué lado se para el proxy y a quién le tapa la cara.

Un forward proxy se sienta del lado del cliente. Vos configurás el navegador o la red para que todo salga a través de él. Sirve para anonimato, para saltar restricciones geográficas o para filtrar lo que puede salir de una oficina. El servidor del otro lado ve la IP del proxy, no la tuya.

Un proxy inverso hace lo contrario: se sienta del lado del servidor. El cliente cree que habla con un único servidor, cuando en realidad detrás puede haber tres, diez o cincuenta máquinas. Según la documentación de Cloudflare, esta es la pieza que se encarga de recibir el tráfico, distribuirlo y devolver la respuesta sin revelar qué hay atrás.

Aspecto	Forward proxy	Reverse proxy
Ubicación	Delante del cliente	Delante del servidor
A quién protege	Al que navega	Al backend
Qué oculta	La IP del cliente	La IP y topología del servidor
Caso típico	Anonimato, filtrado de salida	Balanceo, caché, terminación SSL
Quién lo configura	El usuario o la red	El dueño del servicio

¿Por qué usar un reverse proxy en tu infraestructura?

Ponele que tenés una app que arrancó en un solo servidor y empezó a recibir tráfico de verdad. El día que ese servidor se cae, se cae todo. Y si alguien escanea tu IP, encuentra la máquina exacta donde corre tu base de datos. Un proxy inverso resuelve las dos cosas de una. Para más detalles técnicos, mirá configuración en tu hosting.

• Oculta los backends. El atacante ve la IP del proxy, nunca la de tus servidores reales. Menos superficie expuesta.
• Balancea la carga. Reparte las solicitudes entre varias máquinas, así ninguna se satura sola.
• Termina el SSL. El proxy maneja los certificados en un solo lugar. Tus backends hablan HTTP plano puertas adentro y te ahorrás configurar TLS en cada uno.
• Cachea respuestas. Contenido estático servido desde el proxy = menos trabajo para el backend y menos latencia para el usuario.
• Da alta disponibilidad. Si un backend muere, el proxy lo saca de la rotación y manda el tráfico a los que siguen vivos.

Esto importa especialmente cuando alojás aplicaciones de cara al público. Si estás montando tu infraestructura en un VPS o servidor dedicado, conviene tener el reverse proxy bien configurado desde el día uno; proveedores como donweb.com te dan el control total del servidor para hacerlo sin restricciones raras.

¿Cómo funciona un proxy inverso en la arquitectura web?

El recorrido es simple de seguir. El cliente abre una conexión contra el proxy inverso, el proxy elige uno de los backends disponibles, le pasa la solicitud, espera la respuesta y se la devuelve al cliente. Para el navegador, todo el ida y vuelta ocurrió hacia una sola dirección: la del proxy inverso.

¿Y cómo sabe el backend quién era el cliente original si todo le llega desde el proxy? Acá entran los headers de reenvío. El proxy agrega X-Forwarded-For con la IP real del cliente, X-Real-IP con la misma información y X-Forwarded-Proto para indicar si la conexión original era HTTP o HTTPS. Sin esos headers, tu app cree que todos los visitantes son el proxy.

Hay un detalle que muerde seguido. Cuando desplegás detrás de un servicio gestionado, a veces el propio hosting reescribe o sobreescribe esos headers antes de que lleguen a tu código. El autor de la nota original en dev.to cuenta exactamente ese problema: el servicio donde tenía deployada la app le pisaba el dato del subdominio antes de que su código pudiera leerlo. La lección es clara: siempre verificá qué headers llegan de verdad, no los que asumís.

Configuración básica de reverse proxy en Nginx

Nginx es la opción por defecto para esto, y con razón. Te alcanza con un bloque upstream que define dónde están tus backends y un proxy_pass que manda el tráfico ahí. Lo demás son los headers que no podés olvidar.

upstream backend_app {
 server 127.0.0.1:3000;
}

server {
 listen 80;
 server_name midominio.com;

 location / {
 proxy_pass http://backend_app;
 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;
 }
}

Esos cuatro proxy_set_header no son decorativos. Host mantiene el nombre de dominio original, los dos de IP preservan quién es el cliente real y X-Forwarded-Proto evita los bucles de redirección cuando terminás el SSL en el proxy. La sintaxis completa está en la documentación oficial de Nginx.

Reverse proxy para balanceo de carga entre servidores

El salto interesante viene cuando metés más de un servidor en el bloque upstream. Ahí Nginx pasa de simple intermediario a balanceador. Por defecto usa round-robin: reparte las solicitudes una por una, en orden, entre todos los backends. En arquitecturas modernas en la nube profundizamos sobre esto.

upstream backend_cluster {
 least_conn;
 server 10.0.0.1:3000 weight=3;
 server 10.0.0.2:3000;
 server 10.0.0.3:3000 max_fails=2 fail_timeout=30s;
}

Tenés varios algoritmos según lo que necesites:

• Round-robin: el default. Reparte parejo, ideal si tus backends son iguales.
• weighted: con weight=3 un servidor recibe el triple de tráfico. Sirve si una máquina es más potente que las otras.
• least_conn: manda cada solicitud al backend con menos conexiones activas. Mejor para requests que duran distinto.
• ip_hash: ata a cada cliente al mismo backend según su IP. Necesario si manejás sesiones en memoria sin almacenamiento compartido.

Los parámetros max_fails y fail_timeout arman un health check pasivo: si un backend falla dos veces, Nginx lo saca de la rotación durante 30 segundos y lo reintenta después. No es un chequeo activo, pero zafa para la mayoría de los casos sin instalar nada extra.

Errores comunes al implementar un proxy inverso

Casi todos los problemas con un reverse proxy caen en la misma media docena de fallas. Estas son las que más se repiten.

• No preservar la IP real del cliente. Sin X-Forwarded-For ni X-Real-IP, tus logs muestran la IP del proxy para todos. Corrección: seteá los dos headers en cada location.
• Dejar los backends accesibles directo. Si tus servidores reales responden por internet sin pasar por el proxy, todo el beneficio de seguridad se cae. Corrección: bindealos a la red interna o cerrá el firewall a todo lo que no sea el proxy.
• File descriptors insuficientes. Con tráfico alto, Nginx se queda sin descriptores de archivo y empieza a tirar errores. Corrección: subí worker_connections y el límite del sistema con worker_rlimit_nofile.
• proxy_pass mal armado con la barra final. Poner o sacar el / al final del proxy_pass cambia cómo se reescribe la ruta. Corrección: probá con y sin barra y revisá qué URL recibe el backend de verdad.
• Olvidar X-Forwarded-Proto. Si terminás SSL en el proxy pero no avisás el protocolo, la app puede entrar en un loop infinito de redirección a HTTPS. Corrección: agregá proxy_set_header X-Forwarded-Proto $scheme y configurá tu app para confiar en él.

Preguntas Frecuentes

¿Qué es un proxy inverso?

Un proxy inverso es un servidor que recibe las solicitudes de los clientes y las reenvía a uno o más servidores backend, devolviendo la respuesta como si fuera propia. Oculta la infraestructura real, balancea carga y centraliza la seguridad. Nginx y Apache son las implementaciones más usadas.

¿Cuál es la diferencia entre forward proxy y reverse proxy?

El forward proxy se ubica del lado del cliente y oculta quién hace la solicitud; el reverse proxy se ubica del lado del servidor y oculta quién responde. El primero da anonimato al usuario, el segundo da seguridad y escalabilidad al backend. Ya lo cubrimos antes en en tus pipelines CI/CD.

¿Cómo configurar un reverse proxy en Nginx?

Se necesita un bloque upstream que liste los backends y una directiva proxy_pass dentro de un bloque location. Hay que sumar los headers Host, X-Real-IP, X-Forwarded-For y X-Forwarded-Proto para preservar la información del cliente original.

¿Por qué un proxy inverso mejora la seguridad del servidor?

Porque oculta la IP y la topología de los servidores backend: el atacante solo ve el proxy y nunca las máquinas reales. Además centraliza la terminación SSL y permite filtrar tráfico malicioso antes de que llegue a la aplicación.

¿Un proxy inverso sirve para balanceo de carga?

Sí. Al definir varios servidores en el bloque upstream, Nginx reparte las solicitudes entre ellos con algoritmos como round-robin, least_conn o ip_hash. También saca de rotación a los backends que fallan, dando alta disponibilidad sin software adicional.

Conclusión

El proxy inverso es de esas piezas que no ves hasta que la necesitás, y cuando la necesitás ya es tarde para improvisar. Si tu app vive en internet, en algún momento vas a querer ocultar los backends, repartir la carga o centralizar el SSL. Mejor montarlo antes de que el tráfico te obligue.

Lo concreto para arrancar: definí tu bloque upstream, no te olvides nunca de los cuatro headers de reenvío y cerrá el acceso directo a tus backends. Con esas tres cosas ya tenés el 80% del beneficio. El balanceo y la caché vienen después, cuando los números lo pidan.

Fuentes

• Nginx – Documentación oficial de balanceo de carga HTTP
• Cloudflare – Qué es un reverse proxy
• Apache HTTP Server – Guía de proxy inverso
• Microsoft – Reverse proxy con URL Rewrite y ARR
• dev.to – The Invisible Middleman: Understanding Forward and Reverse Proxies