Programación · Servidores · Redes

¿Qué es un proxy inverso?

En cuanto ejecutas más de una aplicación en un servidor —un sitio web, una API, quizá unos cuantos contenedores— te topas con un problema práctico: los visitantes llegan todos a los puertos 80 y 443, pero cada aplicación escucha en un sitio distinto. Un proxy inverso es la respuesta estándar. Esta guía explica qué es un proxy inverso, en qué se diferencia del proxy que quizá ya conoces y por qué casi todo despliegue en producción tiene uno.

La definición corta

Un proxy inverso es un servidor que se sitúa delante de uno o varios servidores backend, recibe cada petición entrante del cliente y la reenvía al backend adecuado, para luego devolver la respuesta de ese backend al cliente. Para el visitante, el proxy inverso es el sitio web: solo habla con él y nunca ve los servidores que hay detrás. La palabra «inverso» importa, y la siguiente sección explica por qué.

Proxy inverso vs proxy directo

Un proxy normal (directo) se sitúa delante de los clientes. Cuando tu navegador está configurado para usar uno, tus peticiones salen a través del proxy en tu nombre: actúa por quienes hacen las peticiones. Un proxy inverso es la imagen reflejada: se sitúa delante de los servidores y actúa en su nombre. Los clientes se conectan a él creyendo que es el servidor real, y él decide qué backend atiende realmente cada petición. La misma idea de intermediario, pero en el lado opuesto de la conversación.

Para qué se usa de verdad un proxy inverso

• Enrutamiento por nombre de host o ruta: enviar api.example.com a tu API y example.com a tu sitio web, aunque ambos corran en la misma máquina.
• Terminación TLS: gestionar los certificados HTTPS en un solo sitio para que cada backend hable HTTP simple internamente y tú manejes los certificados una sola vez.
• Caché: almacenar y servir directamente las respuestas frecuentes, para no golpear el backend en cada petición.
• Búfer y protección: absorber clientes lentos, aplicar límites y ocultar las direcciones reales de los backends tras un único punto de entrada público.

En la práctica, el enrutamiento y el TLS ya bastan para justificarlo: te permiten alojar varias aplicaciones en un solo VPS de forma limpia, con HTTPS, tras una única dirección.

Proxy inverso vs balanceador de carga

Estos conceptos se solapan, de ahí la confusión. Un balanceador de carga tiene una función concreta: repartir el tráfico entrante entre varios backends idénticos para que ninguno se sature. Un proxy inverso es el concepto más amplio —reenvía peticiones y puede hacer muchas cosas (enrutamiento, TLS, caché), y repartir la carga entre backends es una de ellas. Así que un balanceador de carga es, en esencia, un proxy inverso centrado en la tarea de balanceo. La mayoría de los proxies inversos modernos también pueden balancear carga, mientras que un balanceador dedicado quizá no haga mucho más.

Las herramientas comunes

Los proxies inversos más usados son Nginx, Caddy, HAProxy y Traefik. Nginx es la referencia de toda la vida y es extremadamente rápido sirviendo y haciendo de proxy. Caddy es popular porque obtiene y renueva los certificados HTTPS automáticamente, casi sin configuración. Traefik está pensado para entornos de contenedores y Kubernetes, donde descubre los servicios a medida que aparecen y desaparecen. HAProxy se prefiere cuando el balanceo de carga de alto volumen es la prioridad. Los proveedores de nube también ofrecen proxies inversos y balanceadores gestionados como servicio.

Un ejemplo mínimo

Una configuración de proxy inverso es sobre todo una lista corta de reglas. En Nginx, enviar las peticiones de un host a una aplicación que corre en local en el puerto 3000 se ve así:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
    }
}

Esa es toda la idea: las peticiones para example.com llegan a Nginx en el puerto 80, y Nginx las reenvía a tu aplicación en el puerto 3000, pasando el host original. Añade un bloque TLS y un segundo server para tu API, y una sola máquina sirve varias aplicaciones por HTTPS de forma limpia.

Las concesiones honestas

Un proxy inverso añade una pieza móvil más. Se convierte en el punto único por el que pasa cada petición, así que si cae, todo lo que hay detrás queda inaccesible —por eso en producción se ejecuta de forma fiable y a veces por duplicado. También añade algo de latencia y un archivo de configuración más que entender. Para una sola aplicación pequeña que ya escucha en el puerto 443, quizá no lo necesites. Pero en cuanto alojas más de un servicio, quieres gestionar el HTTPS en un solo sitio o piensas escalar, un proxy inverso se amortiza rápido.

Preguntas frecuentes

Explora más explicaciones claras en nuestro índice de guías.