Nginx lee su configuración al arrancar. Cambiar un archivo no hace nada hasta que le pide releer, y cómo se lo pide decide si alguien se entera.

Pruebe siempre primero

nginx -t

Analiza todo y nombra el archivo y la línea de lo que no le gusta. No cambia nada. Nunca hay motivo para saltárselo.

Recargue, no reinicie

  • reload: arranca trabajadores nuevos con la configuración nueva, deja que los viejos terminen lo que tienen entre manos y luego los jubila. No se pierde ninguna conexión.
  • restart: para todo y vuelve a empezar. Toda petición en vuelo falla.
systemctl reload nginx
Una recarga con la configuración rota NO rompe el sitio: Nginx rechaza la nueva y sigue con la vieja. Un reinicio con la configuración rota deja el sitio caído. Solo eso ya es motivo para recargar.

Cuándo hace falta de verdad reiniciar

  • Al cambiar el usuario con el que corre Nginx.
  • Al añadir un módulo.
  • Al cambiar en el contexto principal algo que los trabajadores en marcha no pueden asumir.

Mantenga el cambio reversible

cp /etc/nginx/sites-available/mysite{,.bak-$(date +%F)}
# edit, test, reload
# and if it is wrong:
cp /etc/nginx/sites-available/mysite.bak-2026-09-04 /etc/nginx/sites-available/mysite
nginx -t && systemctl reload nginx

Compruebe qué está cargado de verdad

nginx -T | grep -A5 "server_name yourdomain.com"

La T mayúscula imprime toda la configuración en servicio con cada include resuelto, que es la única manera de asegurarse de que el archivo que editó es el que se usa.

Si un cambio parece no hacer nada, busque un segundo bloque de servidor que case con el mismo nombre. Gana la primera coincidencia, y un archivo olvidado en sites-enabled es el motivo habitual.