Server down o non raggiungibile: cosa controllare e in che ordine

Questa guida parla del server in sé: un VPS, un server dedicato o un server cloud che amministri tu. Se non funziona un solo sito web e tutto il resto sulla macchina va, oppure il tuo sito è su un hosting condiviso, parti piuttosto dalla guida sito non raggiungibile. Qui guardiamo la macchina: risponde ancora? Riesci a entrare? Cosa si è fermato?

Passo 1: cosa è down esattamente?

“Il server è down” può voler dire tre cose molto diverse, e ognuna ha la sua soluzione. Verifica prima dall’esterno, da una rete che non sia la tua. Per i siti web ospitati sul server, il Website down checker ti dice in pochi secondi se il nome si risolve, se la porta risponde e quale codice di stato torna. Per la macchina, usa ping e un test delle porte dal tuo computer:

ping -c 3 203.0.113.10
nc -zv -w 5 203.0.113.10 22
nc -zv -w 5 203.0.113.10 443

Leggi i risultati insieme:

• Niente ping, niente SSH, niente porta web: la macchina è spenta, bloccata, oppure la rete davanti a lei è interrotta. Vai al passo 2.
• Il ping risponde, SSH no: la macchina funziona, ma SSH è bloccato, fermo, oppure il server è troppo sovraccarico per rispondere. Vai al passo 3.
• SSH funziona, il sito web no: il server sta bene, un servizio no. Vai al passo 4.

Alcuni server non rispondono al ping di proposito. Se il ping non ha mai funzionato, fidati dei test delle porte.

Passo 2: non risponde nulla

Apri prima di tutto il pannello cliente o la console cloud del tuo provider. Tre domande risolvono la maggior parte dei casi in un minuto:

1. Il server è acceso? Un’istanza fermata, un account sospeso o un pagamento rifiutato si vedono dall’esterno esattamente come un guasto.
2. C’è un problema noto? Guarda la status page del provider per la tua regione o il tuo data center.
3. Cosa mostra la console? La console web o seriale mostra lo schermo della macchina anche senza rete. Un kernel panic, “Out of memory: Killed process” a ripetizione o un avvio fermo al controllo del file system ti dicono dov’è il problema.

Se la macchina è bloccata, un riavvio dalla console di solito la riporta in vita. Prima di riavviare, fai uno screenshot della console: dopo il riavvio, l’indizio sparisce. Se non si avvia più, quasi tutti i provider offrono un sistema di ripristino da cui monti il disco, leggi i log e correggi /etc/fstab o una configurazione di rete rotta.

Passo 3: il ping risponde, SSH no

La macchina è viva, quindi la causa è dentro di lei. Entra dalla console e controlla i soliti sospetti:

sudo ufw status verbose
sudo iptables -S | head -n 30
sudo fail2ban-client status sshd
sudo systemctl status ssh sshd 2>/dev/null | grep -E 'Loaded|Active'

Una regola del firewall aggiunta di fretta, il tuo indirizzo IP bloccato dopo qualche password sbagliata o una configurazione di SSH che non ha superato il suo test sono i blocchi più frequenti. Sblocca il tuo indirizzo con sudo fail2ban-client set sshd unbanip TUO_IP ed esegui sempre sudo sshd -t prima di riavviare SSH. Se SSH funziona ma è lentissimo, il server è sovraccarico: vai al passo 4.

Passo 4: sei dentro, leggi quattro numeri

uptime
free -m
df -h
df -i
sudo dmesg -T | grep -iE 'oom|killed process|i/o error|read-only' | tail -n 20

• Carico (uptime): molto sopra il numero di core significa che la macchina è sovraccarica. top o htop mostra quale processo è il colpevole.
• Memoria (free -m): senza memoria libera né swap, e con “Killed process” in dmesg, il kernel ha terminato un processo per sopravvivere. Di solito è il database o PHP.
• Disco (df -h): un disco pieno è la causa più frequente di un server down. I database smettono di scrivere, i log si interrompono, le sessioni falliscono. df -i controlla gli inode: un disco può essere “pieno” con gigabyte liberi se milioni di file piccoli occupano tutti gli inode.
• Errori di I/O o file system in sola lettura in dmesg: il disco stesso ha un problema. Smetti di scrivere, copia quello che puoi e contatta il tuo provider.

Per liberare spazio senza rischi, parti dal journal di sistema e dai file vecchi:

sudo journalctl --vacuum-size=200M
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 15

Non cancellare mai file del database o del sito web per fare spazio.

Passo 5: quale servizio si è fermato e perché?

systemctl --failed
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -t

systemctl --failed elenca ogni servizio che si è fermato con un errore. Il suo log dà il motivo: una porta già occupata, un errore di sintassi in un file di configurazione, un certificato mancante, spazio esaurito. Testa la configurazione prima di ogni riavvio (nginx -t, apachectl configtest, php-fpm -t) e poi esegui sudo systemctl restart SERVIZIO. Un riavvio senza test può buttare giù un servizio che funzionava ancora a metà.

Passo 6: cosa è cambiato?

I guasti hanno una causa, e quasi sempre è l’ultima modifica. Cercala:

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -n 20
last -n 10
sudo journalctl --since "2 hours ago" -p err --no-pager | tail -n 40

Aggiornamenti automatici, un kernel nuovo in attesa di riavvio, un deploy, un cron job che ha riempito il disco di backup, un certificato scaduto o una modifica di configurazione fatta da qualcun altro: se una di queste coincide con l’inizio del guasto, hai l’indizio.

Quando gli stessi problemi tornano

Un server che è andato down una volta per un disco pieno o un database fermo lo rifarà. La verifica dall’esterno ti dice quando è down; la verifica dall’interno ti avvisa prima. L’agente server invia carico, memoria, dischi e servizi dalla macchina stessa e ti avvisa quando un disco supera la tua soglia o si ferma un servizio che hai segnato, finché c’è ancora tempo per agire. Il monitoraggio server con agente fa parte dei piani a pagamento.

Quando non vuoi fare tutto questo alle 3 di notte

Se il tuo server è down e preferisci farlo riparare invece di cercare tu, il Quick Fix, l’intervento automatico a prezzo fisso, risolve le cause più frequenti: riavvia un servizio fermo se il test di configurazione riesce, libera un disco pieno e rinnova un certificato scaduto, con una copia di backup prima. Se non basta, il Deep Fix prende il testimone 24 ore su 24, fatturato a blocchi di 15 minuti, con il prezzo visibile prima dell’ordine; la stima è il prezzo massimo. Entrambi lavorano tramite il Responder, SSH come root o l’accesso SSH al tuo hosting condiviso. Tutti i dettagli nella pagina assistenza server 24/7.

Down? Interveniamo. Quick Fix a prezzo fisso o Deep Fix a blocchi di 15 minuti, sul tuo server o su un hosting condiviso con accesso SSH.