sudo systemctl status nginx --no-pager
sudo nginx -t

Si nginx -t da error, normalmente indica el archivo y el número de línea, por ejemplo:

nginx: [emerg] invalid number of arguments in "proxy_pass" directive in /etc/nginx/sites-enabled/app.conf:18

En ese momento no adivines: abre directamente el archivo y la línea correspondientes.

Proceso de publicación recomendado:

sudo nginx -t
sudo systemctl reload nginx

No se recomienda empezar con:

sudo systemctl restart nginx

Cuando reload falla, los workers antiguos suelen seguir activos y el servicio en línea puede no interrumpirse; cuando restart falla, puede que directamente no haya ningún proceso de Nginx sirviendo.

Revisa los registros:

sudo journalctl -u nginx -n 100 --no-pager
sudo tail -n 100 /var/log/nginx/error.log

Estructura habitual en Ubuntu / Debian:

/etc/nginx/nginx.conf
/etc/nginx/conf.d/*.conf
/etc/nginx/sites-available/
/etc/nginx/sites-enabled/

Lista los sitios habilitados:

ls -l /etc/nginx/sites-enabled/

Problemas comunes:

• Hay un enlace simbólico roto en sites-enabled;
• El mismo server_name está escrito varias veces;
• Varios sitios escuchan en el mismo puerto pero no hay sitio predeterminado;
• El orden de carga de los nombres de archivo hace que la configuración predeterminada coincida primero.

Puedes usar:

sudo nginx -T | less

Para ver la configuración completa tal como la carga Nginx realmente.

Si el navegador abre el sitio predeterminado, un sitio antiguo o un 404, revisa primero:

server {
    listen 80;
    server_name example.com www.example.com;
}

También confirma que el DNS apunta al VPS actual:

dig +short example.com

Si también tienes IPv6, no olvides el registro AAAA. A veces el registro A es correcto pero el AAAA sigue apuntando a la máquina antigua, lo que provoca problemas de acceso a algunos usuarios.

Un error común en sitios estáticos es entender mal cómo se concatenan las rutas de root / alias.

Para casos simples, usa root:

location / {
    root /var/www/site;
    try_files $uri $uri/ =404;
}

alias es más adecuado para mapear un prefijo de URL a un directorio completamente distinto:

location /uploads/ {
    alias /data/uploads/;
}

La barra final en alias es importante; si se escribe mal, provoca 404 o una concatenación de rutas anómala.

Configuración habitual de proxy inverso:

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;
}

Diagnostica el backend:

curl -I http://127.0.0.1:3000
sudo ss -lntup | grep 3000

Si el backend no está escuchando, Nginx devolverá 502 por muy correcta que sea su configuración.

Para un diagnóstico más detallado de 502/504, consulta:

• Qué hacer ante 502 / 504 Bad Gateway en VPS (2026): lista de comprobación de Nginx, PHP-FPM, Gunicorn y tiempos de espera del upstream

Errores comunes en la configuración de certificados:

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

Comprueba si los archivos existen:

sudo ls -l /etc/letsencrypt/live/example.com/

Comprueba la renovación:

sudo certbot renew --dry-run

Rutas de certificado incorrectas, falta de coincidencia del dominio o el puerto 80 bloqueado pueden hacer que la configuración HTTPS no surta efecto o que el reload falle.

Confirma si Nginx está escuchando:

sudo ss -lntup | egrep ':80|:443'

Si el puerto está ocupado por Apache, Caddy u otro Nginx, en los registros normalmente aparece bind() to 0.0.0.0:80 failed.

Revisa UFW:

sudo ufw status verbose

Permite HTTP/HTTPS:

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

También revisa el grupo de seguridad del proveedor de nube; de lo contrario, aunque la máquina local lo permita, el acceso externo puede seguir fallando.

Haz una copia de seguridad antes de cada cambio de configuración:

sudo cp /etc/nginx/sites-available/app.conf /etc/nginx/sites-available/app.conf.bak.$(date +%F-%H%M)

Orden de publicación:

sudo nginx -t
sudo systemctl reload nginx
curl -I https://example.com

Si falla, revierte:

sudo cp /etc/nginx/sites-available/app.conf.bak.时间戳 /etc/nginx/sites-available/app.conf
sudo nginx -t
sudo systemctl reload nginx

No adivines y cambies cosas en la máquina de producción. Guarda cada cambio y comando de reversión en el historial del shell o en un registro de cambios; el diagnóstico futuro será mucho más rápido.

1. sudo nginx -t para ver el archivo y el número de línea;
2. journalctl -u nginx -n 100 para ver los errores de systemd;
3. tail /var/log/nginx/error.log para ver los errores en tiempo de ejecución;
4. nginx -T para ver la configuración final cargada;
5. Revisa los enlaces simbólicos de sites-enabled;
6. Revisa server_name y el DNS;
7. Revisa root/alias o proxy_pass;
8. Revisa las rutas de los certificados y certbot;
9. Revisa la escucha en 80/443, el firewall y el grupo de seguridad;
10. Si es necesario, revierte desde la copia de seguridad.

Lecturas adicionales:

• El servicio VPS arrancó pero no es accesible desde Internet (2026): cómo diagnosticar puertos, firewall, grupo de seguridad y dirección de escucha
• Qué hacer cuando falla la renovación del certificado Let's Encrypt en un VPS (2026): lista de comprobación de certbot, Cloudflare, DNS-01 y puerto 80

El principio central ante errores de configuración de Nginx es: primero nginx -t, luego reload, no restart directamente. Para errores de sintaxis, mira el número de línea; para errores en tiempo de ejecución, mira error.log; para problemas de proxy inverso, mira la escucha del backend; para problemas de HTTPS, mira las rutas de los certificados y la accesibilidad de 80/443. Fijar el proceso de publicación y reversión es más fiable que adivinar la configuración sobre la marcha.