Tutti e quattro significano la stessa cosa al livello che conta: la conversazione non è mai arrivata abbastanza avanti da avere un risultato. Chrome ha provato ad aprire una connessione verso un server, e la connessione è stata rifiutata, troncata, chiusa o mai risposta - quindi non c’è pagina, non c’è codice di stato e non c’è niente del sito da leggere.

È questo che li separa dagli errori con cui di solito vengono confrontati. Un 404 o un 504 significa che un server ti ha risposto, in HTTP, con qualcosa. Un ERR_CONNECTION_ qualunque significa che lo scambio è fallito sotto HTTP, prima che tutto questo potesse succedere. Chrome si inventa questi nomi da solo, ed è per questo che non assomigliano affatto a un codice di stato.

I quattro si distinguono per come è fallito, e quella differenza è gran parte della diagnosi.

ERR_CONNECTION_REFUSED

Qualcosa ha risposto, e quello che ha detto è stato no.

La macchina a quell’indirizzo è raggiungibile, e ha attivamente rifiutato la connessione su quella porta. Lì non c’è niente in ascolto, oppure un firewall respinge subito la connessione invece di scartarla in silenzio.

Le cause più comuni, nell’ordine in cui conviene controllarle: il server non è in esecuzione; è in esecuzione su una porta diversa da quella nell’indirizzo; è associato a 127.0.0.1 e accetta quindi connessioni solo dalla propria macchina; oppure hai chiesto https su una porta che serve http semplice.

Se sei uno sviluppatore e vedi questo contro localhost, quasi sempre è una di quelle quattro e quasi mai è il browser.

ERR_CONNECTION_TIMED_OUT

Non ha risposto proprio niente.

Chrome ha mandato pacchetti nel buio e ha aspettato. È la firma di qualcosa che scarta il traffico in silenzio invece di rifiutarlo: un firewall configurato per scartare anziché respingere, un indirizzo che non porta più da nessuna parte, una VPN che manda il tuo traffico da qualche parte da cui la destinazione non è raggiungibile.

La spia è l’attesa. Un rifiuto torna indietro all’istante; un timeout dura quanto la pazienza del browser.

ERR_CONNECTION_RESET

La connessione era aperta, e poi è stata uccisa a metà frase.

Qualcosa ha mandato un reset: il server, o più spesso qualcosa fra te e lui. Proxy aziendali che ispezionano il traffico, software di sicurezza sulla macchina, un collegamento instabile, o un apparato di rete che ha deciso che la connessione non era permessa dopo che era già cominciata.

È quello dei quattro che più probabilmente è causato da qualcosa che non è il sito. Se succede su una rete e non su un’altra, hai trovato la risposta senza toccare il sito.

ERR_CONNECTION_CLOSED

La stessa forma di un reset, finita più educatamente: l’altro capo ha chiuso la connessione mentre il browser ne aspettava ancora.

In pratica indica il server, o qualcosa davanti a lui, che si arrende a metà strada: un processo che riparte, un bilanciatore di carico che lascia cadere una connessione inattiva, un disallineamento di protocollo. In questa famiglia vedrai anche ERR_CONNECTION_ABORTED, che di solito significa che la richiesta è stata annullata prima di finire, a volte dalla pagina stessa che naviga altrove.

Quattro domande che lo localizzano in circa un minuto

Qualunque dei quattro tu abbia, lo stesso triage lo restringe. Falle in ordine e fermati quando una risponde.

  • Altri siti funzionano? No, e il problema è la tua connessione, non il sito.
  • Funziona in una finestra privata? Sì, ed è un’estensione, un cookie o una risorsa in cache più che la rete.
  • Funziona su un altro dispositivo sulla stessa rete? Sì, ed è quella macchina: il suo software di sicurezza, le sue impostazioni proxy, la sua VPN.
  • Funziona sotto rete mobile invece che sul wi-fi? Sì, ed è quella rete, che è la spiegazione abituale di un reset che vede una persona sola.

Due di quelle quattro domande escludono il sito del tutto, il che vale la pena sapere prima che qualcuno passi un pomeriggio a leggere log del server per un guasto che al server non è mai arrivato.

Session Replay

Estensione gratuita per Chrome. Un clic sulla pagina che si comporta male cattura lo screenshot, la console e il registro di rete, e ti restituisce un link da incollare nel ticket.

Installa l'estensione

Perché vengono segnalati così male

Un errore di connessione non produce nessuno stato HTTP e spesso niente di utile in console. O la pagina non si carica affatto, oppure - molto peggio da diagnosticare - si carica benissimo mentre una singola richiesta al suo interno fallisce in questo modo, così il sito sembra rotto in un modo specifico e inspiegabile.

Quel secondo caso è quello che arriva come “il pulsante salva non fa niente”. Nessun errore sullo schermo, nessun testo rosso, niente che la persona possa citarti. Nel pannello di rete è ovvio ed è una riga: una richiesta in stato fallito, nessuno stato, e accanto un host.

Quale host sia conta più di qualsiasi altra cosa nella segnalazione. Se le richieste fallite nominano tutte il tuo dominio, è la tua infrastruttura o la rotta che ci porta. Se nominano un fornitore di pagamenti, un servizio di mappe o un host di font, la pagina si sta comportando correttamente e qualcosa da cui dipende no - e chi legge può andare a controllare la pagina di stato di quel fornitore invece della tua.

Il registro di rete in una segnalazione di bug porta esattamente quello, che è la differenza fra questa classe di bug riproducibile e una storia su qualcosa successo martedì.

La versione breve

  • Refused: qualcosa ha detto no, subito. Di solito non c’è niente in ascolto su quella porta.
  • Timed out: nessuno ha detto niente. Di solito qualcosa scarta il traffico in silenzio.
  • Reset: la connessione è morta in volo. Di solito la rete di mezzo, non il sito.
  • Closed: l’altro capo ha riagganciato presto. Di solito il server o qualcosa davanti a lui.

E nessuno dei quattro è un errore HTTP, ed è per questo che accanto non compare nessun codice di stato e che il server può non avere alcuna traccia del tentativo.