IPv4 funktioniert, IPv6 fällt aus: einen teilweisen Webausfall erkennen

Prüfen Sie DNS und erzwingen Sie jede Adressfamilie

Erfassen Sie die A- und AAAA-Antworten für den Hostnamen. Ein AAAA-Eintrag enthält eine IPv6-Adresse, bestätigt allein aber keine Erreichbarkeit des Dienstes unter dieser Adresse. Bei einem CDN oder einem externen Proxyserver kann die öffentliche Adresse zu dessen Eingangspunkt führen. Klären Sie zuerst, welchen Teil des Weges Sie testen, und vergleichen Sie ihn mit der Konfiguration des Anbieters.

Verwenden Sie auf einem Rechner mit nachgewiesener IPv4- und IPv6-Konnektivität curl -4 --http1.1 und curl -6 --http1.1 für dieselbe HTTPS-URL. So trennen Sie die Adressfamilien und behalten HTTP/1.1 für den Vergleich bei. Speichern Sie Zieladresse, Ergebnis und Testzeit. Prüfen Sie auch, ob ein Proxyserver in der Testumgebung den Netzwerkweg verändert.

Lassen Sie sich vom Erfolg eines Clients nicht täuschen

Mit Happy Eyeballs kann ein Client Verbindungsversuche über verfügbare Adressen zeitlich versetzen und einen weiteren Versuch starten, während der vorherige noch wartet. Eine erfolgreiche IPv4-Verbindung kann dadurch einen defekten IPv6-Weg verdecken. Das Ergebnis hängt von Client und Netzwerk ab. Ein Erfolg in Ihrem Browser liefert daher nicht denselben Nachweis wie ein getrennter IPv6-Test.

RFC 8305 betrachtet einen Versuch in der Regel bereits beim Abschluss der TCP-Verbindung als erfolgreich. Verlassen Sie sich deshalb nicht auf Happy Eyeballs als allgemeine Rettung bei einem späteren TLS- oder Anwendungsfehler. Erfassen Sie bei einer Besuchermeldung Client, Netzwerk, Zeitpunkt und genaues Fehlerbild. Unterscheiden Sie Namensauflösungsfehler, Verbindungs-Timeouts, TLS-Fehler und erfolglose HTTP-Antworten.

Prüfen Sie Listener und Paketweg

Vergleichen Sie auf dem zuständigen Linux-Server oder dem Proxyserver ss -lnt4 und ss -lnt6. Die Ausgaben zeigen lauschende TCP-Sockets nach Adressfamilie. Ein Listener allein prüft weder Routing noch Firewallregeln beim Anbieter und auf dem Host. Untersuchen Sie die Schicht, auf die die öffentliche Adresse zeigt. Bei einem CDN können öffentliche IPv6-Verbindungen anderswo als auf Ihrem Ursprungsserver enden.

Kommt eine Verbindung zustande, aber eine größere Übertragung bleibt hängen, prüfen Sie auch MTU und ICMPv6 Packet Too Big. Diese Nachrichten teilen dem Sender bei Path MTU Discovery mit, dass er die Paketgröße anpassen soll. Pauschales Blockieren von ICMPv6 kann deshalb die Kommunikation stören. Das ist eine Diagnosemöglichkeit, kein Beweis für die Ursache jedes Timeouts. Prüfen Sie Regeln gezielt anhand der Netzwerktopologie.

Prüfen Sie nach der Behebung beide Wege und die eigentliche Operation

Behalten Sie beim Vergleich denselben Hostnamen und die Zertifikatsprüfung bei. Der direkte Aufruf einer IP-Adresse verändert die Testbedingungen; curl prüft bei HTTPS auch den Zertifikatsnamen gegen den Namen in der URL. Bestätigen Sie die Behebung anschließend mit dem üblichen Clientprotokoll und der zuvor fehlgeschlagenen Operation. Ein erzwungener HTTP/1.1-Test prüft nicht sämtliche Protokolle des Dienstes vollständig.

Bieten Sie IPv6 öffentlich an, richten Sie getrennte Prüfungen für beide Adressfamilien in einem Werkzeug ein, das sie erzwingen kann. Erfassen Sie verwendete Adresse, Fehler und Antwortzeit, damit die automatische Wegauswahl keine Störung verdeckt. Wiederholen Sie den Vergleich nach Änderungen an DNS, Netzwerk oder Proxy auch von einem weiteren geeigneten Messpunkt aus.

• Erfassen Sie A- und AAAA-Antworten für denselben Hostnamen.
• Erzwingen Sie IPv4 und IPv6 an einem Messpunkt mit geprüfter Konnektivität.
• Trennen Sie Verbindungs-, TLS- und HTTP-Probleme; prüfen Sie auch MTU.
• Überwachen Sie nach der Behebung beide Wege und die ursprüngliche Nutzeroperation.