Schlagwort: Hosting

Website nicht erreichbar: Was tun? Ursachen finden und Fehler beheben

Wenn eine Website nicht erreichbar ist, kann die Ursache beim eigenen Gerät, beim Netzwerk, beim Browser, beim DNS, beim Hosting oder direkt beim Webserver liegen. Eine systematische Prüfung hilft dabei, den Fehler einzugrenzen, statt wahllos Einstellungen zu ändern. Dieser Ratgeber zeigt, welche Schritte sich für Besucherinnen und Besucher, Website-Betreibende und Administratoren eignen.

Website nicht erreichbar: Was tun? Die erste Einordnung

Pru00fcfweg von einem Geru00e4t u00fcber Netzwerk und DNS zu einem Webserver
Der Prüfweg zeigt, an welcher Stelle eine Website-Anfrage scheitern kann.

Die Grafik macht sichtbar, dass ein Zugriffsfehler nicht automatisch am Webserver entstehen muss. Leserinnen und Leser können die einzelnen Stationen nacheinander prüfen.

Bevor Sie technische Änderungen vornehmen, sollten Sie die genaue Fehlermeldung notieren. Ein Browser unterscheidet beispielsweise zwischen einer abgelaufenen Zeitüberschreitung, einer nicht gefundenen Domain, einem Zertifikatsfehler und einem Serverfehler. Diese Hinweise sind wichtig, weil sie auf unterschiedliche Fehlerquellen hindeuten.

Prüfen Sie zunächst, ob nur eine einzelne Seite betroffen ist oder ob keine Website funktioniert. Öffnen Sie anschließend eine bekannte, zuverlässige Website in einem neuen Tab. Funktioniert diese ebenfalls nicht, liegt das Problem möglicherweise an der Internetverbindung, am lokalen Netzwerk oder am DNS. Ist nur eine bestimmte Website betroffen, sollten Sie die Domain, den Serverstatus und die Konfiguration dieser Website untersuchen.

  • Notieren Sie die vollständige Webadresse und die angezeigte Fehlermeldung.
  • Prüfen Sie, ob das Problem auf mehreren Geräten oder in einem anderen Netzwerk auftritt.
  • Testen Sie die Adresse ohne zusätzliche Unterseite, also zunächst nur die Hauptdomain.
  • Vermeiden Sie es, während der ersten Diagnose mehrere Änderungen gleichzeitig vorzunehmen.

Schnelle Prüfungen für Besucherinnen und Besucher

Seite neu laden und Browserdaten ausschließen

Laden Sie die Seite zunächst normal neu. Wenn eine veraltete oder beschädigte Browserdatei vermutet wird, kann ein privates Browserfenster helfen. Dort werden vorhandene Sitzungen, viele Cookies und Teile des Browser-Caches nicht wie im normalen Fenster verwendet. Funktioniert die Website im privaten Fenster, können Erweiterungen, Cookies oder zwischengespeicherte Inhalte die Ursache sein.

Deaktivieren Sie Browser-Erweiterungen nur vorübergehend und einzeln. Besonders Werbeblocker, Sicherheits-Erweiterungen, Proxy-Erweiterungen oder spezielle Datenschutzfilter können einzelne Domains blockieren. Löschen Sie den Cache gezielt für die betroffene Website, anstatt sofort alle gespeicherten Browserdaten zu entfernen.

Andere Geräte und Netzwerke testen

Rufen Sie die Website über ein Smartphone im Mobilfunknetz auf, während das WLAN deaktiviert ist. Sie können auch ein anderes WLAN verwenden. Der Vergleich liefert einen wichtigen Hinweis:

  • Funktioniert die Website nur im Mobilfunknetz, liegt die Ursache wahrscheinlich im WLAN, im Router, im lokalen DNS oder im Anschluss.
  • Funktioniert sie auf keinem Gerät und in keinem Netzwerk, ist ein Problem bei der Website, der Domain oder dem Hosting wahrscheinlicher.
  • Funktioniert sie nur auf einem Gerät nicht, sollten Sie dort Browser-, Netzwerk- oder Sicherheitseinstellungen prüfen.

VPN, Proxy und Sicherheitssoftware kontrollieren

Ein VPN oder ein Unternehmens-Proxy kann den Zugriff über eine andere IP-Adresse oder einen anderen DNS-Dienst leiten. Dadurch können regionale Sperren, Filterregeln oder fehlerhafte Verbindungen sichtbar werden. Deaktivieren Sie ein VPN testweise nur, wenn dies mit den Sicherheitsvorgaben Ihres Unternehmens vereinbar ist. Bei Firmen- oder Schulnetzwerken sollten Sie die zuständige Administration einbeziehen.

Auch lokale Sicherheitssoftware kann Verbindungen blockieren. Ändern Sie deren Schutzfunktionen nicht dauerhaft, sondern prüfen Sie zuerst, ob die betroffene Domain dort als gesperrt, unsicher oder nicht vertrauenswürdig eingestuft wird.

Die häufigsten Fehlermeldungen richtig verstehen

Fehlermeldung oder Hinweis Mögliche Bedeutung Erster sinnvoller Schritt
DNS_PROBE_FINISHED_NXDOMAIN Die Domain konnte über DNS nicht aufgelöst werden oder existiert aus Sicht des verwendeten DNS-Dienstes nicht. Adresse prüfen, DNS vergleichen und bei einer eigenen Domain die DNS-Einträge kontrollieren.
ERR_CONNECTION_TIMED_OUT Der Zielserver antwortet innerhalb der vorgesehenen Zeit nicht. Andere Netzwerke testen und anschließend Hosting, Firewall oder Serverlast prüfen.
ERR_CONNECTION_REFUSED Die Verbindung wurde vom Zielsystem abgelehnt. Serverdienst, Portfreigabe, Firewall und Webserver-Konfiguration untersuchen.
404 Not Found Der Server ist erreichbar, findet die angeforderte Ressource aber nicht. URL, Weiterleitungen, Dateipfad und interne Verknüpfung prüfen.
500 Internal Server Error Auf dem Server ist während der Verarbeitung ein nicht näher beschriebener Fehler aufgetreten. Server- und Anwendungsprotokolle sowie die letzte Änderung prüfen.
502 oder 504 Ein vorgeschalteter Dienst erhält keine gültige oder rechtzeitige Antwort vom Ursprungssystem. Origin-Server, Reverse Proxy, Gateway und externe Abhängigkeiten prüfen.
Zertifikatswarnung Das HTTPS-Zertifikat passt möglicherweise nicht zur Domain, ist abgelaufen oder wird nicht vertrauenswürdig ausgeliefert. Datum, Domainnamen, Zertifikatskette und Serverkonfiguration kontrollieren.

Eine Fehlermeldung ist kein endgültiger Beweis für eine bestimmte Ursache. Ein DNS-Problem kann beispielsweise durch einen lokalen Resolver entstehen, während eine Zeitüberschreitung sowohl auf einen ausgefallenen Server als auch auf eine blockierende Firewall hindeuten kann. Nutzen Sie die Meldung deshalb als Richtung für die nächsten Prüfungen.

Wenn nur die eigene Website nicht erreichbar ist

Domain und DNS prüfen

Rufen Sie im Verwaltungsbereich des Domainanbieters den Status der Domain auf. Prüfen Sie, ob die Domain noch registriert ist, ob die Nameserver korrekt gesetzt sind und ob kürzlich DNS-Einträge geändert wurden. Die wichtigsten Einträge sind häufig der A- oder AAAA-Eintrag für die IP-Adresse sowie CNAME-Einträge für bestimmte Subdomains.

Prüfen Sie dabei sowohl IPv4 als auch IPv6. Eine falsch konfigurierte IPv6-Adresse kann dazu führen, dass manche Netzwerke die Website nicht erreichen, während andere über IPv4 weiterhin funktionieren. Wenn Sie keinen Zugriff auf den Domainbereich haben, benötigen Sie die Unterstützung des Domaininhabers oder der zuständigen Agentur.

Hosting- und Serverstatus kontrollieren

Öffnen Sie das Kundenportal des Hosters und prüfen Sie Wartungshinweise, Kontosperren, Ressourcenmeldungen und den Status der zugehörigen Dienste. Kontrollieren Sie außerdem, ob der Webserver läuft und ob die Domain auf das richtige Hosting-Ziel zeigt.

Bei einem virtuellen Server sollten Sie die Systemauslastung, den verfügbaren Speicherplatz und die laufenden Dienste ansehen. Ein voller Datenträger kann dazu führen, dass Datenbanken, Protokolle oder temporäre Dateien nicht mehr geschrieben werden können. Hohe Prozess- oder Speicherauslastung kann wiederum Zeitüberschreitungen auslösen. Nehmen Sie Neustarts nicht als erste und einzige Maßnahme: Sie können Symptome kurzfristig beseitigen, aber die eigentliche Ursache bleibt möglicherweise bestehen.

Die letzte Änderung zurückverfolgen

Viele Ausfälle beginnen nach einer konkreten Änderung. Fragen Sie daher: Wurde ein Plugin, Theme oder Paket aktualisiert? Wurde eine neue Weiterleitung eingerichtet? Gab es eine Änderung an PHP, der Datenbank, dem Webserver, dem CDN oder der Firewall? Wurde ein Zertifikat erneuert oder die Domain auf einen neuen Server umgezogen?

Wenn der Zeitpunkt bekannt ist, sichern Sie zunächst aktuelle Protokolle und Daten. Danach können Sie die letzte Änderung kontrolliert zurücknehmen oder eine bekannte funktionierende Version wiederherstellen. Bei einem Content-Management-System sollten Sie Erweiterungen nicht blind einzeln deaktivieren, wenn dadurch weitere Daten verloren gehen könnten. Nutzen Sie, sofern vorhanden, eine Staging-Umgebung und dokumentieren Sie jeden Schritt.

DNS, Cache und Weiterleitungen systematisch untersuchen

DNS-Änderungen können je nach Resolver und Einstellungen unterschiedlich lange in dessen Cache verbleiben. Ein lokaler DNS-Cache kann deshalb eine alte IP-Adresse liefern, obwohl die Konfiguration beim Anbieter bereits geändert wurde. Leeren Sie den lokalen DNS-Cache nur, wenn Sie wissen, welches Betriebssystem und welcher Resolver verwendet werden. Alternativ können Sie mit einem anderen DNS-Dienst oder einem externen Netzwerk vergleichen.

Prüfen Sie die Weiterleitungskette der Website. Eine HTTP-zu-HTTPS-Weiterleitung ist üblich, sollte aber nicht zwischen mehreren Varianten hin- und herspringen. Typische problematische Varianten sind:

  • Die Domain verweist auf eine IP-Adresse, auf der der virtuelle Host nicht eingerichtet ist.
  • Die Weiterleitung von www auf die Hauptdomain und zurück erzeugt eine Schleife.
  • Das Zertifikat deckt die verwendete Subdomain nicht ab.
  • Eine alte Weiterleitung verweist auf eine nicht mehr vorhandene Domain oder Unterseite.

Wenn ein CDN oder Reverse Proxy vorgeschaltet ist, müssen Sie sowohl den Proxy als auch den Ursprungsserver prüfen. Ein Proxy kann Inhalte ausliefern, während der Origin bereits nicht erreichbar ist; umgekehrt kann eine fehlerhafte Proxy-Konfiguration den Origin unnötig verdecken.

Server- und Anwendungsfehler beheben

Protokolle zuerst sichern

Serverprotokolle sind häufig die wichtigste Informationsquelle. Sichern Sie relevante Einträge aus Webserver, Anwendung, Datenbank und Betriebssystem für den Zeitraum rund um den Ausfall. Achten Sie auf wiederkehrende Fehlermeldungen, fehlende Dateien, Berechtigungsfehler, Verbindungsabbrüche und ungewöhnlich lange Antwortzeiten.

Veröffentlichen Sie Protokolle nicht ungeschützt im Internet. Sie können IP-Adressen, Dateipfade, Benutzernamen oder interne technische Informationen enthalten. Entfernen oder schützen Sie personenbezogene und sicherheitsrelevante Daten, bevor Sie Ausschnitte an einen Dienstleister weitergeben.

Konfiguration und Berechtigungen prüfen

Ein falsch gesetzter Dateipfad, eine ungültige Direktive in der Serverkonfiguration oder eine unpassende PHP-Version kann die gesamte Website blockieren. Prüfen Sie Konfigurationsdateien zunächst auf Syntaxfehler und laden Sie Änderungen erst nach einer Validierung neu. Achten Sie auf korrekte Dateirechte, den richtigen Besitzer und die erwartete Dokumentenwurzel.

Wenn nur eine Anwendung betroffen ist, kann die Verbindung zur Datenbank oder zu einem externen Dienst fehlschlagen. Prüfen Sie, ob Zugangsdaten, Endpunkte und Zertifikate noch gültig sind. Eine Anwendung sollte bei einem Ausfall externer Dienste möglichst eine verständliche Fehlerseite anzeigen, statt sensible Fehlermeldungen an Besucher auszugeben.

Wartungsmodus und Notfallseite vorbereiten

Bei geplanten Arbeiten ist eine klare Wartungsseite hilfreicher als ein leerer Browserfehler. Sie sollte erklären, dass die Website vorübergehend nicht verfügbar ist, und – sofern bekannt – einen ungefähren Zeitraum oder einen alternativen Kontakt nennen. Vermeiden Sie Versprechen, die Sie nicht einhalten können. Für wichtige Websites lohnt sich eine technisch unabhängige Statusseite oder eine separate statische Notfallseite.

Was Sie besser nicht tun sollten

  • Ändern Sie nicht gleichzeitig DNS, Zertifikat, Firewall und Anwendung. Sonst lässt sich die Ursache kaum noch nachvollziehen.
  • Löschen Sie keine Protokolle oder Backups, bevor Sie den Vorfall dokumentiert haben.
  • Deaktivieren Sie Sicherheitsmechanismen nicht dauerhaft, nur um eine Seite kurzfristig erreichbar zu machen.
  • Setzen Sie keine Datenbank oder Website ohne aktuelle Sicherung zurück.
  • Geben Sie keine Zugangsdaten an Personen weiter, deren Identität und Zuständigkeit nicht geklärt sind.
  • Ignorieren Sie wiederkehrende Ausfälle nicht. Ein scheinbar kleiner Fehler kann auf ein dauerhaftes Konfigurations- oder Ressourcenproblem hinweisen.

Wann professionelle Unterstützung sinnvoll ist

Beauftragen Sie den Hoster, eine Agentur oder die interne Administration, wenn Sie keinen Zugriff auf Domain- oder Serververwaltung haben, wenn geschäftskritische Funktionen betroffen sind oder wenn ein Sicherheitsvorfall möglich erscheint. Auch bei Datenbankfehlern, beschädigten Backups, unbekannten Administratorkonten oder auffälligen Änderungen sollten Sie nicht experimentieren.

Für eine schnelle Bearbeitung sind folgende Informationen hilfreich:

  • vollständige Domain und betroffene Unterseiten,
  • Beginn und Häufigkeit des Problems,
  • genaue Fehlermeldung und verwendeter Browser,
  • Ergebnis des Tests über ein anderes Gerät oder Netzwerk,
  • letzte Änderungen an Domain, Hosting, Software oder Firewall,
  • relevante, geschützte Protokollausschnitte und vorhandene Backup-Informationen.

Wenn Sie einen Angriff vermuten, ändern Sie Zugangsdaten über einen sicheren Weg, bewahren Sie Protokolle auf und stimmen Sie weitere Schritte mit einer fachkundigen Sicherheitsstelle ab. Eine vorschnelle Bereinigung kann wichtige Spuren beseitigen.

Vorbeugung gegen spätere Ausfälle

Eine gute Vorbereitung verkürzt die Diagnose. Dokumentieren Sie Domainanbieter, Nameserver, Hostingzugänge, technische Ansprechpartner und die wichtigsten Abhängigkeiten. Bewahren Sie diese Informationen sicher und getrennt von den Zugangsdaten auf. Legen Sie fest, wer bei einem Ausfall entscheiden darf und wie Änderungen freigegeben werden.

Backups sollten regelmäßig erstellt, geschützt gespeichert und gelegentlich wiederhergestellt werden. Ein Backup gilt erst dann als verlässlich, wenn die Wiederherstellung nachvollziehbar funktioniert. Dokumentieren Sie außerdem Konfigurationsänderungen und führen Sie größere Updates zunächst in einer Testumgebung durch.

Überwachen Sie die Erreichbarkeit von außen, nicht nur den Zustand des Servers. Ein laufender Webserver bedeutet nicht automatisch, dass DNS, TLS, Datenbank, Login oder zentrale Geschäftsprozesse funktionieren. Sinnvolle Prüfungen sollten die wichtigsten Nutzerwege abdecken und bei einem Fehler eine verantwortliche Person benachrichtigen.

FAQ

Was bedeutet „Website nicht erreichbar“?

Die Meldung bedeutet zunächst nur, dass der Browser keine nutzbare Antwort erhalten hat. Gründe können eine fehlerhafte Internetverbindung, DNS-Probleme, ein nicht erreichbarer Server, eine falsche Weiterleitung, ein Zertifikatsfehler oder ein Fehler der Website-Anwendung sein.

Wie erkenne ich, ob die Website nur bei mir nicht funktioniert?

Testen Sie die Website auf einem zweiten Gerät und über ein anderes Netzwerk, etwa über Mobilfunk statt WLAN. Wenn sie dort funktioniert, liegt die Ursache eher im lokalen Netzwerk, Browser, DNS, VPN oder auf dem einzelnen Gerät.

Warum funktioniert eine Website im Mobilfunk, aber nicht im WLAN?

Dann kommen unter anderem ein fehlerhafter Router, eine DNS-Störung, eine Firewall-Regel, ein Proxy oder eine Einschränkung des lokalen Anschlusses infrage. Starten Sie den Router nicht sofort mehrfach neu, sondern notieren Sie zuerst die Fehlermeldung und vergleichen Sie die DNS- und Netzwerkbedingungen.

Wie lange dauert es, bis eine DNS-Änderung sichtbar wird?

Das hängt unter anderem von den TTL-Einstellungen, den verwendeten DNS-Resolvern und lokalen Caches ab. Während dieser Übergangszeit können verschiedene Netzwerke unterschiedliche Ergebnisse liefern. Prüfen Sie deshalb mehrere Resolver und ändern Sie nicht wiederholt dieselben Einträge ohne klare Diagnose.

Was kann ich bei einem Fehler 500 tun?

Der Server ist grundsätzlich erreichbar, die Anwendung konnte die Anfrage aber nicht verarbeiten. Prüfen Sie die Server- und Anwendungsprotokolle, die letzte Änderung, Dateirechte, PHP- oder Laufzeitversionen sowie die Datenbankverbindung. Ohne Protokolle bleibt die Ursache meist unklar.

Ist eine Zertifikatswarnung nur ein Browserproblem?

Nein. Sie kann auf ein abgelaufenes Zertifikat, einen falschen Domainnamen, eine fehlerhafte Zertifikatskette oder eine falsche Serverzeit hinweisen. Besucher sollten eine solche Warnung nicht einfach umgehen, besonders wenn Zugangsdaten oder Zahlungsdaten übertragen werden.

Wann sollte ich den Hoster kontaktieren?

Kontaktieren Sie den Hoster, wenn mehrere Geräte und Netzwerke betroffen sind, der Serverstatus unklar ist, Sie keinen administrativen Zugriff haben oder Ressourcen-, Netzwerk- und Systemfehler vermuten. Übermitteln Sie die genaue Fehlermeldung, den Zeitraum und die bereits durchgeführten Prüfungen.

Fazit

Wenn eine Website nicht erreichbar ist, führt eine strukturierte Prüfung schneller zur Ursache als wiederholtes Neuladen. Beginnen Sie mit Fehlermeldung, anderem Gerät und anderem Netzwerk. Danach folgen Domain, DNS, Zertifikat, Hosting, Serverprotokolle und die zuletzt vorgenommenen Änderungen. Dokumentieren Sie jeden Schritt, sichern Sie Daten und greifen Sie bei Sicherheits- oder Serverproblemen auf fachkundige Unterstützung zurück. So lässt sich der Ausfall nicht nur beheben, sondern häufig auch künftig besser verhindern.

DNS und Website-Erreichbarkeit prüfen: Der umfassende Ratgeber

Wenn eine Website nicht erreichbar ist, liegt die Ursache nicht immer beim Webserver. Häufig beginnt die Fehlersuche bei der Namensauflösung: Das Domain Name System (DNS) übersetzt eine Domain in eine IP-Adresse und entscheidet damit, welchen Server Browser, Mailprogramme und andere Dienste ansprechen. Wer DNS und Website-Erreichbarkeit prüfen möchte, sollte deshalb systematisch vorgehen und DNS, Netzwerk, TLS und Webserver getrennt betrachten.

Dieser Ratgeber zeigt, welche Prüfungen sinnvoll sind, wie typische Fehlermeldungen einzuordnen sind und wann eine Änderung am DNS tatsächlich wirksam wird. Die beschriebenen Schritte eignen sich für private Websites, Unternehmensseiten und technische Dokumentationen. Sie ersetzen keine individuelle Administration, helfen aber dabei, Probleme einzugrenzen und gezielt an den zuständigen Anbieter weiterzugeben.

Was DNS und Website-Erreichbarkeit miteinander verbindet

Eine Website-Erreichbarkeit besteht aus mehreren Stationen. Gibt eine Person beispielsweise www.beispiel.de in den Browser ein, muss zunächst ein DNS-Resolver die passende IP-Adresse ermitteln. Anschließend baut das Gerät eine Verbindung zu dieser Adresse auf. Bei HTTPS folgt außerdem die Prüfung des TLS-Zertifikats, bevor der Webserver eine HTTP-Antwort liefert.

Jede dieser Stationen kann unabhängig ausfallen:

  • DNS-Auflösung: Die Domain liefert keine, eine falsche oder eine nicht mehr aktuelle IP-Adresse.
  • Netzwerkverbindung: Der Zielserver ist nicht erreichbar, ein Port ist blockiert oder eine Firewall verwirft die Anfrage.
  • TLS beziehungsweise HTTPS: Das Zertifikat ist abgelaufen, gilt nicht für den verwendeten Hostnamen oder die Zertifikatskette ist fehlerhaft.
  • Webserver und Anwendung: Der Server antwortet mit einem Fehler wie 404, 500 oder 503.
  • Lokale Umgebung: Ein lokaler DNS-Cache, eine Hosts-Datei, ein VPN oder ein Unternehmensfilter beeinflusst das Ergebnis.

Die erste wichtige Frage lautet daher nicht nur „Ist die Website erreichbar?“, sondern: In welcher Schicht tritt das Problem auf? Genau diese Einordnung verhindert unnötige Änderungen an DNS-Einträgen oder am Server.

Vorbereitung: Was Sie vor der Prüfung notieren sollten

Schematische Darstellung der einzelnen Pru00fcfschritte von DNS bis Webserver
Die Fehlersuche folgt dem Weg von der Domainauflösung bis zur Webserverantwort.

Die Darstellung macht sichtbar, dass DNS nur eine Station der gesamten Verbindung ist. So lässt sich besser unterscheiden, ob die Namensauflösung, das Netzwerk oder der Webserver untersucht werden muss.

Bevor Sie einzelne Befehle ausführen, halten Sie die betroffenen Adressen und den Zeitpunkt fest. Prüfen Sie möglichst sowohl die Hauptdomain ohne Subdomain als auch die Variante mit www. Bei internationalen oder mehrsprachigen Websites können zusätzlich weitere Hostnamen relevant sein.

  • die betroffene Domain, zum Beispiel beispiel.de,
  • die genaue URL einschließlich http oder https,
  • die verwendete Subdomain, etwa www, shop oder blog,
  • die angezeigte Fehlermeldung und den ungefähren Beginn des Problems,
  • ob die Störung bei allen Personen oder nur in einem Netzwerk auftritt,
  • ob kurz zuvor DNS-, Hosting-, CDN- oder Zertifikatsänderungen vorgenommen wurden.

Diese Informationen sind auch für den Support eines Hosters oder Domainregistrars wertvoll. Eine präzise Fehlerbeschreibung mit Uhrzeit und betroffener URL ist hilfreicher als die pauschale Aussage, eine Website sei „offline“.

DNS und Website-Erreichbarkeit prüfen: Ein sinnvoller Ablauf

Arbeiten Sie von der Namensauflösung zur Anwendung. So lässt sich erkennen, ob ein Problem bereits vor dem Webserver entsteht.

1. Die Domain in mehreren Netzwerken öffnen

Testen Sie die Website zunächst in einem normalen Browserfenster und, wenn möglich, über ein zweites Netzwerk. Eine Verbindung über Mobilfunk kann dabei als Vergleich dienen. Öffnet sich die Seite über Mobilfunk, aber nicht im Büro- oder Heimnetz, spricht das eher für einen lokalen Resolver, einen Filter, eine Firewall oder einen Routingfehler als für einen vollständigen Ausfall der Website.

Prüfen Sie außerdem die URL mit und ohne www. Beide Hostnamen können unterschiedliche DNS-Einträge und unterschiedliche Serverkonfigurationen besitzen. Auch die Weiterleitung von HTTP zu HTTPS sollte separat betrachtet werden.

2. Die DNS-Antwort des lokalen Systems ansehen

Unter Windows kann nslookup verwendet werden:

nslookup beispiel.de
nslookup www.beispiel.de

Auf macOS und Linux liefert dig detailliertere Informationen:

dig beispiel.de A
dig www.beispiel.de A
dig beispiel.de AAAA

Die Abfrage für A zeigt IPv4-Adressen, die Abfrage für AAAA IPv6-Adressen. Eine Domain kann mehrere Adressen zurückgeben. Das ist beispielsweise bei Lastverteilung, Hochverfügbarkeit oder einem CDN normal. Ein Ergebnis ohne Adresse, eine unerwartete Zieladresse oder eine Fehlermeldung wie SERVFAIL verdient dagegen eine genauere Untersuchung.

Notieren Sie auch, welcher DNS-Server die Antwort geliefert hat. Das Ergebnis kann vom Resolver des Internetanbieters, einem Unternehmensresolver oder einem öffentlichen Resolver stammen. Unterschiedliche Resolver können wegen Caching vorübergehend verschiedene Antworten liefern.

3. Autoritative Nameserver und DNS-Kette prüfen

Die maßgebliche DNS-Konfiguration liegt bei den autoritativen Nameservern der Domain. Mit dig können Sie zunächst deren Namen ermitteln:

dig beispiel.de NS
dig +trace beispiel.de

dig +trace verfolgt die Delegation von der Root-Zone über die zuständige Top-Level-Domain bis zu den autoritativen Nameservern. Die Ausgabe ist technisch und je nach System unterschiedlich formatiert. Entscheidend ist, ob die Delegation konsistent ist und ob die autoritativen Server eine plausible Antwort liefern.

Prüfen Sie danach einen autoritativen Nameserver direkt. Ersetzen Sie ns1.example.net durch den tatsächlich ermittelten Server:

dig @ns1.example.net beispiel.de A
dig @ns1.example.net www.beispiel.de A

Wenn die autoritative Antwort korrekt ist, aber ein einzelner lokaler Resolver noch einen alten Wert liefert, handelt es sich wahrscheinlich um Caching. Wenn bereits die autoritativen Server unterschiedliche oder falsche Antworten geben, liegt die Ursache eher in der DNS-Zone oder bei der Delegation.

4. DNS-Einträge auf typische Fehler prüfen

Für die Website sind vor allem folgende Eintragstypen relevant:

Eintrag Aufgabe Typische Fehler
A Verweist auf eine IPv4-Adresse. Alte Serveradresse, Tippfehler oder falscher Zielserver.
AAAA Verweist auf eine IPv6-Adresse. Fehlerhafte IPv6-Konfiguration, obwohl IPv6 bevorzugt wird.
CNAME Verweist einen Hostnamen auf einen anderen Hostnamen. Falsches Ziel, unerlaubter Einsatz an der Zone-Apex oder eine zusätzliche CNAME-Kette.
NS Legt autoritative Nameserver fest. Delegation beim Registrar passt nicht zur tatsächlich gepflegten DNS-Zone.
CAA Kann festlegen, welche Zertifizierungsstellen Zertifikate ausstellen dürfen. Eine gewünschte Zertifikatsausstellung wird unbeabsichtigt verhindert.

Besondere Aufmerksamkeit verdient ein vorhandener AAAA-Eintrag. Ist IPv6 veröffentlicht, aber der Server über IPv6 nicht erreichbar, können manche Geräte zuerst die fehlerhafte IPv6-Verbindung verwenden. Ein Test muss daher beide Protokolle berücksichtigen. Ein unpassender AAAA-Eintrag kann die Website für einen Teil der Besucher ausfallen lassen, obwohl IPv4 funktioniert.

5. Verbindung zur IP-Adresse untersuchen

Wenn die DNS-Adresse bekannt ist, testen Sie die Verbindung zur Website. Mit curl können Sie HTTP-Header abrufen:

curl -I http://beispiel.de
curl -I https://beispiel.de

Die Option -I fordert normalerweise nur die Header an. Antworten wie 200 oder eine nachvollziehbare Weiterleitung mit 301 oder 302 zeigen, dass ein HTTP-Dienst antwortet. Ein Fehlercode wie 403, 404, 500 oder 503 bedeutet nicht automatisch, dass DNS fehlerhaft ist. Im Gegenteil: Der Server wurde in diesen Fällen meist bereits erreicht.

Mit folgenden Varianten lässt sich die Protokollfamilie getrennt betrachten:

curl -4 -I https://beispiel.de
curl -6 -I https://beispiel.de

Funktioniert IPv4, aber IPv6 nicht, konzentriert sich die weitere Fehlersuche auf den AAAA-Eintrag, die IPv6-Erreichbarkeit, die Firewall und die Serverkonfiguration. Fällt beides aus, kommen unter anderem ein gestoppter Webserver, ein Netzwerkproblem, ein falsches Ziel oder eine Sperre infrage.

DNS-Caching und TTL richtig einordnen

DNS-Antworten werden zwischengespeichert. Die Gültigkeitsdauer wird durch die TTL, also die „Time to Live“, beeinflusst. Nach einer Änderung kann deshalb ein Resolver noch den alten Wert aus seinem Cache liefern, während ein anderer bereits die neue Adresse kennt.

Die oft verwendete Formulierung „DNS-Änderungen brauchen immer 24 bis 48 Stunden“ ist zu pauschal. Die tatsächliche Dauer hängt von der vorherigen TTL, dem Zeitpunkt des Caches, der Delegation und weiteren Resolver-Regeln ab. Eine reduzierte TTL kurz vor einer geplanten Änderung kann die Wartezeit verkürzen, wirkt aber nicht rückwirkend auf bereits gespeicherte Antworten.

Für eine belastbare Prüfung vergleichen Sie mehrere Resolver und direkt die autoritativen Nameserver. Ein einzelner Test aus einem einzigen Netzwerk reicht bei einer kürzlich vorgenommenen Änderung nicht immer aus. Gleichzeitig sollte nicht jede abweichende Antwort als Fehler interpretiert werden: Während einer laufenden Umstellung können Unterschiede vorübergehend erwartbar sein.

HTTPS, Weiterleitungen und Browserfehler getrennt prüfen

Eine korrekte DNS-Antwort garantiert noch keine funktionierende Website. Danach muss der Hostname eine passende TLS- und Webserverkonfiguration besitzen.

  • Zertifikatsname: Das Zertifikat muss den aufgerufenen Hostnamen abdecken, etwa die Domain oder die verwendete Subdomain.
  • Gültigkeitszeitraum: Ein abgelaufenes oder noch nicht gültiges Zertifikat führt zu Browserwarnungen.
  • Zertifikatskette: Fehlende Zwischenzertifikate können vor allem bei bestimmten Clients Probleme verursachen.
  • HTTPS-Weiterleitung: Eine Weiterleitung von HTTP zu HTTPS sollte auf das gewünschte Ziel zeigen und keine Endlosschleife bilden.
  • Virtuelle Hosts: Der Webserver muss den angeforderten Hostnamen der richtigen Website zuordnen.

Eine Fehlermeldung wie „DNS_PROBE_FINISHED_NXDOMAIN“ weist typischerweise auf einen nicht vorhandenen Domainnamen oder eine fehlende DNS-Antwort hin. „ERR_CONNECTION_REFUSED“ deutet eher darauf hin, dass die Zieladresse gefunden wurde, aber kein Dienst die Verbindung annimmt oder eine Firewall sie zurückweist. „502 Bad Gateway“ und „504 Gateway Timeout“ betreffen häufig einen Reverse Proxy, ein CDN oder einen nicht erreichbaren Backend-Dienst.

Häufige Ursachen und passende nächste Schritte

Falsche IP-Adresse nach einem Umzug

Nach einem Hostingwechsel bleibt der A- oder AAAA-Eintrag gelegentlich auf den alten Server zeigen. Vergleichen Sie die aktuelle DNS-Antwort mit den vom neuen Hostinganbieter mitgeteilten Zielwerten. Kontrollieren Sie dabei auch www und weitere produktive Subdomains.

Domain ist beim falschen DNS-Anbieter delegiert

Die DNS-Zone wird nicht unbedingt dort verwaltet, wo die Domain registriert ist. Maßgeblich sind die beim Registrar hinterlegten NS-Einträge. Werden Änderungen im falschen Verwaltungsbereich vorgenommen, bleiben sie wirkungslos. Prüfen Sie daher die Delegation, bevor Sie einzelne Records bearbeiten.

IPv6 wurde veröffentlicht, aber nicht vollständig eingerichtet

Ein AAAA-Eintrag sollte nur auf eine tatsächlich erreichbare und korrekt abgesicherte IPv6-Adresse zeigen. Prüfen Sie Firewallregeln, Routing, Webserverbindung und die TLS-Konfiguration für IPv6. Entfernen Sie einen veralteten Eintrag nicht unüberlegt, sondern stimmen Sie die Änderung mit der verantwortlichen Administration ab.

CNAME, Weiterleitung und DNS-Zone widersprechen sich

Eine Subdomain kann entweder direkt auf eine Adresse zeigen oder per CNAME auf einen anderen Hostnamen verweisen. Unzulässige Kombinationen und lange Verkettungen erschweren die Fehlersuche. Prüfen Sie, ob das Ziel existiert und ob der Zielanbieter die gewünschte Domain kennt.

CDN, Proxy oder Firewall blockiert Anfragen

Bei einem CDN ist die veröffentlichte IP-Adresse häufig nicht die des Ursprungsservers. Ein Fehler kann deshalb zwischen Browser und CDN, zwischen CDN und Origin oder nur im Cache entstehen. Prüfen Sie die Konfiguration beider Seiten und achten Sie auf unterschiedliche Antworten für HTTP und HTTPS. Sicherheitsregeln, Ratenbegrenzungen und regionale Sperren können außerdem einzelne Netzwerke betreffen.

Werkzeuge für eine nachvollziehbare Prüfung

Für eine erste Analyse reichen meist Bordmittel. nslookup ist auf vielen Systemen verfügbar und leicht zu bedienen. dig eignet sich besser für detaillierte DNS-Antworten, TTL-Werte, Nameserver und Abfragen gegen bestimmte Resolver. curl zeigt, ob HTTP oder HTTPS antwortet und welche Statuscodes zurückgegeben werden.

Zusätzlich können Browserentwicklertools, Serverprotokolle und die Statusseiten des Hosting- oder CDN-Anbieters helfen. Öffentliche DNS-Prüfdienste können Antworten aus verschiedenen Regionen vergleichen. Verlassen Sie sich jedoch nicht blind auf einen einzelnen Dienst: Prüfen Sie, welcher Resolver tatsächlich gefragt wird und ob die Daten möglicherweise bereits zwischengespeichert sind.

Für die Dokumentation sollten Sie Befehle, Zeitpunkt, Netzwerk, verwendeten Resolver und Ergebnis festhalten. Entfernen oder schwärzen Sie interne Adressen und vertrauliche Zugangsdaten, bevor Sie Ausgaben weitergeben.

Wann professionelle Unterstützung sinnvoll ist

Holen Sie Unterstützung hinzu, wenn die Domaindelegation unklar ist, mehrere Anbieter beteiligt sind oder eine produktive Website dauerhaft ausfällt. Das gilt besonders für Shops, Buchungsseiten, Kundenportale und Systeme mit getrennten Frontend- und Backend-Diensten. Auch Änderungen an Nameservern, DNSSEC, Mailrouting oder Firewallregeln sollten nur von Personen vorgenommen werden, die die Auswirkungen beurteilen können.

Geben Sie dem Support eine strukturierte Zusammenfassung: betroffene Hostnamen, Zeitpunkt, DNS-Antworten, verwendete Netzwerke, HTTP-Statuscodes und bereits geprüfte Protokollfamilien. So lassen sich Rückfragen reduzieren und die zuständige Ebene schneller bestimmen.

FAQ

Woran erkenne ich, dass DNS die Ursache ist?

Typische Hinweise sind eine nicht auflösbare Domain, NXDOMAIN, SERVFAIL oder eine falsche IP-Adresse. Wenn der Server bereits mit einem HTTP-Status antwortet, funktioniert die DNS-Auflösung grundsätzlich; die Ursache liegt dann eher bei Webserver, Anwendung, TLS oder einer vorgeschalteten Infrastruktur.

Wie prüfe ich A- und AAAA-Einträge?

Verwenden Sie beispielsweise dig beispiel.de A und dig beispiel.de AAAA oder unter Windows nslookup -type=A beispiel.de und nslookup -type=AAAA beispiel.de. Vergleichen Sie die Ergebnisse mit den vorgesehenen Serveradressen und prüfen Sie IPv4 und IPv6 getrennt.

Warum sehen verschiedene DNS-Checker unterschiedliche Ergebnisse?

Resolver befinden sich an unterschiedlichen Standorten und besitzen eigene Caches. Nach einer Änderung laufen diese Caches nicht gleichzeitig ab. Auch eine inkonsistente Delegation oder unterschiedliche autoritative Antworten kann Abweichungen verursachen. Entscheidend ist der Vergleich mit den autoritativen Nameservern.

Kann ich den DNS-Cache lokal leeren?

Ja, viele Betriebssysteme und Browser halten DNS-Informationen lokal vor. Die konkreten Schritte unterscheiden sich jedoch nach Betriebssystem und Version. Das Leeren des lokalen Caches beseitigt keine veraltete Antwort bei einem externen Resolver und ersetzt daher keinen Vergleich mehrerer DNS-Server.

Was bedeutet ein HTTP-Statuscode 503?

Ein Statuscode 503 bedeutet, dass der angesprochene Dienst vorübergehend nicht verfügbar ist. DNS hat in diesem Fall meist bereits funktioniert. Mögliche Ursachen sind Wartung, Überlastung, ein gestopptes Backend oder eine fehlerhafte Proxy-Konfiguration.

Warum funktioniert die Domain ohne „www“, aber nicht mit „www“?

Die beiden Hostnamen können unterschiedliche A-, AAAA- oder CNAME-Einträge besitzen. Außerdem muss der Webserver beide Hostnamen kennen und das TLS-Zertifikat beide Varianten abdecken. Prüfen Sie DNS und HTTPS deshalb für jede verwendete Adresse separat.

Ist ein DNS-Propagationsproblem immer die wahrscheinlichste Erklärung?

Nein. Nach einer Änderung ist Caching zwar möglich, aber ebenso kommen eine falsche Delegation, ein Tippfehler, ein fehlerhafter AAAA-Eintrag oder ein nicht erreichbarer Server infrage. Ein strukturierter Vergleich autoritativer und rekursiver Antworten grenzt diese Ursachen besser ein.

Fazit: Schrittweise statt zufällig prüfen

DNS und Website-Erreichbarkeit prüfen bedeutet, mehrere technische Ebenen voneinander zu trennen. Beginnen Sie mit der betroffenen URL, vergleichen Sie A- und AAAA-Antworten, kontrollieren Sie die autoritativen Nameserver und testen Sie anschließend HTTP, HTTPS sowie IPv4 und IPv6. Berücksichtigen Sie TTL und Caching, ohne jede Verzögerung vorschnell als Propagation zu bezeichnen.

Eine dokumentierte Prüfung spart Zeit: Sie zeigt, ob die Domain korrekt delegiert ist, ob der richtige Server antwortet und ob das Problem erst bei TLS, Webserver, Anwendung oder Netzwerk entsteht. Je genauer diese Grenze bestimmt ist, desto gezielter können Sie selbst handeln oder die zuständige technische Stelle einbeziehen.