Schlagwort: Website-Monitoring

Eine Domain kann für manche Besucher erreichbar sein und für andere trotzdem Fehler liefern. Ursache können ein fehlerhafter DNS-Eintrag, ein abgelaufenes TLS-Zertifikat, eine nicht erreichbare IPv6-Adresse, ein falsch konfigurierter Webserver oder eine Störung beim Hosting sein. Wer die Domain-Erreichbarkeit zuverlässig testen möchte, sollte deshalb nicht nur einen einzelnen Aufruf im Browser prüfen, sondern mehrere technische Ebenen getrennt betrachten.

Dieser Ratgeber zeigt eine nachvollziehbare Vorgehensweise: von der Namensauflösung über die Netzwerkverbindung bis zur HTTP-Antwort. Außerdem erfahren Sie, wie Sie Ergebnisse einordnen, typische Fehlerquellen eingrenzen und ein angemessenes Monitoring aufbauen.

Was bedeutet Domain-Erreichbarkeit?

Der Begriff Erreichbarkeit beschreibt nicht nur, ob eine Website im Browser sichtbar wird. Eine Domain ist technisch über mehrere Stationen erreichbar:

• DNS: Der Domainname wird in eine IP-Adresse aufgelöst.
• Netzwerk: Die Zieladresse ist über das Internet erreichbar.
• TLS: Bei HTTPS kann eine verschlüsselte Verbindung aufgebaut und geprüft werden.
• HTTP: Der Webserver nimmt die Anfrage an und liefert eine passende Antwort.
• Anwendung: Die Website erzeugt den erwarteten Inhalt, statt beispielsweise einen Serverfehler auszugeben.

Diese Ebenen können unabhängig voneinander ausfallen. Ein funktionierender DNS-Eintrag beweist beispielsweise noch nicht, dass der Webserver antwortet. Umgekehrt kann ein Server erreichbar sein, während eine falsch gesetzte DNS-Zone Besucher an ein falsches Ziel führt.

Die wichtigsten Prüfungen im Überblick

Die Grafik zeigt, warum ein einzelner Browseraufruf nicht alle Fehlerquellen abdeckt. Leserinnen und Leser erkennen, an welcher Stelle DNS, Netzwerk, TLS oder HTTP separat geprüft werden sollten.

Für einen zuverlässigen Test empfiehlt sich eine Kombination aus manueller Prüfung, Befehlszeilen-Tools und regelmäßiger Überwachung. Die folgende Reihenfolge spart Zeit, weil sie die wahrscheinlichsten Ursachen von unten nach oben überprüft.

Prüfebene	Leitfrage	Geeignete Prüfung
DNS	Wird der richtige Hostname aufgelöst?	dig, nslookup oder ein DNS-Prüfdienst
Netzwerk	Ist das Ziel grundsätzlich erreichbar?	ping mit Einschränkungen, traceroute beziehungsweise tracert
Port	Ist der benötigte Dienst erreichbar?	TCP-Prüfung auf Port 80 oder 443
TLS	Ist HTTPS gültig und passend konfiguriert?	Browser, TLS-Prüfer oder openssl
HTTP	Liefert der Webserver die erwartete Antwort?	curl -I, Browser-Entwicklertools oder Monitoring
Anwendung	Funktionieren wichtige Inhalte und Prozesse?	Definierte Inhaltsprüfung oder synthetischer Test

Je nach Ziel ist nicht jede Prüfung gleich wichtig. Für eine reine Informationsseite genügt häufig ein HTTP- und TLS-Test. Bei einem Shop, einer Anmeldung oder einer API sollten zusätzlich Statuscodes, Antwortinhalte und zentrale Abläufe geprüft werden.

Domain-Erreichbarkeit zuverlässig testen: Schritt für Schritt

1. Den Domainnamen und die Varianten festlegen

Bevor Sie testen, notieren Sie alle relevanten Varianten. Dazu können die Hauptdomain ohne Subdomain, die www-Variante, wichtige Subdomains und gegebenenfalls eine API-Adresse gehören. Prüfen Sie außerdem, ob HTTP auf HTTPS weiterleiten soll und ob sowohl IPv4 als auch IPv6 vorgesehen sind.

Ein häufiger Fehler ist, nur die sichtbare Startseite zu testen. Eine Weiterleitung kann zwar funktionieren, während eine Subdomain, ein Login-Endpunkt oder eine statische Datei nicht erreichbar ist. Legen Sie deshalb fest, welche Adressen für Besucher und interne Systeme tatsächlich wichtig sind.

2. DNS-Auflösung kontrollieren

Bei einer DNS-Prüfung wird festgestellt, welche IP-Adressen zu einem Hostnamen geliefert werden. Für eine Website sind meist A-Einträge für IPv4 und AAAA-Einträge für IPv6 relevant. Zusätzlich können CNAME-Einträge, Nameserver und DNSSEC eine Rolle spielen.

Mit dig lässt sich eine erste Prüfung durchführen:

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

Unter Windows steht häufig nslookup zur Verfügung:

nslookup beispiel.de
nslookup -type=AAAA beispiel.de

Achten Sie auf folgende Punkte:

• Wird überhaupt eine Adresse zurückgegeben?
• Zeigen alle erwarteten Hostnamen auf das richtige Ziel?
• Existiert ein AAAA-Eintrag, obwohl der Server über IPv6 nicht erreichbar ist?
• Gibt es widersprüchliche Antworten bei unterschiedlichen DNS-Resolvern?
• Ist die Gültigkeitsdauer, also die TTL, nach einer Änderung berücksichtigt?

Nach einer DNS-Änderung sehen nicht alle Resolver sofort dieselben Werte. Das ist kein Beweis für eine Störung, kann aber während einer Umstellung zu unterschiedlichen Ergebnissen führen. Prüfen Sie daher mehrere Resolver und berücksichtigen Sie die bisherige TTL.

3. IPv4 und IPv6 getrennt prüfen

Ein besonders schwer erkennbares Problem entsteht, wenn IPv4 funktioniert, IPv6 aber auf einen nicht erreichbaren Server zeigt. Einige Netzwerke bevorzugen IPv6. Dort kann der Seitenaufruf langsam werden oder vollständig scheitern, obwohl ein Test aus einem reinen IPv4-Netz erfolgreich war.

Testen Sie beide Protokolle getrennt, beispielsweise mit:

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

Wenn die IPv6-Prüfung fehlschlägt, sollten Sie klären, ob IPv6 bewusst unterstützt werden soll. Falls ja, müssen Routing, Firewall, Webserver und TLS-Konfiguration für IPv6 vollständig eingerichtet sein. Falls nein, kann ein nicht benötigter AAAA-Eintrag die Ursache sein. Änderungen an DNS-Einträgen sollten nur vorgenommen werden, wenn Sie die Auswirkungen auf die gesamte Infrastruktur geprüft haben.

4. Netzwerk und Ports untersuchen

Ein Ping kann Hinweise geben, ist aber kein vollständiger Verfügbarkeitsnachweis. Viele Server oder Firewalls blockieren ICMP-Anfragen, während HTTP weiterhin funktioniert. Ein fehlender Ping bedeutet daher nicht automatisch, dass die Website offline ist.

Für Webadressen sind vor allem TCP-Port 80 für HTTP und TCP-Port 443 für HTTPS relevant. Eine Portprüfung kann zeigen, ob überhaupt eine Verbindung zum vorgesehenen Dienst möglich ist. Beachten Sie dabei, dass eine offene Verbindung noch keine gültige Website-Antwort garantiert.

traceroute unter Linux und macOS beziehungsweise tracert unter Windows können den Weg zum Ziel sichtbar machen. Zeitüberschreitungen an einzelnen Zwischenstationen sind jedoch nicht zwingend ein Fehler: Manche Router beantworten solche Diagnosepakete nicht, leiten den normalen Datenverkehr aber weiter.

5. TLS-Zertifikat und HTTPS prüfen

Bei HTTPS muss der Server ein Zertifikat präsentieren, das zum aufgerufenen Hostnamen passt. Zusätzlich müssen Gültigkeitszeitraum, Zertifikatskette und unterstützte Verschlüsselungsverfahren mit dem verwendeten Browser oder Client kompatibel sein.

Prüfen Sie insbesondere:

• Ist das Zertifikat noch gültig?
• Deckt es alle benötigten Namen ab, etwa die Hauptdomain und www?
• Wird die vollständige Zertifikatskette ausgeliefert?
• Wird HTTPS ohne Endlosschleife oder unerwartete Umleitung erreicht?
• Verwendet die Website gemischte Inhalte, also unsichere Ressourcen innerhalb einer HTTPS-Seite?

Ein Browser zeigt Zertifikatsfehler meist direkt an. Für automatisierte Systeme ist ein passender TLS-Test sinnvoll, weil Anwendungen Zertifikate anders bewerten können als ein Browser. Bei einer Zertifikatserneuerung sollten Sie nicht nur die Startseite, sondern auch wichtige Subdomains und die Erreichbarkeit aus mehreren Netzen prüfen.

6. HTTP-Status und Weiterleitungen prüfen

Mit curl lässt sich der HTTP-Header einer Adresse abrufen:

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

Die Option -L folgt Weiterleitungen. So sehen Sie, ob die Anfrage direkt eine erfolgreiche Antwort erhält oder mehrere Stationen durchläuft. Eine einzelne Weiterleitung von HTTP zu HTTPS ist oft beabsichtigt. Viele aufeinanderfolgende Weiterleitungen, eine Schleife oder ein Wechsel zwischen verschiedenen Hostnamen deuten dagegen auf eine fehlerhafte Konfiguration hin.

Die Statuscodes liefern wichtige Hinweise:

• 2xx: Die Anfrage wurde erfolgreich verarbeitet.
• 3xx: Eine Weiterleitung oder eine andere Umleitung ist aktiv.
• 4xx: Die Anfrage wird aus Sicht des Servers oder der Zugriffsregeln abgelehnt.
• 5xx: Der Server kann die Anfrage nicht ordnungsgemäß verarbeiten.

Ein Statuscode allein beschreibt noch nicht die Qualität der Seite. Eine Fehlerseite mit Status 200 kann beispielsweise in Monitoring-Systemen als erreichbar erscheinen, obwohl der eigentliche Inhalt fehlt. Deshalb sollte bei kritischen Seiten zusätzlich nach einem erwarteten Text, einem bestimmten HTML-Element oder einem eindeutigen Inhaltssignal gesucht werden.

Von mehreren Standorten aus testen

Ein Test vom eigenen Rechner zeigt nur, was aus Ihrem Netzwerk sichtbar ist. Lokale DNS-Caches, Unternehmens-Firewalls, VPNs, Content-Delivery-Netzwerke und regionale Routing-Probleme können das Ergebnis beeinflussen. Für eine belastbare Einschätzung sollten Sie die Domain aus verschiedenen Netzen oder Regionen prüfen.

Geeignet sind beispielsweise:

• ein Mobilfunknetz und ein Festnetzanschluss,
• ein unabhängiger DNS-Resolver,
• ein Server in einer anderen Region,
• ein externes Monitoring mit mehreren Prüfstandorten.

Vergleichen Sie bei Abweichungen nicht nur „erreichbar“ oder „nicht erreichbar“, sondern auch DNS-Antworten, IPv4- und IPv6-Ergebnisse, TLS-Meldungen, Statuscodes und Antwortzeiten. Eine Störung an einem einzelnen Standort kann auf Routing, Geoblocking, eine regionale Firewall-Regel oder eine fehlerhafte CDN-Konfiguration hindeuten.

Monitoring sinnvoll einrichten

Ein einmaliger Test ist eine Momentaufnahme. Für wichtige Domains ist ein regelmäßiger Monitor sinnvoll, der bei einer Abweichung benachrichtigt. Die Prüfhäufigkeit sollte zum Geschäftsrisiko passen. Eine einfache Informationsseite benötigt meist weniger engmaschige Kontrolle als ein zentraler Login- oder Bestellprozess.

Ein gutes Monitoring unterscheidet mehrere Testarten:

• Uptime-Check: Prüft, ob die URL erreichbar ist und einen erwarteten Statuscode liefert.
• Inhaltsprüfung: Sucht nach einem stabilen Text oder Merkmal im Antwortinhalt.
• Port-Check: Prüft, ob der relevante TCP-Dienst erreichbar ist.
• TLS-Überwachung: Meldet Probleme mit Zertifikat und Gültigkeit.
• DNS-Überwachung: Erkennt unerwartete Änderungen an wichtigen DNS-Einträgen.
• Transaktionstest: Simuliert einen wichtigen Ablauf, etwa das Öffnen einer Anmeldeseite.

Konfigurieren Sie Benachrichtigungen mit Bedacht. Ein einzelner fehlgeschlagener Check kann durch eine kurzfristige Netzwerkstörung verursacht werden. Sinnvoll sind Wiederholungen, eine Bestätigung von einem zweiten Standort und eine klare Eskalationsregel. Gleichzeitig darf die Verzögerung nicht so lang sein, dass eine echte Störung erst deutlich später bemerkt wird.

Typische Fehlerbilder richtig einordnen

DNS-Fehler

Antworten wie „Name nicht gefunden“ weisen meist auf einen fehlenden oder fehlerhaften DNS-Eintrag hin. Prüfen Sie Zone, Nameserver-Delegation und den Hostnamen. Nach Änderungen müssen Sie außerdem Cache- und TTL-Effekte berücksichtigen.

Zeitüberschreitung

Eine Zeitüberschreitung kann durch Firewall-Regeln, Routing-Probleme, einen überlasteten Server oder einen nicht erreichbaren IPv6-Pfad entstehen. Vergleichen Sie verschiedene Netzwerke und testen Sie die Protokolle getrennt, bevor Sie die Ursache einem bestimmten System zuordnen.

Verbindung abgelehnt

Wird die Verbindung aktiv abgelehnt, läuft am Ziel möglicherweise kein Dienst auf dem erwarteten Port. Auch eine Firewall kann Verbindungen gezielt zurückweisen. Prüfen Sie Webserver, Reverse Proxy, Container, Load-Balancer und Sicherheitsregeln in ihrer tatsächlichen Reihenfolge.

TLS-Warnung

Eine TLS-Warnung deutet häufig auf einen falschen Hostnamen, ein abgelaufenes Zertifikat, eine unvollständige Zertifikatskette oder eine fehlerhafte Serverzeit hin. Bei mehreren Frontends muss jedes Frontend die richtige Konfiguration ausliefern.

HTTP-Fehler 4xx oder 5xx

Bei 4xx-Fehlern sind oft Zugriffsregeln, Authentifizierung, WAF-Regeln oder falsche Pfade beteiligt. 5xx-Fehler weisen eher auf Webserver, Anwendung, Datenbank, Proxy oder Ressourcenengpässe hin. Die Server- und Anwendungsprotokolle liefern in der Regel mehr Hinweise als ein erneuter Browseraufruf.

Praktische Checkliste für die Fehlersuche

1. Definieren Sie die zu prüfenden Domains, Subdomains und wichtigen URLs.
2. Prüfen Sie A-, AAAA- und gegebenenfalls CNAME-Einträge.
3. Vergleichen Sie die DNS-Antworten aus mindestens zwei Netzwerken.
4. Testen Sie IPv4 und IPv6 getrennt.
5. Prüfen Sie die Erreichbarkeit der benötigten Ports.
6. Kontrollieren Sie TLS-Zertifikat, Hostnamen und Zertifikatskette.
7. Rufen Sie die URL ohne und mit Weiterleitungsfolge ab.
8. Bewerten Sie Statuscode, Antwortinhalt und Antwortzeit gemeinsam.
9. Vergleichen Sie regionale oder netzwerkabhängige Unterschiede.
10. Dokumentieren Sie Zeitpunkt, Teststandort, Zieladresse und Ergebnis.

Eine solche Dokumentation erleichtert die Zusammenarbeit mit Hosting-Anbietern, DNS-Verwaltern und Netzwerkadministratoren. Notieren Sie außerdem, wann Änderungen an DNS, Zertifikaten, Firewalls, CDN oder Webserver vorgenommen wurden. So lassen sich zeitliche Zusammenhänge besser erkennen.

FAQ

Reicht ein Aufruf der Domain im Browser aus?

Nein. Ein Browsertest ist hilfreich, prüft aber vor allem Ihren aktuellen Standort und verarbeitet viele Dinge automatisch. DNS, IPv6, Weiterleitungen, TLS, Statuscode und Antwortinhalt sollten bei einer systematischen Prüfung separat betrachtet werden.

Ist ein erfolgreicher Ping ein Beweis für eine erreichbare Website?

Nein. Ping prüft in der Regel ICMP und nicht den Webdienst. Ein Server kann auf Ping antworten, während Port 443 oder der Webserver fehlerhaft ist. Umgekehrt kann Ping blockiert sein, obwohl HTTPS ordnungsgemäß funktioniert.

Warum funktioniert eine Domain über IPv4, aber nicht über IPv6?

Häufig ist ein AAAA-Eintrag vorhanden, obwohl Routing, Firewall oder Webserver für IPv6 nicht vollständig eingerichtet sind. Prüfen Sie beide Protokolle getrennt und entfernen oder korrigieren Sie den AAAA-Eintrag nur nach einer bewussten technischen Entscheidung.

Wie erkenne ich eine fehlerhafte Weiterleitung?

Rufen Sie die URL mit einem Werkzeug wie curl -IL auf und verfolgen Sie alle Stationen. Achten Sie auf Schleifen, unnötig viele Sprünge, wechselnde Hostnamen und einen fehlenden finalen Erfolgsstatus.

Wie oft sollte eine Domain geprüft werden?

Das hängt von der Bedeutung der Domain ab. Für kritische Dienste sind regelmäßige Checks aus mehreren Standorten sinnvoll. Bei weniger wichtigen Seiten genügt möglicherweise eine geringere Häufigkeit. Entscheidend ist, dass die Prüfung zu den erwarteten Ausfallkosten und zur Reaktionszeit Ihres Teams passt.

Was sollte ein Uptime-Monitor zusätzlich prüfen?

Mindestens Statuscode, TLS-Gültigkeit und eine stabile Inhaltsprüfung. Für wichtige Prozesse kommen DNS-Überwachung, IPv4- und IPv6-Checks sowie synthetische Tests hinzu, die einen zentralen Ablauf aus Nutzersicht nachbilden.

Kann ein CDN die Domain-Erreichbarkeit beeinflussen?

Ja. Ein CDN kann DNS, TLS, Routing, Caching und Sicherheitsregeln übernehmen. Ein Problem kann deshalb am Ursprungsserver oder an der CDN-Konfiguration liegen. Vergleichen Sie die Ergebnisse verschiedener Standorte und prüfen Sie, ob die Anfrage das erwartete Frontend erreicht.

Fazit

Wer die Domain-Erreichbarkeit zuverlässig testen möchte, sollte sich nicht auf einen Browseraufruf oder einen einzelnen Uptime-Wert verlassen. Eine belastbare Prüfung verbindet DNS-Kontrolle, getrennte IPv4- und IPv6-Tests, Port- und TLS-Prüfungen, HTTP-Status sowie eine einfache Inhaltskontrolle.

Für dauerhaft wichtige Domains empfiehlt sich ein Monitoring aus mehreren Standorten mit klaren Benachrichtigungs- und Eskalationsregeln. Wenn Sie Ergebnisse dokumentieren und technische Änderungen zeitlich zuordnen, können Sie Fehler schneller eingrenzen und unterscheiden, ob DNS, Netzwerk, Webserver, Sicherheitsregeln oder die Anwendung selbst betroffen sind.