Wie behebe ich HTTP-502-Fehler bei Application Load Balancer?

Kurzbeschreibung

Es gibt mehrere mögliche Ursachen für HTTP 502: Bad Gateway-Fehler, und die Quelle kann entweder Ihr Ziel oder Ihr Application Load Balancer sein. Zum Identifizieren der Fehlerquelle verwenden Sie Amazon-CloudWatch-Metriken und Zugriffsprotokolle.

Bevor Sie den Fehler in Ihrem Application Load Balancer beheben, sollten Sie die Zugriffsprotokolle aktivieren. Informationen zur Bedeutung der einzelnen Felder im Zugriffsprotokoll finden Sie unter Zugriffsprotokolleinträge.

Wenn es sich beim Ziel um eine AWS Lambda-Funktion handelt, lesen Sie Fehlerbehebung bei HTTP-502-Fehlern, wenn das Ziel eine Lambda-Funktion ist im Abschnitt „Lösung“.

Lösung

Finden der Quelle der HTTP-502-Fehler

Mithilfe von CloudWatch-Metriken

Wenn Datenpunkte unter der Metrik HTTPCode_ELB_502_Count aufgeführt sind, dann ist Ihr Load Balancer die Quelle der HTTP-502-Fehler. Wenn sie unter der Metrik HTTPCode_Target_5XX_Count aufgeführt sind, dann ist Ihr Ziel die Fehlerquelle.

Mithilfe von Zugriffsprotokollen

Wenn der elb_status_code den Wert „502“ und target_status_code den Wert „-“ hat, dann ist Ihr Load Balancer die Quelle der HTTP-502-Fehler. Wenn elb_status_code den Wert „502“ und target_status_code den Wert „502“ hat, dann ist Ihr Ziel die Quelle der Fehler.

Beheben von HTTP-502-Fehlern

Hinweis: Filtern Sie die Zugriffsprotokolle nach elb_status_code = "502" und target_status_code, um die Ursache zu ermitteln. Führen Sie dann die entsprechenden Schritte für Ihren Anwendungsfall aus.

Der Load Balancer erhielt beim Versuch, eine Verbindung herzustellen, einen TCP RST vom Ziel.

Wenn Sie beim Verbindungsaufbau einen TCP RST vom Ziel erhalten, kann der Load Balancer keinen TCP-3-Wege-Handshake mit dem Ziel einrichten. Infolgedessen kann der Load Balancer die Benutzeranforderung nicht an das Ziel weiterleiten.

• Prüfen Sie, ob Datenpunkte für die Metrik TargetConnectionErrorCount vorhanden sind. Diese Metrik stellt die Anzahl der Verbindungen dar, die nicht erfolgreich zwischen dem Load Balancer und dem Ziel hergestellt wurden.
• Prüfen Sie, ob die Felder request_processing_time, target_processing_time und response_processing_time in den Zugriffsprotokollen jeweils auf den Wert -1 gesetzt sind. Dieser Wert bedeutet, dass der Load Balancer die Anforderung nicht an das Ziel senden kann, da er eine erfolgreiche Verbindung benötigt.

Im Folgenden finden Sie ein Beispiel für einen Zugriffsprotokolleintrag:

http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 -1 -1 -1 502 - 86 155 "GET http://example.com:80/ HTTP/1.1"
"curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067" Root=1-58337262-36d228ad5d99923122bbe354"

Hinweis: In diesem Zugriffsprotokolleintrag sind request_processing_time, target_processing_time und response_processing_time jeweils auf den Wert -1 gesetzt.

Der Load Balancer erhielt beim Versuch, eine Verbindung herzustellen, eine unerwartete Antwort vom Ziel, z. B. „ICMP Destination unreachable (Host unreachable)“ (ICMP-Ziel unerreichbar (Host unerreichbar))

• Prüfen Sie, ob die Felder request_processing_time, target_processing_time und response_processing_time in den Zugriffsprotokollen alle auf den Wert -1 gesetzt sind.
• Prüfen Sie, ob Datenverkehr von den Load-Balancer-Subnetzen zu den Zielen am Zielport zulässig ist.

Das Ziel hat die Verbindung mit TCP RST oder TCP FIN geschlossen, während der Load Balancer eine offene Anforderung an das Ziel hatte

Der Load Balancer empfängt eine Anforderung und leitet sie an das Ziel weiter. Das Ziel empfängt die Anforderung und beginnt mit der Verarbeitung, schließt aber die Verbindung zum Load Balancer zu früh. Dies geschieht in der Regel, wenn die Dauer des Keepalive-Timeouts für das Ziel kürzer ist als der Timeout bei Leerlauf des Load Balancers. Stellen Sie sicher, dass die Dauer des Keepalive-Timeouts größer ist als der Wert des Timeouts bei Leerlauf.

Überprüfen Sie die Werte für die Felder request_processing_time, target_processing_time und response_processing_time.

Sehen Sie sich das folgende Beispiel für einen Zugriffsprotokolleintrag an:

http 2022-04-15T16:52:50.757968Z app/my-loadbalancer/50dc6c495c0c9188 192.168.131.39:2817 10.0.0.1:80 0.001 4.205 -1 502 - 94 326 "GET http://example.com:80 HTTP/1.1" "curl/7.51.0" - - arn:aws:elasticloadbalancing:us-east-1:123456789012:targetgroup/my-targets/73e2d6bc24d8a067 "Root=1-58337262-36d228ad5d99923122bbe354"

Hinweis: In diesem Zugriffsprotokolleintrag ist request_processing_time gleich 0,001, target_processing_time gleich 4,205 und response_processing_time gleich -1.

Die Zielantwort ist falsch formatiert oder enthält ungültige HTTP-Header

Führen Sie eine Paketaufzeichnung auf dem Ziel für den Zeitraum des Problems durch, um die Reaktion des Ziels zu verstehen.

Beim Load Balancer ist bei der Verbindung zu einem Ziel ein SSL-Handshake-Fehler oder ein SSL-Handshake-Timeout (10 Sekunden) aufgetreten

Die TCP-Verbindung vom Load Balancer zum HTTPS-Listener des Ziels ist erfolgreich, aber beim anschließenden SSL-Handshake tritt ein Timeout auf. Infolgedessen kann der Load Balancer die Anforderung nicht an das Ziel weiterleiten.

Prüfen Sie, ob die Zielgruppe das HTTPS-Protokoll verwendet. Wenn es das HTTPS-Protokoll nicht verwendet, ist das Timeout beim SSL-Handshake nicht die Ursache des Problems. Wenn die Zielgruppe das HTTPS-Protokoll verwendet, überprüfen Sie die folgenden Punkte:

• Prüfen Sie, ob die Felder request_processing_time, target_processing_time und response_processing_time in den Zugriffsprotokollen alle auf den Wert -1 gesetzt sind.
• Prüfen Sie, ob Datenpunkte für die Metrik TargetTLSNegotiationErrorCount vorhanden sind.
• Führen Sie eine Paketaufzeichnung auf dem Ziel für den Zeitraum des Problems durch, um zu überprüfen, ob das Problem mit einem SSL-Handshake zusammenhängt. Ist dies der Fall, führen Sie die Schritte im Abschnitt Durchführen einer Paketerfassung aus.
• Prüfen Sie, ob die Verschlüsselungen oder Protokolle nicht übereinstimmen.

Verzögerungsfrist der Registrierungsaufhebung für eine Anforderung, die von einem Ziel bearbeitet wurde, dessen Registrierung aufgehoben wurde, ist abgelaufen

Suchen Sie in Ihren CloudTrail-Ereignissen nach einem API-Aufruf mit der Aktion DeregisterTargets während des Zeitraums des Problems. Wenn während des Zeitraums des Problems ein API-Aufruf mit DeregisterTargets erfolgte, wird der Fehler durch ein Ziel verursacht, dessen Registrierung zu früh aufgehoben wurde. Um dieses Problem zu beheben, verlängern Sie die Verzögerungsfrist der Registrierungsaufhebung damit langwierige Vorgänge ohne Fehler abgeschlossen werden können.

Beheben der HTTP-502-Fehler, wenn das Ziel eine Lambda-Funktion ist

Hinweis: Bei fehlgeschlagenen Anforderungen an eine Lambda-Funktion speichert der Load Balancer Lambda-spezifische Fehlergrundcodes im Feld error_reason der Zugriffsprotokolle.

Das Ziel ist eine Lambda-Funktion, und der Antworttext überschreitet 1 MB

• Prüfen Sie, ob ein Datenpunkt für die Metrik LambdaUserError vorhanden ist.
• Prüfen Sie, ob das Feld error_reason im Zugriffsprotokoll des Load Balancers auf LambdaResponseTooLarge gesetzt ist.

Das Ziel ist eine Lambda-Funktion, die nicht reagiert hat, bevor ihr konfiguriertes Timeout erreicht wurde

• Überprüfen Sie die Timeout-Konfiguration der Lambda-Funktion.
• Prüfen Sie, ob ein Datenpunkt für die Metrik LambdaUserError vorhanden ist.
• Prüfen Sie, ob das Feld error_reason im Zugriffsprotokoll des Load Balancers auf LambdaUnhandled gesetzt ist.

Das Ziel ist eine Lambda-Funktion, die einen Fehler zurückgegeben hat, oder die Funktion wurde vom Lambda-Dienst gedrosselt

Wenden Sie sich an den AWS Support, um Informationen zur Servicedrosselung zu erhalten.

Durchführen einer Paketerfassung

Verwenden Sie für Linux den folgenden Befehl:

sudo tcpdump -i any -w filename.pcap

Für Microsoft Windows laden Sie die Wireshark-Anwendung (von der Wireshark-Website) herunter und verwenden Sie sie.

Weitere Informationen finden Sie unter „How do I troubleshoot network performance issues between EC2 Linux or Windows instances in a VPC and an on-premises host over the internet gateway?“ (Wie behebe ich Probleme mit der Netzwerkleistung zwischen EC2-Linux- oder Windows-Instances in einer VPC und einem lokalen Host über das Internet-Gateway?). Lesen Sie die Abschnitte Test packet capture samples using tcpdump (Testen von Paketerfassungsbeispielen mit tcpdump) und Take a packet capture (Erstellen einer Paketerfassung).