HTTP 504-Statuscode (Gateway Timeout)

Ein HTTP 504-Statuscode (Gateway-Timeout) gibt an, dass bei der CloudFront Weiterleitung einer Anfrage an den Ursprung (weil sich das angeforderte Objekt nicht im Edge-Cache befand) einer der folgenden Fälle eingetreten ist:

• Der Ursprung hat einen HTTP 504-Statuscode an CloudFront zurückgegeben.

• Der Ursprung reagierte nicht, bevor die Anforderung ablief.

CloudFront gibt einen HTTP 504-Statuscode zurück, wenn der Datenverkehr zum Ursprung durch eine Firewall oder Sicherheitsgruppe blockiert wird oder wenn der Ursprung im Internet nicht zugänglich ist. Überprüfen Sie diese Punkte zuerst. Wenn der Zugriff nicht das Problem ist, sehen Sie sich Anwendungsverzögerungen und Server-Timeouts an, um die Probleme zu ermitteln und zu beheben.

Konfigurieren Sie die Firewall auf Ihrem Ursprungsserver so, dass CloudFront Datenverkehr zugelassen wird

Wenn die Firewall auf Ihrem Ursprungsserver den CloudFront Datenverkehr blockiert, wird ein HTTP-504-Statuscode CloudFront zurückgegeben. Stellen Sie daher sicher, dass dies nicht das Problem ist, bevor Sie nach anderen Problemen suchen.

Die Methode, die Sie nutzen, um zu bestimmen, ob es sich um ein Problem mit Ihrer Firewall handelt, hängt davon ab, welches System Ihr Ursprungs-Server verwendet:

• Wenn Sie eine IPTable Firewall auf einem Linux-Server verwenden, können Sie nach Tools und Informationen suchen, die Ihnen bei der Arbeit helfen IPTables.

• Wenn Sie die Windows-Firewall auf einem Windows-Server verwenden, finden Sie weitere Informationen unter Hinzufügen oder Bearbeiten einer Firewallregel in der Microsoft-Dokumentation.

Wenn Sie die Firewall-Konfiguration auf Ihrem Ursprungsserver auswerten, sollten Sie auf der Grundlage des veröffentlichten IP-Adressbereichs nach Firewalls oder Sicherheitsregeln Ausschau halten, die den Datenverkehr von CloudFront Edge-Standorten blockieren. Weitere Informationen finden Sie unter Standorte und IP-Adressbereiche von Edge-Servern CloudFront .

Wenn der CloudFront IP-Adressbereich eine Verbindung zu Ihrem Ursprungsserver herstellen darf, stellen Sie sicher, dass Sie die Sicherheitsregeln Ihres Servers aktualisieren, um die Änderungen zu berücksichtigen. Sie können ein Amazon-SNS-Thema abonnieren und Benachrichtigungen erhalten, wenn die IP-Adressbereichsdatei aktualisiert wird. Nachdem Sie die Benachrichtigung erhalten haben, können Sie Code verwenden, um die Datei abzurufen, sie zu analysieren und ggf. Anpassungen Ihrer lokalen Umgebung vorzunehmen. Weitere Informationen finden Sie im AWS News-Blog unter AWS Öffentliche IP-Adressänderungen über Amazon SNS abonnieren.

Konfigurieren Sie die Sicherheitsgruppen auf Ihrem Ursprungsserver, um Datenverkehr zuzulassen CloudFront

Wenn Ihr Origin Elastic Load Balancing verwendet, überprüfen Sie die ELB-Sicherheitsgruppen und stellen Sie sicher, dass die Sicherheitsgruppen eingehenden CloudFront Datenverkehr zulassen.

Sie können Ihre Sicherheitsgruppen auch automatisch aktualisieren, um eingehenden Datenverkehr von zuzulassen. AWS Lambda CloudFront

Erlauben des Zugriffs auf Ihren benutzerdefinierten Ursprungsserver über das Internet

Wenn Sie nicht auf Ihren benutzerdefinierten Ursprungsserver zugreifen CloudFront können, weil er nicht öffentlich im Internet verfügbar ist, wird ein HTTP 504-Fehler CloudFront zurückgegeben.

CloudFront Edge-Standorte stellen über das Internet eine Verbindung zu den Ursprungsservern her. Wenn sich Ihr benutzerdefinierter Ursprung in einem privaten Netzwerk befindet, CloudFront kann er nicht erreicht werden. Aus diesem Grund können Sie private Server, einschließlich interner Classic Load Balancer, nicht als Ursprungsserver mit CloudFront verwenden.

Um zu überprüfen, ob der Internetverkehr eine Verbindung zu Ihrem Ursprungsserver herstellen kann, führen Sie die folgenden Befehle aus (wo OriginDomainName ist der Domainname für Ihren Server):

Für HTTPS-Datenverkehr:

• nc -zv 443 OriginDomainName

• Telnet 443 OriginDomainName

Für HTTP-Datenverkehr:

• NC-ZV 80 OriginDomainName

• Telnet 80 OriginDomainName

Suchen und Beheben verzögerter Antworten von Anwendungen auf Ihrem Ursprungsserver

Server-Timeouts sind häufig das Ergebnis einer Anwendung, die recht lange braucht, um zu reagieren, oder eines Timeout-Werts, der zu niedrig eingestellt ist.

Eine schnelle Abhilfe zum Vermeiden des HTTP-Fehlers 504 besteht darin, einen höheren CloudFront-Timeout-Wert für Ihre Verteilung festzulegen. Wir empfehlen jedoch, dass Sie zunächst sicherstellen, dass Sie alle Leistungs- und Latenzprobleme mit der Anwendung und dem Ursprungs-Server beheben. Anschließend können Sie einen angemessenen Timeout-Wert festlegen, der zur Vermeidung des HTTP-Fehlers 504 beiträgt und eine gute Reaktionsfähigkeit für Benutzer bietet.

Im Folgenden finden Sie eine Übersicht über die Schritte, die Sie ausführen können, um Leistungsprobleme zu ermitteln und zu beheben:

1. Messen Sie die normale Latenz und die Latenz bei hoher Last (Reaktionsfähigkeit) Ihrer Webanwendung.

2. Fügen Sie weitere Ressourcen, z. B. CPU oder Speicher (bei Bedarf) hinzu. Führen Sie andere Schritte aus, um die Probleme zu beheben, z. B. Optimierung von Datenbankabfragen für Szenarien mit hoher Last.

3. Passen Sie bei Bedarf den Timeout-Wert für Ihre CloudFront Distribution an.

Im Folgenden finden Sie Details zu jedem einzelnen Schritt.

Messen der normalen Latenz und der Latenz bei hoher Last

Um festzustellen, ob auf einem oder mehreren Backend-Webanwendungsservern eine hohe Latenz vorliegt, führen Sie den folgenden Linux curl-Befehl auf jedem Server aus:

curl -w "DNS Lookup Time: %{time_namelookup} \nConnect time: %{time_connect} \nTLS Setup: %{time_appconnect} \nRedirect Time: %{time_redirect} \nTime to first byte: %{time_starttransfer} \nTotal time: %{time_total} \n" -o /dev/null https://www.example.com/yourobject

Anmerkung

Wenn Sie Windows auf Ihren Servern ausführen, können Sie curl für Windows suchen und herunterladen, um einen entsprechenden Befehl auszuführen.

Beachten Sie beim Messen und Auswerten der Latenz einer Anwendung, die auf Ihrem Server ausgeführt wird, folgende Punkte:

• Latenzwerte sind für jede Anwendung relativ. Allerdings ist eine Zeit bis zum ersten Byte in Millisekunden statt Sekunden oder mehr sinnvoll.

• Wenn Sie die Anwendungslatenz unter normalen Lastbedingungen messen und das Ergebnis in Ordnung ist, sollten Sie daran denken, dass bei Viewern dennoch Timeouts bei hoher Last auftreten können. Wenn eine hohe Nachfrage besteht, können Server Antworten verzögert senden oder gar nicht reagieren. Überprüfen Sie zur Vermeidung von Latenzproblemen bei hoher Last Ihre Serverressourcen wie CPU, Arbeitsspeicher sowie Lese- und Schreibvorgänge auf Speichermedien, um sicherzustellen, dass Ihre Server über die Kapazitäten zur Skalierung für hohe Auslastung verfügen.

  Sie können den folgenden Linux-Befehl zum Überprüfen des Speichers ausführen, der von Apache-Prozessen verwendet wird:

  watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"

• Eine hohe CPU-Auslastung auf dem Server kann die Leistung einer Anwendung erheblich reduzieren. Wenn Sie eine EC2 Amazon-Instance für Ihren Backend-Server verwenden, überprüfen Sie die CloudWatch Metriken für den Server, um die CPU-Auslastung zu überprüfen. Weitere Informationen finden Sie im CloudWatch Amazon-Benutzerhandbuch. Oder wenn Sie Ihren eigenen Server verwenden, finden Sie in der Server-Hilfedokumentation Anweisungen zur Überprüfung der CPU-Auslastung.

• Überprüfen Sie, ob andere potenzielle Probleme unter hoher Last vorliegen, wie beispielsweise Datenbankabfragen, die bei einem hohen Volume von Anfragen langsam ausgeführt werden.

Hinzufügen von Ressourcen und Optimieren von Servern und Datenbanken

Nachdem Sie die Reaktionsfähigkeit Ihrer Anwendungen und Server bewertet haben, stellen Sie sicher, dass Sie über ausreichend Ressourcen für normalen Datenverkehr und Situationen mit hoher Auslastung verfügen:

• Wenn Sie einen eigenen Server nutzen, stellen Sie basierend auf Ihrer Bewertung sicher, dass dieser über ausreichend CPU, Arbeitsspeicher und Festplattenspeicher für die Verarbeitung von Viewer-Anfragen verfügt.

• Wenn Sie eine EC2 Amazon-Instance als Backend-Server verwenden, stellen Sie sicher, dass der Instance-Typ über die entsprechenden Ressourcen verfügt, um eingehende Anfragen zu bearbeiten. Weitere Informationen finden Sie unter Instance-Typen im EC2 Amazon-Benutzerhandbuch.

Außerdem sollten Sie ggf. die folgenden Optimierungsschritte ausführen, um Timeouts zu vermeiden:

• Wenn der Wert für die Zeit bis zum ersten Byte, der vom curl-Befehl zurückgegeben wird, hoch erscheint, ergreifen Sie Maßnahmen zur Verbesserung der Leistung Ihrer Anwendung. Durch Verbessern der Anwendungsreaktionsfähigkeit lassen sich wiederum Timeout-Fehler reduzieren.

• Optimieren Sie Datenbankabfragen, um sicherzustellen, dass sie hohe Abfragezahlen verarbeiten können, ohne dass die Leistung beeinträchtigt wird.

• Richten Sie (persistente) Keepalive-Verbindungen auf Ihrem Backend-Server ein. Mit dieser Option lassen sich Latenzen vermeiden, die auftreten, wenn Verbindungen für nachfolgende Anfragen oder Benutzer erneut hergestellt werden müssen.

• Wenn Sie Elastic Load Balancing als Ausgangspunkt verwenden, sind die folgenden möglichen Ursachen für einen 504-Fehler:

  • Der Load Balancer kann vor Ablauf des Verbindungs-Timeouts (10 Sekunden) keine Verbindung zum Ziel herstellen.

  • Der Load Balancer stellt eine Verbindung zum Ziel her, aber das Ziel reagiert nicht, bevor das Leerlauf-Timeout abgelaufen ist.

  • Die Network Access Control List (ACL) für das Subnetz lässt keinen Datenverkehr von den Zielen zu den Load Balancer-Knoten an den kurzlebigen Ports (1024-65535) zu.

  • Das Ziel gibt einen Inhaltslängen-Header zurück, der größer ist als der Entitätskörper. Der Load Balancer hat beim Warten auf die fehlenden Bytes eine Zeitüberschreitung.

  • Das Ziel ist eine Lambda-Funktion und Lambda reagiert nicht, bevor das Verbindungstimeout abgelaufen ist.

  Weitere Informationen zur Reduzierung der Latenz finden Sie unter Wie behebe ich Probleme mit hoher Latenz auf meinem ELB Classic Load Balancer?

• Wenn Sie die Datei MediaTailor als Ursprung verwenden, sind die folgenden möglichen Ursachen für einen 504-Fehler:

  • Wenn Verwandte falsch behandelt URLs werden, MediaTailor kann es zu Fehlbildungen URLs von Spielern kommen.

  • Wenn dies der offensichtliche Ursprung für MediaPackage ist MediaTailor, können offensichtliche MediaPackage 404-Fehler MediaTailor dazu führen, dass ein 504-Fehler zurückgegeben wird.

  • Es dauert mehr als 2 Sekunden, bis die Anfrage an den MediaTailor Ursprungsserver abgeschlossen ist.

• Wenn Sie Amazon API Gateway als Quelle verwenden, ist Folgendes eine mögliche Ursache für einen 504-Fehler:

  • Eine Integrationsanforderung dauert länger als der maximale Integrationstimeout-Parameter Ihres API-Gateway-REST-API-Parameters. Weitere Informationen finden Sie unter Wie kann ich API-HTTP-504-Timeout-Fehler mit API Gateway beheben?

Passen Sie bei Bedarf den CloudFront Timeout-Wert an

Wenn Sie eine langsame Anwendungsleistung, Ursprungs-Serverkapazität und weitere Probleme festgestellt und behoben haben, die Viewer aber weiterhin den HTTP-Fehler 504 erhalten, sollten Sie in Betracht ziehen, die Zeit, die in Ihrer Verteilung als Ursprungs-Reaktions-Timeout angegeben ist, zu ändern. Weitere Informationen finden Sie unter Antwort-Timeout (nur benutzerdefinierte und VPC-Ursprünge).