Errore 503: sovraccarico, manutenzione o limite dell’hosting?

Cosa significa l’errore

Con un 503 il server web dice: “Ci sono, ma in questo momento non posso servirti.” A differenza del 502, non c’è per forza qualcosa di rotto, e a differenza del 500, l’applicazione non è andata in errore. Il server invia il 503 di proposito, in tre situazioni: è in modalità manutenzione, ha raggiunto un limite che qualcuno gli ha fissato (connessioni, worker, banda, richieste al secondo) oppure è talmente carico da rifiutare richieste per non cadere del tutto. Un 503 può portare con sé un header Retry-After, che dice ai client quando riprovare; i motori di ricerca trattano un 503 breve come temporaneo e non tolgono il sito dall’indice.

Cause frequenti

1. Modalità manutenzione rimasta bloccata. Durante un aggiornamento, WordPress crea un file .maintenance e risponde 503 finché esiste. Se l’aggiornamento si interrompe, il file resta, e l’errore con lui. Laravel, Magento e Drupal hanno un interruttore simile.
2. Sovraccarico. Più richieste di quante i worker riescano a servire: MaxRequestWorkers di Apache raggiunto, pm.max_children di PHP-FPM esaurito, oppure un database così lento che ogni worker resta in attesa.
3. Un limite dell’hosting. I provider di hosting condiviso limitano i secondi di CPU, i processi simultanei o gli “entry processes” per account. Limite raggiunto, il gateway del provider risponde 503 solo per il tuo sito.
4. Un backend fuori rotazione. Dietro un bilanciatore di carico o una CDN, 503 significa che nessun backend ha superato il controllo di salute. Cloudflare mostra la sua pagina 503 quando il server di origine è sovraccarico o ha raggiunto un limite di richieste.
5. Crawler e scraper. Un crawler che scarica migliaia di pagine o un attacco a forza bruta contro wp-login.php o xmlrpc.php consuma i worker; i visitatori veri ricevono 503.
6. Disco o memoria pieni. Il servizio funziona, ma non riesce più a scrivere sessioni, cache o log; alcune applicazioni rispondono allora con 503.

Se sei un visitatore

Aspetta un minuto e ricarica; un 503 è quasi sempre breve. Se un sito resta in 503 per ore, chi lo gestisce ha una modalità manutenzione bloccata o un problema di capacità; può agire solo lui.

Se il sito è tuo: verifica prima

Apri il Website down checker per confermare il 503 dall’esterno e vedere se l’ha inviato una CDN o il tuo server. Poi decidi: negli ultimi minuti è partito un aggiornamento? Se sì, è la modalità manutenzione. Se no, è la capacità.

Sul tuo server:

# il server web funziona almeno?
systemctl status nginx
systemctl status apache2

# carico, memoria, disco: i tre numeri dietro quasi ogni 503
uptime
free -m
df -h

# chi sta martellando il sito?
sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

Un carico molto sopra il numero di core, meno di 100 MB di memoria libera o un solo IP con migliaia di richieste negli ultimi minuti: ognuno spiega un 503.

Soluzioni sul tuo server

1. Uscire da una modalità manutenzione bloccata

WordPress: elimina il file .maintenance nella radice del sito e apri la pagina. Se l’aggiornamento si è interrotto, un plugin o il core possono essere rimasti installati a metà; ripeti l’aggiornamento dalla bacheca o con WP-CLI:

rm /var/www/example.com/.maintenance
wp core verify-checksums
wp plugin update --all

Laravel: php artisan up. Magento: bin/magento maintenance:disable. Drupal: imposta $settings['maintenance_mode'] a false oppure usa drush state:set system.maintenance_mode 0.

2. Fermare la valanga

Blocca l’IP o la rete sospetta e poi limita il ritmo delle richieste, così la prossima non arriva così lontano.

# bloccare un indirizzo (Debian/Ubuntu con ufw)
sudo ufw deny from 203.0.113.45

# oppure con nftables
sudo nft add rule inet filter input ip saddr 203.0.113.45 drop

Limite di richieste in nginx per la pagina di login (nel blocco http, poi nel blocco server):

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /wp-login.php {
    limit_req zone=login burst=5 nodelay;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Apache: mod_evasive o mod_qos fanno lo stesso; fail2ban con le jail apache-badbots e wordpress blocca i recidivi in automatico.

3. Dare capacità al server

Se il carico viene da visitatori veri e non da un abuso, alza i limiti dei worker fin dove la memoria lo permette. Apache (mpm_event): MaxRequestWorkers. PHP-FPM: pm.max_children. Controlla prima la memoria per worker (ps -ylC php-fpm8.3 --sort:rss), poi testa e ricarica:

sudo apachectl configtest && sudo systemctl reload apache2
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm

Attiva una cache delle pagine (WordPress: un plugin di cache o la cache FastCGI di nginx), così un picco non avvia PHP a ogni richiesta. Una pagina in cache costa una frazione di millisecondo; senza cache, centinaia.

4. Liberare il disco

sudo du -xh --max-depth=1 /var | sort -h | tail
sudo journalctl --vacuum-size=200M
sudo apt clean

Log vecchi, backup sullo stesso disco, un log di debug che non smette di crescere: i soliti sospetti.

5. Dietro un bilanciatore di carico

Se tutti i backend falliscono insieme il controllo di salute, di solito è rotto l’URL del controllo (pagina cancellata, redirect a HTTPS che il controllo non segue), non ogni singolo backend. Richiama l’URL di controllo a mano dal bilanciatore.

Se il problema è presso il tuo provider di hosting

Su un hosting condiviso non puoi alzare nessun limite. Chiedi al tuo provider di hosting quale hai raggiunto, e se è stato il tuo traffico o un altro account sullo stesso server:

Buongiorno, il mio sito example.com risponde “503 Service Unavailable” da circa le 9:10 (UTC). Non ho avviato nessun aggiornamento e il sito non è in modalità manutenzione. Potete dirmi se il mio account ha raggiunto un limite di risorse (CPU, processi, memoria) o se il server è sovraccarico? Se è il mio account: quale limite, e da quando?

Se la risposta è regolarmente “il tuo account ha raggiunto i limiti”, metti il sito in cache come si deve o passa a un piano o a un server con più capacità.

Perché non succeda di nuovo

Un 503 si annuncia: il carico sale, la memoria scarseggia, un IP comincia a inondare. Le verifiche del sito catturano il 503 entro un minuto; l’agente server mostra carico, memoria e disco prima che si arrivi a tanto.

Down? Interveniamo. Sul tuo server o su un hosting condiviso con accesso SSH, il Quick Fix, l’intervento automatico a prezzo fisso, libera spazio su disco e riavvia un servizio bloccato; il Deep Fix configura il limite di richieste e la cache, a blocchi di 15 minuti, 24 ore su 24, anche nel fine settimana, perché il server regga la prossima volta; la stima è il prezzo massimo.