Webseite nicht erreichbar? So testest du, ob sie für alle down ist oder nur für dich

Webseite nicht erreichbar? Ob sie für alle down ist oder nur für dich, findest du heraus, indem du sie aus einem fremden Netz aufrufst und die Antworten vergleichst. Lädt sie dort, läuft die Seite, und das Problem liegt irgendwo zwischen dir und ihr: dein DNS-Resolver, dein Provider, das VPN, das WLAN im Büro oder im Zug. Scheitert sie auch dort, ist sie sehr wahrscheinlich für alle weg. Spannender als Ja oder Nein ist aber, wo die Anfrage hängen bleibt, denn daran entscheidet sich, wer das Problem lösen muss.

Erst eine zweite Meinung holen

Am schnellsten geht das mit der kostenlosen Prüfung „Ist die Seite offline?“ hier auf der Website. Sie ruft die URL von unserem Server in Zürich ab: ein GET, nur die Header, höchstens fünf Weiterleitungen, nach 8 Sekunden ist Schluss. Ein Endstatus von 200 bis 399 gilt als „hat geantwortet“, eine 4xx oder 5xx als „hat nicht korrekt geantwortet“. Kommt gar keine HTTP-Antwort zurück, sagt sie dir, woran es lag: Der Hostname ließ sich nicht auflösen, die Verbindung wurde abgelehnt oder zurückgesetzt, die Anfrage lief in einen Timeout, oder der Host war nicht erreichbar. Diese Unterscheidung ist schon der halbe Befund.

Die zweite Meinung hast du in der Hosentasche: WLAN am Handy aus und die Seite über mobile Daten laden. Anderer Provider, anderer Resolver, andere Route. Hängst du im Firmen-VPN, schalte es für den Test ab. Dann liest du beide Ergebnisse zusammen:

Herausfinden, wo die Anfrage hängen bleibt

Ein Seitenaufruf sind vier Schritte nacheinander: Namen auflösen, TCP-Verbindung aufbauen, TLS aushandeln, HTTP-Antwort holen. Jeder scheitert auf seine eigene Art, und curl zeigt dir, welcher:

curl -sS -o /dev/null --connect-timeout 5 \
  -w 'dns %{time_namelookup}s  connect %{time_connect}s  tls %{time_appconnect}s  first byte %{time_starttransfer}s  code %{http_code}\n' \
  https://example.com

Die Zeiten zählen ab Beginn der Anfrage, tls minus connect ist also der Handshake. Scheitert ein Schritt, gibt curl einen Fehler mit Exit-Code aus. Der Wortlaut ändert sich je nach curl-Version, die Nummern nicht:

• (6) Could not resolve host: DNS. Beim Server ist noch gar nichts angekommen.
• (7) Failed to connect … Connection refused: Unter der IP antwortet etwas, aber auf dem Port lauscht nichts, oder eine Firewall weist dich aktiv ab.
• (28) Timeout: Pakete gehen raus, zurück kommt nichts. Eine Firewall verwirft sie, die Maschine ist aus, oder die Route ist kaputt.
• (60) oder (35): TLS. 60 heißt, das Zertifikat ließ sich nicht verifizieren, 35, dass schon der Handshake gescheitert ist.
• Ein 4xx- oder 5xx-Code ohne Fehler: Alles unterhalb von HTTP funktioniert. Der Server oder etwas davor hat mit einem Fehler geantwortet.

Der Name lässt sich nicht auflösen

Stell deinem eigenen Resolver und einem öffentlichen dieselbe Frage:

dig example.com              # header shows status: NOERROR, NXDOMAIN or SERVFAIL
dig @1.1.1.1 example.com     # same question, public resolver
dig +short example.com AAAA  # IPv6 address, if there is one

# Windows
nslookup example.com
nslookup example.com 1.1.1.1

NXDOMAIN von beiden heißt: Den Namen gibt es nicht. Ein Tippfehler, ein gelöschter Eintrag oder eine abgelaufene Domain. Dann ist die Seite wirklich für alle weg. SERVFAIL heißt, der Resolver hat keine gültige Antwort bekommen, und meistens ist DNSSEC kaputt. Nicht jeder Resolver validiert, deshalb kann es bei einem scheitern und beim anderen klappen. Liefern dein Resolver und 1.1.1.1 nach einer DNS-Umstellung unterschiedliche Adressen, hat deiner noch den alten Eintrag im Cache. Die Zahl hinter dem Namen in der Answer Section ist die verbleibende TTL in Sekunden.

dig fragt direkt einen DNS-Server und übergeht dabei die hosts-Datei und den Cache des Browsers. Bekommt dig die richtige Adresse und der Browser trotzdem nicht, such dort: eine vergessene Zeile in /etc/hosts (unter Windows C:\Windows\System32\drivers\etc\hosts) vom letzten Staging-Test oder ein veralteter Cache. Chrome hat einen eigenen, den leerst du unter chrome://net-internals/#dns. Den des Betriebssystems so:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

# Linux with systemd-resolved
resolvectl flush-caches

Verbindung abgelehnt oder Timeout

Abgelehnt ist die bessere Nachricht. Unter der IP hat etwas geantwortet und Nein gesagt, meist läuft der Webserver nicht oder lauscht nicht auf 443. Ein Timeout heißt, es hat überhaupt nichts geantwortet: Die Maschine ist aus, eine Firewall verwirft deine Pakete, oder irgendwo unterwegs ist die Route kaputt. Kommt Zürich durch und du läufst in den Timeout, tippe auf die Route oder auf eine Sperrliste auf dem Server, auf der deine IP gelandet ist. Probier außerdem beide IP-Versionen:

curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

Eine Seite mit AAAA-Eintrag und kaputtem IPv6-Weg antwortet mit -4 und hängt mit -6. Browser weichen meist schnell auf IPv4 aus, du merkst es also vielleicht nie. Andere Clients tun das nicht immer, und die Nutzer deiner API gehören dazu.

Das Zertifikat wird abgelehnt

Im Browser kommt eine ganzseitige Warnung, bei curl Exit-Code 60. Die drei Klassiker: Das Zertifikat ist abgelaufen, der Name passt nicht (www.example.com statt example.com), oder das Zwischenzertifikat fehlt. Letzteres ist tückisch, weil manche Browser es selbst nachladen oder schon im Cache haben. Im Browser geht die Seite dann, in curl, in Apps und bei anderen Servern, die sie aufrufen, nicht.

5xx: Der Server antwortet mit einem Fehler

Eine 500 kommt aus der Anwendung, eine 502 oder 504 von einem Proxy oder Load Balancer, der von dahinter keine brauchbare Antwort bekommen hat, eine 503 von etwas, das überlastet ist oder im Wartungsmodus steckt. Der Netzweg funktioniert, und die Seite ist für alle down, die auf diesem Server landen. Das sind aber nicht immer alle: Hinter einem Load Balancer wird aus einem kaputten Backend eine 502 bei jeder dritten Anfrage. Prüf also mehrmals, bevor du etwas schließt. Der Artikel zu HTTP-Statuscodes geht die Codes einzeln durch.

4xx und Geo-Sperren: online, nur nicht für dich

Eine 403 oder 451 heißt, der Server sagt einem bestimmten Client Nein. Bekommt dein Browser eine 403 und Zürich eine 200, liegt es an deiner IP: Exit-Knoten von VPNs und Cloud-Adressbereiche landen gern auf Sperrlisten, und manche Seiten außerhalb der EU sperren europäische Besucher einfach komplett aus. Das gibt es auch andersherum. Bot-Schutz weist oft Rechenzentrums-IPs und unbekannte User-Agents ab. Eine 403 von unserem Checker, während die Seite in deinem Browser lädt, heißt also: Die Seite läuft und filtert automatisierte Zugriffe. Unsere Anfragen geben sich als HyperMonitors/1.0 zu erkennen, und das gefällt einer strengen WAF-Regel nicht unbedingt.

CDN- und Edge-Probleme

Steht ein CDN vor der Seite, redest du mit zwei Servern: dem Edge-Standort in deiner Nähe und dem Origin dahinter. Wer geantwortet hat, steht in den Response-Headern. cf-ray heißt Cloudflare, x-cache und x-served-by tauchen bei vielen CDNs auf. Cloudflares eigene 52x-Codes bedeuten: Edge in Ordnung, Origin nicht. 521 heißt, der Origin lehnt die Verbindung ab, 522, er antwortet nicht rechtzeitig. Edge-Probleme sind oft regional, denn Besucher in Frankfurt und in Singapur landen an verschiedenen Edge-Standorten. Um das CDN aus der Gleichung zu nehmen, schickst du die Anfrage direkt an den Origin:

# 203.0.113.10 stands in for your origin's IP
curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/

--resolve legt den Hostnamen auf diese IP fest, SNI und Host-Header bleiben aber gleich, der Origin sieht also eine ganz normale Anfrage. Klappt das und die öffentliche URL nicht, liegt das Problem beim CDN. Viele Origins nehmen allerdings nur Verbindungen vom eigenen CDN an. Dann läuft das in den Timeout und sagt dir nichts. Und -D - -o /dev/null steht da mit Absicht: Aus Gewohnheit tippt man curl -I, das schickt aber ein HEAD, und manche Anwendungen beantworten HEAD anders als GET.

Es liegt an dir

Laden Zürich und dein Handy die Seite und dein Laptop nicht, liegt es lokal. Grob nach Häufigkeit: VPN oder Firmen-Proxy, ein DNS mit Werbefilter (Pi-hole, eine Filtereinstellung im Router), der die Domain auf einer Liste hat, eine Browser-Erweiterung, eine gecachte Weiterleitung oder ein HSTS-Eintrag von früher, ein vergessener hosts-Eintrag. Ein privates Fenster schließt Erweiterungen und die meisten Caches aus, ein zweiter Browser fast den Rest. Geht die Seite mit 1.1.1.1 als Resolver und mit dem deines Providers nicht, ist dessen Resolver kaputt oder sperrt den Namen. Das kommt in Deutschland tatsächlich vor: Große Provider sperren auf Empfehlung der CUII einzelne Domains per DNS.

Wann eine Einzelprüfung nicht reicht

Alles bisher beantwortet die Frage „Ist sie gerade down?“. Bei deiner eigenen Seite kommt die Frage zu spät, denn wenn du sie stellst, hat es schon jemand anderes gemerkt. Probleme, die kommen und gehen, ein Ausfall, den nur Kunden in Asien sehen, ein Zertifikat, das in neun Tagen abläuft: Nichts davon zeigt eine Prüfung, die du einmal von Hand machst.

Ein HyperMonitors-Monitor stellt dieselbe Art Anfrage nach Zeitplan. Im Gratis-Tarif bekommst du 5 Monitore (HTTP, Port oder Ping), geprüft alle 5 Minuten aus einer Region, die automatisch nach gemessener Latenz gewählt wird. Schlägt eine Prüfung fehl, prüft eine Sonde in einer zweiten Region nach, bevor jemand alarmiert wird, auch im Gratis-Tarif. Eine wackelige Strecke zwischen einer Sonde und deinem Server weckt dich also nicht. Solo (5 $ im Monat) prüft jede Minute aus bis zu zwei Regionen, Team (25 $) aus allen drei: Zürich, New York und Singapur. Ein Monitor mit mehreren Regionen geht erst auf down, wenn mindestens zwei davon den Ausfall sehen. Scheitert nur eine, steht er auf „degraded“. So wird ein regionales Problem sichtbar, ohne dass du nachts aus dem Bett musst.

Zwei Einstellungen schließen die Lücken, um die es hier ging. Eine Keyword-Regel, auch im Gratis-Tarif, lässt die Prüfung scheitern, wenn eine Seite 200 liefert, aber der erwartete Text fehlt. Ein SSL-Monitor, in den bezahlten Tarifen, schlägt bei abgelaufenem oder nicht vertrauenswürdigem Zertifikat an, was ein HTTP-Check nicht als Ausfall wertet. Und eine öffentliche Statusseite, eine ist im Gratis-Tarif dabei, beantwortet deinen Nutzern die Frage „Liegt es an mir?“, bevor sie ein Ticket schreiben.