{"id":34315,"date":"2026-07-20T21:18:25","date_gmt":"2026-07-20T21:18:25","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/ipv6-monitoring\/"},"modified":"2026-07-24T21:32:18","modified_gmt":"2026-07-24T21:32:18","slug":"ipv6-monitoring","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/de\/ipv6-monitoring\/","title":{"rendered":"IPv6-\u00dcberwachung mit Dotcom-Monitor: Finden Sie IPv6-Blindstellen"},"content":{"rendered":"
\"Diagramm
Eine IPv4-Pr\u00fcfung kann erfolgreich sein, w\u00e4hrend der IPv6-Pfad zur gleichen Seite ausgefallen ist.<\/figcaption><\/figure>\n

Die meisten Websites laufen heute im Dual-Stack-Modus. Derselbe Server, API oder Checkout-Seite antwortet gleichzeitig \u00fcber IPv4 und IPv6. Diese Konfiguration sorgt daf\u00fcr, dass Sie erreichbar bleiben, w\u00e4hrend IPv4-Adressen knapp werden, teilt aber auch Ihren Verkehr auf zwei Netzwerke auf, die unabh\u00e4ngig voneinander ausfallen k\u00f6nnen.<\/p>\n

Hier entsteht das Problem: Wenn Ihre \u00dcberwachung nur \u00fcber IPv4 testet, meldet sie gr\u00fcn, w\u00e4hrend native IPv6-Benutzer auf ein nicht erreichbares Gateway, einen fehlenden DNS-Eintrag oder eine nie aktualisierte Firewall-Regel sto\u00dfen. Das Dashboard zeigt 100 % Verf\u00fcgbarkeit. Ein wachsender Teil Ihres Publikums sagt, die Seite ist kaputt.<\/p>\n

Dieser Artikel erkl\u00e4rt, wie Dotcom-Monitor den IPv6-Pfad eigenst\u00e4ndig testet: native IPv6-only Knoten ohne Tunneling, Browserskripte, die jedes Drittanbieter-Asset \u00fcber IPv6 laden, und Protokollpr\u00fcfungen, die einen IPv6-Fehler isolieren, w\u00e4hrend der IPv4-Pfad sauber bleibt.<\/p>\n

Was ist IPv6-Monitoring?<\/h2>\n

IPv6-Monitoring ist die Praxis, zu testen, ob Ihre Website, API und Dienste \u00fcber IPv6 korrekt antworten, aus der Sicht eines echten IPv6-Nutzers. Es f\u00fchrt dieselben Verf\u00fcgbarkeits- und Leistungstests durch, die Sie bereits \u00fcber IPv4 verwenden \u2014 DNS-Aufl\u00f6sung, Seitenladezeiten, Transaktionen und Protokollantworten \u2014 aber \u00fcber den IPv6-Pfad, der eigene DNS-Eintr\u00e4ge, Routen und Firewall-Regeln hat.<\/p>\n

Bei einer Dual-Stack-Website, die beide Protokolle bedient, ist IPv6-Monitoring die einzige M\u00f6glichkeit zu best\u00e4tigen, dass die IPv6-H\u00e4lfte funktioniert. Eine IPv4-Pr\u00fcfung 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\u00fchrt und Verf\u00fcgbarkeit, Transaktionen, DNS und Protokollpr\u00fcfungen auf beiden Ebenen abdeckt.<\/p>\n

Warum Dual-Stack-Netzwerke eine \u00dcberwachungs-Blindstelle schaffen<\/h2>\n

Ein Dual-Stack-Dienst antwortet auf zwei Protokollen, aber IPv4 und IPv6 teilen sich keinen Pfad. Sie sind zwei Routing-Ebenen. Der Verkehr wird \u00fcber unterschiedliche DNS-Eintr\u00e4ge aufgel\u00f6st, passiert unterschiedliche Firewall-Regeln und reist \u00fcber verschiedene Transit-Anbieter, bevor er denselben Ursprungsserver erreicht.<\/p>\n

So kann eine Anfrage \u00fcber eine Ebene erfolgreich sein und \u00fcber die andere fehlschlagen. Der IPv4-Client l\u00f6st Ihren A-Eintrag auf, passiert eine IPv4-Firewall, die Ihr Team \u00fcber Jahre optimiert hat, und l\u00e4dt die Seite. Der IPv6-Client l\u00f6st Ihren AAAA-Eintrag, st\u00f6\u00dft auf ein Gateway, das nie vollst\u00e4ndig konfiguriert wurde, und die Verbindung l\u00e4uft ins Leere. Beide Benutzer haben dieselbe URL eingegeben. Einer von ihnen denkt, Ihre Seite ist ausgefallen.<\/p>\n

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\u00e4uchliche 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\u00fcr die \u00dcberwachung gilt: Ein IPv4-Ergebnis sagt nichts Verl\u00e4ssliches \u00fcber den IPv6-Pfad aus. Sie m\u00fcssen jeden Pfad dort testen, wo er lebt.<\/p>\n

Wie Dotcom-Monitor natives IPv6-only Monitoring durchf\u00fchrt<\/h2>\n

Dotcom-Monitor f\u00fchrt seine Pr\u00fcfungen von einem globalen \u00dcberwachungsnetzwerk<\/a> von Knoten auf echten IPv4- und IPv6-Backbones aus. Einige dieser Knoten sind Dual-Stack und k\u00f6nnen ein Ziel \u00fcber beide Protokolle erreichen. Andere sind nur IPv6-only.<\/p>\n

Die IPv6-only Standorte sind hier entscheidend, wegen dessen, was sie nicht tun. Viele Netzwerkger\u00e4te, die IPv6 sprechen, k\u00f6nnen den Verkehr auch \u00fcber \u00dcbergangsmechanismen wie 6to4-Tunneling oder NAT64 zur\u00fcck zu IPv4 \u00fcbersetzen. Diese \u00dcbersetzung ist im Betrieb n\u00fctzlich, aber beim Testen irref\u00fchrend. Ein Dual-Stack-Agent kann ein sauberes Ergebnis melden, w\u00e4hrend er heimlich auf IPv4 zur\u00fcckf\u00e4llt, wodurch der genaue Fehler verdeckt wird, den Sie finden wollen.<\/p>\n

Ein IPv6-only Knoten verwendet keine \u00dcbersetzung. Er sendet und empf\u00e4ngt nur IPv6. Wenn eine Pr\u00fcfung von diesem Knoten besteht, hat das Ziel tats\u00e4chlich \u00fcber natives IPv6 geantwortet. Wenn sie fehlschl\u00e4gt, haben Sie einen echten IPv6-Fehler gefunden, anstatt dass eine R\u00fcckfallerkennung ihn verdeckt.<\/p>\n

Die gleiche Pr\u00fcfung von einem nativen IPv4-Knoten und einem nativen IPv6-only-Knoten durchzuf\u00fchren, gibt Ihnen ein klares Vorher-Nachher f\u00fcr jede Ebene. Jede Differenz zwischen den beiden Ergebnissen ist ein IPv6-spezifisches Problem, kein Messrauschen.<\/p><\/blockquote>\n

Diese doppelte Baseline l\u00e4uft \u00fcber alle Ger\u00e4tetypen der Plattform. Das Monitoring von Webanwendungen steuert einen echten Browser durch eine skriptgesteuerte Transaktion. Das Monitoring von Webseiten l\u00e4dt eine einzelne Seite auf dieselbe Weise. Das Monitoring der Internet-Infrastruktur f\u00fchrt Protokollpr\u00fcfungen gegen Ihre Server aus. Und das Monitoring von Web Services validiert Ihre APIs. Alle k\u00f6nnen auf IPv6-only Standorte festgelegt werden, und die beiden Browserger\u00e4te zeichnen mit dem EveryStep-Skripting-Tool<\/a> auf, sodass Sie einen Pfad einmal erfassen und von jedem Knoten aus wiedergeben k\u00f6nnen.<\/p>\n

Drittanbieter-AAAA-Geister mit Real-Browser-Monitoring erkennen<\/h2>\n

Ihr Ursprung kann IPv6 perfekt unterst\u00fctzen und Ihre Seiten k\u00f6nnen trotzdem f\u00fcr IPv6-Nutzer fehlerhaft sein. Der Grund sind all die Dinge, die Sie nicht hosten. Eine moderne Seite l\u00e4dt ein CDN, Webfonts, ein Analytics-Tag, ein Chat-Widget und einen Zahlungsprozessor nach. Wenn ein IPv6-only Nutzer diese Seite l\u00e4dt, versucht der Browser auch jedes dieser Assets \u00fcber IPv6 zu laden.<\/p>\n

Wenn ein Drittanbieter nie einen AAAA-Eintrag ver\u00f6ffentlicht hat oder IPv6-Pakete verwirft, h\u00e4ngt der Browser bei diesem Asset. Er wartet, bis die Verbindung ausl\u00e4uft, und kann das Rendering des Restes verz\u00f6gern, w\u00e4hrend 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\u00fcn, weil Ihr Ursprung in Ordnung ist. Das Problem liegt im Netzwerk eines Dritten.<\/p>\n

\"Seiten-an-Seiten-Vergleich
Dieselbe Seite, zwei Ebenen: Bei IPv6-only kommt es bei Drittanbieter-Assets ohne AAAA-Eintr\u00e4ge zu Zeit\u00fcberschreitungen.<\/figcaption><\/figure>\n

Web Applications Monitoring<\/a> f\u00e4ngt dies ab, indem es die komplette Seite in einem echten Browser von einem IPv6-only Knoten l\u00e4dt und jede Anfrage im Waterfall aufzeichnet. F\u00fcr eine einzelne Seite statt einer vollst\u00e4ndigen Transaktion funktioniert Web Pages Monitoring<\/a> auf die gleiche Weise. Statt eines einzigen Bestehen\/Nicht-Bestehen sehen Sie, welches spezifische Asset aufgel\u00f6st wurde, welches Timeout hatte und wo das Rendering gestoppt wurde. Die folgende Tabelle zeigt das Muster, das dadurch sichtbar wird.<\/p>\n

\n\n\n\n\n\n\n
Testprofil<\/th>\nKern-HTML<\/th>\nCDN- und Medien-Assets<\/th>\nDrittanbieter-Skripte<\/th>\nWas der Nutzer sieht<\/th>\n<\/tr>\n<\/thead>\n
IPv4-Monitoring<\/td>\nL\u00f6st auf (A-Eintrag)<\/td>\nL\u00f6st auf<\/td>\nL\u00f6st auf<\/td>\nSeite l\u00e4dt vollst\u00e4ndig und normal.<\/td>\n<\/tr>\n
IPv6-only Monitoring<\/td>\nL\u00f6st auf (AAAA-Eintrag)<\/td>\nL\u00f6st nicht auf<\/td>\nTimeout<\/td>\nTeilweise Ladung: kaputtes Layout, leere Frames, blockierter Checkout.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Nehmen wir einen Checkout-Prozess als Beispiel. Ein Web Applications Skript meldet sich an, f\u00fcgt einen Artikel hinzu und erreicht den Zahlungsschritt. \u00dcber 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\u00e4gt an dieser Stelle fehl und nennt das Asset, das das Problem verursacht hat. Ein Ping der Verf\u00fcgbarkeit auf Ihrer eigenen Domain h\u00e4tte den Checkout \u00fcberhaupt nicht bemerkt. Die Transaktionsskripte mit synthetischem Monitoring<\/a> machen aus “die Seite ist erreichbar” ein “Kunden k\u00f6nnen tats\u00e4chlich bezahlen”.<\/p>\n

Wie Internet-Infrastruktur-Monitoring IPv6-Protokollfehler isoliert<\/h2>\n

Browser-Checks erfassen, was Nutzer sehen. Sie brauchen aber auch die darunter liegende Ebene. Internet Infrastructure Monitoring<\/a> f\u00fchrt Protokollebene-Pr\u00fcfungen gegen Ihre Server durch, so oft wie einmal pro Minute, und es macht dies von IPv6-only Standorten aus, genauso wie die Browserger\u00e4te.<\/p>\n

Diese H\u00e4ufigkeit und diese Isolierung sind der n\u00fctzliche Teil. Wenn Ihr HTTP\/S- oder DNS-Endpunkt \u00fcber IPv4 antwortet, aber \u00fcber IPv6 fehlschl\u00e4gt, meldet Internet Infrastructure Monitoring den IPv6-Protokollfehler eigenst\u00e4ndig, statt ihn durch ein gesundes IPv4-Ergebnis zu verw\u00e4ssern. Web Services Monitoring<\/a> macht das Gleiche f\u00fcr Ihre API-Endpunkte. Sie erhalten eine Warnung, die das Protokoll und den Pfad benennt, nicht eine vage Meldung wie “Antwortzeit ist angestiegen”.<\/p>\n

DNS ist eine dedizierte Pr\u00fcfung wert. Eine Dual-Stack-Site ben\u00f6tigt sowohl einen A-Eintrag als auch einen AAAA-Eintrag, die global und mit gleicher Geschwindigkeit aufgel\u00f6st werden, und ein veralteter oder fehlender AAAA-Eintrag ist einer der h\u00e4ufigsten IPv6-Fehler. DNS Monitoring<\/a> best\u00e4tigt, dass beide Eintr\u00e4ge \u00fcberall antworten, und \u00fcberwacht TTL-Werte, damit eine Routing-\u00c4nderung w\u00e4hrend einer Migration IPv6-Nutzer nicht auf einen toten Eintrag festlegt. Wenn eine Warnung ausgel\u00f6st wird, zeigt ein automatischer IPv6-Traceroute<\/a>, ob der Abbruch bei Ihrem Ursprung oder im Routing-Table eines vorgelagerten Transit-Anbieters liegt.<\/p>\n

Wie Dotcom-Monitor Happy Eyeballs-Latenz aufdeckt<\/h2>\n

Einige IPv6-Probleme zeigen sich nie als Ausfall. Sie zeigen sich als langsam wirkende Seite, ohne dass jemand den Grund daf\u00fcr feststellen kann. Die Ursache ist oft Happy Eyeballs.<\/p>\n

Happy Eyeballs (RFC 8305) ist ein Browser-Fallback. Der Browser startet zuerst seine IPv6-Verbindung und wartet dann ein kurzes Intervall (standardm\u00e4\u00dfig etwa 250 Millisekunden), bevor er auch IPv4 gleichzeitig probiert. Wenn der IPv6-Pfad unterbrochen oder langsam ist, gewinnt der IPv4-Versuch und tr\u00e4gt die Anfrage. Die Verbindung gelingt also, und der Nutzer sieht selten einen Fehler.<\/p>\n

Das ist gut f\u00fcr den Nutzer, aber schlecht f\u00fcr 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\u00fcgt. Jeder IPv6-Nutzer bezahlt eine Latenzsteuer f\u00fcr eine Verbindung, die schlie\u00dflich \u00fcber IPv4 funktioniert. Passive Werkzeuge und Real-User-Analytics zeichnen einen erfolgreichen Ladevorgang auf und machen weiter, sodass der strukturelle Fehler unsichtbar bleibt, w\u00e4hrend sich die Erfahrung leise verschlechtert.<\/p>\n

Natives IPv6-only Monitoring misst diese Steuer direkt, weil kein Fallback verf\u00fcgbar 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<\/a> stellen die IPv4- und IPv6-Zeiten nebeneinander, sodass eine 250-Millisekunden-L\u00fccke, die Nutzer sp\u00fcren, aber nicht beschreiben k\u00f6nnen, zur Linie wird, auf die Sie zeigen k\u00f6nnen. Wenn Sie eine Auffrischung zum Lesen dieser Diagramme brauchen, sehen Sie sich unseren Leitfaden zu Waterfall-Charts<\/a> an.<\/p>\n

So richten Sie Dual-Stack-Monitoring in Dotcom-Monitor ein<\/h2>\n

Hier ist die Einrichtung, die Ihnen beide Ebenen ohne doppelten Wartungsaufwand bietet.<\/p>\n

    \n
  1. Schritt 1: Erstellen Sie die Pr\u00fcfung einmal in EveryStep.<\/strong> Zeichnen Sie Ihren kritischen Pfad oder Protokoll-Check einmal auf. Dasselbe EveryStep-Skript l\u00e4uft an jedem Standort, sodass Sie keine getrennten IPv4- und IPv6-Versionen pflegen m\u00fcssen.<\/li>\n
  2. Schritt 2: Weisen Sie native IPv4- und IPv6-only Standorte zu.<\/strong> F\u00fcgen Sie die Pr\u00fcfung sowohl einem nativen IPv4-Knoten als auch einem IPv6-only Knoten hinzu. \u00dcberspringen Sie 6to4- und NAT64-Standorte f\u00fcr die IPv6-Basislinie, damit keine \u00dcbersetzung zwischen Knoten und Ziel sitzt.<\/li>\n
  3. Schritt 3: Stellen Sie die Pr\u00fcfungsfrequenz ein.<\/strong> F\u00fchren Sie Internet Infrastructure Protokollpr\u00fcfungen so oft wie einmal pro Minute aus. Planen Sie Web Applications Browser-Checks im f\u00fcr Ihr SLA erforderlichen Intervall.<\/li>\n
  4. Schritt 4: F\u00fcgen Sie DNS-Pr\u00fcfungen f\u00fcr A- und AAAA-Eintr\u00e4ge hinzu.<\/strong> Best\u00e4tigen Sie, dass beide Eintr\u00e4ge weltweit mit gleicher Geschwindigkeit aufgel\u00f6st werden, und \u00fcberwachen Sie TTL-Werte, damit eine Migration IPv6-Nutzer nicht auf eine veraltete Route festlegt.<\/li>\n
  5. Schritt 5: L\u00f6sen Sie bei Abweichungen einen IPv6-Traceroute aus.<\/strong> Setzen Sie Warnungen so, dass sofort ein Traceroute gestartet wird, wenn Verf\u00fcgbarkeit oder Antwortzeit nachlassen, sodass Sie einen Ursprungsfehler von einem vorgelagerten Transitfehler sofort trennen k\u00f6nnen.<\/li>\n
  6. Schritt 6: Vergleichen Sie die beiden Waterfalls.<\/strong> Pr\u00fcfen Sie die IPv4- und IPv6-Berichte nebeneinander. Jedes Asset, jeder Hop oder jedes Protokoll, das zwischen beiden unterschiedlich ist, ist Ihr IPv6-spezifisches Problem.<\/li>\n<\/ol>\n

    Das Fazit<\/h2>\n

    Dual-Stack bedeutet, jede Anfrage hat zwei Wege, Sie zu erreichen, und zwei Wege, die scheitern k\u00f6nnen. IPv4-only Monitoring beobachtet einen dieser Wege und berichtet \u00fcber beide \u2013 so erreicht eine Website perfekten Uptime-Status, w\u00e4hrend IPv6-Nutzer Timeouts, halb geladene Seiten und eine Latenzstrafe erhalten, die niemand nachverfolgen kann.<\/p>\n

    Dotcom-Monitor schlie\u00dft diese L\u00fccke, indem es den IPv6-Pfad auf seinen eigenen Bedingungen testet. Native IPv6-only Knoten ohne Tunneling, Web Applications Browserskripte, die jedes Drittanbieter-Asset \u00fcber IPv6 laden, Internet Infrastructure Protokollpr\u00fcfungen bis zu einmal pro Minute, und side-by-side Waterfalls, die einen Ursprungsfehler von einem vorgelagerten Fehler trennen. Sie h\u00f6ren auf, \u00fcber die H\u00e4lfte Ihres Verkehrs zu raten, die IPv4-Pr\u00fcfungen nie erreicht haben.<\/p>\n

    \n

    Testen Sie Ihren IPv6-Pfad, bevor es Ihre Nutzer tun<\/h2>\n

    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\u00e4gige kostenlose Testphase bei Dotcom-Monitor.<\/p>\n

    Starten Sie Ihre kostenlose Testphase<\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

    IPv6-Protokollpr\u00fcfungen werden einmal pro Minute von nativen Knoten durchgef\u00fchrt und isolieren Fehler, die Ihre IPv4-\u00dcberwachung niemals erfassen wird. So macht es Dotcom-Monitor.<\/p>\n","protected":false},"author":39,"featured_media":34301,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[883],"tags":[],"class_list":["post-34315","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-unkategorisiert"],"_links":{"self":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts\/34315","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/users\/39"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/comments?post=34315"}],"version-history":[{"count":0,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/posts\/34315\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/media\/34301"}],"wp:attachment":[{"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/media?parent=34315"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/categories?post=34315"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dotcom-monitor.com\/blog\/de\/wp-json\/wp\/v2\/tags?post=34315"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}