Die meisten Websites laufen heute im Dual-Stack-Modus. Derselbe Server, API oder Checkout-Seite antwortet gleichzeitig über IPv4 und IPv6. Diese Konfiguration sorgt dafür, dass Sie erreichbar bleiben, während IPv4-Adressen knapp werden, teilt aber auch Ihren Verkehr auf zwei Netzwerke auf, die unabhängig voneinander ausfallen können.
Hier entsteht das Problem: Wenn Ihre Überwachung nur über IPv4 testet, meldet sie grün, während native IPv6-Benutzer auf ein nicht erreichbares Gateway, einen fehlenden DNS-Eintrag oder eine nie aktualisierte Firewall-Regel stoßen. Das Dashboard zeigt 100 % Verfügbarkeit. Ein wachsender Teil Ihres Publikums sagt, die Seite ist kaputt.
Dieser Artikel erklärt, wie Dotcom-Monitor den IPv6-Pfad eigenständig testet: native IPv6-only Knoten ohne Tunneling, Browserskripte, die jedes Drittanbieter-Asset über IPv6 laden, und Protokollprüfungen, die einen IPv6-Fehler isolieren, während der IPv4-Pfad sauber bleibt.
Was ist IPv6-Monitoring?
IPv6-Monitoring ist die Praxis, zu testen, ob Ihre Website, API und Dienste über IPv6 korrekt antworten, aus der Sicht eines echten IPv6-Nutzers. Es führt dieselben Verfügbarkeits- und Leistungstests durch, die Sie bereits über IPv4 verwenden — DNS-Auflösung, Seitenladezeiten, Transaktionen und Protokollantworten — aber über den IPv6-Pfad, der eigene DNS-Einträge, Routen und Firewall-Regeln hat.
Bei einer Dual-Stack-Website, die beide Protokolle bedient, ist IPv6-Monitoring die einzige Möglichkeit zu bestätigen, dass die IPv6-Hälfte funktioniert. Eine IPv4-Prüfung besteht, egal ob IPv6 funktioniert oder nicht, deshalb bleibt ein Ausfall, der nur IPv6-Nutzer betrifft, ohne ein dediziertes IPv6-Netzwerkmonitoring unsichtbar. Die folgenden Abschnitte zeigen, wie Dotcom-Monitor diesen Test von nativen IPv6-only Knoten ausführt und Verfügbarkeit, Transaktionen, DNS und Protokollprüfungen auf beiden Ebenen abdeckt.
Warum Dual-Stack-Netzwerke eine Überwachungs-Blindstelle schaffen
Ein Dual-Stack-Dienst antwortet auf zwei Protokollen, aber IPv4 und IPv6 teilen sich keinen Pfad. Sie sind zwei Routing-Ebenen. Der Verkehr wird über unterschiedliche DNS-Einträge aufgelöst, passiert unterschiedliche Firewall-Regeln und reist über verschiedene Transit-Anbieter, bevor er denselben Ursprungsserver erreicht.
So kann eine Anfrage über eine Ebene erfolgreich sein und über die andere fehlschlagen. Der IPv4-Client löst Ihren A-Eintrag auf, passiert eine IPv4-Firewall, die Ihr Team über Jahre optimiert hat, und lädt die Seite. Der IPv6-Client löst Ihren AAAA-Eintrag, stößt auf ein Gateway, das nie vollständig konfiguriert wurde, und die Verbindung läuft ins Leere. Beide Benutzer haben dieselbe URL eingegeben. Einer von ihnen denkt, Ihre Seite ist ausgefallen.
Die beiden Ebenen unterscheiden sich auch unter der Haube. IPv6 verwendet einen festen 40-Byte-Basisheader, ein 8-Bit Traffic-Class-Feld und ein 20-Bit Flow-Label, sodass Transit-Router IPv6-Pakete anders verarbeiten als das seit Jahrzehnten gebräuchliche Best-Effort-IPv4-Modell. Und ein einzelnes IPv6-Subnetz fasst weit mehr Adressen als das gesamte alte IPv4-Internet, was beeinflusst, wie Routen verbreitet werden und wie Filter angewandt werden. Für die Überwachung gilt: Ein IPv4-Ergebnis sagt nichts Verlässliches über den IPv6-Pfad aus. Sie müssen jeden Pfad dort testen, wo er lebt.
Wie Dotcom-Monitor natives IPv6-only Monitoring durchführt
Dotcom-Monitor führt seine Prüfungen von einem globalen Überwachungsnetzwerk von Knoten auf echten IPv4- und IPv6-Backbones aus. Einige dieser Knoten sind Dual-Stack und können ein Ziel über beide Protokolle erreichen. Andere sind nur IPv6-only.
Die IPv6-only Standorte sind hier entscheidend, wegen dessen, was sie nicht tun. Viele Netzwerkgeräte, die IPv6 sprechen, können den Verkehr auch über Übergangsmechanismen wie 6to4-Tunneling oder NAT64 zurück zu IPv4 übersetzen. Diese Übersetzung ist im Betrieb nützlich, aber beim Testen irreführend. Ein Dual-Stack-Agent kann ein sauberes Ergebnis melden, während er heimlich auf IPv4 zurückfällt, wodurch der genaue Fehler verdeckt wird, den Sie finden wollen.
Ein IPv6-only Knoten verwendet keine Übersetzung. Er sendet und empfängt nur IPv6. Wenn eine Prüfung von diesem Knoten besteht, hat das Ziel tatsächlich über natives IPv6 geantwortet. Wenn sie fehlschlägt, haben Sie einen echten IPv6-Fehler gefunden, anstatt dass eine Rückfallerkennung ihn verdeckt.
Die gleiche Prüfung von einem nativen IPv4-Knoten und einem nativen IPv6-only-Knoten durchzuführen, gibt Ihnen ein klares Vorher-Nachher für jede Ebene. Jede Differenz zwischen den beiden Ergebnissen ist ein IPv6-spezifisches Problem, kein Messrauschen.
Diese doppelte Baseline läuft über alle Gerätetypen der Plattform. Das Monitoring von Webanwendungen steuert einen echten Browser durch eine skriptgesteuerte Transaktion. Das Monitoring von Webseiten lädt eine einzelne Seite auf dieselbe Weise. Das Monitoring der Internet-Infrastruktur führt Protokollprüfungen gegen Ihre Server aus. Und das Monitoring von Web Services validiert Ihre APIs. Alle können auf IPv6-only Standorte festgelegt werden, und die beiden Browsergeräte zeichnen mit dem EveryStep-Skripting-Tool auf, sodass Sie einen Pfad einmal erfassen und von jedem Knoten aus wiedergeben können.
Drittanbieter-AAAA-Geister mit Real-Browser-Monitoring erkennen
Ihr Ursprung kann IPv6 perfekt unterstützen und Ihre Seiten können trotzdem für IPv6-Nutzer fehlerhaft sein. Der Grund sind all die Dinge, die Sie nicht hosten. Eine moderne Seite lädt ein CDN, Webfonts, ein Analytics-Tag, ein Chat-Widget und einen Zahlungsprozessor nach. Wenn ein IPv6-only Nutzer diese Seite lädt, versucht der Browser auch jedes dieser Assets über IPv6 zu laden.
Wenn ein Drittanbieter nie einen AAAA-Eintrag veröffentlicht hat oder IPv6-Pakete verwirft, hängt der Browser bei diesem Asset. Er wartet, bis die Verbindung ausläuft, und kann das Rendering des Restes verzögern, während er wartet. Das sichtbare Ergebnis ist eine halb geladene Seite: fehlende Navigation, leere Asset-Rahmen, ein Checkout-Button, der nie funktioniert. Ihr internes Health-Dashboard zeigt die ganze Zeit grün, weil Ihr Ursprung in Ordnung ist. Das Problem liegt im Netzwerk eines Dritten.
Web Applications Monitoring fängt dies ab, indem es die komplette Seite in einem echten Browser von einem IPv6-only Knoten lädt und jede Anfrage im Waterfall aufzeichnet. Für eine einzelne Seite statt einer vollständigen Transaktion funktioniert Web Pages Monitoring auf die gleiche Weise. Statt eines einzigen Bestehen/Nicht-Bestehen sehen Sie, welches spezifische Asset aufgelöst wurde, welches Timeout hatte und wo das Rendering gestoppt wurde. Die folgende Tabelle zeigt das Muster, das dadurch sichtbar wird.
| Testprofil | Kern-HTML | CDN- und Medien-Assets | Drittanbieter-Skripte | Was der Nutzer sieht |
|---|---|---|---|---|
| IPv4-Monitoring | Löst auf (A-Eintrag) | Löst auf | Löst auf | Seite lädt vollständig und normal. |
| IPv6-only Monitoring | Löst auf (AAAA-Eintrag) | Löst nicht auf | Timeout | Teilweise Ladung: kaputtes Layout, leere Frames, blockierter Checkout. |
Nehmen wir einen Checkout-Prozess als Beispiel. Ein Web Applications Skript meldet sich an, fügt einen Artikel hinzu und erreicht den Zahlungsschritt. Über IPv4 funktioniert der gesamte Pfad. Vom IPv6-only Knoten hat das Skript des Zahlungsabwicklers keinen AAAA-Eintrag, der Browser bleibt vor dem Formular stehen. Das Skript schlägt an dieser Stelle fehl und nennt das Asset, das das Problem verursacht hat. Ein Ping der Verfügbarkeit auf Ihrer eigenen Domain hätte den Checkout überhaupt nicht bemerkt. Die Transaktionsskripte mit synthetischem Monitoring machen aus “die Seite ist erreichbar” ein “Kunden können tatsächlich bezahlen”.
Wie Internet-Infrastruktur-Monitoring IPv6-Protokollfehler isoliert
Browser-Checks erfassen, was Nutzer sehen. Sie brauchen aber auch die darunter liegende Ebene. Internet Infrastructure Monitoring führt Protokollebene-Prüfungen gegen Ihre Server durch, so oft wie einmal pro Minute, und es macht dies von IPv6-only Standorten aus, genauso wie die Browsergeräte.
Diese Häufigkeit und diese Isolierung sind der nützliche Teil. Wenn Ihr HTTP/S- oder DNS-Endpunkt über IPv4 antwortet, aber über IPv6 fehlschlägt, meldet Internet Infrastructure Monitoring den IPv6-Protokollfehler eigenständig, statt ihn durch ein gesundes IPv4-Ergebnis zu verwässern. Web Services Monitoring macht das Gleiche für Ihre API-Endpunkte. Sie erhalten eine Warnung, die das Protokoll und den Pfad benennt, nicht eine vage Meldung wie “Antwortzeit ist angestiegen”.
DNS ist eine dedizierte Prüfung wert. Eine Dual-Stack-Site benötigt sowohl einen A-Eintrag als auch einen AAAA-Eintrag, die global und mit gleicher Geschwindigkeit aufgelöst werden, und ein veralteter oder fehlender AAAA-Eintrag ist einer der häufigsten IPv6-Fehler. DNS Monitoring bestätigt, dass beide Einträge überall antworten, und überwacht TTL-Werte, damit eine Routing-Änderung während einer Migration IPv6-Nutzer nicht auf einen toten Eintrag festlegt. Wenn eine Warnung ausgelöst wird, zeigt ein automatischer IPv6-Traceroute, ob der Abbruch bei Ihrem Ursprung oder im Routing-Table eines vorgelagerten Transit-Anbieters liegt.
Wie Dotcom-Monitor Happy Eyeballs-Latenz aufdeckt
Einige IPv6-Probleme zeigen sich nie als Ausfall. Sie zeigen sich als langsam wirkende Seite, ohne dass jemand den Grund dafür feststellen kann. Die Ursache ist oft Happy Eyeballs.
Happy Eyeballs (RFC 8305) ist ein Browser-Fallback. Der Browser startet zuerst seine IPv6-Verbindung und wartet dann ein kurzes Intervall (standardmäßig etwa 250 Millisekunden), bevor er auch IPv4 gleichzeitig probiert. Wenn der IPv6-Pfad unterbrochen oder langsam ist, gewinnt der IPv4-Versuch und trägt die Anfrage. Die Verbindung gelingt also, und der Nutzer sieht selten einen Fehler.
Das ist gut für den Nutzer, aber schlecht für Ihre Sichtbarkeit. Die Wartezeit, bevor der Browser IPv6 aufgibt und auf IPv4 umschwenkt, wird zur realen Time to First Byte und Largest Contentful Paint hinzugefügt. Jeder IPv6-Nutzer bezahlt eine Latenzsteuer für eine Verbindung, die schließlich über IPv4 funktioniert. Passive Werkzeuge und Real-User-Analytics zeichnen einen erfolgreichen Ladevorgang auf und machen weiter, sodass der strukturelle Fehler unsichtbar bleibt, während sich die Erfahrung leise verschlechtert.
Natives IPv6-only Monitoring misst diese Steuer direkt, weil kein Fallback verfügbar ist, hinter dem man sich verstecken kann. Der IPv6-Pfad performt entweder oder nicht, und die Zahl landet im Bericht. Side-by-Side Waterfall-Berichte stellen die IPv4- und IPv6-Zeiten nebeneinander, sodass eine 250-Millisekunden-Lücke, die Nutzer spüren, aber nicht beschreiben können, zur Linie wird, auf die Sie zeigen können. Wenn Sie eine Auffrischung zum Lesen dieser Diagramme brauchen, sehen Sie sich unseren Leitfaden zu Waterfall-Charts an.
So richten Sie Dual-Stack-Monitoring in Dotcom-Monitor ein
Hier ist die Einrichtung, die Ihnen beide Ebenen ohne doppelten Wartungsaufwand bietet.
- Schritt 1: Erstellen Sie die Prüfung einmal in EveryStep. Zeichnen Sie Ihren kritischen Pfad oder Protokoll-Check einmal auf. Dasselbe EveryStep-Skript läuft an jedem Standort, sodass Sie keine getrennten IPv4- und IPv6-Versionen pflegen müssen.
- Schritt 2: Weisen Sie native IPv4- und IPv6-only Standorte zu. Fügen Sie die Prüfung sowohl einem nativen IPv4-Knoten als auch einem IPv6-only Knoten hinzu. Überspringen Sie 6to4- und NAT64-Standorte für die IPv6-Basislinie, damit keine Übersetzung zwischen Knoten und Ziel sitzt.
- Schritt 3: Stellen Sie die Prüfungsfrequenz ein. Führen Sie Internet Infrastructure Protokollprüfungen so oft wie einmal pro Minute aus. Planen Sie Web Applications Browser-Checks im für Ihr SLA erforderlichen Intervall.
- Schritt 4: Fügen Sie DNS-Prüfungen für A- und AAAA-Einträge hinzu. Bestätigen Sie, dass beide Einträge weltweit mit gleicher Geschwindigkeit aufgelöst werden, und überwachen Sie TTL-Werte, damit eine Migration IPv6-Nutzer nicht auf eine veraltete Route festlegt.
- Schritt 5: Lösen Sie bei Abweichungen einen IPv6-Traceroute aus. Setzen Sie Warnungen so, dass sofort ein Traceroute gestartet wird, wenn Verfügbarkeit oder Antwortzeit nachlassen, sodass Sie einen Ursprungsfehler von einem vorgelagerten Transitfehler sofort trennen können.
- Schritt 6: Vergleichen Sie die beiden Waterfalls. Prüfen Sie die IPv4- und IPv6-Berichte nebeneinander. Jedes Asset, jeder Hop oder jedes Protokoll, das zwischen beiden unterschiedlich ist, ist Ihr IPv6-spezifisches Problem.
Das Fazit
Dual-Stack bedeutet, jede Anfrage hat zwei Wege, Sie zu erreichen, und zwei Wege, die scheitern können. IPv4-only Monitoring beobachtet einen dieser Wege und berichtet über beide – so erreicht eine Website perfekten Uptime-Status, während IPv6-Nutzer Timeouts, halb geladene Seiten und eine Latenzstrafe erhalten, die niemand nachverfolgen kann.
Dotcom-Monitor schließt diese Lücke, indem es den IPv6-Pfad auf seinen eigenen Bedingungen testet. Native IPv6-only Knoten ohne Tunneling, Web Applications Browserskripte, die jedes Drittanbieter-Asset über IPv6 laden, Internet Infrastructure Protokollprüfungen bis zu einmal pro Minute, und side-by-side Waterfalls, die einen Ursprungsfehler von einem vorgelagerten Fehler trennen. Sie hören auf, über die Hälfte Ihres Verkehrs zu raten, die IPv4-Prüfungen nie erreicht haben.
Testen Sie Ihren IPv6-Pfad, bevor es Ihre Nutzer tun
Setzen Sie native IPv6-only Monitoring-Knoten ein und sehen Sie genau, was Ihre Dual-Stack-Nutzer erleben, bis ins Detail des Drittanbieter-Assets. Starten Sie eine 30-tägige kostenlose Testphase bei Dotcom-Monitor.
