Come diagnosticare l'errore «Impossibile raggiungere il sito»

«Impossibile raggiungere il sito» (o la formulazione equivalente del tuo browser) è volutamente vago: copre di tutto, da un errore di battitura nell'URL a un server completamente fermo, fino a un'interruzione della tua stessa connessione. Per affrontarlo in modo efficiente bisogna controllare per prime le cose più semplici e rapide.

Parti da un semplice lookup DNS

Prima di dare per scontato che un server sia fermo, risolvi il dominio da solo, indipendentemente dal browser. Se restituisce un indirizzo IP pulito, il DNS non è il problema e puoi passare a controllare la connessione vera e propria (la porta è aperta, il TLS si negozia, il server risponde davvero). Se restituisce NXDOMAIN, un timeout o un indirizzo privato o dall'aria irraggiungibile, hai isolato il problema al DNS, il che esclude subito un'intera categoria di altre verifiche.

Cosa ti dice ogni esito

Ecco anche perché uno strumento di lookup veloce e senza registrazione è davvero utile durante un incidente: ti dà la risposta a livello DNS in pochi secondi, senza aprire un terminale né ricordare la sintassi di dig/nslookup, così puoi subito capire se hai davvero a che fare con un problema DNS prima di perdere tempo altrove.

Oltre il DNS: cosa controllare dopo, in ordine

1. Connettività TCP verso l'IP risolto sulla porta prevista (di solito la 443): un firewall o un server completamente fermo rifiuteranno la connessione o resteranno in attesa qui, anche con un DNS perfetto.
2. Validità del certificato TLS: un certificato scaduto o non corrispondente produce un avviso di sicurezza del browser che sembra allarmante ma non ha nulla a che fare con il DNS né con la raggiungibilità del server.
3. Risposta a livello HTTP: un server che accetta la connessione ma restituisce un errore 5xx è attivo e raggiungibile, ma fallisce a livello applicativo, molti passaggi dopo qualsiasi cosa il DNS potesse causare.

Procedere in quest'ordine, cioè DNS, poi trasporto, poi TLS, poi applicazione, significa che ogni passaggio escluso restringe in modo significativo le possibilità rimaste, invece di tirare a indovinare sull'intero stack in una volta sola.

Perché proprio quest'ordine

Ogni livello di questa sequenza dipende interamente dal successo di quello precedente, ed è proprio per questo che controllarli in ordine (invece di saltare a quello che sembra più probabile) è l'approccio efficiente. Non ha senso ispezionare un certificato TLS se la connessione TCP non si è mai completata, e non ha senso controllare i codici di risposta HTTP se la negoziazione TLS è fallita. Partire dal DNS, la prima cosa che deve avvenire perché tutto il resto sia anche solo possibile, e procedere verso l'esterno un livello alla volta significa non sprecare mai tempo a indagare su un sintomo che in realtà era causato fin dall'inizio da un problema più semplice di un livello precedente.