Qué es un proxy inverso

Cuando abres un sitio web, casi nunca hablas directamente con el programa que genera la página. En el camino hay un servidor que recibe tu petición y se la entrega a la app. Ese intermediario es el proxy inverso, y está delante de la mayoría de los sitios y APIs que usas.

Entenderlo resuelve dudas comunes: dónde se configura el HTTPS, por qué tu app ve la IP equivocada, cómo ejecutar dos apps en los mismos puertos públicos y por qué un WebSocket se corta al cabo de un minuto.

¿Qué es un proxy inverso?#

Un proxy inverso es un servidor que recibe peticiones en nombre de otros servidores y las reenvía. El cliente habla solo con él. El servidor que está detrás, llamado upstream o backend, no recibe conexiones directas desde internet.

El nombre viene del contraste con el proxy común. Un proxy directo (forward proxy) actúa en nombre del cliente: una empresa lo usa para filtrar lo que visitan los empleados, y el sitio de destino ve la IP del proxy. Un proxy inverso actúa en nombre del servidor: el cliente ve la dirección del proxy y no sabe cuántas apps hay detrás.

Ejemplos conocidos: nginx, Caddy, HAProxy, Traefik y Envoy. Los servicios de CDN también funcionan como un proxy inverso global.

¿Cómo funciona un proxy inverso?#

Una petición recorre cinco pasos:

1. El navegador resuelve el dominio por DNS y se conecta a la IP del proxy.
2. El proxy acepta la conexión y, si es HTTPS, hace el handshake TLS.
3. Lee la petición (método, ruta, cabecera Host) y decide a qué upstream enviarla.
4. Abre una conexión con el upstream, que suele estar en la misma máquina o en la misma red privada, y reenvía la petición.
5. Recibe la respuesta y se la devuelve al cliente.

Como el proxy lee la petición, puede modificarla por el camino: añadir cabeceras, reescribir rutas, guardar la respuesta en caché o rechazar la conexión.

¿Para qué sirve un proxy inverso?#

• HTTPS en un solo lugar. El proxy termina el TLS y habla HTTP simple con la app, dentro de la red interna. Tu código no maneja certificados. Mira qué es SSL/TLS.
• Varias apps en una IP. Con la cabecera Host, el proxy envía api.ejemplo.com a una app y ejemplo.com a otra, ambas en los puertos 80 y 443.
• Balanceo de carga. El proxy reparte las peticiones entre varias copias de la app. Es el tema de qué es un balanceador de carga.
• Caché. Las respuestas que no cambian salen de la memoria o del disco del proxy, sin despertar a la app. A escala global, eso es una CDN.
• Protección. La app no queda expuesta. El proxy puede limitar peticiones por IP, bloquear patrones de ataque y ocultar detalles de la infraestructura.
• Compresión y HTTP/2. El proxy comprime las respuestas y habla protocolos modernos con el cliente, aunque la app solo entienda HTTP/1.1.

¿Cómo configurar un proxy inverso con nginx?#

Supón una app Node.js escuchando en 127.0.0.1:3000. El archivo siguiente envía hacia ella todo lo que llegue al dominio:

server {
    listen 80;
    server_name ejemplo.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        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:

• proxy_pass define el upstream. Puede ser http://, https:// o un socket Unix.
• Por defecto, nginx envía al upstream Host: $proxy_host, es decir, la dirección del propio upstream. proxy_set_header Host $host reenvía el dominio que pidió el cliente, que muchos frameworks esperan.
• X-Forwarded-For lleva la lista de IPs por las que pasó la petición. $proxy_add_x_forwarded_for añade la IP de quien se conectó al proxy al valor que el cliente ya envió.
• X-Forwarded-Proto informa si el cliente usó http o https, necesario para que la app genere enlaces y redirecciones correctos.

Comprueba la sintaxis con nginx -t y recarga con nginx -s reload.

¿Y si la app usa WebSocket?#

Upgrade y Connection son cabeceras hop-by-hop: nginx no las reenvía por sí solo. Sin ellas, la conexión WebSocket falla. Añade un location propio:

location /ws/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600s;
}

Por defecto, nginx cierra la conexión si el upstream no envía datos durante 60 segundos. Para conexiones inactivas, aumenta proxy_read_timeout como arriba o haz que la app envíe frames de ping periódicamente.

¿Cómo descubre la app la IP real del usuario?#

Detrás de un proxy, la conexión que llega a la app viene del proxy, así que la IP de origen es la suya. La IP del cliente viaja en X-Forwarded-For, con el formato cliente, proxy1, proxy2. MDN lo describe como un estándar de facto; el estandarizado es Forwarded, mucho menos usado.

Hay un riesgo: cualquier cliente puede enviar un X-Forwarded-For falso. Para limitar peticiones o controlar accesos, usa solo las IPs añadidas por proxies en los que confías, contando desde la derecha de la lista. Si la app es accesible directamente desde internet, ninguna parte de la cabecera es fiable. Los frameworks tienen una opción para esto, como trust proxy en Express.

¿Cuándo no necesito un proxy inverso?#

• Bots que solo hacen conexiones salientes (Discord, Telegram con long polling) no reciben peticiones.
• Una sola app simple en una plataforma que ya entrega HTTPS delante de ella no requiere que instales nginx por tu cuenta.
• Protocolos que no son HTTP, como la conexión directa a una base de datos, necesitan un proxy TCP (capa 4) o ningún proxy.

Cada capa extra es una pieza más que configurar y monitorear, y un punto más que puede fallar. Añade una cuando haya un motivo concreto.

Cómo hacerlo en Square Cloud#

En Square Cloud no instalas ni configuras un proxy inverso para el caso común. Toda aplicación web recibe un subdominio *.squareweb.app con HTTPS en cualquier plan, y el TLS es automático. El borde recibe el HTTPS, redirige HTTP a HTTPS y reenvía la petición a tu app, que solo tiene que escuchar en 0.0.0.0 en el puerto de la variable PORT.

La red incluye una CDN Anycast con más de 200 puntos de presencia, HTTP/3, WebSockets, WAF y mitigación de DDoS L3/L4/L7. El proxy no corta conexiones largas: WebSocket y SSE pasan sin búfer.

Desde el plan Standard, apuntas un dominio propio creando en tu registrador los registros DNS que muestra el panel. El dominio sigue registrado a tu nombre, y el panel muestra el estado de validación en tiempo real.

Para repartir el tráfico entre copias de tu app, el load balancing sirve un mismo dominio personalizado desde varias aplicaciones, con round-robin y failover pasivo, sin sticky session: hasta 2 aplicaciones por dominio en Standard, hasta 5 en Pro y hasta 10 en Enterprise.

Consulta los detalles de la capa de red en Red y CDN.