Proxy inverso Nginx con SSL

Si está ejecutando una aplicación web en un puerto privado (como Localhost: 3000), no es directamente accesible a través de Internet.Una de las formas más efectivas de exponer esa aplicación de forma segura es poner un proxy inverso frente a él.

Nginx es una herramienta liviana conocida que puede hacer exactamente eso, recibir tráfico entrante y reenviarlo a su aplicación, al tiempo que maneja HTTPS con un certificado SSL gratuito de Let's Cifrypt.

En esta guía, aprenderás a:

• Configure Nginx como un proxy inverso para un servicio web interno
  
• Asegurarlo con un certificado SSL usando CERTBOT
  
• Comprenda cada parte de la configuración para que sepa lo que está haciendo y por qué

¿Nuevo en los servidores web?Mira nuestra explicación en Cómo funcionan los servidores web.

¿Qué es un proxy inverso y por qué usar uno?

UN proxy inverso es un servidor que se encuentra entre sus usuarios y sus servicios de backend.En lugar de que su aplicación escuche públicamente en un puerto (como 3000), Nginx recibe el tráfico primero y luego lo pasa a la aplicación que se ejecuta en segundo plano.

He aquí por qué este enfoque es tan útil:

• Oculta puertos y servicios internos
  Su aplicación no necesita ser expuesta directamente al público.Eso reduce la superficie del ataque y te ayuda a controlar el acceso.
  
• Maneja https para ti
  Muchos marcos web pueden servir directamente a HTTPS, pero a menudo es más fácil y más confiable dejar que Nginx lo haga, especialmente cuando se usa certificados SSL gratuitos de Let's Cifrypt.
  
• Habilita alojamiento de múltiples servicios en un servidor
  Puede ejecutar varias aplicaciones en diferentes puertos (como 3000, 4000, 5000) y enrutar el tráfico en función del dominio o la ruta utilizando solo una IP pública.
  
• Mejora el registro y el monitoreo
  Nginx le ofrece registros de acceso y error centralizados, por lo que es más fácil monitorear el rendimiento o investigar los problemas.
  
• Proporciona almacenamiento en caché opcional, equilibrio de carga y limitación de tarifas
  Puede optimizar el flujo de tráfico y proteger los servicios de backend con solo unas pocas líneas adicionales en su configuración Nginx.

Incluso si su aplicación ya puede manejar el tráfico web, el uso de NGINX como proxy inverso a menudo simplifica la configuración, mejora la flexibilidad y aumenta el control.

Prerrequisitos

Antes de comenzar, asegurémonos de tener todo lo que necesita:

• Un VPS o un servidor en la nube que ejecuta Ubuntu 20.04 o posterior: La mayoría de los comandos y versiones de paquetes utilizados en este tutorial asumen un sistema basado en Debian.Mientras que NGINX y CERTBOT funcionan en otras distribuciones, el proceso de configuración puede diferir.
• Acceso a la raíz o sudo: Instalará paquetes, editará archivos del sistema y reiniciando servicios, todos los cuales requieren privilegios elevados.
• Un nombre de dominio registrado: Necesitará esto para solicitar un certificado SSL.Encrypt valida la propiedad de su dominio antes de emitir un certificado.Sin DNS apuntado a su servidor, la validación fallará.
• DNS apuntando a la IP pública de su servidor: Asegúrese de que los registros DNS de su dominio se actualicen.Un registro simple que apunta a la IP de su servidor es suficiente:

A yourdomain.com → 123.123.123.123
A www.yourdomain.com → 123.123.123.123

La propagación puede llevar unos minutos a unas pocas horas.

¿No sabes cómo configurar tu DNS?Aquí está Cómo agregar un registro A con la mayoría de los anfitriones de dominio.

• Una aplicación que se ejecuta en localhost (por ejemplo, http://localhost:3000): Esta es la aplicación a la que estará representando.Podría ser cualquier cosa: Node.js, Python Flask, Ruby on Rails, etc. Siempre que esté escuchando en un puerto local, puede representarlo.

Nota: Si su aplicación aún no se está ejecutando, está bien, aún puede pasar por la configuración y probar más tarde.

• Nginx instalado: Nginx actuará como el servidor público.Si aún no está instalado:

sudo apt update
sudo apt install nginx

Luego verifique que se esté ejecutando:

sudo systemctl status nginx

Deberías ver "activo (en ejecución)".

• CERTBOT instalado con el complemento NGINX: CERTBOT automatiza el proceso de obtención y renovación de certificados SSL de Let's CiCrypt.Instálelo así:

sudo apt install certbot python3-certbot-nginx

Este complemento permite a CERTBOT modificar su configuración NGINX automáticamente cuando solicita un certificado, no se requiere edición manual para configuraciones básicas.

¿Tiene otro sistema operativo?Sigue esta guía en Cómo instalar Vamos en cifrado en Fedora y Debian

Paso 1: Configure el proxy inverso NGINX

Ahora que su sistema está listo, el primer paso real es configurar NGINX para escuchar el tráfico en su dominio y reenviarlo a su aplicación interna; esto es lo que hace que NGINX actúe como un proxy inverso.

Por qué esto importa

Sin esta configuración, los usuarios que intentan visitar su sitio web presionarían una página vacía o la pantalla de bienvenida predeterminada de NGINX.Necesita decir explícitamente nginx:

• A qué dominio (s) debe responder a
  
• Qué hacer con las solicitudes entrantes
  
• Dónde enviar el tráfico detrás de escena

Crear un nuevo bloque de servidor

Creará un archivo de configuración para su dominio en el directorio disponible de los sitios de Nginx.Esto mantiene las configuraciones organizadas y facilita la habilitación o deshabilitación de sitios individuales.

sudo nano /etc/nginx/sites-available/yourdomain.com

Pegue en el siguiente bloque, ajustando el dominio y el puerto de la aplicación según sea necesario:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;

        # Pass important headers to the backend
        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;
    }
}

Lo que hace esta configuración

• Escucha 80;
  Le dice a Nginx que escuche el tráfico HTTP en el puerto 80.
  
• server_name yourdomain.com www.yourdomain.com;
  Coincide con este bloque con las solicitudes realizadas con su dominio.Puede agregar o eliminar subdominios según sea necesario.
  
• ubicación /
  Atrapa todas las solicitudes a la raíz y las reenvía a su aplicación.
  
• proxy_pass http: // localhost: 3000;
  Este es el corazón del proxy inverso: envía la solicitud a su aplicación de backend que se ejecuta en el puerto 3000.
  
• líneas proxy_set_header
  Estos preservan los detalles de la solicitud del cliente original, como:
  
  • La dirección IP del usuario (X-REAL-IP)
    
  • El protocolo original (http o https)
    
  • El nombre de host original
    
• Esta información es útil para registrar, análisis o cuando su aplicación necesita generar URL que coincidan con la experiencia del visitante.

Habilitar la configuración

Nginx usa enlaces simbólicos en el sitios habilitados directorio para activar sitios.Así que ahora crearás un enlace y recargarás Nginx:

sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
sudo nginx -t

Verifique los errores de sintaxis.Si todo se ve bien:

sudo systemctl reload nginx

Su proxy inverso ahora está en vivo, solicitudes para http://yourdomain.com se pasará a su aplicación en el puerto 3000.

Paso 2: Agregue SSL con Let's Cinpt y CertBot

Con el proxy inverso funcionando a través de HTTP, el siguiente paso es asegurarlo con HTTPS.Esto agrega cifrado a toda comunicación entre sus usuarios y su servidor: proteger las credenciales de inicio de sesión, las solicitudes de API, los datos personales y más.

Utilizará Let's Cintpt, una autoridad de certificado gratuita y CertBot, que automatiza el proceso.

Por qué https es importante

• Cifra el tráfico para que nadie pueda interceptar o manipularlo
  
• Mejora el SEO - Los motores de búsqueda prefieren sitios seguros
  
• Construye confianza - Los usuarios esperan ver el icono de candado
  
• Requerido para muchas API, inicios de sesión y sistemas de pago

Solicitar el certificado

Ejecute este comando, reemplazando los dominios con sus valores reales:

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Lo que esto hace:

• Le dice a CertBot que use el complemento NGINX
  
• Especifica para qué dominios solicita un certificado

CertBot Will:

• Realice la validación de dominio creando un archivo temporal en su configuración NGINX
  
• Contactar Vamos en cifrado para verificar la propiedad del dominio
  
• Descargue su certificado SSL y clave privada
  
• Modifique su configuración NGINX para usar https
  
• Opcionalmente, redirige todo el tráfico HTTP a HTTPS

Consejo: Si su DNS no está completamente propagado o el puerto de bloqueos de firewall de su servidor, la validación fallará.Puedes probar esto con:

curl -I http://yourdomain.com

Para comprender mejor los puertos, consulte nuestra guía sobre Cómo funcionan los puertos del servidor web.

Verificar los cambios

Después de completar CertBot, su configuración NGINX debe incluir algo como esto:

listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

Ahora debería poder visitar https://yourdomain.com y ver su sitio con un certificado SSL válido.

Opcional: fuerza https

Si no eligió la opción de redirección durante la configuración de CertBot, puede agregar esto manualmente:

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri;
}

Esto obliga a todo el tráfico HTTP a ser redirigido a HTTPS, lo que garantiza que los usuarios no usen accidentalmente la versión insegura de su sitio.

Paso 3: Mejorar la configuración de SSL (recomendado para la producción)

Una vez que su certificado SSL esté en su lugar, puede ajustar a Nginx para mejorar la seguridad y la compatibilidad.Estas configuraciones entran dentro del bloque HTTPS del servidor.

Aquí hay un ejemplo mejorado:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

Lo que hacen estas configuraciones

• ssl_protocols TLSv1.2 TLSv1.3
  Desactiva protocolos más antiguos y menos seguros como TLS 1.0 y 1.1.
  
• ssl_prefer_server_ciphers en
  Deje que su servidor decida el algoritmo de cifrado, en lugar de diferir al navegador, lo que puede reducir la exposición a ataques de cifrado débiles.
  
• ssl_ciphers high :! anull :! md5
  Especifica fuertes suites de cifrado y excluye las débiles o rotas (como MD5 y cifrados nulos).
  
• ssl_session_cache y ssl_session_timeout
  Controle la reutilización de la sesión SSL, que puede mejorar ligeramente el rendimiento sin comprometer la seguridad.
  
• ssl_session_tickets apagado
  Desactiva los boletos de sesión, que pueden ser una preocupación de seguridad si no se giran regularmente.

Estos cambios mejoran su puntaje de seguridad SSL y protegen a los visitantes contra ataques de degradación o opciones de cifrado inseguras.

Opcional: Puede probar su sitio con SSL Labs para ver cómo funciona su configuración y obtener sugerencias de mejora específicas.

Paso 4: (Opcional) Agregue los parámetros de Diffie-Hellman

Para un cifrado aún más fuerte, puede generar una tecla Diffie-Hellman (DH) personalizada.Este paso es opcional, pero a menudo se recomienda para entornos de producción.

Ejecute este comando para generar un grupo DH de 2048 bits:

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

Luego agregue la siguiente línea a su bloque de servidor SSL:

ssl_dhparam /etc/ssl/certs/dhparam.pem;

¿Por qué agregar esto?

Los parámetros de Diffie-Hellman se fortalecen Secreto de avance, lo que significa que incluso si su clave privada se ve comprometida de alguna manera en el futuro, las sesiones cifradas pasadas seguirán siendo seguras.

Se necesitan unos minutos para generar el grupo DH, pero es un paso único y vale la pena hacer para una mejor postura de seguridad.

Paso 5: Configure la renovación automática para los certificados SSL

Vamos a cifrar certificados cada 90 días.Afortunadamente, CERTBOT instala un temporizador del sistema que verifica dos veces al día los certificados debido a expirar y renovarlos automáticamente.

Puede confirmar que el temporizador está activo con:

sudo systemctl list-timers | grep certbot

Deberías ver algo como esto:

NEXT                         LEFT    LAST                         PASSED  UNIT           ACTIVATES
2025-06-19 04:00:00 UTC      12h     2025-06-18 04:00:00 UTC       11h ago certbot.timer  certbot.service

Para probar el proceso de renovación manualmente (sin hacer cambios), ejecute:

sudo certbot renew --dry-run

Esto simula el proceso de renovación completo y confirma que su sistema está listo para manejarlo automáticamente.

Si no hay errores, sus certificados se renunciarán en silencio en el fondo en el futuro.

Pasos finales y buenos hábitos

Ahora que su proxy inverso está configurado y asegurado con SSL, es una buena idea concluir con algunas verificaciones prácticas y mejores prácticas.

Estos simples hábitos pueden ayudar a prevenir problemas en el futuro, facilitar su configuración y asegurarse de que todo siga funcionando como espere.

Incluso si todo parece estar funcionando, pasar unos minutos adicionales aquí puede ahorrarle tiempo y problemas más tarde.

Reinicie su aplicación si no detecta automáticamente los cambios
Algunas aplicaciones deben reiniciarse para trabajar correctamente detrás de un proxy.

Verificar registros
Puede monitorear los registros de Nginx para errores o tráfico inusual:

sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

Mantenga a Nginx y CertBot actualizado
Use Sudo Apt Update && Sudo Apt Actualad regularmente.Los paquetes actualizados corrigen errores, mejoran la compatibilidad y los problemas de seguridad del parche.

Casos de uso avanzados para el proxy inverso Nginx con SSL

Una vez que haya dominado los conceptos básicos de configurar un proxy inverso seguro, puede extender su configuración para admitir necesidades más complejas.Aquí hay algunos escenarios comunes que pueden ayudarlo a sacar más de su servidor.

Hosting múltiples aplicaciones en un servidor

Si ejecuta varias aplicaciones web en diferentes puertos, NGINX puede enrutar solicitud a cada aplicación en función de la ruta de dominio o URL.

Ejemplo: diferentes dominios

server {
    listen 80;
    server_name app1.example.com;

    location / {
        proxy_pass http://localhost:3001;
        # proxy headers here
    }
}

server {
    listen 80;
    server_name app2.example.com;

    location / {
        proxy_pass http://localhost:3002;
        # proxy headers here
    }
}

Esta configuración le permite servir múltiples aplicaciones utilizando subdominios separados, todos a través de Nginx en puertos estándar.

¿Usando Docker?Aprender Cómo proxy de múltiples aplicaciones Docker con Nginx.

Proxy basado en la ruta

Alternativamente, puede proxy en función de las rutas de URL, lo cual es útil si desea todas las aplicaciones en un solo dominio:

server {
    listen 80;
    server_name example.com;

    location /app1/ {
        proxy_pass http://localhost:3001/;
        # proxy headers here
    }

    location /app2/ {
        proxy_pass http://localhost:3002/;
        # proxy headers here
    }
}

Nota: Cuando se utiliza la proxy basado en la ruta, las bases finales y la reescritura de URL pueden ser complicadas, asegúrese de que su aplicación de backend pueda manejar ser atendida bajo un subvataje.

Agregar limitación de tasa para proteger su aplicación

Puede limitar cuántas solicitudes puede hacer un cliente en un período de tiempo determinado para proteger su backend del abuso o la sobrecarga accidental.

Agregue esto en el bloque http en /etc/nginx/nginx.conf:

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

Luego en su servidor o bloque de ubicación:

limit_req zone=mylimit burst=20 nodelay;

Esta configuración permite 10 solicitudes por segundo con ráfagas de hasta 20 solicitudes, eliminando las solicitudes de exceso para evitar abrumar su aplicación.

Equilibrio de carga en múltiples servidores de backend

Si tiene varias instancias de su aplicación en ejecución (por ejemplo, múltiples contenedores o VPS), NGINX puede distribuir el tráfico entre ellos:

upstream backend {
    server 192.168.1.10:3000;
    server 192.168.1.11:3000;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        # proxy headers here
    }
}

Nginx Balances solicita Round-Robin de forma predeterminada, pero puede configurarlo para otros métodos como Menod Connections o IP Hash.

Para obtener más información, consulte nuestra guía en Equilibrio de carga del DNS.

Registro y depuración

Puede personalizar el registro para incluir información importante para la resolución o análisis:

log_format proxy '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent" '
                 'upstream_response_time $upstream_response_time '
                 'request_time $request_time';

access_log /var/log/nginx/proxy_access.log proxy;

Esto registra los tiempos de respuesta aguas arriba y los tiempos totales de solicitud, lo que ayuda a identificar respuestas de backend lenta.

Encabezados personalizados y mejoras de seguridad

Es posible que desee agregar o modificar los encabezados HTTP para la seguridad o la funcionalidad:

add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy no-referrer-when-downgrade;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Estos encabezados protegen contra el clickjacking, el olfato mime y el uso de HTTPS.