503 Service Unavailable: sito in manutenzione, server pieno o fornitore giù?

Cosa significa, in una riga

Il server ha ricevuto la richiesta ma in questo momento non riesce a rispondere: non è un problema di connessione del visitatore, è il server (o qualcosa a monte) che si rifiuta temporaneamente di lavorare.

La verifica più rapida (30 secondi)

Prima di aprire log o pannelli, apri il sito da un altro dispositivo o con i dati mobili, non dalla stessa rete. Se risponde da lì ma non dal browser con cui lavori di solito, il problema è una cache locale o un proxy aziendale, non il server. Se il 503 compare ovunque, procedi con le tre cause qui sotto, nell'ordine in cui capitano più spesso.

1) Manutenzione rimasta accesa (il caso più frequente su WordPress)

Come si capisce: il sito mostra la pagina "Briefly unavailable for scheduled maintenance" oppure resta bianco dopo un aggiornamento di plugin o core interrotto (tab chiusa, connessione caduta, timeout). La causa quasi sempre è un file nascosto chiamato .maintenance nella cartella radice di WordPress, che il CMS crea da solo durante gli aggiornamenti e dovrebbe cancellare da solo a fine lavoro.

Come si risolve, su Ubuntu 24.04 via SSH (vale per qualunque hosting su cui hai accesso shell):

cd /var/www/tuosito.it/public_html
ls -la | grep maintenance
rm .maintenance

Alternativa su cPanel: File Manager → vai nella cartella public_html (o quella del dominio se è un addon domain) → Impostazioni → spunta "Show Hidden Files (dotfiles)" → cerca .maintenance → Elimina. Alternativa su Plesk: Gestione file → stessa procedura, mostrando i file nascosti.

Alternativa via WP-CLI, se installato: wp maintenance-mode deactivate, che rimuove il file .maintenance e riporta il sito online immediatamente.

Eliminare il file è un'operazione sicura: cancellare .maintenance è sicuro, WordPress lo ricrea quando serve in un futuro aggiornamento. Se l'aggiornamento si era fermato a metà, dopo aver tolto il file controlla da wp-admin → Bacheca → Aggiornamenti che il plugin o il core risultino installati correttamente; se no, ripeti l'aggiornamento prima di considerare chiuso il problema.

Come si verifica che è risolto: ricarica il sito in una finestra anonima del browser. Se torna il 503, il file si è ricreato: significa che qualcosa (un plugin, un cron, una chiamata rimasta appesa) sta rigenerando la manutenzione, e il passo successivo è disattivare i plugin rinominando la cartella wp-content/plugins via SSH o FTP, per isolare quale blocca l'uscita.

2) Limite di processi o memoria raggiunto (hosting condiviso e VPS con PHP-FPM)

Come si capisce, su Ubuntu 24.04 con Nginx e PHP-FPM: apri il log di Nginx con

sudo tail -n 50 /var/log/nginx/error.log

Il percorso è quello di default su Ubuntu e Debian secondo la documentazione ufficiale di Nginx, che indica che per sistemi RHEL-based, Debian e Ubuntu il percorso è /var/log/nginx/error.log. La riga che conta è quella con un errore di connessione verso il socket PHP-FPM: se vedi scritto che la connessione è fallita per risorsa temporaneamente non disponibile, il pool PHP-FPM ha raggiunto il numero massimo di processi configurato (pm.max_children) e sta rifiutando nuove richieste.

Controlla il valore impostato con:

sudo grep max_children /etc/php/8.3/fpm/pool.d/www.conf

e lo stato del servizio con sudo systemctl status php8.3-fpm. Un 503 di questo tipo arriva spesso insieme a un picco di visite o a un processo che non si chiude (un cron lento, un plugin che fa query pesanti).

Come si risolve: nell'immediato, un riavvio libera i processi bloccati: sudo systemctl restart php8.3-fpm. Nel medio periodo, va alzato pm.max_children solo se la RAM disponibile lo permette (ogni processo PHP occupa memoria reale: aumentare il numero senza controllare la RAM sposta il problema da 503 a OOM kill, cioè il kernel che uccide i processi per mancanza di memoria), oppure va trovato e corretto cosa tiene occupati i processi più del dovuto.

Alternativa su cPanel: il log equivalente è quello di Apache, che secondo la documentazione dei provider che gestiscono server cPanel si trova di norma in /usr/local/apache/logs/error_log, dove vengono registrati tutti gli errori di Apache, indipendentemente dal sito. Da lì cerca righe con "PHP Fatal" o riferimenti a suPHP/php-fpm vicine all'orario del disservizio.

Come si verifica che è risolto: rilancia la pagina più pesante del sito (di solito l'home o una pagina con molte query) più volte di fila in rapida successione; se non torna il 503, il pool regge il carico attuale.

3) Guasto a monte: non dipende da te

Se il sito è irraggiungibile da reti diverse, il pannello di controllo stesso non si apre, o il provider ha pubblicato un avviso sulla sua status page, il problema è a monte: load balancer, CDN, o il nodo fisico su cui gira il tuo spazio. In questo caso non c'è comando locale che risolva, perché non hai accesso alla causa.

Cosa allegare al ticket di assistenza, per non perdere tempo in avanti e indietro:

• l'orario esatto (con fuso orario) in cui hai notato il problema;
• l'indirizzo IP del tuo hosting, ottenibile con nslookup tuosito.it;
• l'output di curl -I https://tuosito.it, che mostra il codice di risposta e gli header ricevuti;
• se possibile, l'output di un traceroute tuosito.it per mostrare dove si ferma la richiesta.

Riepilogo: dove guardare secondo il pannello

Pannello	File/log da controllare per primo	Percorso
Nessuno, SSH su Ubuntu+Nginx+PHP-FPM	Log errori Nginx	/var/log/nginx/error.log
cPanel	Log errori Apache	/usr/local/apache/logs/error_log
Plesk	Log errori del dominio	Gestione file → Log, o Statistiche → Log degli errori
Qualsiasi pannello, se WordPress	File di manutenzione	.maintenance nella radice del sito

Nessuno di questi controlli richiede più di qualche minuto: l'ordine in cui li fai (manutenzione, poi processi, poi guasto esterno) è anche l'ordine di probabilità con cui capita in un hosting condiviso o in un piccolo VPS gestito a mano.