Wir haben Beschwerden erhalten, dass einige Benutzer tagsüber nicht auf die Site zugreifen können. Irgendwie sehen sie die Wartungsseite. Als wir die Haproxy-Protokolle untersuchten, sahen wir, dass die Quell-IPs aller Anfragen mit 503-Fehlern IPv6 sind. Wir haben keinen AAAA-DNS-Eintrag.
ich habe die WAF- und Firewall-WAN-Regeln geprüft. Außerdem habe ich die Serverprotokolle geprüft. Anfragen werden nicht an Backend-Server weitergeleitet.
ein Beispielprotokoll: [ <131>Nov 16 14:59:33 HaProxy haproxy[54113]: 2001:4860:7:631::e0:60332 [16/Nov/2022:14:59:33.173] HTTPS_443-Balance~ HTTP_80_443_ipv4/IIS-03 0/0/-1/-1/0 503 2695 - - SC-- 153/147/5/0/0 0/0 "GET https://example.com/path HTTP/2.0" ]
Antwort1
Eine Quell-IP-Adresse ist in den Protokollen, Ihr Haproxy hat etwas über IPv6 erhalten. Ihr CDN-Routing zu Ihnen funktioniert also.
Wie in den Kommentaren erwähnt,Haproxy „SC“-Beendigungszustandbezieht sich auf eine TCP-Sitzung, die vom Server unerwartet abgebrochen wurde. Wenn Sie Ihre Backends IPv6-fähig machen, funktioniert dies, ohne dass Sie Änderungen an Ihrem CDN oder Load Balancer vornehmen müssen. Oder zumindest tolerant gegenüber IPv6-Adressen in HTTP-Headern, vorausgesetzt, Haproxy befindet sich im HTTP-Modus.
Wer und welcher Client plötzlich IPv6-fähig ist, kann manchmal durch Recherche des Präfixes aufschlussreich werden. Die letzte Zifferngruppe dieser IPv6-Adresse ist zu lang, aber diePräfix wird von Google verwaltet, offenbar fürGoogle Chrome Prefetch-Proxy. Google und Cloudflare aktivieren IPv6 für ihre Benutzer, Sie erhalten also ja IPv6-Adressen.