Cómo configurar Nginx usando inteligencia artificial

Qué es Nginx y por qué se configura con archivos de texto

Nginx es un servidor web y proxy reverso que recibe las peticiones que llegan a tu dominio y decide qué hacer con cada una: entregar un archivo, pasar la solicitud a una aplicación o rechazarla. Se configura editando archivos con extensión .conf, no desde una interfaz gráfica, porque así la configuración es reproducible, versionable y fácil de auditar.

Piénsalo como el recepcionista de un edificio. Cada visitante (petición HTTP) llega preguntando por algo. El recepcionista consulta una lista de reglas —tus archivos de configuración— y lo manda al piso correcto: la web estática al almacén de archivos, la app al servidor de Node, lo sospechoso a la puerta. Configurar Nginx es escribir esa lista de reglas.

La rama estable actual de Nginx es la 1.30.x y la mainline va por la 1.31.x en 2026, pero las directivas de esta guía existen desde hace muchas versiones y funcionan igual en instalaciones anteriores.

La estructura de archivos: sites-available y sites-enabled

En Ubuntu y Debian, cada sitio se define en un archivo dentro de /etc/nginx/sites-available/ y se activa creando un enlace simbólico hacia /etc/nginx/sites-enabled/. Nginx solo carga lo que encuentra en sites-enabled; sites-available es tu cajón de configuraciones guardadas, activas o no.

Esta separación es más útil de lo que parece. Puedes tener diez sitios escritos en sites-available y activar solo tres. Para apagar un sitio no borras nada: eliminas el enlace de sites-enabled y el archivo original sigue intacto, listo para reactivarlo. Un enlace simbólico es simplemente un atajo que apunta a otro archivo, como un acceso directo.

# Ver los sitios disponibles y los activos
ls /etc/nginx/sites-available/
ls /etc/nginx/sites-enabled/

El archivo principal, /etc/nginx/nginx.conf, contiene la configuración global y una línea include /etc/nginx/sites-enabled/*; que arrastra todos los sitios activos. Rara vez necesitas tocarlo.

Tu primer server block

Un server block (bloque de servidor) es el fragmento de configuración que le dice a Nginx cómo atender un dominio concreto: qué dominio, dónde están los archivos y cómo responder. Es el equivalente de Nginx a lo que Apache llama "virtual host".

Este es un server block mínimo para servir una web estática en midominio.com. Se guarda en /etc/nginx/sites-available/midominio.com:

server {
    listen 80;
    server_name midominio.com www.midominio.com;
    root /var/www/midominio/public;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

Línea por línea: listen 80 escucha en el puerto HTTP; server_name indica a qué dominios responde este bloque; root es la carpeta donde viven los archivos; index es el archivo por defecto; y el location / con try_files busca el archivo pedido y devuelve un 404 si no existe. Para activarlo:

sudo ln -s /etc/nginx/sites-available/midominio.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

El comando nginx -t valida la sintaxis antes de aplicar nada. Nunca recargues sin correrlo primero: si hay un error y Nginx ya estaba sirviendo, un reload con configuración rota puede dejar tu sitio caído.

Proxy reverso: cuando Nginx habla con Node, PHP u otra app

Un proxy reverso es Nginx recibiendo las peticiones públicas y pasándolas a una aplicación que corre en el mismo servidor pero en un puerto interno, como Node.js en el 3000 o Gunicorn en el 8000. El visitante habla con Nginx en el puerto 443; Nginx habla con tu app en el 3000. La app nunca queda expuesta directamente a internet.

Esto tiene tres ventajas concretas: Nginx gestiona el SSL por ti (tu app no necesita saber de certificados), oculta la dirección real de la aplicación, y puede repartir carga entre varias instancias. Este es un server block de proxy reverso hacia una app de Node en el puerto 3000:

server {
    listen 80;
    server_name app.midominio.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        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 Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
    }
}

Las líneas proxy_set_header son importantes y se olvidan seguido: sin Host y X-Forwarded-For, tu aplicación no sabe qué dominio pidió el usuario ni cuál es su IP real, y verá a todo el mundo como si viniera de 127.0.0.1. Las dos últimas líneas (Upgrade y Connection) permiten WebSockets, necesarios si tu app usa conexiones en tiempo real. Si quieres profundizar, tenemos una guía dedicada a montar un servidor de Node.js en Nginx.

SSL gratis con Let's Encrypt y Certbot

Para poner HTTPS gratis en Nginx se usa Certbot, la herramienta oficial de Let's Encrypt: instala el certificado, modifica tu server block para servir por el puerto 443 y programa la renovación automática. Todo con dos comandos.

Let's Encrypt es una autoridad certificadora gratuita y automatizada; Certbot es el cliente que pide, instala y renueva sus certificados. Así se hace en Ubuntu:

sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d midominio.com -d www.midominio.com

Certbot detecta tu server block, te pregunta el correo, y reescribe la configuración para redirigir HTTP a HTTPS. Los certificados de Let's Encrypt son válidos por 90 días, pero no tienes que renovarlos a mano: Certbot instala un timer de systemd que revisa dos veces al día y renueva automáticamente cuando quedan menos de 30 días, recargando Nginx después. Comprueba que la renovación funciona sin esperar tres meses:

sudo certbot renew --dry-run

Un apunte para 2026: Let's Encrypt empezó a ofrecer, de forma opcional, certificados de vida más corta (45 días como paso intermedio) y planea acortar la validez general con el tiempo. No cambia nada para ti mientras la renovación esté automatizada, que es justo lo que hace Certbot por defecto.

gzip y caché: dos ajustes que aligeran tu sitio

Activar la compresión gzip y la caché de archivos estáticos reduce el peso de las respuestas y el trabajo del servidor con muy poca configuración. La compresión encoge el HTML, CSS y JavaScript antes de enviarlos; la caché le dice al navegador que guarde imágenes y hojas de estilo en lugar de volver a pedirlas.

Esto va dentro del bloque http de nginx.conf o en tu server block:

gzip on;
gzip_comp_level 5;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff2)$ {
    expires 30d;
    add_header Cache-Control "public, no-transform";
}

Con gzip_min_length 1024 solo comprimes respuestas de más de 1 KB (comprimir archivos diminutos no compensa), y expires 30d le pide al navegador que guarde los estáticos durante un mes. Para sitios con mucho tráfico dinámico, como WordPress, el siguiente paso es la caché del lado del servidor: lo cubrimos en la guía de caché en Nginx para el rendimiento del servidor.

Los errores típicos al configurar Nginx

Estos son los tres tropiezos que se repiten al configurar Nginx, con su causa y su arreglo:

El 502 Bad Gateway merece atención aparte porque es el más frustrante: Nginx está perfecto, pero la aplicación a la que hace de proxy está caída, escucha en otro puerto o cerró la conexión. El primer reflejo debe ser mirar /var/log/nginx/error.log y confirmar que tu app está viva, no reiniciar Nginx a ciegas. Tenemos un artículo entero dedicado a resolver el error 502 Bad Gateway en Nginx con un orden de diagnóstico seguro.

La regla de oro con cualquier cambio: editar, sudo nginx -t, y solo si pasa, sudo systemctl reload nginx. Ese hábito te ahorra la mayoría de las caídas autoinfligidas.

Cómo un agente de IA configura Nginx por ti

Un agente de inteligencia artificial puede configurar Nginx conectándose a tu VPS por SSH y ejecutando los comandos directamente, en lugar de darte un tutorial para que copies y pegues. Le describes lo que necesitas en español y él crea el server block, corre Certbot, valida con nginx -t y recarga el servicio, verificando el resultado en cada paso.

En los VPS de Terranode esto lo hace Cortex AI, el agente de IA incluido sin costo adicional en todos los planes (versión 1.2). Le escribes algo como "configúrame Nginx como proxy reverso para mi app de Node en el puerto 3000 con SSL para app.midominio.com" y ejecuta la secuencia completa: crea el archivo en sites-available, lo enlaza a sites-enabled, instala el certificado con Certbot, valida la sintaxis y recarga. La diferencia frente a preguntarle a un chatbot genérico es que Cortex está conectado a tu máquina: lee el estado real, sabe qué puerto está libre y comprueba que quedó funcionando.

La diferencia práctica entre hacerlo a mano y pedírselo a la IA se resume así:

Cortex se detiene a pedirte confirmación antes de cualquier acción con consecuencias, bloquea los comandos destructivos, guarda un registro consultable de todo lo que ejecuta y trabaja con una llave SSH cifrada con AES-256; cada cliente está aislado del resto. Por ahora funciona solo en Linux. Si quieres el detalle de cómo se conecta y qué más puede hacer, está en el artículo sobre Cortex AI, el agente de IA para VPS, y el panorama completo en la guía de VPS con inteligencia artificial.

Un consejo honesto: la IA acelera el trabajo, pero no te exime de entenderlo. Aprender qué es un server block y por qué falla un 502 te vuelve el jefe de la conversación, no el que copia a ciegas. Usa el agente para ir rápido y esta guía para saber qué le estás pidiendo.