«Impossibile raggiungere il sito»: i sei codici dietro una sola frase, e quali sono i vostri

Chrome mostra “Impossibile raggiungere il sito” per almeno sei tipi di errore diversi, che non hanno quasi nulla in comune se non l’ordine in cui si verificano. Uno significa che il nome non esiste. Uno significa che la macchina ha risposto e ha chiuso la connessione. Uno significa che la wifi del visitatore è caduta.

La frase è sempre la stessa perché è l’unica cosa onesta che il browser può dire di una pagina che non ha mai ricevuto. Ciò che li distingue è il piccolo codice grigio sotto il messaggio, ed è proprio quel codice a costituire l’intera diagnosi.

L’ordine in cui accadono le cose

Il caricamento di una pagina attraversa quattro fasi, e ciascuna ha un proprio modo di fallire. Leggere i codici in quell’ordine è ciò che li rende comprensibili.

1. Trovare l’indirizzo. Il browser chiede a un resolver a quale IP punti il nome host.

2. Aprire una connessione. Tenta di raggiungere quell’IP su quella porta.

3. Metterla in sicurezza. Per HTTPS, valida un certificato.

4. Richiedere la pagina. Invia la richiesta e attende una risposta.

Un errore alla fase uno non può dipendere dal vostro server, perché nulla lo ha ancora raggiunto. Un errore alla fase quattro quasi certamente sì. Il codice indica a quale fase si è arrivati, e questo vale più di qualsiasi descrizione del sintomo.

I codici, in quest’ordine

DNS_PROBE_FINISHED_NXDOMAIN e ERR_NAME_NOT_RESOLVED appartengono alla fase uno. La descrizione che Chromium stesso dà del secondo è “Impossibile risolvere il nome host”. Il nome non esiste, per quanto ne sa il resolver che ha risposto. Correlato, e più specifico: ERR_NAME_RESOLUTION_FAILED, “Si è verificato un errore durante il tentativo di risolvere il nome (DNS)”, che indica un problema nella ricerca stessa, non una risposta arrivata vuota.

Un errore di battitura produce questo effetto. Così come un record DNS non ancora propagato, un dominio scaduto nel fine settimana, o un filtro DNS aziendale o di controllo parentale che rifiuta di rispondere per il vostro dominio. Quest’ultimo caso conta più di quanto sembri: per la persona colpita, il vostro sito semplicemente non esiste, mentre per voi funziona perfettamente.

ERR_CONNECTION_REFUSED appartiene alla fase due, ed è l’errore più informativo di questo elenco. Qualcosa ha risposto. Una macchina a quell’indirizzo ha attivamente detto no, il che significa che il DNS ha funzionato, il percorso di rete ha funzionato, e c’è un host lì con nulla in ascolto su quella porta. Porta sbagliata, un servizio che è morto, un container che non è tornato su dopo un deploy.

ERR_CONNECTION_TIMED_OUT è la fase due che fallisce in silenzio: “Il tentativo di connessione è scaduto”. Nessuno ha detto no, e nessuno ha detto sì. Un firewall che scarta i pacchetti invece di rifiutarli ha esattamente questo aspetto, così come un server troppo occupato per accettare la connessione.

ERR_ADDRESS_UNREACHABLE riguarda l’instradamento: “L’indirizzo IP non è raggiungibile. Questo di solito significa che non esiste un percorso verso l’host o la rete specificati”. I pacchetti non hanno dove andare.

ERR_INTERNET_DISCONNECTED è “La connessione a Internet è stata persa”, ed è l’unico caso in cui potete smettere subito di indagare. È la rete del visitatore, e nessuna segnalazione basata su questo vi dice nulla sul vostro sito.

ERR_EMPTY_RESPONSE appartiene alla fase quattro: “Il server ha chiuso la connessione senza inviare alcun dato”. Questo di solito dipende da voi. Qualcosa ha accettato la connessione e poi è sparito senza rispondere: un processo andato in crash a metà richiesta, un proxy che ha rinunciato, un worker terminato per mancanza di memoria.

Anche gli errori di certificato appartengono alla fase tre, ma hanno una schermata propria, diversa da questa. Quale dei cinque vi riguarda è una domanda a parte, e la famiglia ERR_CONNECTION_* ha un articolo dedicato che approfondisce la distinzione tra refused e reset.

Debole

Il cliente dice che il sito è down. Da qui sembra tutto a posto. Gli abbiamo chiesto di svuotare la cache.

Migliore

DNS_PROBE_FINISHED_NXDOMAIN, solo sulla loro rete d'ufficio, funziona con i dati mobili. È il loro filtro DNS, non il nostro server. Confermato che il record si risolve da tre resolver pubblici.

Quale metà dell’elenco riguarda voi

Ordinandoli in base a chi può risolverli, l’elenco si divide quasi a metà, ed è proprio questo il dato utile.

Di solito è colpa loro: gli errori DNS quando sono filtrati o memorizzati nella cache localmente, la connessione a Internet persa, l’indirizzo non raggiungibile, e un timeout causato dalla loro rete piuttosto che dal carico sui vostri server.

Di solito è colpa vostra: connessione rifiutata, risposta vuota, e un timeout quando i vostri server sono davvero saturi.

Genuinamente ambiguo, e da verificare per primo: un errore DNS che si riproduce da un resolver pubblico dipende dal vostro record, non dalla loro rete. Questa verifica richiede dieci secondi e chiarisce la categoria più numerosa dell’elenco. Su qualsiasi macchina:

nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8

Se entrambi rispondono con il vostro IP e il visitatore continua a ricevere NXDOMAIN, il problema è tra loro e il loro resolver. Se nessuno dei due risponde, il problema è il vostro record, e il tempo trascorso decorre da quando è stato modificato l’ultima volta.

Il problema della segnalazione, che è quello vero

Ogni codice sopra descritto compare su una pagina generata dal browser. Il vostro sito non è mai partito. Non c’è console, non c’è una voce nel pannello rete, nessun errore che il vostro tracker possa catturare, e nulla che qualsiasi strumento in pagina possa registrare, incluso il nostro.

Quindi questa intera categoria arriva a voi solo se qualcuno ve la segnala, e lo farà male, perché sullo schermo non c’è nulla da copiare se non una frase e un codice che nessuno ha motivo di pensare sia importante. La maggior parte di queste segnalazioni arriva come “il vostro sito è down” da qualcuno per cui, in effetti, lo è.

Il che rende la domanda di approfondimento insolitamente preziosa, e insolitamente semplice. Non “riproduca il problema con la console aperta”, cosa impossibile in questo caso. Tre cose, invece:

• Il codice, dal piccolo testo grigio sotto il messaggio, per intero.
• Se il problema si presenta su una rete diversa, i dati mobili sono il test più semplice.
• Se qualcun altro riesce a raggiungere il sito, il che distingue in un solo messaggio un’interruzione globale da un problema del resolver di una singola persona.

Con queste tre risposte di solito sapete già quale delle quattro fasi è fallita, ancora prima di aver guardato un server. È un vostro bug o un disservizio esterno applica lo stesso ragionamento ai servizi che sono attivi ma degradati.

Cosa portarsi via

“Impossibile raggiungere il sito” è una categoria, non una diagnosi, e i sei errori che contiene si dividono quasi equamente tra ciò che potete correggere e ciò che non potete.

Leggete il codice, individuate a quale delle quattro fasi appartiene, e verificate il DNS da un resolver pubblico prima di credere a qualsiasi altra ipotesi. E quando non riuscite a riprodurlo, ricordate che l’impossibilità di raggiungere un sito è l’unico tipo di errore in cui la vostra macchina è lo strumento meno utile che possediate: la vostra risolve, si connette e funziona.

L’elenco di Chromium di questi errori, con la definizione in una riga di ciascuno, si trova in net_error_list.h.