Configurar proxy inverso con Nginx paso a paso

Configurar un proxy inverso con Nginx se ha convertido en casi un estándar de facto cuando queremos mejorar el rendimiento, la seguridad y la flexibilidad de nuestras aplicaciones web. No importa si montas un simple proyecto personal, un servidor de prácticas en clase o la infraestructura de una empresa: tarde o temprano vas a necesitar poner un proxy inverso delante de tus servidores de aplicaciones.

En este artículo vamos a ver qué es exactamente un proxy inverso, en qué se diferencia de un proxy de reenvío, qué ventajas aporta, cómo encaja con WordPress y otros stacks (Apache, Gunicorn, Kubernetes, etc.) y, sobre todo, cómo dejar Nginx perfectamente configurado como proxy inverso, incluyendo balanceo de carga, cabeceras personalizadas, caché, SSL y ejemplos prácticos de laboratorio con dos máquinas Debian.

Qué es un proxy y qué lo diferencia de un proxy inverso

Antes de tocar un solo archivo de configuración conviene tener claras las ideas sobre qué papel juega un proxy dentro de una arquitectura de red moderna, porque si no es muy fácil liarse con términos como proxy directo, inverso, CDN, balanceador, pasarela API, etc.

• Un proxy “normal” (proxy de reenvío o forward proxy) se coloca delante de un conjunto de clientes (por ejemplo, los ordenadores de una oficina, un aula o una red doméstica) y actúa como intermediario cuando esos equipos acceden a Internet. En una comunicación típica sin proxy, el equipo A (cliente) se conecta directamente al servidor C (servidor de origen). Con un proxy de reenvío, el equipo A habla con B (proxy), y es B quien se comunica con C, recibe la respuesta y se la devuelve a A.
• El proxy inverso plantea el escenario opuesto: en lugar de proteger el anonimato del cliente, protege y abstrae a uno o varios servidores de origen. Lo colocamos “por delante” del servidor web o del pool de servidores que sirven la aplicación (Apache, Nginx como servidor web, LiteSpeed, Gunicorn, Node.js, PHP-FPM, etc.), y todo el tráfico entrante de los usuarios llega primero a este proxy inverso.

Si ponemos nombre a las máquinas la diferencia se ve clara: D serían los ordenadores de los usuarios, E el proxy inverso, y F uno o más servidores de origen. Sin proxy inverso, D se comunicaría directamente con F. Con proxy inverso, D solo ve a E, y es E quien decide cómo y a qué F mandar cada petición, y cómo devolver la respuesta a D. El objetivo es que ningún cliente se conecte de forma directa a los servidores de origen.

Por qué merece la pena usar un proxy inverso con Nginx

Usar Nginx como proxy inverso no es un capricho. Se trata de una pieza clave para escalar un sitio, mejorar su seguridad y simplificar la arquitectura, sobre todo cuando combinamos diferentes tecnologías o queremos un dominio único para varios servicios.

Una de las ventajas más potentes es el balanceo de carga. Si tienes un sitio con mucho tráfico, un solo servidor backend puede quedarse corto. Con un proxy inverso puedes repartir las peticiones entre varios servidores de origen que ofrecen el mismo contenido. Si uno cae o se satura, el resto siguen sirviendo el sitio, reduciendo los puntos únicos de fallo.

El proxy inverso también es un escudo de seguridad muy efectivo porque oculta la IP real y otros detalles de los servidores backend. Los usuarios (y los atacantes) solo ven el proxy. De este modo, es mucho más difícil lanzar ataques dirigidos. Además, puedes endurecer el proxy con reglas de cortafuegos, autenticación HTTP básica, filtrado avanzado de tráfico o integración con un WAF.

Otro aspecto clave es la caché y la aceleración web. Nginx, Varnish u otras soluciones de proxy inverso pueden almacenar en caché contenido estático y parte del contenido dinámico, ahorrando recursos a los servidores de origen y sirviendo las respuestas desde el propio proxy, muchas veces desde una ubicación geográfica más cercana al usuario. Esto reduce latencia y mejora radicalmente los tiempos de carga.

Por último, el proxy inverso simplifica el cifrado y la terminación SSL/TLS. El servidor de origen no tiene por qué encargarse de cifrar y descifrar todas las conexiones HTTPS, ya que el proxy inverso puede hacer de terminador SSL, descargar esa carga de CPU y centralizar la gestión de certificados, incluso apoyándose en hardware especializado de aceleración SSL si hace falta.

NGINX como proxy inverso: características y papel en arquitecturas modernas

Nginx es uno de los servidores web y proxies inversos más utilizados en el mundo, tanto en su versión open source como en NGINX Plus (la edición comercial con funciones avanzadas de monitorización, gestión por API y soporte empresarial). Se utiliza como servidor web estático, reverse proxy, balanceador de carga, terminador SSL, controlador de entrada en Kubernetes y pasarela API.

Como proxy inverso, Nginx se sitúa entre los clientes y los servidores backend (Apache, LiteSpeed, Gunicorn, PHP-FPM, Node.js, etc.) y analiza cada petición entrante para decidir qué hacer con ella: servirla directamente desde caché si es estática, reenviarla al backend adecuado si es dinámica o devolver un error controlado si algo va mal.

Para distribuir tráfico entre varios servidores back-end, Nginx implementa diversos algoritmos de balanceo, como round-robin (por turnos), “menos conexiones” (envía cada nueva petición al servidor con menos conexiones activas) o hashing por IP (que ayuda a mantener la sesión de un cliente atada siempre al mismo backend).

NGINX Plus y otras soluciones derivadas amplían estas capacidades con monitorización en tiempo real, paneles de estado, health checks avanzados y APIs de configuración dinámica, lo que encaja muy bien con arquitecturas nativas cloud y despliegues sobre Kubernetes donde Nginx suele actuar como controlador de Ingress.

Montaje de laboratorio: dos servidores Debian con Nginx y proxy inverso

Un ejercicio muy didáctico para entender Nginx como proxy inverso consiste en trabajar con dos máquinas Debian: una actuando como servidor web “final” (backend) y otra como proxy inverso. Desde el navegador de tu máquina física accederás siempre al proxy, que se encargará de redirigir las peticiones al servidor web original.

La idea es la siguiente: en la primera máquina tienes tu web de prácticas (por ejemplo, de una práctica anterior de Nginx). Vas a renombrar su configuración para que el sitio se llame webserver, cambiar el puerto de escucha al 8080 y asegurarte de que sigue sirviendo bien la página.

En concreto, en el servidor web de origen debes:

• Renombrar el archivo de configuración en /etc/nginx/sites-available y cualquier referencia interna al nombre del sitio para que pase a llamarse webserver.
• Eliminar el antiguo enlace simbólico en sites-enabled usando unlink y crear un nuevo symlink que apunte al archivo renombrado.
• Cambiar la directiva listen 80; a listen 8080; en el bloque server correspondiente a esa web.
• Reiniciar Nginx para que coja los cambios y comprobar que puedes acceder al sitio en http://webserver:8080 o vía IP:8080.

En la segunda máquina Debian vas a configurar Nginx como proxy inverso. Pasos básicos:

• Crear un archivo de configuración en /etc/nginx/sites-available con el nombre de tu dominio de pruebas, por ejemplo ejemplo-proxy.
• Definir un bloque server sencillo con el puerto en el que escuchará el proxy (80, u otro si quieres diferenciar aún más los roles) y el server_name con el dominio o alias de tu proxy.
• Dentro del bloque location /, configurar proxy_pass apuntando a la IP y puerto del backend, por ejemplo proxy_pass http://192.168.1.50:8080; o http://webserver:8080; si tienes DNS interno.
• Crear el enlace simbólico en sites-enabled y probar la configuración con nginx -t.

Si todo va bien, tras recargar Nginx podrás acceder a tu sitio con el nombre de proxy y verás el contenido servido realmente desde el servidor web backend, pero pasando por el proxy inverso en todo momento.

Añadir cabeceras personalizadas para demostrar el recorrido de la petición

Una forma muy clara de comprobar que la petición pasa por el proxy y llega al servidor de origen es añadir cabeceras HTTP personalizadas en ambos lados y luego verlas desde las herramientas de desarrollador del navegador.

La práctica consiste en configurar tanto el proxy inverso como el servidor web para que incluyan una cabecera adicional en las respuestas, por ejemplo utilizando la directiva add_header dentro del bloque location / { ... }. La cabecera puede ser algo como X-Host: Proxy_inverso_tunombre en el proxy y X-Host: Servidor_web_tunombre en el backend.

El flujo recomendado suele ser:

1. Añadir primero la cabecera solo en el proxy inverso, reiniciar Nginx y comprobar que sigues accediendo al sitio con normalidad.
2. Abrir las herramientas de desarrollador del navegador (F12) y revisar la pestaña Red, seleccionando la petición principal y revisando las cabeceras de respuesta para ver la nueva cabecera añadida por el proxy.
3. Añadir ahora la cabecera en la configuración del servidor web de origen, con un valor distinto para distinguirlo, y de nuevo reiniciar Nginx en ese servidor.
4. Refrescar la página desactivando la caché del navegador o en una ventana privada, para asegurarte de que las respuestas llegan realmente desde el servidor.

Si todo está bien montado, en las respuestas HTTP verás las dos cabeceras, una generada por el proxy inverso y otra por el servidor web, confirmando que la petición ha seguido el camino completo de ida y vuelta a través del proxy.

Configuración “clásica” de Nginx como proxy inverso sencillo

La configuración mínima de Nginx para hacer de proxy inverso es muy simple, pero a partir de esa base se pueden añadir muchas mejoras. Imagina que quieres que las peticiones a /example se reenvíen a https://example.com. Bastaría con añadir un bloque location al bloque server adecuado:

location /example {
proxy_pass https://example.com;
}

Este fragmento indica que cualquier petición cuyo path empiece por /example se enviará al destino indicado en proxy_pass. A menudo se acompaña de otras directivas para ajustar cabeceras, tiempos de espera y comportamiento de redirección.

Una versión más completa para un subdirectorio tipo blog podría tener esta forma:

server {
listen 80;
server_name example.com;

location / {
try_files $uri $uri/ /index.php?$query_string;
}

location /blog {
proxy_pass http://blog.domain.com;
proxy_http_version 1.1;
proxy_cache_bypass $http_upgrade;

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection «upgrade»;
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;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;

proxy_connect_timeout 60s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
}
}

La clave aquí es proxy_pass apuntando al backend y un conjunto de cabeceras que aseguran que el servidor de origen conoce la IP real del cliente, el esquema original (HTTP o HTTPS) y otros datos importantes para logs y para aplicaciones que dependen de esas cabeceras.

Estructura de archivos de Nginx y buenas prácticas de configuración

Cuando instalas Nginx en una distribución como Ubuntu o Debian, la estructura típica de configuración se organiza en varios directorios que conviene respetar para no montar un caos según crece el número de sitios.

Los puntos clave de esta estructura son:

• /etc/nginx/nginx.conf, el archivo de configuración principal, donde se definen directivas globales y se incluyen otros archivos.
• /etc/nginx/sites-available/, que almacena los archivos de configuración de cada sitio virtual, activos o no.
• /etc/nginx/sites-enabled/, que contiene enlaces simbólicos a los sitios que realmente están activos.
• /etc/nginx/conf.d/, donde puedes poner configuraciones globales adicionales en ficheros .conf que se cargan automáticamente.

Trabajar con sites-available y sites-enabled tiene varias ventajas. Puedes preparar la configuración de un sitio sin activarlo hasta que crees el symlink, desactivar sitios eliminando solo el enlace simbólico, y mantener agrupada la configuración de cada servicio en un solo archivo fácil de localizar.

Dentro de cada archivo de sitio suelen aparecer varios bloques server, cada uno con sus directivas listen, server_name y distintos bloques location. Estos últimos definen cómo se manejan diferentes rutas (estáticos, proxies, APIs, etc.), por ejemplo sirviendo /static/ directamente desde disco y enviando /api/ a un backend Node.js.

La recomendación general es probar siempre la configuración antes de recargar usando sudo nginx -t, para evitar dejar el servicio caído por un simple error de sintaxis, y utilizar systemctl reload nginx siempre que sea posible, ya que recarga la configuración sin cortar conexiones activas.

Instalación y primeros pasos con Nginx como proxy inverso en Ubuntu/Debian

Si estás montando un VPS desde cero o una máquina de prácticas, los pasos para tener Nginx funcionando como proxy inverso en Ubuntu 22.04 (o similares) son bastante directos y se pueden automatizar con scripts sin problema.

Secuencia típica de instalación:

• Actualizar paquetes con sudo apt update y sudo apt upgrade -y para asegurarte de que todo está al día.
• Instalar Nginx con sudo apt install nginx -y, lo que iniciará el servicio automáticamente.
• Comprobar el estado del servicio usando sudo systemctl status nginx para ver que aparece como active (running).
• Abrir el firewall en caso de usar UFW, con sudo ufw allow 'Nginx Full' para permitir tráfico en los puertos 80 y 443.

Una vez instalado Nginx, puedes crear tu primer host virtual en /etc/nginx/sites-available/ejemplo.com y enlazarlo en sites-enabled. Desde ahí, basta con añadir un bloque location / que haga proxy_pass al backend y las cabeceras recomendadas para que la aplicación del otro lado reciba toda la información necesaria.

En entornos más avanzados es habitual acompañar Nginx de otras piezas como Certbot para obtener certificados Let’s Encrypt, Gunicorn para aplicaciones Python, o incluso configurar el proxy inverso en una Raspberry Pi que reenvía tráfico a servicios internos (NAS, paneles de administración, etc.) con redirecciones de puertos desde el router hacia la máquina con Nginx.

Opciones avanzadas: balanceo, caché, SSL y ajuste fino de directivas proxy

Una vez que dominas la configuración básica de proxy inverso, es muy tentador quedarse ahí. Pero Nginx ofrece muchas directivas que te permiten exprimir el rendimiento y el control al máximo.

Para crear un balanceador de carga defines primero un bloque upstream con los servidores backend y luego usas proxy_pass apuntando a ese upstream:

upstream myapp1 {
server backend1.example.com;
server backend2.example.com;
}

server {
listen 80;
server_name example.com;

location / {
proxy_pass http://myapp1;
proxy_next_upstream error timeout;
}
}

Para servir contenido estático directamente desde el proxy, puedes definir un bloque de ubicación adicional:

server {
listen 80;
server_name example.com;

location / {
proxy_pass http://backend.example.com;
}

location /static/ {
root /path/to/static/files;
expires 30d;
}
}

En cuanto a las directivas proxy_*, algunas de las más utilizadas son:

• proxy_set_header para ajustar cabeceras como Host, X-Real-IP o X-Forwarded-Proto. Básicas para aplicaciones web modernas.
• proxy_cache y proxy_cache_path. Para activar y configurar cachés reverse proxy que reducen carga en el backend.
• proxy_buffering para decidir si Nginx almacena en búfer las respuestas o las envía en streaming, lo que puede reducir latencias en ciertas APIs.
• proxy_connect_timeout, proxy_read_timeout y proxy_send_timeout. Para controlar cuándo se considera que un backend no responde y pasar al siguiente o devolver error.
• proxy_ssl y parámetros relacionados si el tráfico entre Nginx y el backend va cifrado con HTTPS.

Cuando ensamblas todas estas piezas —proxy inverso, balanceo de carga, caché, SSL y monitorización—, Nginx se convierte en el punto neurálgico por el que pasa absolutamente todo el tráfico de tus aplicaciones. Saber configurarlo bien y entender su papel en la arquitectura marca la diferencia entre un sistema frágil y uno capaz de crecer, resistir ataques y ofrecer tiempos de respuesta muy bajos incluso bajo carga elevada.