Quando un sito è down, verifica prima che non funzioni per tutti e non solo per te. Poi procedi dall’esterno verso l’interno: DNS, connessione, certificato TLS, CDN o proxy, web server e infine l’applicazione e le sue dipendenze. L’errore che vedi di solito ti dice da quale livello partire, e ogni passaggio qui sotto ha un test rapido che lo conferma o lo esclude.
Prendi appunti mentre procedi: cosa hai controllato, a che ora e cosa hai visto. Rendono più veloce passare la soluzione a qualcun altro e più facile scrivere il postmortem.
Passo 1: è down per tutti o solo per te?
Incolla l’indirizzo nel checker Is it down?. Richiede la pagina da Stoccolma, in Svezia, segue fino a cinque redirect e considera online qualsiasi risposta sotto HTTP 500. Poi prova il sito dal telefono con il Wi-Fi spento.
Se funziona dall’esterno ma non per te, il problema è vicino a te: una VPN, una voce nel file hosts, la cache DNS del router, un’estensione del browser o un firewall che ha bloccato il tuo indirizzo IP dopo troppi accessi falliti. Prova una finestra privata e un’altra rete prima di toccare il server.
Leggi il messaggio di errore
L’errore esatto indica il livello che non funziona. Annotalo prima di iniziare a cambiare qualcosa.
Cosa vediLivello probabileParti daDNS_PROBE_FINISHED_NXDOMAIN, “impossibile trovare l’indirizzo IP del server”DNS o dominioPasso 2ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUTRete o serverPasso 3“La connessione non è privata”, NET::ERR_CERT_DATE_INVALIDCertificato TLSPasso 4Cloudflare 521, 522, 525 o 526, oppure una pagina di errore della CDNDalla CDN all’originePasso 5500, 502, 503 o 504Web server o applicazionePasso 6Una pagina che si carica ma è vuota o mostra un erroreApplicazione o dipendenzaPasso 7
Passo 2: controlla il DNS e il dominio
Se il nome non viene risolto, nient’altro conta. Chiedi al DNS cosa risponde per il tuo dominio e confrontalo con l’indirizzo del tuo server:
dig +short example.com A
dig +short www.example.com
dig +short example.com NS
Nessuna risposta: verifica se la registrazione del dominio è scaduta con il controllo scadenza dominio. Un dominio scaduto spesso perde i nameserver o punta alla pagina di parcheggio del registrar.
L’indirizzo sbagliato: qualcuno ha modificato un record, oppure i nameserver sono passati a un provider che non ha i tuoi record. Confronta la risposta con quella che ti aspetti usando lo strumento DNS lookup.
Giusto per alcuni, sbagliato per altri: una modifica recente si sta ancora diffondendo. I resolver mantengono la vecchia risposta finché non scade il suo TTL: è la propagazione DNS.
La nostra guida a DNS_PROBE_FINISHED_NXDOMAIN esamina le cause legate al DNS una per una.
Passo 3: riesci a raggiungere il server?
Con l’indirizzo giusto, verifica se il server accetta connessioni sulle porte web:
nc -vz example.com 443
curl -sv -o /dev/null https://example.com/
Connessione rifiutata: la macchina risponde, ma nulla è in ascolto sulla porta. Il web server si è fermato o è andato in crash. Avvialo e leggi il suo log per capire perché.
Timeout: i pacchetti non arrivano da nessuna parte. Il server è spento, un firewall o un security group scarta il traffico, oppure la rete nel mezzo ha un guasto. Controlla la pagina di stato e la console del tuo provider di hosting.
Non affidarti solo a ping. Molti host bloccano l’ICMP, quindi un server può non rispondere al ping e servire il sito senza problemi, oppure rispondere al ping mentre il web server è down.
Passo 4: controlla il certificato TLS
Un problema di certificato rende il sito irraggiungibile per tutti contemporaneamente, con un avviso del browser a tutta pagina, mentre il server in sé funziona. Verifica l’host con l’SSL checker, oppure controlla dalla riga di comando:
openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject
Le cause più comuni sono un certificato scaduto dopo un rinnovo automatico fallito, un certificato emesso per un altro nome o un certificato intermedio mancante. Errori dei certificati SSL spiegati associa ogni avviso del browser alla sua soluzione.
Passo 5: escludi la CDN o il proxy
Se davanti al sito c’è una CDN o un reverse proxy, la pagina di errore può arrivare dal proxy e non dal tuo server. I codici 52x di Cloudflare dicono esattamente dove si è interrotto:
521: il server di origine ha rifiutato la connessione.
522: la connessione all’origine è andata in timeout.
525: l’handshake TLS con l’origine non è riuscito.
526: il certificato dell’origine non è valido.
Per testare l’origine senza la CDN, invia la richiesta direttamente al suo indirizzo IP mantenendo il nome host. Sostituisci 203.0.113.10 con l’indirizzo della tua origine:
curl -sv -o /dev/null –resolve example.com:443:203.0.113.10 https://example.com/
Se l’origine risponde correttamente, guarda la CDN: la sua pagina di stato, le regole firewall che hai modificato di recente e se ha ancora l’indirizzo giusto dell’origine. Se anche l’origine non risponde, passa al server.
Passo 6: controlla il web server e l’applicazione
Un codice di stato 5xx significa che la richiesta ha raggiunto il tuo stack e lì qualcosa non ha funzionato. Il codice restringe il campo:
500: l’applicazione ha generato un errore. Vedi 500 Internal Server Error.
502: il web server non ha ricevuto una risposta valida dal processo dell’applicazione dietro di lui, spesso perché quel processo è andato in crash. Vedi 502 Bad Gateway.
503: il servizio è sovraccarico o in modalità manutenzione. Vedi 503 Service Unavailable.
504: l’applicazione ha impiegato troppo a rispondere. Vedi 504 Gateway Timeout.
Ogni codice ha la sua pagina nella guida ai codici di stato HTTP. Sul server, tre controlli trovano la maggior parte delle cause:
df -h # a full disk stops databases, logs and uploads
free -m # out of memory kills processes
tail -n 50 /var/log/nginx/error.log # or your web server and app logs
Poi chiediti cosa è cambiato. Un deploy, l’aggiornamento di un plugin, una modifica alla configurazione o una chiave API scaduta nell’ultima ora sono la causa più probabile, e annullare la modifica è spesso più rapido che fare debug in produzione.
Passo 7: controlla le dipendenze
Il tuo sito può essere in salute mentre qualcosa di cui ha bisogno non lo è. Un database che ha esaurito le connessioni, un server di cache che si è fermato o un provider di pagamenti, email o login in down: tutto questo rompe pagine che per il resto si caricano. Controlla le pagine di stato dei tuoi provider e cerca i più grandi su Is it down?, che monitora i servizi più noti e le loro interruzioni recenti.
Quando il sito è online ma non funziona
Alcuni guasti rispondono 200: un elenco prodotti vuoto, un pulsante di checkout che non fa nulla, un messaggio di errore dentro una pagina normale. Un codice di stato non li rileva. Verifica che la pagina contenga ciò che deve contenere e percorri il flusso che conta, come l’accesso o il pagamento, come farebbe un cliente.
Mentre risolvi: avvisa le persone
Pubblica un breve aggiornamento appena sai che c’è un problema, anche se puoi solo dire che stai indagando, e indica quando arriverà il prossimo aggiornamento. Il generatore di aggiornamenti di stato ne scrive uno per ogni fase, e il piano di comunicazione degli incidenti chiarisce chi dice cosa e dove.
Rendi più breve la prossima interruzione
La parte più lenta della maggior parte delle interruzioni è accorgersene. Con un monitoraggio esterno vieni a sapere del problema da un avviso invece che da un cliente, e parti da dati concreti invece che da ipotesi. Ecco cosa ti offre Uptimecheck:
Controlli ogni minuto da Stoccolma, Londra e New York, con ogni errore confermato da una seconda località prima che tu riceva l’avviso. Vedi monitoraggio uptime.
Prove nell’incidente: l’indirizzo a cui il DNS ha risolto, i redirect, il certificato, gli header e l’inizio della risposta, più uno screenshot quando il server ha risposto o un traceroute quando non l’ha fatto. Vedi come funzionano incidenti e prove.
Tempi di risposta suddivisi in fasi: DNS, connessione, TLS, server e download, così un livello lento si nota prima che smetta di funzionare.
Promemoria prima della scadenza per certificati e domini, e avvisi quando i record DNS cambiano.
Controlli per parola chiave e flussi che rilevano una pagina che risponde 200 ma non funziona. Vedi monitoraggio dei flussi.
Se un monitor segnala down mentre il sito per te funziona, perché un monitor è down quando il sito funziona spiega come interpretare la differenza.
Scoprilo prima dei tuoi clienti. Prova Uptimecheck gratis per 14 giorni, senza carta di credito.