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

server {
    listen 443 ssl;
    server_name midominio.com;

    ssl_certificate /etc/letsencrypt/live/midominio.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/midominio.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;

    gzip on;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    gzip_min_length 1024;

    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;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

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

Nginx como proxy inverso

Nginx es uno de los servidores web y proxies inversos más usados del mundo, tanto para servir contenido estático directamente como para hacer de intermediario frente a aplicaciones backend (Node.js, Python, Java...) que escuchan en un puerto interno. Colocar Nginx delante de la aplicación permite terminar TLS en un único punto, servir varios dominios desde el mismo servidor (virtual hosting), aplicar compresión y cache sin tocar el código de la aplicación, y absorber picos de tráfico de forma mucho más eficiente que la mayoría de runtimes de aplicación.

SSL/TLS y redirecciones

Con SSL activado, la configuración generada añade un bloque adicional en el puerto 80 que redirige todo el tráfico HTTP a HTTPS con un código 301 (redirección permanente), práctica recomendada tanto por seguridad como por SEO, ya que los motores de búsqueda consolidan la autoridad de la versión cifrada. La ruta de certificados apunta al formato estándar de Certbot / Let's Encrypt; si usas otro proveedor de certificados deberás ajustar las rutas ssl_certificate y ssl_certificate_key a su ubicación real.

Cabeceras de proxy y WebSockets

Las cabeceras X-Forwarded-For y X-Forwarded-Proto son imprescindibles para que la aplicación backend conozca la IP real del cliente y si la petición original llegó por HTTPS, algo que de otro modo se pierde al pasar por el proxy. Las líneas de Upgrade y Connection son necesarias específicamente para que funcionen conexiones WebSocket a través del proxy, muy habituales en aplicaciones con actualizaciones en tiempo real (chats, notificaciones, dashboards en vivo).

Preguntas frecuentes

¿Dónde coloco este bloque server?

Normalmente en /etc/nginx/sites-available/tu-dominio.conf, con un enlace simbólico desde sites-enabled/, o directamente dentro del bloque http{} de nginx.conf según la distribución.

¿Necesito generar el certificado SSL antes?

Sí, esta configuración asume que ya existe un certificado (por ejemplo, generado con `certbot --nginx`). Sin el certificado en esa ruta, Nginx no arrancará con SSL activado.

¿Cómo verifico que la configuración es correcta antes de recargar?

Ejecuta `nginx -t` para validar la sintaxis sin aplicar cambios, y solo después `systemctl reload nginx` (o `nginx -s reload`) para aplicarla sin cortar conexiones activas.