Publicada enLINUX

Servidor web nginx: Guía completa 2026

No hay comentarios
configuracion-de-servidor-web-nginx
configuracion-de-servidor-web-nginx

Configurar un servidor web nginx no consiste solo en instalar un paquete y copiar un archivo de ejemplo. Nginx es una pieza central de la infraestructura: recibe peticiones HTTP y HTTPS, decide qué sitio debe responder, sirve archivos estáticos, puede actuar como proxy inverso hacia aplicaciones, comprime contenido, registra actividad y aplica reglas de seguridad.

En esta guía veremos una configuración práctica orientada al servidor web nginx, pensada para administrar uno o varios sitios en un servidor Linux. El objetivo es entender qué hace cada parte, cómo validar los cambios y qué ajustes conviene revisar antes de poner un sitio en producción.

👉 Y recuerda, si quieres aprender más de Linux, pincha en este curso de Linux gratis

👉 También te dejo por aquí una guía de comandos Linux por categorías

Qué es Nginx y para qué se usa

Un servidor web nginx es muy usado para servir páginas estáticas, publicar aplicaciones web y actuar como proxy inverso. A diferencia de un servidor que crea un proceso pesado por cada conexión, Nginx está diseñado con una arquitectura orientada a eventos, lo que le permite manejar muchas conexiones simultáneas con un consumo moderado de recursos.

En una instalación real, Nginx puede cumplir varias funciones:

  • Servir archivos HTML, CSS, JavaScript, imágenes y descargas.
  • Publicar sitios creados con WordPress, Laravel, Django, Node.js u otros frameworks.
  • Redirigir tráfico HTTP a HTTPS.
  • Terminar certificados TLS y gestionar conexiones seguras.
  • Enviar peticiones a una aplicación interna mediante proxy inverso.
  • Aplicar reglas de cache, compresión, límites y cabeceras de seguridad.
  • Separar múltiples dominios en un mismo servidor mediante bloques de servidor.

La configuración correcta depende del caso, pero casi todos los despliegues comparten una base común: una estructura clara de archivos, un bloque de servidor por dominio, pruebas antes de recargar el servicio y una política mínima de seguridad.

Instalación de Nginx en Linux

En distribuciones basadas en Debian o Ubuntu, la instalación suele hacerse con apt:

sudo apt update
sudo apt install nginx

Después de instalarlo, conviene comprobar que el servicio está activo:

systemctl status nginx

También puedes verificar la versión instalada:

nginx -v

En CentOS, Rocky Linux, AlmaLinux o Fedora, el gestor de paquetes puede variar:

sudo dnf install nginx
sudo systemctl enable --now nginx

Una vez instalado, abre la IP pública del servidor en el navegador. Si todo funciona, deberías ver la página de bienvenida de Nginx o una respuesta HTTP válida.

Estructura de archivos más habitual

En Debian y Ubuntu, los archivos importantes suelen estar en:

/etc/nginx/
├── nginx.conf
├── sites-available/
├── sites-enabled/
├── conf.d/
└── snippets/

El archivo nginx.conf contiene la configuración global. Ahí se definen parámetros generales como usuarios, procesos de trabajo, logs, tipos MIME, compresión y carga de configuraciones adicionales.

La carpeta sites-available se usa para guardar configuraciones de sitios disponibles. La carpeta sites-enabled contiene enlaces simbólicos a los sitios que realmente están activos. Esta separación permite preparar una configuración sin activarla todavía.

Un flujo común es:

  1. Crear el archivo del sitio en /etc/nginx/sites-available/.
  2. Crear un enlace simbólico en /etc/nginx/sites-enabled/.
  3. Probar la sintaxis con nginx -t.
  4. Recargar Nginx con systemctl reload nginx.

En otras distribuciones puede usarse más la carpeta /etc/nginx/conf.d/, con archivos terminados en .conf. El concepto es el mismo: mantener cada sitio en su propio archivo y evitar mezclar configuraciones no relacionadas.

Configuración básica servidor web nginx

Antes de crear sitios concretos, conviene revisar el archivo principal:

sudo nano /etc/nginx/nginx.conf

Una configuración global típica incluye directivas como estas:

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 1024;
}

http {
    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log /var/log/nginx/access.log;
    error_log /var/log/nginx/error.log;

    sendfile on;
    tcp_nopush on;
    keepalive_timeout 65;

    gzip on;
    gzip_types text/plain text/css application/json application/javascript application/xml image/svg+xml;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

No hace falta modificar este archivo en exceso para un primer despliegue. Lo importante es comprender que el bloque http carga los archivos de configuración de los sitios. Si un sitio no responde, una causa frecuente es que su archivo no esté incluido o no esté enlazado correctamente.

Crear el directorio del sitio

Para servir un sitio estático o una aplicación con archivos públicos, crea una carpeta específica:

sudo mkdir -p /var/www/ejemplo.com/public

Asigna permisos razonables:

sudo chown -R www-data:www-data /var/www/ejemplo.com
sudo find /var/www/ejemplo.com -type d -exec chmod 755 {} \;
sudo find /var/www/ejemplo.com -type f -exec chmod 644 {} \;

Puedes añadir un archivo de prueba:

echo "<h1>Servidor Nginx funcionando</h1>" | sudo tee /var/www/ejemplo.com/public/index.html

El usuario exacto puede variar según la distribución. En Debian y Ubuntu suele ser www-data; en otras puede ser nginx.

Crear un bloque de servidor web nginx

El bloque de servidor, también llamado server block, indica a Nginx cómo debe responder para un dominio concreto. Crea un archivo:

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

Una configuración básica para HTTP sería:

server {
    listen 80;
    listen [::]:80;

    server_name ejemplo.com www.ejemplo.com;

    root /var/www/ejemplo.com/public;
    index index.html index.htm;

    access_log /var/log/nginx/ejemplo.com.access.log;
    error_log /var/log/nginx/ejemplo.com.error.log;

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

Las directivas principales son:

  • listen: indica el puerto y protocolo donde escucha Nginx.
  • server_name: define los dominios que atenderá este bloque.
  • root: carpeta desde la que se servirán los archivos.
  • index: archivos que se buscarán como página inicial.
  • location: reglas de manejo para rutas concretas.
  • try_files: orden de búsqueda de archivos antes de devolver error.

Después activa el sitio:

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

Comprueba que no haya errores:

sudo nginx -t

Si la prueba es correcta, recarga Nginx:

sudo systemctl reload nginx

Configurar DNS antes de probar el dominio

Para que el dominio apunte al servidor, debes crear registros DNS en el proveedor del dominio:

Tipo A     ejemplo.com       IP_DEL_SERVIDOR
Tipo A     www.ejemplo.com   IP_DEL_SERVIDOR

Si usas IPv6, añade también registros AAAA. La propagación DNS puede tardar desde unos minutos hasta varias horas, aunque en muchos casos es rápida.

Puedes comprobar la resolución con:

dig ejemplo.com
dig www.ejemplo.com

Si el dominio no apunta todavía a la IP correcta, Nginx puede estar bien configurado aunque el navegador no llegue al servidor esperado.

Redirección de www a no-www, o al revés

Conviene decidir una versión canónica del dominio. Por ejemplo, si quieres usar ejemplo.com como dominio principal y redirigir www.ejemplo.com, puedes separar los bloques:

server {
    listen 80;
    listen [::]:80;

    server_name www.ejemplo.com;
    return 301 http://ejemplo.com$request_uri;
}

server {
    listen 80;
    listen [::]:80;

    server_name ejemplo.com;
    root /var/www/ejemplo.com/public;
    index index.html;

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

Más adelante, cuando actives HTTPS, esa redirección debe apuntar directamente a HTTPS para evitar saltos innecesarios.

Activar HTTPS con Certbot

Un sitio moderno debe usar HTTPS. La forma más habitual de obtener certificados gratuitos de Let’s Encrypt es usar Certbot.

En Ubuntu o Debian:

sudo apt install certbot python3-certbot-nginx

Después ejecuta:

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

Certbot validará el dominio, solicitará el certificado y puede modificar la configuración de Nginx automáticamente. Al terminar, comprueba la renovación automática:

sudo certbot renew --dry-run

Una configuración HTTPS generada o ajustada manualmente suele incluir:

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

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    server_name ejemplo.com;

    root /var/www/ejemplo.com/public;
    index index.html;

    ssl_certificate /etc/letsencrypt/live/ejemplo.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ejemplo.com/privkey.pem;

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

La ruta exacta de los certificados depende del dominio usado al generar el certificado.

Configurar Nginx como proxy inverso

Muchas aplicaciones no se sirven como archivos estáticos. Por ejemplo, una app Node.js puede escuchar internamente en el puerto 3000, mientras Nginx recibe el tráfico público en 80 y 443.

Un bloque de proxy inverso básico sería:

server {
    listen 80;
    listen [::]:80;

    server_name app.ejemplo.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;
    }
}

Estas cabeceras permiten que la aplicación conozca el dominio original, la IP del cliente y el protocolo usado. Son especialmente importantes para frameworks que generan URLs, registran IPs o aplican lógica distinta en HTTP y HTTPS.

Para WebSockets, añade:

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Configurar PHP-FPM para WordPress/otros CMS

Si el servidor va a ejecutar WordPress, Nginx no procesa PHP por sí mismo. Necesita comunicarse con PHP-FPM.

Una configuración típica para WordPress puede ser:

server {
    listen 80;
    listen [::]:80;

    server_name ejemplo.com www.ejemplo.com;
    root /var/www/ejemplo.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    }

    location ~ /\.ht {
        deny all;
    }
}

El socket de PHP-FPM puede cambiar según la versión instalada. Compruébalo con:

ls /run/php/

Para WordPress, la línea clave es:

try_files $uri $uri/ /index.php?$args;

Permite que las URLs amigables funcionen aunque el archivo solicitado no exista físicamente.

Reglas básicas de seguridad

Una configuración mínima de seguridad debería bloquear archivos sensibles y reducir exposición innecesaria.

Puedes añadir reglas como:

location ~ /\. {
    deny all;
}

location ~* \.(bak|config|sql|ini|log|sh|inc|swp)$ {
    deny all;
}

También puedes ocultar la versión de Nginx en las respuestas:

server_tokens off;

Esta directiva suele colocarse dentro del bloque http en nginx.conf.

Para cabeceras de seguridad básicas:

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

La cabecera Content-Security-Policy puede ser muy útil, pero debe configurarse con cuidado para no romper scripts, estilos o recursos externos del sitio.

Compresión y cache de archivos estáticos

La compresión reduce el tamaño de texto, CSS, JavaScript y JSON. Si está activada globalmente con gzip on, puedes complementar con tipos adecuados:

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

Para cachear recursos estáticos en el navegador:

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

Este ajuste mejora la carga para usuarios recurrentes. En sitios con despliegues frecuentes, conviene usar nombres de archivo versionados, como app.8f3a2.css, para evitar que el navegador conserve versiones antiguas.

Logs: dónde mirar cuando algo falla

Nginx registra accesos y errores. Los archivos más comunes son:

/var/log/nginx/access.log
/var/log/nginx/error.log

Si configuraste logs por sitio, también tendrás archivos como:

/var/log/nginx/ejemplo.com.access.log
/var/log/nginx/ejemplo.com.error.log

Para ver errores en tiempo real:

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

Para revisar las últimas líneas de acceso:

sudo tail -n 100 /var/log/nginx/access.log

Los logs ayudan a detectar rutas inexistentes, errores de permisos, fallos de proxy, problemas con PHP-FPM y respuestas incorrectas.

Comandos esenciales para administrar Nginx

Estos comandos cubren la mayor parte del trabajo diario:

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl restart nginx
sudo systemctl status nginx
sudo systemctl enable nginx
sudo journalctl -u nginx --no-pager -n 100

La diferencia entre reload y restart es importante. reload recarga la configuración sin detener completamente el servicio. Es la opción preferida después de cambios válidos. restart reinicia el servicio completo y puede interrumpir conexiones activas.

Antes de cualquier recarga, usa siempre:

sudo nginx -t

Si la sintaxis tiene errores, Nginx indicará el archivo y la línea aproximada.

Problemas comunes y cómo resolverlos

Uno de los errores más frecuentes es ver la página por defecto de Nginx en lugar del sitio. Esto suele ocurrir porque el bloque correcto no está activado, el server_name no coincide o el dominio apunta a otra IP.

Otro problema habitual es recibir un error 403 Forbidden. En ese caso revisa permisos, propietario de archivos y existencia del archivo index. Nginx debe poder entrar en todos los directorios del camino hasta el archivo público.

Si aparece 502 Bad Gateway, normalmente el proxy o PHP-FPM no está respondiendo. Revisa si la aplicación está activa, si el puerto es correcto o si el socket de PHP-FPM existe.

Si HTTPS falla, comprueba que el certificado exista, que las rutas sean correctas, que el puerto 443 esté abierto en el firewall y que el dominio resuelva hacia el servidor.

Firewall y puertos necesarios

Para publicar un sitio web necesitas permitir tráfico en los puertos 80 y 443.

Con UFW:

sudo ufw allow "Nginx Full"
sudo ufw status

También puedes permitir los puertos directamente:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

Si el servidor está en un proveedor cloud, revisa además las reglas del firewall externo o grupo de seguridad. A veces el sistema operativo permite el tráfico, pero el proveedor lo bloquea antes de que llegue a la máquina.

Checklist antes de producción

Antes de considerar lista la configuración, revisa estos puntos:

  • El dominio y www apuntan a la IP correcta.
  • El bloque de servidor está activo.
  • nginx -t no muestra errores.
  • HTTP redirige a HTTPS.
  • El certificado TLS se renueva correctamente.
  • Los logs están separados o son fáciles de auditar.
  • Los permisos de archivos no son más amplios de lo necesario.
  • Los puertos 80 y 443 están abiertos.
  • Los archivos sensibles están bloqueados.
  • La aplicación interna o PHP-FPM responden si se usa proxy.

Conclusión

La configuración de un servidor web nginx debe hacerse con método: instalar, crear una estructura clara, definir un bloque de servidor, validar la sintaxis, activar HTTPS, revisar logs y aplicar medidas básicas de seguridad. Una vez entiendes el papel de directivas como server_name, root, location, try_files y proxy_pass, Nginx se vuelve una herramienta flexible para publicar desde sitios estáticos hasta aplicaciones complejas.

La clave es no editar a ciegas. Para configurar un servidor web nginx, cada cambio debe probarse con nginx -t, recargarse con cuidado y verificarse desde el navegador, los logs y la línea de comandos. Así se consigue un servidor web nginx estable, mantenible y preparado para crecer.

Comentarios

No hay comentarios aún. ¿Por qué no comienzas el debate?

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *