Wenn eine Website down ist, klären Sie zuerst, ob sie für alle ausgefallen ist oder nur für Sie. Arbeiten Sie sich dann von außen nach innen vor: DNS, Verbindung, TLS-Zertifikat, CDN oder Proxy, Webserver und schließlich die Anwendung und ihre Abhängigkeiten. Die Fehlermeldung verrät meist, mit welcher Schicht Sie beginnen sollten, und zu jedem Schritt unten gibt es einen schnellen Test, der die Ursache bestätigt oder ausschließt.
Machen Sie sich dabei Notizen: was Sie geprüft haben, wann und was Sie gesehen haben. So lässt sich die Lösung schneller übergeben, und das Postmortem ist leichter geschrieben.
Schritt 1: Ist die Website für alle down oder nur für Sie?
Fügen Sie die Adresse in den Is it down?-Checker ein. Er ruft die Seite aus Stockholm in Schweden ab, folgt bis zu fünf Weiterleitungen und wertet alles unter HTTP 500 als erreichbar. Rufen Sie die Website dann auf Ihrem Smartphone mit ausgeschaltetem WLAN auf.
Funktioniert sie von außen, aber nicht bei Ihnen, liegt das Problem in Ihrer Nähe: ein VPN, ein Eintrag in der hosts-Datei, der DNS-Cache Ihres Routers, eine Browser-Erweiterung oder eine Firewall, die Ihre IP-Adresse nach zu vielen fehlgeschlagenen Anmeldungen gesperrt hat. Probieren Sie ein privates Fenster und ein anderes Netzwerk, bevor Sie den Server anfassen.
Lesen Sie die Fehlermeldung
Der genaue Fehler zeigt auf die Schicht, die versagt hat. Notieren Sie ihn, bevor Sie etwas ändern.
Was Sie sehenWahrscheinliche SchichtBeginnen beiDNS_PROBE_FINISHED_NXDOMAIN, „IP-Adresse des Servers wurde nicht gefunden“DNS oder DomainSchritt 2ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUTNetzwerk oder ServerSchritt 3„Dies ist keine sichere Verbindung“, NET::ERR_CERT_DATE_INVALIDTLS-ZertifikatSchritt 4Cloudflare 521, 522, 525 oder 526 oder eine CDN-FehlerseiteCDN zum UrsprungsserverSchritt 5500, 502, 503 oder 504Webserver oder AnwendungSchritt 6Eine Seite, die lädt, aber leer ist oder einen Fehler zeigtAnwendung oder AbhängigkeitSchritt 7
Schritt 2: DNS und Domain prüfen
Wenn der Name nicht aufgelöst wird, spielt alles andere keine Rolle. Fragen Sie das DNS, was es für Ihre Domain liefert, und vergleichen Sie es mit der Adresse Ihres Servers:
dig +short example.com A
dig +short www.example.com
dig +short example.com NS
Gar keine Antwort: Prüfen Sie mit dem Domain-Ablauf-Checker, ob die Domainregistrierung abgelaufen ist. Eine abgelaufene Domain verliert oft ihre Nameserver oder zeigt auf die Parkseite des Registrars.
Die falsche Adresse: Jemand hat einen Eintrag geändert, oder die Nameserver wurden zu einem Anbieter verlegt, der Ihre Einträge nicht hat. Vergleichen Sie die Antwort mit dem erwarteten Wert über das Tool DNS-Lookup.
Für manche richtig, für andere falsch: Eine kürzliche Änderung verbreitet sich noch. Resolver behalten die alte Antwort, bis ihre TTL abläuft. Das ist die DNS-Propagation.
Unser Leitfaden zu DNS_PROBE_FINISHED_NXDOMAIN geht die DNS-Ursachen einzeln durch.
Schritt 3: Ist der Server erreichbar?
Mit der richtigen Adresse testen Sie, ob der Server Verbindungen auf den Web-Ports annimmt:
nc -vz example.com 443
curl -sv -o /dev/null https://example.com/
Verbindung abgelehnt: Der Rechner antwortet, aber auf dem Port lauscht nichts. Der Webserver ist gestoppt oder abgestürzt. Starten Sie ihn und lesen Sie sein Log, um die Ursache zu finden.
Zeitüberschreitung: Die Pakete gehen ins Leere. Der Server ist aus, eine Firewall oder Security Group verwirft den Traffic, oder das Netzwerk dazwischen hat eine Störung. Sehen Sie sich die Statusseite und die Konsole Ihres Hosting-Anbieters an.
Verlassen Sie sich nicht allein auf ping. Viele Hosts blockieren ICMP. Ein Server kann also beim Ping durchfallen und die Website trotzdem einwandfrei ausliefern oder auf Ping antworten, während der Webserver down ist.
Schritt 4: Das TLS-Zertifikat prüfen
Ein Zertifikatsproblem legt die Website für alle gleichzeitig lahm, mit einer ganzseitigen Browserwarnung, obwohl der Server selbst einwandfrei läuft. Prüfen Sie den Host mit dem SSL-Checker oder über die Kommandozeile:
openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject
Typische Ursachen sind ein abgelaufenes Zertifikat nach einer fehlgeschlagenen automatischen Verlängerung, ein Zertifikat für einen anderen Namen oder ein fehlendes Zwischenzertifikat. SSL-Zertifikatsfehler erklärt ordnet jeder Browserwarnung die passende Lösung zu.
Schritt 5: CDN oder Proxy ausschließen
Sitzt ein CDN oder Reverse Proxy vor der Website, kann eine Fehlerseite vom Proxy stammen und nicht von Ihrem Server. Die 52x-Codes von Cloudflare sagen genau, wo es gehakt hat:
521: Der Ursprungsserver hat die Verbindung abgelehnt.
522: Die Verbindung zum Ursprungsserver ist in eine Zeitüberschreitung gelaufen.
525: Der TLS-Handshake mit dem Ursprungsserver ist fehlgeschlagen.
526: Das Zertifikat des Ursprungsservers ist nicht gültig.
Um den Ursprungsserver ohne CDN zu testen, schicken Sie die Anfrage direkt an seine IP-Adresse und behalten den Hostnamen bei. Ersetzen Sie 203.0.113.10 durch die Adresse Ihres Ursprungsservers:
curl -sv -o /dev/null –resolve example.com:443:203.0.113.10 https://example.com/
Antwortet der Ursprungsserver einwandfrei, liegt es am CDN: Prüfen Sie seine Statusseite, kürzlich geänderte Firewall-Regeln und ob es noch die richtige Adresse des Ursprungsservers kennt. Schlägt auch der Ursprungsserver fehl, machen Sie mit dem Server weiter.
Schritt 6: Webserver und Anwendung prüfen
Ein 5xx-Statuscode bedeutet, dass die Anfrage Ihren Stack erreicht hat und dort etwas fehlgeschlagen ist. Der Code grenzt es ein:
500: Die Anwendung hat einen Fehler ausgelöst. Siehe 500 Internal Server Error.
502: Der Webserver hat vom Anwendungsprozess dahinter keine gültige Antwort erhalten, oft weil dieser abgestürzt ist. Siehe 502 Bad Gateway.
503: Der Dienst ist überlastet oder im Wartungsmodus. Siehe 503 Service Unavailable.
504: Die Anwendung hat zu lange für die Antwort gebraucht. Siehe 504 Gateway Timeout.
Jeder Code hat eine eigene Seite in der HTTP-Statuscode-Referenz. Auf dem Server finden drei Prüfungen die meisten Ursachen:
df -h # eine volle Platte stoppt Datenbanken, Logs und Uploads
free -m # zu wenig Speicher beendet Prozesse
tail -n 50 /var/log/nginx/error.log # oder die Logs Ihres Webservers und Ihrer App
Fragen Sie dann, was sich geändert hat. Ein Deployment, ein Plugin-Update, eine Konfigurationsänderung oder ein abgelaufener API-Schlüssel in der letzten Stunde ist die wahrscheinlichste Ursache, und ein Rollback geht oft schneller als die Fehlersuche im laufenden Betrieb.
Schritt 7: Die Abhängigkeiten prüfen
Ihre Website kann gesund sein, während etwas, das sie braucht, ausfällt. Eine Datenbank ohne freie Verbindungen, ein gestoppter Cache-Server oder eine Störung beim Zahlungs-, E-Mail- oder Login-Anbieter legen Seiten lahm, die sonst laden würden. Prüfen Sie die Statusseiten Ihrer Anbieter und schlagen Sie die großen unter Is it down? nach. Dort verfolgen wir bekannte Dienste und ihre jüngsten Ausfälle.
Wenn die Website erreichbar, aber kaputt ist
Manche Fehler antworten mit 200: eine leere Produktliste, ein Checkout-Button ohne Funktion, eine Fehlermeldung mitten in einer normalen Seite. Ein Statuscode erkennt das nicht. Prüfen Sie, ob die Seite enthält, was sie enthalten soll, und gehen Sie den entscheidenden Ablauf, etwa Anmelden oder Bezahlen, so durch wie ein Kunde.
Während Sie es beheben: Informieren Sie die Betroffenen
Veröffentlichen Sie ein kurzes Update, sobald Sie von dem Problem wissen, auch wenn Sie nur sagen können, dass Sie es untersuchen, und nennen Sie den Zeitpunkt des nächsten Updates. Der Status-Update-Generator schreibt eines für jede Phase, und der Kommunikationsplan für Vorfälle regelt, wer was wo sagt.
Den nächsten Ausfall verkürzen
Am längsten dauert bei den meisten Ausfällen, überhaupt davon zu erfahren. Mit externem Monitoring hören Sie von dem Problem durch einen Alarm statt durch einen Kunden und beginnen mit Belegen statt mit Vermutungen. Das bietet Ihnen Uptimecheck:
Prüfungen jede Minute aus Stockholm, London und New York, wobei jeder Fehler von einem zweiten Standort bestätigt wird, bevor Sie alarmiert werden. Siehe Uptime-Monitoring.
Belege im Vorfall: die Adresse, zu der DNS aufgelöst hat, Weiterleitungen, das Zertifikat, Header und der Anfang der Antwort, dazu ein Screenshot, wenn der Server geantwortet hat, oder ein Traceroute, wenn nicht. Siehe So funktionieren Vorfälle und Belege.
Antwortzeiten in Phasen aufgeteilt: DNS, Verbindung, TLS, Server und Download, sodass eine langsame Schicht auffällt, bevor sie versagt.
Erinnerungen vor dem Ablauf von Zertifikaten und Domains sowie Alarme, wenn sich DNS-Einträge ändern.
Keyword-Prüfungen und Flows, die eine Seite erkennen, die mit 200 antwortet, aber kaputt ist. Siehe Flow-Monitoring.
Meldet ein Monitor einen Ausfall, obwohl die Website bei Ihnen funktioniert, erklärt Warum ein Monitor down ist, obwohl Ihre Website funktioniert, wie Sie den Unterschied deuten.
Erfahren Sie es vor Ihren Kunden. Testen Sie Uptimecheck 14 Tage kostenlos, ohne Kreditkarte.