Website-Überwachung nach Fehlertyp: DNS, TCP, TLS und HTTP

Wenn eine Website ausfällt, fühlt sich die Ursache oft wie eine Blackbox an. Besucher sehen ein drehendes Lade-Symbol, einen kryptischen Fehlercode oder eine leere Seite. Für die Leute, die verantwortlich sind, die Seite online zu halten, ist die erste Frage immer dieselbe: was ist kaputt?

Die Wahrheit ist, dass es nicht den einen Weg gibt, wie eine Website „ausfällt“. Stattdessen durchläuft eine Anfrage aus dem Browser mehrere Schritte — DNS-Auflösung, TCP-Verbindung, TLS-Aushandlung und HTTP-Antwort. Jeder Schritt hängt von den vorherigen ab. Und in jedem Schritt können unterschiedliche Dinge schiefgehen.

Deshalb sagt intelligentes Verfügbarkeits-Monitoring nicht nur, dass die Site „down“ ist. Es sagt Ihnen, wo in der Kette der Fehler aufgetreten ist. DNS-Fehler deuten auf das eine hin. TCP-Fehler auf etwas anderes. TLS/SSL-Fehler zeigen eine andere Ursache als HTTP-5xx. Wenn Sie wissen, welche Schicht ausgefallen ist, wissen Sie, welches Team oder welcher Anbieter kontaktiert werden muss — und können die Behebungszeit dramatisch verkürzen.

Dieser Artikel führt durch die einzelnen Fehlertypen in der Reihenfolge, in der ein Browser eine Seite tatsächlich lädt: DNS, TCP, TLS und HTTP. Für jeden Abschnitt erklären wir, was der Schritt macht, was schiefgehen kann und wie Monitoring Probleme entdecken kann, bevor es Ihre Kunden tun.

DNS-Fehler

DNS ist der Ort, an dem jede Web-Anfrage beginnt. Wenn ein Nutzer Ihre Domain in einen Browser eingibt, passiert zunächst eine Abfrage, um die Domain in eine IP-Adresse aufzulösen. Scheitert dieser Schritt, ist nichts anderes von Bedeutung — es kann keine Verbindung aufgebaut, kein Zertifikat geprüft und keine HTTP-Antwort empfangen werden. Deshalb sind DNS-Fehler oft die frühesten und kritischsten Signale eines Ausfalls.

Häufige DNS-Fehler

Unten sind einige gängige DNS-Ausfälle aufgeführt:

• NXDOMAIN — Das bedeutet, dass der Domainname schlichtweg nicht existiert. In der Praxis resultiert das meist aus abgelaufenen Registrierungen, falsch konfigurierten Zonen oder Tippfehlern in Einträgen. Eine abgelaufene Domain kann Ihre gesamte Site sofort vom Netz nehmen, während ein falsch eingetragener Record nur ein einzelnes Subdomain oder einen Dienst beeinträchtigen kann.
• SERVFAIL — Ein Serverfehler, der anzeigt, dass der autoritative DNS-Server die Anfrage nicht verarbeiten konnte. Häufige Ursachen sind fehlerhafte Zonendateien, fehlende Glue-Records oder Probleme bei der DNSSEC-Validierung. SERVFAILs treten oft plötzlich nach Konfigurationsänderungen auf und sind daher ein nützliches Frühwarnsignal für misslungene Deployments.
• Timeouts — Wenn innerhalb der erwarteten Zeit keine Antwort zurückkommt, gibt der Client schließlich auf. Timeouts werden oft durch überlastete Nameserver, Netzunterbrechungen oder DDoS-Angriffe verursacht, die den Resolver saturieren. Da DNS-Abfragen vor dem Cache erfolgen, können schon kleine Latenzspitzen hier zu langsameren Ladezeiten für Ihre gesamte Nutzerbasis führen.

Wie man DNS überwacht

Die Überwachung der DNS-Gesundheit geht über die einmalige Prüfung, ob Ihre Domain aufgelöst wird, hinaus. Es erfordert das Testen der Auflösungspfade so, wie echte Nutzer sie erleben:

• Globale Checks: Synthetische Monitoring-Agenten sollten DNS-Abfragen aus mehreren Regionen und Netzen ausführen. Ein Eintrag kann in Ihrem Büro sauber aufgelöst werden, aber in Asien oder Südamerika fehlschlagen, etwa wegen Anycast-Routingproblemen oder regionalen Ausfällen beim Provider.
• TTL-Bewusstsein: Jeder Record hat einen Time-to-Live (TTL), der das Caching steuert. Lange TTLs beschleunigen normales Browsing, können aber die Propagation nach Änderungen verzögern. Monitoring sollte validieren, dass neue Werte in Live-Abfragen tatsächlich sichtbar sind und kein veralteter Cache bestehen bleibt.
• Alarmierung bei Anomalien: Die handlungsfähigsten Signale kommen aus Trends. Ein plötzlicher Anstieg von NXDOMAIN- oder SERVFAIL-Antworten oder ein Spike in der Auflösungslatenz ist oft der erste Hinweis darauf, dass etwas nicht stimmt — noch bevor Kunden zu klagen beginnen.

Wenn die DNS-Überwachung ausfällt, gibt das auch Sicherheit darüber, was nicht das Problem ist. Wenn Abfragen nicht aufgelöst werden, wurden TCP-, TLS- und HTTP-Checks gar nicht erst versucht. Das grenzt das Triage-Feld schnell ein. In den meisten Fällen liegt die Lösung beim DNS-Hosting-Provider, Registrar oder dem Verantwortlichen für die Zonendatei. Reife Teams pflegen Beziehungen und Eskalationspfade zu diesen Anbietern, damit Probleme schnell gemeldet und behoben werden können.

TCP-Verbindungsfehler

Sobald DNS eine IP-Adresse geliefert hat, ist der nächste Schritt der TCP-Handshake. Das ist das digitale Äquivalent eines Händedrucks: Der Client sendet ein SYN, der Server antwortet mit SYN-ACK, und der Client bestätigt mit ACK. Erst nach diesem Austausch ist ein Kommunikationskanal etabliert.

Scheitert TCP, weiß der Browser, wo der Server sein sollte, kann aber nicht wirklich mit ihm sprechen. Das Ergebnis fühlt sich an wie ein schwarzes Loch — Seiten hängen, Sockets öffnen sich nicht und Nutzer sehen endlose Lade-Symbole. Anders als DNS-Fehler, die meist schnell und offensichtlich sind, erzeugen TCP-Fehler häufig verwirrende partielle Ausfälle, bei denen die Seite für einige Nutzer erreichbar ist, für andere jedoch nicht.

Häufige TCP-Fehler

• Connection refused — Der Client hat den Host erreicht, aber auf dem erwarteten Port lauscht nichts. Das passiert oft, wenn Dienste abstürzen, Container sterben oder Loadbalancer falsch konfiguriert sind. Ein Webserver, der vergessen hat, Port 443 zu binden, ist unsichtbar, selbst wenn die Maschine an sich in Ordnung ist.
• Connection timed out — Pakete werden irgendwo auf dem Pfad verworfen. Das kann ein still blockierendes Firewall-Regelwerk sein, eine fehlerhafte Routing-Konfiguration oder upstream-seitige Überlastung. Timeouts sind besonders frustrierend, weil sie kein Feedback geben — nur Stille, bis der Client aufgibt.
• Connection reset — Hier wird der Handshake zwar abgeschlossen, aber sofort wieder abgebrochen. Resets deuten meist auf überlastete Proxies, aggressive Idle-Timeouts oder Middleboxes (z. B. WAFs) hin, die Sitzungen als verdächtig einstufen und beenden.

Wie man TCP überwacht

Einfache Uptime-Checks reichen hier nicht aus. ICMP-Pings können erfolgreich sein, während TCP-Handshakes fehlschlagen und so ein falsches Gefühl der Gesundheit vermitteln. Richtiges TCP-Monitoring fokussiert auf das Verbindungsverhalten:

• Handshake-Validierung: Tools sollten explizit einen SYN/SYN-ACK/ACK-Austausch auf dem tatsächlichen Service-Port versuchen. Das stellt sicher, dass der Listener erreichbar ist und antwortet.
• Pfadanalyse: Traceroutes oder MTRs aus verschiedenen Regionen können offenbaren, wo Verbindungen stocken — innerhalb Ihres Rechenzentrums, an der CDN-Edge oder bei einem upstream-ISP.
• Protokoll-Parität: Wenn Sie sowohl IPv4 als auch IPv6 unterstützen, überwachen Sie beide. Viele reale Vorfälle betreffen nur eine Variante und erzeugen sichtbare Kundenprobleme, die unentdeckt bleiben, wenn nur die andere getestet wird.

TCP-Monitoring vermittelt die Gewissheit, dass Server nicht nur leben, sondern bereit sind, Traffic zu akzeptieren. Und es grenzt die Ursachen ein: Wenn TCP fehlschlägt, hat die DNS-Auflösung bereits funktioniert, also liegt das Problem beim Host oder im Netzwerkpfad. Diese Klarheit verhindert, dass Teams in der Anwendungsebene falschen Spuren nachjagen, wenn die eigentliche Ursache eine Firewall-Regel oder ein Loadbalancer-Pool ist, der stillschweigend seinen letzten gesunden Knoten verloren hat.

TLS/SSL-Fehler

Heutzutage laufen nahezu alle Sites über HTTPS (verglichen mit früheren Jahren, in denen SSL nicht so verbreitet war). Das bedeutet, dass nach dem TCP-Handshake der Browser und der Server eine TLS-(Transport Layer Security)-Sitzung aushandeln müssen. TLS erfüllt zwei Aufgaben gleichzeitig: Es verschlüsselt Daten im Transit und beweist mittels digitaler Zertifikate, dass der Server wirklich der ist, der er vorgibt zu sein.

Dieses Vertrauen bringt Komplexität mit sich. Wenn Zertifikate ablaufen, nicht zum Hostnamen passen oder nicht validiert werden können, sehen Nutzer Browser-Warnungen — oder die Seite weigert sich komplett zu laden. In der Praxis gehören TLS-Fehler zu den sichtbarsten und peinlichsten Vorfällen, weil sie Nutzer bereits an der Haustür mit einer Warnung stoppen, die nicht sicher umgangen werden kann.

Häufige TLS/SSL-Fehler:

• Abgelaufenes Zertifikat — Das Gültigkeitsfenster des Zertifikats ist abgelaufen. Dies ist einer der häufigsten Ausfälle, weil keine Automatisierung für die Erneuerung vorhanden ist oder die Erneuerung nicht überall propagiert wurde.
• Hostname-Mismatch — Das Zertifikat wurde für www.example.com ausgestellt, der Nutzer hat jedoch api.example.com besucht. Das tritt oft nach dem Hinzufügen neuer Subdomains oder beim Verschieben von Diensten hinter ein CDN auf.
• Nicht vertrauenswürdige Zertifizierungsstelle (CA) — Der Browser erkennt die ausstellende CA nicht, meist weil das Zertifikat selbstsigniert ist oder an eine private Root gekettet ist, die auf den Client-Geräten nicht installiert ist.
• Handshake-Fehler — Die kryptographische Aushandlung selbst schlägt fehl. Ursachen reichen von nicht unterstützten Cipher-Suites, veralteten Protokollversionen bis hin zu einer beschädigten Zertifikatskette.

Wie man TLS überwacht:

TLS-Monitoring muss proaktiv und kontinuierlich sein. Zertifikate versagen nicht schrittweise — sie funktionieren an einem Tag und blockieren den Zugriff am nächsten. Gutes Monitoring sollte:

• Die Zertifikatsgültigkeit verfolgen und Alarme weit vor Ablauf auslösen — idealerweise mit mehreren Schwellen (30 Tage, 7 Tage, 1 Tag).
• Die gesamte Zertifikatskette validieren aus mehreren Regionen, da fehlende Intermediates oder regionale CA-Probleme das Vertrauen an verschiedenen Orten unterschiedlich zerstören können.
• Protokoll- und Cipher-Support prüfen, um sicherzustellen, dass die Site kompatibel bleibt, während Browser ältere Versionen wie TLS 1.0 und 1.1 deprecaten.
• Auf Handshake-Error-Spikes achten, die oft mit Fehleinstellungen von Loadbalancern oder CDN-Rollouts zusammenfallen.

Wenn TLS-Fehler im Monitoring auftauchen, liefern sie auch Kontext: DNS-Auflösung hat funktioniert, TCP-Konnektivität war in Ordnung, aber der sichere Kanal konnte nicht aufgebaut werden. Das grenzt die Fehlersuche sofort ein. Die Behebung liegt meist im Bereich der Zertifikatserneuerung, Loadbalancer-Konfiguration oder Edge-Termination — nicht im Anwendungs-Code.

Für viele Teams ist die operative Lektion einfach: Behandle Zertifikate wie Code. Automatisiere Ausgabe und Erneuerung, überwache das Ablaufdatum mit derselben Strenge wie Festplattenplatz und probe Rotationenszenarien, damit ablaufende Zertifikate niemals zu ernsthaften öffentlichen Ausfällen werden.

HTTP-Fehler

Schließlich, nachdem DNS, TCP und TLS erfolgreich waren, sendet der Browser eine HTTP-Anfrage. Der Server antwortet mit einem HTTP-Statuscode — 200, wenn alles in Ordnung ist, oder einem Fehlercode, wenn nicht.

HTTP-Monitoring ist das, woran die meisten Menschen denken, wenn sie „Uptime-Monitoring“ hören. Ohne Kontext aus den vorherigen Schritten erzählen HTTP-Fehler jedoch nur einen Teil der Geschichte.

Häufige HTTP-Fehler:

• 404 Not Found – Die Ressource existiert nicht. Das kann ein defekter Link, eine gelöschte Seite oder eine fehlgelenkte Anfrage sein.
• 500 Internal Server Error – Der Server stieß auf einen unerwarteten Zustand. Meist Fehler im Code oder in der Konfiguration.
• 502 Bad Gateway – Ein Proxy oder Loadbalancer konnte keine gültige Antwort von einem Upstream-Server erhalten.
• 503 Service Unavailable – Der Server ist überlastet oder befindet sich in Wartung.
• 504 Gateway Timeout – Ein Upstream-Dienst hat zu lange für die Antwort gebraucht.

Wie man HTTP überwacht:

• Führen Sie synthetische GET-Anfragen von globalen Agenten aus, um Antworten zu verifizieren.
• Erfassen Sie Response-Codes und alarmieren Sie bei allem außerhalb des Bereichs 200–299.
• Überwachen Sie Transaktionsabläufe, nicht nur einzelne Seiten (Login, dann „In den Warenkorb“, dann Checkout).
• Setzen Sie Schwellenwerte für Antwortzeiten, nicht nur für Verfügbarkeit.

HTTP-Monitoring sagt Ihnen, dass die Anwendungsschicht defekt ist. Im Gegensatz zu DNS/TCP/TLS-Problemen liegen HTTP-Fehler meist in der Verantwortung von Entwicklungs- oder Ops-Teams, nicht bei externen Anbietern.

Alles zusammenfügen: Eine geschichtete Strategie für Fehler-Monitoring

Der Wert, Fehler nach Typ zu gliedern, ist Klarheit. Jeder Ausfall passiert in einer Reihenfolge. Wenn DNS ausfällt, passiert nichts Weiteres. Wenn TCP ausfällt, war DNS in Ordnung. Wenn TLS ausfällt, funktionierten DNS und TCP. Wenn HTTP ausfällt, haben alle vorherigen Schritte funktioniert.

Ein schichtweiser Monitoring-Ansatz spiegelt genau diese Reihenfolge wider:

1. Beginnen Sie mit DNS-Prüfungen.
2. Fügen Sie TCP-Verbindungsüberwachung hinzu.
3. Überlagern Sie TLS-Zertifikatsüberwachung.
4. Schließen Sie mit HTTP-Antwortüberwachung ab.

Dieses Schichtmodell ermöglicht es, die Ursache schnell zu lokalisieren:

• DNS-Fehler? Rufen Sie Ihren DNS-Provider an.
• TCP-Fehler? Binden Sie Ihren Hosting-Provider oder ISP ein.
• TLS-Fehler? Beheben Sie Ihr Zertifikat oder die Edge-Konfiguration.
• HTTP-Fehler? Sprechen Sie mit Ihrem Web-Team.

Statt einer vagen „Site ist down“-Alarmmeldung erhalten Sie eine präzise Karte dessen, was kaputt ist und wer es beheben sollte. Das reduziert die mittlere Zeit bis zur Behebung (MTTR) und verhindert Schuldzuweisungen zwischen den Teams.

Fazit

Websites fallen nicht auf nur eine Art aus — sie fallen in Schichten. DNS, TCP, TLS und HTTP bringen jeweils eigene Risiken und eigene Fehlersignaturen mit sich. Monitoring nach Fehlertyp verwandelt diese Komplexität in Klarheit.

Mit der richtigen Monitoring-Strategie (und einem Tool wie Dotcom-Monitor) wissen Sie nicht nur, dass die Site ausgefallen ist: Sie wissen, warum sie ausgefallen ist. Sie wissen, ob Sie an Ihren DNS-Host, den Netzbetreiber, das Sicherheitsteam oder die Entwickler eskalieren müssen. Und Sie erhalten diese Einsicht schnell, ohne auf ein Support-Ticket oder die Beschwerde eines Kunden warten zu müssen.

Am Ende geht es beim Monitoring nach Fehlertyp nicht nur um Verfügbarkeit. Es geht um Verantwortlichkeit und Tempo. Das nächste Mal, wenn Ihre Site ausfällt, geben Sie sich nicht mit „etwas ist kaputt“ zufrieden. Wissen Sie genau, welche Schicht ausgefallen ist, was das bedeutet und wie man es behebt.