Nginx legge la configurazione all'avvio. Cambiare un file non fa nulla finché non gli dice di rileggere, e il modo in cui glielo dice decide se qualcuno se ne accorge.
Provare sempre per primo
nginx -t
Analizza tutto e indica file e riga di ciò che non gli piace. Non cambia nulla. Non c'è mai un motivo per saltarlo.
Ricaricare, non riavviare
- reload - avvia nuovi worker con la nuova configurazione, lascia che i vecchi finiscano quel che stanno facendo, poi li congeda. Non cade nessuna connessione.
- restart - ferma tutto e riparte. Ogni richiesta in volo fallisce.
systemctl reload nginx
Un reload con una configurazione rotta NON rompe il sito: Nginx rifiuta quella nuova e continua con la vecchia. Un restart con una configurazione rotta lascia il sito a terra. Basta questo come motivo per ricaricare.
Quando un riavvio serve davvero
- Quando cambia l'utente con cui gira Nginx.
- Quando si aggiunge un modulo.
- Quando si cambia nel contesto principale qualcosa che i worker in esecuzione non possono recepire.
Tenga la modifica reversibile
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
Controlli che cosa è caricato davvero
nginx -T | grep -A5 "server_name yourdomain.com"
La T maiuscola stampa tutta la configurazione in servizio con ogni include risolto, ed è l'unico modo per essere certi che il file che ha modificato sia quello in uso.
Se una modifica sembra non fare nulla, cerchi un secondo blocco server che risponda allo stesso nome. Vince la prima corrispondenza, e un file dimenticato in sites-enabled è la ragione solita.
