Warum wird der Traffic für meine Webinhalte an den falschen CloudFront-Edge-Standort weitergeleitet?
Ich verwende Amazon CloudFront, um meine Webinhalte zu verteilen. Der Traffic auf meine Website wird jedoch an den falschen Edge-Standort weitergeleitet. Wie kann ich das beheben?
Kurzbeschreibung
CloudFront leitet Traffic auf der Grundlage der Preisklasse der Distribution, der zugehörigen Geolocation-Datenbanken und der Unterstützung von EDNS0-Client-Subnetzen weiter. Abhängig von der Kombination dieser Faktoren werden die Besucher Ihrer Website möglicherweise an einen unerwarteten Edge-Standort weitergeleitet. Dies kann die Gesamtlatenz beim Abrufen eines Objekts von einem CloudFront-Edge-Standort erhöhen.
Um Probleme beim Routing zu einer unerwarteten Edge-Position zu beheben, überprüfen Sie Folgendes:
- Die Preisklasse unterstützt die Edge-Lage, die Sie erwarten.
- Der DNS-Resolver unterstützt Anycast-Routing.
- Der DNS-Resolver unterstützt das EDNS0-Client-Subnetz.
Behebung
Die Preisklasse unterstützt die Edge-Lage, die Sie erwarten
Informieren Sie sich über die Edge-Standorte, die in der Preisklasse Ihrer CloudFront-Distribution enthalten sind. Sie können die Preisklasse Ihrer Distribution aktualisieren, wenn Sie andere Edge-Standorte einbeziehen möchten.
Der DNS-Resolver unterstützt Anycast-Routing
Wenn der DNS-Resolver Anycast-Routing unterstützt, verwendet der DNS-Resolver mehrere Edge-Standorte. Dies bedeutet, dass der Edge-Standort eines Anforderers auf einer optimalen Latenz basiert, was zu einem unerwarteten Standort für die IP-Adresse des Resolvers führen kann.
Um zu überprüfen, ob der DNS-Resolver Anycast unterstützt, führen Sie einen der folgenden Befehle mehrmals aus:
Hinweis: Ersetzen Sie in diesen Beispielbefehlen example.com unbedingt durch den DNS-Resolver-Domainnamen, den Sie verwenden.
Führen Sie unter Linux oder macOS einen Befehl dig aus, der dem folgenden ähnelt:
dig +nocl TXT o-o.myaddr.l.example.com
Führen Sie unter Windows einen nslookup-Befehl aus, der dem folgenden ähnelt:
nslookup -type=txt o-o.myaddr.l.example.com
Wenn die Ausgabe bei jeder Ausführung des Befehls dieselbe IP-Adresse enthält, unterstützt der DNS-Resolver Anycast nicht. Wenn die Ausgabe bei jeder Ausführung des Befehls eine andere IP-Adresse enthält, unterstützt der DNS-Resolver Anycast. Dies könnte eine unerwartete Kantenposition erklären.
Der DNS-Resolver unterstützt das EDNS0-Client-Subnetz
Um herauszufinden, wie Sie falsches Routing vermeiden können, überprüfen Sie zunächst, ob der DNS-Resolver EDNS0-Client-Subnet unterstützt, indem Sie einen der folgenden Befehle ausführen:
Hinweis: Ersetzen Sie in diesen Beispielbefehlen example.com unbedingt durch den DNS-Resolver-Domainnamen, den Sie verwenden.
Führen Sie unter Linux oder macOS einen Befehl dig aus, der dem folgenden ähnelt:
dig +nocl TXT o-o.myaddr.l.example.com
Führen Sie unter Windows einen nslookup-Befehl aus, der dem folgenden ähnelt:
nslookup -type=txt o-o.myaddr.l.example.com
Hinweis: Überprüfen Sie den TTL-Wert und stellen Sie sicher, dass Sie den Befehl ausführen, wenn der TTL-Wert abgelaufen ist. Andernfalls erhalten Sie möglicherweise eine zwischengespeicherte Antwort vom rekursiven Resolver.
Wenn der DNS-Resolver das EDNS0-Client-Subnetz nicht unterstützt, sieht die Ausgabe ähnlich wie folgt aus:
$ dig +nocl TXT o-o.myaddr.l.example.com +short "192.0.2.1"
Im vorherigen Beispiel ist 192.0.2.1 die IP-Adresse des nächstgelegenen DNS-Servers, der Anycast verwendet. Dieser DNS-Resolver unterstützt kein EDNS0-Client-Subnetz. Um falsches Routing zu vermeiden, können Sie einen der folgenden Schritte ausführen:
- Wechseln Sie zu einem DNS-Resolver zu einem rekursiven DNS-Resolve, der sich geografisch näher an den Kunden Ihrer Website befindet.
- Wechseln Sie zu einem DNS-Resolver, der das EDNS0-Client-Subnetz unterstützt.
Wenn der DNS-Resolver das EDNS0-Client-Subnetz unterstützt, enthält die Ausgabe ein verkürztes Client-Subnetz (/24 oder /32) zum autoritativen CloudFront-Nameserver, ähnlich dem Folgenden:
$ dig +nocl TXT o-o.myaddr.l.example.com @8.8.8.8 +short "192.0.2.1" "edns0-client-subnet 198.51.100.0/24"
Im vorherigen Beispiel ist 192.0.2.1 die nächstgelegene DNS-Resolver-IP-Adresse. Darüber hinaus beträgt der Client-Subnetzbereich 198.51.100.0/24, der für die Beantwortung von DNS-Abfragen verwendet wird. Um falsches Routing zu vermeiden, wenn der DNS-Resolver das EDNS0-Client-Subnetz unterstützt, stellen Sie sicher, dass eine öffentliche Geolocation-Datenbank mit dem Client-Subnetzbereich verknüpft ist, der die Anfrage an den DNS-Resolver sendet. Wenn der DNS-Resolver die gekürzte Version der Client-IP-Adressen an CloudFront-Nameserver weiterleitet, überprüft CloudFront eine Datenbank, die auf mehreren öffentlichen Geolocation-Datenbanken basiert. Die IP-Adressen müssen in der Geolocation-Datenbank korrekt zugeordnet sein, damit Anfragen korrekt weitergeleitet werden.
Wenn der DNS-Resolver das EDNS0-Client-Subnetz unterstützt, können Sie den Edge-Standort überprüfen, zu dem der Datenverkehr weitergeleitet wird, indem Sie zuerst Ihren CloudFront-CNAME auflösen, indem Sie einen DNS-Suchbefehl wie dig ausführen:
$ dig dftex7example.cloudfront.net. +short 13.224.77.109 13.224.77.62 13.224.77.65 13.224.77.75
Führen Sie dann eine umgekehrte DNS-Suche für die IP-Adressen durch, die vom vorherigen Befehl zurückgegeben wurden:
$ dig -x 13.224.77.62 +short server-13-224-77-62.man50.r.cloudfront.net.
Im vorherigen Beispiel wird der Verkehr an den Edge-Standort Manchester weitergeleitet.
Tipp: Für einen zusätzlichen Test können Sie einen öffentlichen DNS-Resolver verwenden, der das EDNS0-Client-Subnetz unterstützt, z. B. 8.8.8.8 oder 8.8.4.4. Senden Sie Abfragen mit Edge-Standort-IP-Adressen an den öffentlichen DNS-Resolver. Überprüfen Sie anschließend die Ergebnisse der DNS-Abfragen, um festzustellen, ob CloudFront über die richtigen Informationen zu Ihrem EDNS0-Client-Subnetz verfügt.
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 8 Monaten
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor einem Jahr