Bei uns geht die Seite, beim Kunden nicht: Ursachen finden

Was „geht nicht“ im Supportfall bedeutet

„Geht nicht“ ist keine Fehlermeldung, sondern eine Zusammenfassung. Dahinter stecken sehr verschiedene Bilder aus verschiedenen Schichten zwischen Browser und Server. Wer den genauen Wortlaut der Meldung kennt, spart den größten Teil der Suche.

Vier Rückfragen grenzen den Fall meist schon ein:

• Wortlaut und Bildschirmfoto: die genaue Meldung des Browsers.
• Gerät und Browser: Tritt der Fehler auch im privaten Fenster oder in einem anderen Browser auf?
• Netz: Büro-WLAN, Heimanschluss, Mobilfunk oder VPN? Ändert sich etwas im Mobilfunknetz?
• Zeitpunkt und Umfang: Seit wann, nur diese Seite oder auch andere, eine Unterseite oder die ganze Domain?

Die Netzfrage ist die wertvollste. Funktioniert die Seite im Mobilfunknetz und scheitert im Firmen-WLAN, liegt die Ursache mit hoher Wahrscheinlichkeit bei Resolver, Filter oder Proxy dieses Netzes. Scheitert sie überall, aber nur auf einem Gerät, liegt sie eher im Browser oder im Betriebssystem.

Erster Schritt: Erreichen die Prüfknoten die Seite?

Das eigene Büro ist kein neutraler Messpunkt: Dort laufen dieselben Resolver wie bei den Entwicklern, vielleicht steht noch ein Eintrag aus der Umzugsphase in der hosts-Datei, und der Browser kennt die Seite seit Monaten. Vor der Suche beim Kunden braucht es deshalb einen Blick von außen.

Das Uptime-Monitoring von XICTRAQ® prüft jede Website von drei Knoten in Nürnberg, Helsinki und Falkenstein aus, also von zwei in Deutschland und einem in Finnland (XICTRAQ®-Funktionsseite). Ein Ausfall gilt erst als bestätigt, wenn zwei von drei Knoten ihn melden (XICTRAQ®-Funktionsseite). Im Knoten-Konsens-Panel der Website steht je Knoten der letzte Befund mit Status, Antwortzeit und Standort.

Scheitert die Verbindung zu einem Knoten schon auf Transportebene, steht dort „Nicht erreichbar vom Scan-Node (Timeout/geblockt)“ mit dem konkreten Grund, nicht pauschal „offline“. Das Handbuch zum Uptime-Monitoring beschreibt, wie dieser Knoten-Befund zu lesen ist und wann aus ihm ein Vorfall wird.

Aus dem Befund folgt die Richtung der weiteren Suche:

• Alle Knoten erreichen die Seite: Server und autoritatives DNS antworten, die Ursache liegt mit hoher Wahrscheinlichkeit auf dem Weg zum Besucher oder bei ihm.
• Zwei oder drei Knoten scheitern: Der Konsens kippt, ein Vorfall ist eröffnet. Weiter bei Server, DNS und Netz.
• Nur ein Knoten scheitert: Der Status bleibt grün. Der Knoten-Befund zeigt, ob dieser Knoten ein lokales Netzproblem hat oder das Ziel Rechenzentrumsadressen sperrt.

Wenn die Knoten scheitern: Server, DNS oder Netz

Der Timing-Wasserfall zeigt, wie weit die Verbindung gekommen ist: DNS-Auflösung, TCP-Verbindung, TLS-Handshake und Time to First Byte (TTFB). Die Phase, in der die Messung abbricht, benennt die Schicht, in der gesucht wird.

• Abbruch bei DNS: gelöschter Eintrag, falsche Delegation, abgelaufene Domain oder DNSSEC-Fehler. Änderungen an Einträgen und Delegation macht das DNS-Monitoring sichtbar.
• Abbruch bei TCP: Eine Zeitüberschreitung spricht eher für eine Firewall, die Pakete verwirft, eine sofortige Ablehnung für einen geschlossenen Port oder einen gestoppten Dienst.
• Abbruch bei TLS: Zertifikat abgelaufen, falscher Name oder unvollständige Kette. Einen Ausweichweg beschreibt der Beitrag Zertifizierungsstelle wechseln.
• Lange TTFB oder Serverfehler: Die Anwendung antwortet zu langsam oder mit einem Status der 5xx-Klasse, mit dem der Server einen eigenen Fehler anzeigt (RFC 9110).

Scheitert die Seite nur aus manchen Netzen, kann das Routing die Ursache sein. Wie sich ein solcher Teilausfall erkennen und belegen lässt, beschreibt der Beitrag BGP und RPKI: Wenn die Seite nur aus manchen Netzen fehlt.

Ein kurzer DNS-Ausfall kann bei einzelnen Besuchern länger nachwirken als im Monitoring. Antwortet ein Resolver mit SERVFAIL, weil er die autoritativen Server nicht erreicht, darf er diese Antwort speichern, aber nicht länger als fünf Minuten (RFC 2308). RFC 9520 verlangt für Auflösungsfehler, auch für gescheiterte DNSSEC-Prüfungen, einen Fehlerspeicher von mindestens einer Sekunde (RFC 9520) und hält an der Obergrenze von fünf Minuten fest (RFC 9520). Die Uhrzeit des Kundenversuchs gehört deshalb neben die Messreihe.

Negativ-Cache: das gespeicherte „gibt es nicht“

Eine oft übersehene Ursache ist eine negative DNS-Antwort im Zwischenspeicher. Eine neue Subdomain wie neu.example.com wird per Mail angekündigt, ein Empfänger klickt, bevor der Eintrag existiert. Oder beim Wechsel des DNS-Anbieters war die Zone kurz leer. Der Resolver des Kunden erhält NXDOMAIN, also „diesen Namen gibt es nicht“, und merkt es sich. Nach der Korrektur sieht das Büro die Seite, der Kunde weiter „Server nicht gefunden“.

Wie lange das dauern kann, regelt RFC 2308. Der autoritative Server legt jeder negativen Antwort den SOA-Eintrag der Zone bei. Dessen Gültigkeit ergibt sich aus dem kleineren Wert von MINIMUM-Feld und Time to Live (TTL) des SOA, und so lange darf ein Resolver die negative Antwort speichern (RFC 2308). Als eigene Obergrenze eines Resolvers nennt die Norm eine bis drei Stunden als sinnvolle Vorgabe (RFC 2308), Werte über einem Tag hätten sich als problematisch erwiesen (RFC 2308). Das Protokoll selbst ließe eine Speicherung von bis zu 68 Jahren zu (RFC 2308).

Zwei Regeln verschärfen den Fall. Nach RFC 8020 gilt ein NXDOMAIN für den abgelehnten Namen und für alle Namen darunter (RFC 8020): Hat ein Resolver NXDOMAIN für kunde.example.com gespeichert, soll er auch für www.kunde.example.com NXDOMAIN liefern. In Zonen mit DNSSEC dürfen validierende Resolver aus gespeicherten NSEC- oder NSEC3-Einträgen negative Antworten für ganze Namensbereiche erzeugen (RFC 8198). Zonenbetreiber sollten deshalb nicht erwarten, dass ein neu angelegter Name sofort funktioniert (RFC 8198). Für die Gültigkeit solcher Antworten verweist RFC 8198 auf die Obergrenze von drei Stunden aus RFC 2308 (RFC 8198).

Ob ein Negativ-Cache im Spiel ist, zeigt dig, idealerweise auf einem Rechner im Netz des Kunden:

Die erste Abfrage zeigt Status NXDOMAIN und in der SOA-Zeile vor IN die verbleibende Gültigkeit der negativen Antwort in Sekunden. Die zweite liest den SOA-Eintrag: Das letzte Feld ist MINIMUM, die Zahl vor IN die TTL des SOA. Der kleinere der beiden Werte begrenzt, wie lange eine Panne nachwirken kann.

Für den Betrieb heißt das: Einträge anlegen, bevor ein Link verschickt wird, und Umzüge so planen, dass die Zone zu keinem Zeitpunkt ohne den Namen ist. Ein niedriges MINIMUM verkürzt die Nachwirkung. Den Zwischenspeicher am eigenen Rechner zu leeren, hilft dem Kunden nur, wenn der Rechner selbst die Antwort hält. Hält sie der Router oder der Provider, bleibt nur Warten oder ein anderes Netz.

Resolver-TTL und alte Adressen nach einem Umzug

Das Gegenstück zum Negativ-Cache ist die gespeicherte alte Adresse. Nach einem Server- oder Anbieterwechsel halten Resolver den bisherigen A- oder AAAA-Eintrag, bis seine TTL abläuft. Wie die TTL vor einem Umzug gesenkt wird, steht im Beitrag DNS-Propagation und Multi-Resolver-Monitoring.

Für den Supportfall genügt oft ein Vergleich: Das kostenlose Werkzeug DNS-Propagation fragt mehrere öffentliche Resolver gleichzeitig. Liefern alle die neue Adresse, der Rechner des Kunden aber nicht, hängt sein Resolver nach. Den Resolver des Kunden selbst sieht der Abgleich nicht.

Eine Besonderheit sind abgelaufene Einträge. RFC 8767 erlaubt Resolvern, nach Ablauf der TTL mit alten Daten zu antworten, wenn die autoritativen Server nicht erreichbar sind. Solche Antworten tragen eine kurze TTL, empfohlen sind 30 Sekunden (RFC 8767). Abgelaufene Einträge sollen nach dem Vorschlag der Norm einen bis drei Tage aufbewahrt werden (RFC 8767), TTL-Werte allgemein soll ein Resolver auf sieben Tage begrenzen (RFC 8767). Fallen beim Umzug die neuen Nameserver aus, können manche Besucher deshalb noch die alte Adresse bekommen.

Welcher Resolver beim Kunden antwortet, ist dabei offen: Router, Provider, Firmen-DNS oder ein verschlüsseltes DNS im Browser. Bei DNS over HTTPS (DoH) schickt der Browser seine Anfragen über HTTPS an einen Resolver seiner Wahl (RFC 8484). Das Leeren des Betriebssystem-Caches ändert dann für den Browser in der Regel nichts.

Im Browser: Service Worker, Weiterleitungen und HSTS

Funktioniert die Seite im privaten Fenster oder in einem anderen Browser, liegt die Ursache im gespeicherten Zustand des Browsers. Drei Mechanismen wirken dabei auch nach einer Korrektur auf dem Server weiter.

Service Worker

Ein Service Worker fängt Anfragen der Seite ab und kann sie aus einem eigenen Speicher beantworten. Rund ein Fünftel der Websites setzt Service Worker ein (HTTP Archive Web Almanac 2025). Liefert ein alter Service Worker eine veraltete Fassung oder eine leere Hülle aus, sieht nur der Besucher mit diesem Stand den Fehler. Nach der Spezifikation gilt eine Registrierung als veraltet, wenn die letzte Prüfung auf eine neue Fassung mehr als 86.400 Sekunden, also 24 Stunden, zurückliegt (W3C Service Workers). Wie sich solche Fallen nach einer Auslieferung finden lassen, zeigt der Beitrag Cache-Fallen nach dem Deploy.

Gespeicherte Weiterleitungen

Eine Weiterleitung mit Status 301 ist heuristisch cachebar (RFC 9110): Ohne ausdrückliche Cache-Angabe darf ein Browser sie speichern und künftig ohne Rückfrage befolgen. Für Antworten mit Last-Modified nennt RFC 9111 als typischen Wert eine Frische von 10 Prozent der Zeit seit der letzten Änderung (RFC 9111). Zeigte eine Domain während eines Umbaus kurz per 301 auf eine Wartungsseite, landen Besucher mit diesem Eintrag weiter dort.

HSTS im Browser

HTTP Strict Transport Security (HSTS) weist den Browser an, eine Domain für die Dauer von max-age nur noch per HTTPS aufzurufen, mit includeSubDomains auch alle Subdomains. Die Norm erläutert das an einem Beispiel mit einem Jahr, rund 31.536.000 Sekunden (RFC 6797), und dieser Wert ist im Web üblich: Der Median von max-age liegt bei 365 Tagen (HTTP Archive Web Almanac 2025). Den Kopf senden 36 Prozent der mobil aufgerufenen Seiten (HTTP Archive Web Almanac 2025), und von den Seiten mit HSTS schützen rund 40 Prozent auch ihre Subdomains (HTTP Archive Web Almanac 2025).

Entscheidend ist eine Regel aus RFC 6797: Fehler beim sicheren Verbindungsaufbau sollen ohne Ausweg für den Nutzer behandelt werden, ein Dialog zum Fortfahren ist nicht vorgesehen (RFC 6797). Ein Kunde, der einmal example.com aufgerufen hat, das HSTS mit includeSubDomains sendet, erreicht danach test.example.com ohne gültiges Zertifikat nicht mehr, Kollegen ohne diesen Eintrag schon. Ebenso blockiert der Browser eine HSTS-Domain, wenn ein Firmenproxy TLS mit einem nicht eingerichteten Zertifikat aufbricht. Mehr dazu im Beitrag HSTS-Preload: Voraussetzungen und Risiken.

Netz des Besuchers: VPN, Firmenfilter, Jugendschutz

Ein VPN verlegt den Ausgangspunkt des Datenverkehrs in ein anderes Land oder ein Rechenzentrum und bringt häufig eigene Resolver mit. Dann greifen Geo-Sperren und Regeln gegen Rechenzentrumsadressen, und der DNS-Zwischenspeicher ist ein anderer. Die Probe ist einfach: VPN aus, Seite neu laden.

Filter wirken ähnlich unauffällig. Firmenproxys, Schulnetze, die Kinderschutzfunktion im Router oder ein Sicherheits-DNS des Providers sperren Domains nach Kategorien, und eine neue oder falsch eingestufte Domain kann dabei durchfallen. Der Besucher sieht dann NXDOMAIN, eine Sperrseite oder eine Zertifikatswarnung, weil die Sperrseite unter einem fremden Zertifikat ausgeliefert wird.

Ob ein Resolver absichtlich sperrt, kann er über Extended DNS Errors (EDE) mitteilen. RFC 8914 definiert dafür unter anderem Code 15 „Blocked“ für eine Sperre nach interner Sicherheitsrichtlinie des Resolverbetreibers (RFC 8914), Code 16 „Censored“ für eine Sperre aufgrund einer externen Vorgabe (RFC 8914) und Code 17 „Filtered“ für eine Filterung, die der Nutzer selbst angefordert hat (RFC 8914). Nicht jeder Resolver sendet diese Codes. Wenn doch, zeigt dig sie in einer eigenen Zeile mit der Kennung EDE.

Freigeben oder neu einstufen kann in der Regel nur die IT des Kunden oder der Anbieter des Filters. Hilfreich ist eine Notiz mit Domain, Uhrzeit und Wortlaut der Sperrseite. Ob die Leitung des Kunden stabil ist, zeigt der Ping-Test: Er misst aus dem Browser des Kunden Laufzeit, Schwankung und Paketverlust zum Messserver von XICTRAQ® in Nürnberg, also den Anschluss, nicht die Website.

IPv6-Pfad: wenn nur eine Protokollversion hakt

Hat eine Domain einen AAAA-Eintrag, versuchen Geräte mit IPv6-Anschluss in der Regel zuerst IPv6. Ist dieser Pfad gestört, etwa durch eine Firewallregel nur für IPv4 oder einen AAAA-Eintrag, der nach dem Umzug noch auf den alten Server zeigt, hängt das Ergebnis vom Gerät ab. Clients mit Happy Eyeballs Version 2 warten nach der IPv4-Antwort des DNS nur kurz auf die IPv6-Antwort, empfohlen sind 50 Millisekunden (RFC 8305), und starten den nächsten Verbindungsversuch nach einer Vorgabe von 250 Millisekunden (RFC 8305). Sie weichen schnell auf IPv4 aus, und der Fehler bleibt oft unbemerkt.

Ältere Software und Mobilfunknetze, die intern nur IPv6 mit einer Übersetzung nach IPv4 (NAT64) nutzen, haben diesen Ausweg oft nicht. Das Büro mit reinem IPv4-Anschluss sieht die Seite, der Kunde im Mobilfunknetz eine Zeitüberschreitung. Die getrennte Probe beider Protokollversionen zeigt den Unterschied:

Wie sich beide Protokollversionen dauerhaft getrennt überwachen lassen, beschreibt der Beitrag IPv6-Erreichbarkeit überwachen.

Geo-Blocking und WAF: wenn der Server selbst ablehnt

Manche Sperren setzt der Server oder eine vorgeschaltete Web Application Firewall (WAF) selbst, und der Status verrät die Art. Status 403 heißt, der Server hat die Anfrage verstanden und verweigert sie (RFC 9110). Status 451 steht für eine Verweigerung aufgrund einer rechtlichen Anforderung (RFC 7725). Status 429 meldet zu viele Anfragen in einem bestimmten Zeitraum (RFC 6585) und kann mit Retry-After angeben, wann ein neuer Versuch sinnvoll ist.

Geo-Blocking stützt sich auf Datenbanken, die IP-Adressen Ländern zuordnen, oft grob und mitunter falsch, wie der Beitrag Besucher aus Frankfurt? Wie IP-Standorte wirklich entstehen zeigt. Gesperrt wird dann auch ein Kunde in Deutschland, dessen Adressen anderswo verortet sind, oder einer mit VPN-Ausgang im Ausland. Die Prüfknoten in Deutschland und Finnland sehen Sperren für andere Länder nicht.

Umgekehrt sperren manche WAF-Regeln Rechenzentrumsadressen. Dann melden die Knoten „Nicht erreichbar vom Scan-Node (Timeout/geblockt)“, während echte Besucher die Seite laden. Abhilfe schafft eine Firewall-Whitelist für Monitoring. Für einen einzelnen gesperrten Kunden ist das Protokoll der WAF zu Uhrzeit und IP-Adresse des Kunden der schnellste Beleg.

Die Eingrenzung in fester Reihenfolge

Erst kommen die Prüfungen, die ohne den Kunden auskommen und viele Ursachen auf einmal ausschließen, dann die, für die er selbst etwas tun muss.

1. Symptom aufnehmen: Wortlaut, Bildschirmfoto, Gerät, Browser, Netz und Uhrzeit.
2. Prüfknoten ansehen: Konsens, Befund je Knoten und die Phasenzeiten DNS, TCP, TLS und TTFB der Prüfungen zur Uhrzeit der Meldung.
3. Bei bestätigtem Ausfall: die Phase im Wasserfall bestimmen und bei Server, DNS oder Netz weitersuchen.
4. Bei erreichbarer Seite das Netz wechseln lassen: Mobilfunk statt WLAN, VPN aus.
5. Browserzustand ausschließen: privates Fenster oder anderer Browser.
6. DNS beim Kunden prüfen: NXDOMAIN, SERVFAIL oder alte Adresse seines Resolvers, verglichen mit öffentlichen Resolvern.
7. IPv4 und IPv6 getrennt testen: Scheitert nur eine Protokollversion, sind AAAA-Eintrag oder Firewall verdächtig.
8. Serverseite nachlesen: Zugriffs- und WAF-Protokolle zur Uhrzeit und Adresse des Kunden.

Für die Rückfrage an den Kunden hilft eine kurze Vorlage. Sie fragt ab, was sich aus der Ferne nicht ermitteln lässt:

Betreff: Ihre Meldung „Seite lädt nicht“

Damit wir die Ursache eingrenzen können, bitten wir um folgende Angaben:

1. Welche Meldung zeigt der Browser? Ein Bildschirmfoto hilft am meisten.
2. Welche Adresse haben Sie aufgerufen, vollständig mit Unterseite?
3. Welches Gerät und welcher Browser?
4. Über welches Netz: Büro-WLAN, Heimanschluss, Mobilfunk oder VPN?
5. Öffnet sich die Seite, wenn Sie das Telefon vom WLAN ins Mobilfunknetz wechseln?
6. Öffnet sie sich in einem privaten Fenster?
7. Seit wann besteht das Problem, und wann war der letzte Versuch?

Was das Monitoring beiträgt und wo es endet

Ein externes Monitoring ersetzt nicht den Blick auf den Rechner des Kunden. Es beantwortet aber die erste Frage mit Zeitstempel: Hat die Seite zum Zeitpunkt der Meldung von außen funktioniert, und wenn nicht, in welcher Phase ist sie gescheitert? Damit lässt sich dem Kunden sachlich antworten, statt auf beiden Seiten zu vermuten.

Drei Bausteine helfen im Alltag. Eine öffentliche Statusseite zeigt Kunden den Stand, bevor sie anrufen. Wie man sie aufsetzt, beschreibt der Beitrag Statusseite einrichten. Das DNS-Monitoring hält Änderungen an den Einträgen der Domain mit altem und neuem Wert im Changelog fest. Zeigt der Changelog, dass ein Eintrag weggefallen ist, ist ein Negativ-Cache bei Besuchern ein naheliegender Verdacht. Und die Prüfung aus mehreren Standorten, erklärt im Beitrag Multi-Location-Monitoring, trennt eine echte Störung vom Netzproblem eines einzelnen Messpunkts.

Supportfälle mit Messwerten statt Vermutungen klären

„Bei uns geht es“ hilft dem Kunden wenig, auch wenn es stimmt. Hilfreich ist eine Aussage mit Messung: Die Seite war zur genannten Uhrzeit aus mehreren Netzen erreichbar, die Ursache liegt deshalb mit hoher Wahrscheinlichkeit auf dem Weg zum Kunden, und diese eine Probe grenzt sie ein. Das Uptime-Monitoring liefert dafür den Befund je Knoten und den Timing-Wasserfall, auch im kostenlosen Plan. Die Prüfintervalle je Tarif stehen auf der Preisseite.