Forward proxy y reverse proxy: ¿en qué se diferencian?

La palabra «proxy» se usa para dos esquemas distintos, y se confunden constantemente. Cuando un desarrollador dice «hemos puesto un proxy delante del sitio», se refiere a un reverse proxy. Cuando un equipo de datos dice «nuestras peticiones pasan por un proxy», se refiere a un forward proxy. Ambos son intermediarios entre dos partes; la diferencia está en en nombre de quién trabajan y quién los configura.

Este artículo define cada esquema por separado, muestra paso a paso cómo pasa una petición por cada uno y resume las diferencias en una tabla. Después vemos para qué se usa un reverse proxy (balanceo de carga, terminación TLS, caché), dónde encajan las CDN y una configuración breve de Nginx.

¿Qué es un forward proxy?#

Un forward proxy es el intermediario que usan uno o varios clientes para llegar a internet. El cliente conoce la dirección del proxy y le envía sus peticiones; el proxy las reenvía a los sitios de destino con su propia dirección IP. El sitio de destino ve la conexión como procedente del proxy.

En el lenguaje cotidiano, «proxy» casi siempre significa forward proxy. Los proxies residenciales, de centro de datos y móviles que venden los proveedores son todos forward proxies. Explicamos el mecanismo básico en detalle en Qué es un servidor proxy y cómo funciona.

Este es el camino de una petición a través de un forward proxy:

1. El usuario configura la dirección del proxy en el navegador o en el código.
2. El cliente se conecta al proxy en lugar de al sitio de destino y, para HTTPS, envía una petición CONNECT target.com:443.
3. El proxy autentica al cliente si hace falta y se conecta al sitio de destino con su propia dirección IP.
4. El sitio de destino registra la petición como procedente de la IP del proxy y le envía la respuesta.
5. El proxy devuelve la respuesta al cliente.

Usar un forward proxy desde la línea de comandos es una sola opción:

curl -x "http://user:pass@pr.proxynet.io:8000" https://httpbin.org/ip

Aquí el cliente sabe que hay un proxy, porque ha indicado la dirección él mismo.

¿Qué es un reverse proxy?#

Un reverse proxy es un intermediario situado delante de uno o varios servidores. Cuando un visitante se conecta a example.com, en realidad se conecta al reverse proxy; este reenvía la petición a uno de los servidores de aplicación que tiene detrás y devuelve la respuesta al visitante. El visitante no sabe qué máquina ha respondido, ni necesita saberlo.

El estándar HTTP, RFC 9110, llama a este esquema «gateway» o «reverse proxy» y lo describe como un intermediario que actúa como servidor de origen desde el punto de vista del cliente. Para el cliente, el reverse proxy es el sitio.

Este es el camino de una petición a través de un reverse proxy:

1. El visitante abre example.com; el DNS resuelve el nombre a la dirección IP del reverse proxy.
2. El reverse proxy acepta la conexión y normalmente descifra TLS en ese punto.
3. Elige uno de los servidores backend según la ruta de la petición, el nombre de host o la carga actual.
4. Reenvía la petición a ese servidor y añade la dirección IP real del visitante en una cabecera X-Forwarded-For o Forwarded.
5. Recibe la respuesta del servidor de aplicación, la guarda en caché si está configurado y la envía al visitante.

¿Cuál es la diferencia entre ambos?#

Los dos esquemas toman tráfico de un extremo y lo pasan al otro. La forma más rápida de ver la diferencia es preguntar a qué intereses sirve el intermediario.

La fila más importante es la de TLS. Un forward proxy solo abre un túnel para el tráfico HTTPS y transporta bytes cifrados. Un reverse proxy tiene el certificado del sitio, así que descifra el tráfico, lee la petición y puede enrutarla según su contenido.

¿Para qué se usa un reverse proxy?#

Un reverse proxy asume los trabajos de los que la aplicación no debería tener que ocuparse:

• Balanceo de carga. Reparte las peticiones entrantes entre varios servidores de aplicación. Si un servidor deja de responder, el tráfico pasa a los demás y los visitantes no lo notan.
• Terminación TLS. La gestión de certificados y el descifrado se hacen en un solo lugar. Los servidores backend pueden hablar HTTP plano en la red interna o usar un certificado interno aparte.
• Caché y compresión. Guarda las páginas y archivos estáticos solicitados con frecuencia y comprime las respuestas, de modo que llegan menos peticiones al servidor de aplicación.
• Capa de seguridad. Aplica reglas de firewall de aplicaciones web (WAF), límites de velocidad y filtros de bots. Las direcciones IP de los servidores backend no quedan expuestas directamente a ataques.
• Enrutamiento por ruta. Envía las peticiones /api a un servicio y las de /blog a otro, de modo que varias aplicaciones funcionan bajo un mismo dominio.
• Despliegues sin interrupción. Publicar una versión nueva en servidores nuevos y desplazar el tráfico poco a poco se hace a través del reverse proxy.

Cómo trabaja un reverse proxy junto a un firewall se explica en Proxy o firewall: ¿en qué se diferencian?.

¿Cómo se configura un reverse proxy sencillo con Nginx?#

La directiva central de un reverse proxy en Nginx es proxy_pass. La configuración siguiente reparte el tráfico que llega al puerto 443 entre dos servidores de aplicación y pasa la IP real del visitante al backend:

upstream app {
    server 10.0.0.11:3000;
    server 10.0.0.12:3000;
}

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/ssl/example.com/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.com/privkey.pem;

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

Qué hace cada línea:

• El bloque upstream define los servidores backend. Por defecto Nginx reparte las peticiones por turnos; directivas como least_conn o ip_hash cambian el método.
• listen 443 ssl y las líneas del certificado terminan TLS en el reverse proxy.
• proxy_pass reenvía la petición al grupo app.
• Sin las líneas proxy_set_header, la aplicación backend ve todas las peticiones como procedentes de la IP del reverse proxy, lo que deja sin sentido los registros y los límites de velocidad.

La lista completa de directivas está en la documentación de ngx_http_proxy_module de Nginx.

¿Se puede confiar en la cabecera X-Forwarded-For?#

Una aplicación detrás de un reverse proxy lee la dirección IP del visitante en la cabecera X-Forwarded-For. Esa cabecera es texto plano y el cliente también puede enviarla. Si la aplicación confía en ella a ciegas, un visitante puede escribir una IP falsa y saltarse límites de velocidad o restricciones por IP.

El enfoque correcto:

• Tener en cuenta la cabecera solo en conexiones que vienen de reverse proxies conocidos. En Nginx se hace con las directivas set_real_ip_from y real_ip_header.
• Si hay varios intermediarios, leer la lista de derecha a izquierda y tomar la dirección anterior al último intermediario de confianza.
• Donde la infraestructura lo admita, preferir la cabecera estandarizada Forwarded (RFC 7239).

La misma lógica vale en el lado del forward proxy: un sitio de destino puede mirar las cabeceras que añade un proxy y ver al cliente real. Por eso la mayoría de los servicios de proxy no añaden cabeceras con la IP del cliente.

¿Una CDN es un reverse proxy?#

Sí. Una red de distribución de contenido (CDN) está formada por servidores reverse proxy repartidos por todo el mundo. Cuando pones un sitio detrás de una CDN, tu dominio resuelve a las IP de la CDN; los visitantes se conectan al servidor de la CDN más cercano, y la CDN reenvía a tu servidor (el origen) las peticiones que no tiene en caché.

Por eso las CDN asumen a gran escala todos los trabajos de un reverse proxy: terminación TLS, caché, absorción de ataques DDoS, WAF y gestión de bots. Los límites de velocidad y las páginas de verificación de bots con las que se topa un scraper no suelen venir del propio sitio de destino, sino de esta capa de reverse proxy que tiene delante. Para un ejemplo de cómo esa capa clasifica el tráfico de bots, consulta Cloudflare Precursor.

¿Se usan juntos el forward y el reverse proxy?#

La mayoría de las peticiones pasan por ambos. Cuando el script de un equipo de datos obtiene precios de una tienda online, el camino es este:

1. El script envía la petición al forward proxy del equipo.
2. El forward proxy resuelve el dominio del sitio y se conecta a la CDN (reverse proxy) que hay delante del sitio.
3. La CDN evalúa la petición y, si no está en caché, la reenvía al servidor de aplicación del sitio.
4. La respuesta vuelve al script por la misma cadena.

Aquí el sitio ve la IP de salida del forward proxy y el script ve la IP de la CDN; ninguna de las partes conoce la máquina real que hay detrás de la otra. En las redes corporativas la cadena es aún más larga: equipo del empleado → proxy de la empresa → firewall → internet → CDN del sitio → servidor de aplicación.

Casos de uso#

• Equipo de recogida de datos: usa un forward proxy para ver precios en distintos países y repartir peticiones. Para este trabajo se configura un Proxies rotativos, que da una IP distinta en cada conexión a través de una sola dirección. El escalado de rastreos se trata en nuestra página de solución de web crawler.
• Equipo de TI corporativo: usa un forward proxy para sacar el tráfico de los empleados por una única salida y guardar registros, y un reverse proxy para exponer aplicaciones internas. La parte de protección de datos está en nuestra página de solución de seguridad de datos.
• Desarrollador de aplicaciones web: pone la aplicación detrás de Nginx o de una CDN y deja el balanceo de carga y TLS fuera del código de la aplicación.
• Equipo de pruebas de software: usa un forward proxy para ver cómo se abre una aplicación desde otros países y un reverse proxy para reunir servicios de prueba bajo un mismo dominio.
• Usuario individual: configura un forward proxy como un Proxies HTTPS para enrutar el tráfico del navegador por otra ubicación. Si además necesita cifrado, la herramienta es una VPN.

Errores comunes#

• Tratar un reverse proxy como herramienta de anonimato. Un reverse proxy protege al propietario del sitio; no oculta la IP del visitante y, de hecho, la pasa al backend con X-Forwarded-For.
• No reenviar la cabecera Host. Por defecto Nginx envía el nombre de servidor de la dirección de proxy_pass. Si la aplicación backend depende del nombre de dominio, devuelve el sitio equivocado o una página de error.
• Dejar el servidor backend accesible directamente. Las reglas de seguridad del reverse proxy pierden sentido si el servidor de aplicación se puede alcanzar por su propia IP. El puerto de la aplicación solo debería estar abierto a la dirección interna del reverse proxy.
• Llevar la identidad en cabeceras en un forward proxy. Un proxy Squid propio puede añadir las cabeceras X-Forwarded-For y Via con la configuración por defecto, y entonces el sitio de destino ve la dirección real del cliente.
• Timeouts desajustados. Si el timeout del reverse proxy es más corto que el de la aplicación, las peticiones largas se cortan con 504 Gateway Timeout.

Guía de decisión#

Preguntas frecuentes#

¿«Reverse proxy» es lo mismo que «proxy inverso»?#

Sí, son dos nombres para lo mismo. La documentación técnica y la configuración del software usan casi siempre «reverse proxy».

¿Una VPN es un forward proxy?#

En su función se parecen: ambos sacan tu tráfico por otro servidor y el sitio de destino ve la IP de ese servidor. Pero una VPN funciona a nivel del sistema operativo y cifra todo el tráfico entre tu dispositivo y el servidor VPN. Un forward proxy se configura por aplicación y no cifra nada por sí mismo.

¿Se puede usar Nginx como forward proxy?#

Nginx puede reenviar peticiones HTTP planas, pero la versión estándar no admite el método CONNECT necesario para HTTPS; para eso hace falta un módulo de terceros. Los forward proxies suelen montarse con software específico como Squid.

¿Un reverse proxy ralentiza un sitio?#

En teoría añade un pequeño retraso porque hay un salto más. En la práctica, la mayoría de los sitios cargan más rápido detrás de un reverse proxy o una CDN gracias a la caché, la compresión, la reutilización de conexiones y la cercanía a los visitantes.

¿Un sitio revela que está detrás de un reverse proxy?#

A menudo sí. Aparecen cabeceras de respuesta como Server, Via o cabeceras propias de la CDN, y la IP del dominio pertenece a una CDN. Aun así, esa información no revela la dirección del servidor que hay detrás.

¿Qué tipo de proxy venden los servicios de proxy?#

Los servicios de proxy residencial, de centro de datos, ISP y móvil son todos forward proxies. Recibes una dirección de entrada y tus peticiones salen por una de las IP de salida del proveedor.

En resumen#

Un forward proxy representa al cliente y un reverse proxy al servidor. El usuario configura el forward proxy a sabiendas y el sitio de destino ve la IP del proxy; el propietario del sitio configura el reverse proxy y los visitantes nunca ven los servidores de detrás. Los reverse proxies se encargan del balanceo de carga, la terminación TLS, la caché y la seguridad, y las CDN son la misma idea a escala global. Si necesitas enviar peticiones desde distintas direcciones IP y ubicaciones, lo que buscas es un forward proxy; encontrarás las opciones en nuestros servicios de proxy.