Wenn eine Website ausfällt, rät man zuerst an der Ursache herum. Server neu starten. Das Release zurückrollen. Den Hoster anrufen. Manchmal hilft das. Öfter kostet es die ersten zwanzig Minuten.

Besser ist es, zunächst genau zu benennen, was Sie sehen. Das Symptom grenzt die Ursache auf eine oder zwei Ebenen ein, und jede Ebene hat ihre eigene erste Prüfung. Um diese Idee ist die Anleitung aufgebaut. Zur Definition von Ausfallzeit und ihren Folgen siehe Website-Ausfallzeit.

Ist die Website für alle nicht erreichbar?

Bevor Sie etwas ändern, klären Sie, wer betroffen ist.

  • Öffnen Sie die Website auf einem Smartphone mit mobilen Daten, nicht in Ihrem Büronetz.
  • Sehen Sie nach, was Ihr Monitoring aufgezeichnet hat: wann der erste Fehler auftrat und was der Grund war.
  • Bitten Sie eine Kollegin oder einen Kollegen an einem anderen Ort, es zu versuchen.
  • Prüfen Sie, ob nur eine Seite, ein Land oder ein Gerätetyp ausfällt.

Sehen nur Sie das Problem, liegt die Ursache wahrscheinlich bei Ihnen vor Ort: Ihr Netzwerk, eine zwischengespeicherte DNS-Antwort, ein VPN oder eine Browser-Erweiterung. Sehen es alle, lesen Sie weiter.

Vom Symptom zur ersten Prüfung

Was Sie sehen Wahrscheinliche Ebene Erste Prüfung
Die Seite lädt nie und läuft dann in eine Zeitüberschreitung Server, Netzwerk oder Firewall Können Sie die Adresse des Servers überhaupt erreichen? Läuft die Maschine?
„Verbindung abgelehnt“ Auf dem Port lauscht nichts Läuft der Webserver-Prozess, und auf dem erwarteten Port?
„Server nicht gefunden“ DNS oder die Domain Wird der Name aufgelöst? Ist die Domain abgelaufen?
Zertifikatswarnung über die ganze Seite TLS-Zertifikat Ist das Zertifikat abgelaufen oder für einen anderen Namen ausgestellt?
500 Internal Server Error Die Anwendung Anwendungslog zum Zeitpunkt der Anfrage
502 Bad Gateway Ein Proxy kann den Server dahinter nicht nutzen Läuft der Anwendungsserver und liefert er gültige Antworten?
503 Service Unavailable Überlast oder Wartung Läuft gerade ein Deployment oder ein Wartungsfenster? Ist die Kapazität erschöpft?
504 Gateway Timeout Ein Proxy hat zu lange auf den Server dahinter gewartet Ist die Anwendung langsam oder hängt sie?
200 OK, aber die Seite ist defekt Anwendungslogik oder eine Abhängigkeit Der Teil der Seite, der fehlschlägt, und der Dienst dahinter

RFC 9110 definiert die drei Gateway-Codes. Ein 502 bedeutet, dass ein Gateway oder Proxy vom Server dahinter eine ungültige Antwort erhalten hat. Ein 503 bedeutet, dass der Server die Anfrage gerade nicht bearbeiten kann, meist wegen Überlast oder Wartung, und er kann einen Retry-After-Header mitsenden. Ein 504 bedeutet, dass das Gateway nicht rechtzeitig eine Antwort bekam. In allen drei Fällen ist die Vordertür offen, und das Problem sitzt weiter drinnen.

Befehle für den ersten Blick

Von jedem Rechner mit Terminal aus:

curl -I https://example.com/

Das gibt die Statuszeile und die Header ohne den Inhalt aus. Für mehr Details, einschließlich DNS-Abfrage, Verbindungsaufbau und Zertifikatsschritt, ergänzen Sie -v:

curl -v https://example.com/ -o /dev/null

Wo die Ausgabe abbricht, zeigt, wo der Fehler liegt. Bricht sie vor „Connected“ ab, liegt das Problem beim Namen oder im Netzwerk. Bricht sie beim Zertifikatsschritt ab, sehen Sie sich das Zertifikat an. Erhalten Sie eine Statuszeile, hat der Server geantwortet, und der Status verrät den nächsten Schritt.

Server und Hosting

Die Maschine kann ausgeschaltet sein, keinen Arbeitsspeicher oder keinen Speicherplatz mehr haben oder überlastet sein. Eine volle Festplatte ist tückisch: Datenbanken schreiben nicht mehr, Logs laufen voll, und die Anwendung fällt auf merkwürdige Weise aus.

Prüfen Sie zuerst die Statusseite des Hosters, dann die Maschine selbst: laufende Prozesse, Arbeitsspeicher, Speicherplatz und Last. Ein Vorfall beim Cloud-Anbieter kann genauso aussehen wie ein eigener Fehler, also sehen Sie auf dessen Statusseite nach, bevor Sie eine Stunde in Ihre Konfiguration stecken.

Anwendung und Deployments

Ein fehlgeschlagenes Release gehört zu den häufigsten Ursachen für einen Ausfall, der in einer bestimmten Minute beginnt. Hat der Fehler direkt nach einem Deployment angefangen, rollen Sie zuerst zurück und untersuchen danach.

Typische Anzeichen sind 500-Fehler, eine leere Seite oder eine Anwendung, die startet und sich dann beendet. Das Anwendungslog nennt im Moment des ersten Fehlers meist die Ausnahme. Häufige Ursachen sind eine neue, nicht installierte Abhängigkeit, ein fehlender Wert in der Umgebung und eine Datenbankänderung, die der Code nicht erwartet.

Proxys, Load Balancer und CDNs

Viele Websites stehen hinter einem Reverse-Proxy, einem Load Balancer oder einem Content Delivery Network. Funktioniert der Proxy, aber der Server dahinter nicht, sehen Besucher 502 oder 504, oft auf einer Seite im Design des Proxys. Dieses Design zeigt Ihnen, dass die vordere Ebene lebt und Sie dahinter suchen sollten.

Sehen Sie im Log des Proxys nach dem Upstream-Fehler. Ein Proxy-Timeout, der kürzer ist als die langsamste Anfrage der Anwendung, erzeugt 504-Fehler, obwohl die Anwendung gesund ist.

DNS und die Domain

Wird der Name nicht mehr aufgelöst, ist die Website unerreichbar, so gesund der Server auch ist. Ursachen sind ein gelöschter Eintrag, ein geänderter Nameserver, ein Ausfall beim Anbieter und eine abgelaufene Domain.

Folgen Sie So beheben Sie DNS-Auflösungsfehler, um die Ebene zu finden, und prüfen Sie die Registrierung mit So prüfen Sie, wann eine Domain abläuft.

Zertifikate

Ein abgelaufenes Zertifikat oder eines, das für einen anderen Namen ausgestellt wurde, lässt Browser eine Warnung über die ganze Seite anzeigen. Der Server läuft, aber Besucher kommen nicht durch. Prüfen Sie die Daten und die Namen im Zertifikat. Ursache und Vorbeugung behandelt So verhindern Sie das Ablaufen von SSL-Zertifikaten.

Überlast

Ein Besucheransturm, ein aufwendiger Hintergrundjob oder eine Suchmaschine, die zu schnell crawlt, kann die gesamte Kapazität aufbrauchen. Anzeichen sind zuerst langsame Seiten, dann 503- oder 504-Fehler, dann Zeitüberschreitungen. Oft erholt sich das System ohne Eingriff und fällt bei der nächsten Spitze wieder aus.

Sehen Sie sich den Lastverlauf in den Minuten vor dem ersten Fehler an. Sind die Antwortzeiten vor dem Ausfall stetig gestiegen, ist Überlast wahrscheinlich.

Dienste von Drittanbietern

Eine Seite kann laden, während eine Funktion ausfällt: Zahlung, Login, Suche oder eine Karte. Der Dienst dahinter ist ausgefallen oder langsam. Von außen sieht die Website erreichbar aus. Lesen Sie den Fehler, den die Anwendung zum fehlgeschlagenen Aufruf protokolliert, und sehen Sie auf der Statusseite des Anbieters nach.

Was ein Monitor Ihnen sagen kann

Eine Prüfung von außen, wie die von UptimeWire, ruft die Adresse ab und liest die Antwort. Bei einer fehlgeschlagenen Prüfung zeichnet sie einen Grund auf. Zu den Gründen, die sie unterscheidet, gehören:

  • der Domainname konnte nicht aufgelöst werden,
  • die Verbindung ist fehlgeschlagen,
  • keine Antwort innerhalb von 15 Sekunden,
  • das TLS-Zertifikat oder die TLS-Verbindung ist ungültig,
  • der Server hat mit einem bestimmten Statuscode geantwortet,
  • der erwartete Text wurde auf der Seite nicht gefunden.

Dieser Grund führt Sie zur richtigen Zeile in der Tabelle oben, bevor Sie einen Server öffnen. UptimeWire eröffnet nach drei fehlgeschlagenen Prüfungen in Folge im Abstand von etwa 20 Sekunden einen Vorfall und hält den Grund dort fest. Die Einrichtung beschreibt So überwachen Sie die Verfügbarkeit einer Website.

Eine Prüfung, die einen Statuscode liest, erkennt nicht, wenn ein Login jedes Passwort ablehnt. Zum umgekehrten Problem siehe auch warum Monitore Fehlalarme senden.

Nach der Wiederherstellung

Sobald die Website wieder antwortet, halten Sie fest:

  • den Zeitpunkt des ersten Fehlers und den der Wiederherstellung,
  • das Symptom und die Ursache,
  • was den Fehler behoben hat,
  • was Sie früher hätte aufmerksam werden lassen.

Diese vier Zeilen genügen, um aus einem Ausfall etwas zu machen, das die nächste Person nutzen kann.

Checkliste

  • Beschreiben Sie das Symptom in einem Satz.
  • Prüfen Sie, ob alle betroffen sind.
  • Lesen Sie den aufgezeichneten Fehlergrund.
  • Führen Sie curl -v aus und sehen Sie, wo es abbricht.
  • Prüfen Sie das letzte Deployment oder die letzte Änderung.
  • Prüfen Sie DNS, Domain und Zertifikat, die ausfallen, ohne dass Sie etwas geändert haben.
  • Halten Sie Ursache und Lösung schriftlich fest.