Guía de nginx como proxy inverso
En esta página
Un proxy inverso se coloca delante de tus aplicaciones y les pasa las peticiones de los visitantes. Con nginx delante, una app de Node.js, un contenedor de Docker o un panel que corre en algún puerto se convierte en https://app.example.com, con HTTPS, las cabeceras correctas y un único lugar desde el que gestionarlo todo.
Esta guía configura nginx como proxy inverso en Ubuntu, paso a paso: el server block, las cabeceras, los WebSockets, HTTPS gratis y los errores con los que más probablemente te encontrarás.
Qué hace un proxy inverso
- Un único punto de entrada público. nginx escucha en los puertos 80 y 443 y reenvía cada dominio o ruta a la app correcta, así las apps nunca quedan expuestas directamente a internet.
- HTTPS en un solo sitio. nginx se encarga de los certificados; las apps que están detrás pueden hablar HTTP plano en localhost.
- Varias apps en un mismo servidor.
app.example.com,api.example.comyexample.com/blogpueden ir cada uno a un servicio distinto. - Extras: compresión, caché, límites de subida y reglas de acceso, sin tocar la app.
Paso 1: instalar nginx
sudo apt update sudo apt install nginx
Abre http://your-server-ip y deberías ver la página de bienvenida de nginx. Si usas ufw, permite el tráfico web con sudo ufw allow 'Nginx Full'.
Comprueba que tu app está en marcha y responde en el propio servidor, por ejemplo con curl http://127.0.0.1:3000. Si eso falla, nginx también fallará.
Ejecuta nginx y tus apps con acceso root completo: los planes VPS KVM de HytHost empiezan en €2.92/mes.
Ver planes VPSPaso 2: crear el server block del proxy
En Ubuntu, cada sitio tiene un archivo en /etc/nginx/sites-available/, que se activa con un enlace en sites-enabled. Crea /etc/nginx/sites-available/app.example.com:
server {
listen 80;
server_name app.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
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;
}
}
Actívalo, prueba la configuración y recarga:
sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx
Apunta el registro A del dominio a tu servidor y http://app.example.com mostrará tu app. Ejecuta siempre nginx -t antes de recargar: detecta las erratas antes de que tiren el sitio.
Las cabeceras y la barra final
Hostpasa el dominio que pidió el visitante. Sin ella, nginx envía la dirección deproxy_pass, y las apps que construyen enlaces a partir del host se rompen.X-Real-IPyX-Forwarded-Forpasan la dirección IP del visitante. Sin ellas, todas las peticiones parecen venir de127.0.0.1.X-Forwarded-Protoindica a la app si el visitante usó HTTPS, para que no entre en un bucle de redirecciones.
El paquete de nginx de Ubuntu incluye estas líneas en /etc/nginx/proxy_params, así que include proxy_params; sirve de atajo.
La barra final importa. Para una app bajo una ruta:
location /app/ {
proxy_pass http://127.0.0.1:3000/;
}
Con la barra después del puerto, /app/login llega a la app como /login. Sin ella, la app recibe la ruta completa /app/login.
WebSockets
Las apps de chat, los paneles en tiempo real y muchos paneles de administración usan WebSockets, que necesitan dos cabeceras más. Añade este map una sola vez, dentro del bloque http, por ejemplo en un archivo nuevo /etc/nginx/conf.d/websocket.conf:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
Y luego, en el location:
proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_read_timeout 1h;
nginx cierra una conexión proxificada que no envía nada durante 60 segundos; un proxy_read_timeout más largo mantiene abiertos los WebSockets inactivos. proxy_http_version 1.1 solo es el valor por defecto a partir de nginx 1.29.7, y Ubuntu 24.04 trae la 1.24, así que deja la línea.
Paso 3: HTTPS gratis con Certbot
sudo snap install --classic certbot sudo ln -s /snap/bin/certbot /usr/local/bin/certbot sudo certbot --nginx -d app.example.com
Certbot obtiene un certificado gratuito de Let's Encrypt, añade la configuración HTTPS a tu server block y puede redirigir HTTP a HTTPS. Renueva el certificado automáticamente; compruébalo con sudo certbot renew --dry-run. Más sobre certificados en cómo conseguir un certificado SSL gratis.
Cómo solucionar los errores 502, 504 y 413
| Error | Causa habitual | Solución |
|---|---|---|
| 502 Bad Gateway | nginx no llega a la app: está parada, se ha caído o escucha en otro puerto o dirección | Arranca la app, comprueba el puerto con curl http://127.0.0.1:PORT, lee /var/log/nginx/error.log |
| 504 Gateway Timeout | La app tardó más de 60 segundos en responder | Acelera la petición o sube proxy_read_timeout en ese location |
| 413 Request Entity Too Large | Una subida supera el límite por defecto de nginx, de 1 MB | Pon client_max_body_size 50m; en el server block |
| Bucle de redirecciones | La app no sabe que el visitante usó HTTPS | Pasa X-Forwarded-Proto e indica a la app que está detrás de un proxy |
Después de cada cambio: sudo nginx -t y luego sudo systemctl reload nginx.
Ejecútalo en un VPS de HytHost
Un proxy inverso necesita un servidor en el que controles los puertos 80 y 443. Los planes VPS de HytHost funcionan sobre KVM con acceso root completo, almacenamiento SSD y protección DDoS; elige Ubuntu 24.04 y sigue los pasos anteriores. ¿Ejecutas tus apps en contenedores? Instala primero Docker con cómo instalar Docker en Ubuntu y vincula los puertos de los contenedores a 127.0.0.1 para que solo nginx pueda llegar a ellos.
Preguntas frecuentes
Un proxy inverso reenvía las peticiones a una o varias apps que están detrás. Un balanceador de carga es un proxy inverso que reparte las peticiones entre varias copias de la misma app. nginx puede hacer ambas cosas, con un bloque upstream que enumera las copias.
nginx no llega a la app que tiene detrás. Comprueba que la app está en marcha y escucha en la dirección y el puerto de proxy_pass, y lee /var/log/nginx/error.log para ver el motivo exacto.
No, si la app corre en el mismo servidor. nginx gestiona el HTTPS de los visitantes y habla con la app por HTTP plano en 127.0.0.1, que nunca sale de la máquina.
Dale a cada app su propio server block con su propio server_name, como app.example.com y api.example.com, cada uno con un proxy_pass a un puerto distinto.
Sí. Publica el puerto de cada contenedor solo en 127.0.0.1 y apunta proxy_pass a él. Así los contenedores quedan fuera de la internet pública, algo importante porque los puertos publicados por Docker se saltan ufw.
Aloja tus apps detrás de nginx
Los planes VPS KVM de HytHost con acceso root completo, almacenamiento SSD y protección DDoS empiezan en €2.92/mes.
Live chat 8 AM – 11 PM (Chișinău time) · tickets answered during business hours¿Te ha resultado útil esta guía?