So diagnostizieren Sie die Fehlermeldung „Diese Website ist nicht erreichbar“

„Diese Website ist nicht erreichbar“ (oder die entsprechende Formulierung Ihres Browsers) ist bewusst vage -- sie umfasst alles von einem Tippfehler in der URL über einen komplett ausgefallenen Server bis zu einem Netzwerkausfall Ihrer eigenen Verbindung. Wer effizient vorgehen will, prüft zuerst die günstigsten und schnellsten Dinge.

Beginnen Sie mit einer einfachen DNS-Abfrage

Bevor Sie annehmen, ein Server sei ausgefallen, lösen Sie die Domain für sich allein auf, unabhängig von Ihrem Browser. Kommt eine saubere IP-Adresse zurück, ist DNS nicht das Problem, und Sie können die Verbindung selbst prüfen (ist der Port offen, wird TLS ausgehandelt, antwortet der Server tatsächlich). Kommt NXDOMAIN, ein Timeout oder eine private bzw. unerreichbar wirkende Adresse zurück, haben Sie das Problem auf DNS eingegrenzt, was sofort eine ganze Kategorie anderer Fehlersuche ausschließt.

Was jedes Ergebnis Ihnen verrät

Deshalb ist ein schnelles Lookup-Tool ohne Anmeldung mitten in einem Vorfall wirklich nützlich: Es liefert Ihnen die Antwort der DNS-Ebene in Sekunden, ohne dass Sie ein Terminal öffnen oder sich die Syntax von dig/nslookup merken müssen, sodass Sie sofort eingrenzen können, ob überhaupt ein DNS-Problem vorliegt, bevor Sie anderswo Zeit investieren.

Jenseits von DNS: die nächsten Prüfpunkte der Reihe nach

1. TCP-Konnektivität zur aufgelösten IP auf dem erwarteten Port (meist 443) -- eine Firewall oder ein komplett ausgefallener Server verweigert oder hängt hier selbst bei perfektem DNS.
2. Gültigkeit des TLS-Zertifikats -- ein abgelaufenes oder nicht passendes Zertifikat führt zu einer Sicherheitswarnung im Browser, die alarmierend aussieht, aber nichts damit zu tun hat, ob DNS funktioniert oder der Server erreichbar ist.
3. HTTP-Antwort -- ein Server, der die Verbindung annimmt, aber einen 5xx-Fehler zurückgibt, ist online und erreichbar, scheitert nur auf Anwendungsebene, mehrere Schritte jenseits dessen, was DNS hätte verursachen können.

Wer diese Punkte der Reihe nach abarbeitet -- DNS, dann Transport, dann TLS, dann Anwendung --, grenzt mit jedem ausgeschlossenen Schritt die verbleibenden Möglichkeiten spürbar ein, statt den gesamten Stack auf einmal zu erraten.

Warum gerade diese Reihenfolge

Jede Ebene dieser Abfolge hängt vollständig davon ab, dass die vorherige erfolgreich ist, weshalb es effizient ist, sie der Reihe nach zu prüfen (statt direkt zur vermeintlich wahrscheinlichsten zu springen). Es hat keinen Sinn, ein TLS-Zertifikat zu untersuchen, wenn die TCP-Verbindung nie zustande kam, und keinen Sinn, HTTP-Statuscodes zu prüfen, wenn die TLS-Aushandlung scheiterte. Wer bei DNS beginnt -- dem allerersten Schritt, der geschehen muss, bevor alles andere überhaupt möglich ist -- und sich Ebene für Ebene nach außen arbeitet, verschwendet nie Zeit mit einem Symptom, das in Wahrheit ein einfacheres Problem einer früheren Ebene verursacht hat.