VPS · Guía

Guía de nginx como proxy inverso

Actualizado October 11, 2026 5 min de lectura

En esta página
  1. Qué hace un proxy inverso
  2. Paso 1: instalar nginx
  3. Paso 2: crear el server block del proxy
  4. Las cabeceras y la barra final
  5. WebSockets
  6. Paso 3: HTTPS gratis con Certbot
  7. Cómo solucionar los errores 502, 504 y 413
  8. Ejecútalo en un VPS de HytHost
  9. FAQ

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.com y example.com/blog pueden 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 VPS

Paso 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

  • Host pasa el dominio que pidió el visitante. Sin ella, nginx envía la dirección de proxy_pass, y las apps que construyen enlaces a partir del host se rompen.
  • X-Real-IP y X-Forwarded-For pasan la dirección IP del visitante. Sin ellas, todas las peticiones parecen venir de 127.0.0.1.
  • X-Forwarded-Proto indica 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

ErrorCausa habitualSolución
502 Bad Gatewaynginx no llega a la app: está parada, se ha caído o escucha en otro puerto o direcciónArranca la app, comprueba el puerto con curl http://127.0.0.1:PORT, lee /var/log/nginx/error.log
504 Gateway TimeoutLa app tardó más de 60 segundos en responderAcelera la petición o sube proxy_read_timeout en ese location
413 Request Entity Too LargeUna subida supera el límite por defecto de nginx, de 1 MBPon client_max_body_size 50m; en el server block
Bucle de redireccionesLa app no sabe que el visitante usó HTTPSPasa 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.

FAQ

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?