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

Lösung

Die Quelle der HTTP-502-Fehler identifizieren

Es gibt mehrere mögliche Ursachen für HTTP 502: Bad gateway-Fehler. Die Fehlerquelle kann dein Ziel oder dein Load Balancer sein. Zum Identifizieren der Fehlerquelle verwende CloudWatch-Metriken oder Zugriffsprotokolle.

CloudWatch-Metriken verwenden

Wenn die HTTPCode_ELB_502_Count-Metrik Datenpunkte aufweist, dann ist dein Load Balancer die Fehlerquelle. Wenn die HTTPCode_Target_5XX_Count-Metrik Datenpunkte aufweist, dann ist dein Ziel die Fehlerquelle.

Zugriffsprotokolle verwenden

Wenn der elb_status_code den Wert „502“ und target_status_code den Wert „-“ hat, dann ist dein Load Balancer die Fehlerquelle. Wenn elb_status_code den Wert „502“ und target_status_code den Wert „502“ hat, dann ist dein Ziel die Fehlerqueller.

Beheben von HTTP-502-Fehlern

Filtere die Zugriffsprotokolle nach elb_status_code = "502" und target_status_code, um die Ursache zu ermitteln. Vervollständige dann die Lösung für das Problem, das bei dir auftritt.

Der Load Balancer erhält ein TCP RST vom Ziel, wenn der Load Balancer versucht, eine Verbindung aufzubauen

Möglicherweise erhältst du eine TCP RST-Meldung vom Ziel, wenn du eine Verbindung aufbaust. Diese Meldung wird angezeigt, wenn der Load Balancer keinen 3-Wege-TCP-Handshake mit dem Ziel einrichten kann. Infolgedessen kann der Load Balancer die Benutzeranforderung nicht an das Ziel weiterleiten.

Überprüfe die Metrik TargetConnectionErrorCount auf Datenpunkte, die zeigen, dass das Ziel Verbindungen vom Load Balancer mit einem TCP RST ablehnt.

Setze in den Zugriffsprotokollen die Felder request_processing_time, target_processing_time und response_processing_time auf einen Wert von -1. Wenn du den Wert auf -1 setzt, kann der Load Balancer die Anfrage nicht an das Ziel senden, weil du den Load Balancer verbinden musst.

Nachfolgend ein Beispiel für einen Zugriffsprotokolleintrag, bei dem die Werte für request_processing_time, target_processing_time und response_processing_time auf -1 gesetzt sind:

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"

Der Load Balancer erhält eine unerwartete Antwort vom Ziel, z. B. „ICMP Destination unreachable (Host unreachable)“, wenn der Load Balancer versucht, eine Verbindung herzustellen

Setze die Felder request_processing_time, target_processing_time und response_processing_time in den Zugriffsprotokollen auf einen Wert von -1. Bestätige dann, dass die Load Balancer-Subnetze den Verkehr zu den Zielen auf dem Zielport zulassen.

Das Ziel schließt die Verbindung mit einer TCP RST- oder einer TCP FIN-Nachricht, wenn der Load Balancer eine ausstehende Anfrage an das Ziel hat

Der Load Balancer empfängt eine Anfrage und leitet sie an das Ziel weiter. Das Ziel beginnt mit der Bearbeitung der Anfrage, schließt aber die Verbindung zum Load Balancer zu früh. Dies tritt auf, wenn die Dauer des Keepalive-Timeouts, den du auf dem Ziel konfiguriert hast, kürzer ist als der Wert des Timeouts bei Leerlauf des Load Balancers. Stelle sicher, dass die Dauer des Keepalive-Timeouts länger ist als der Wert des Timeouts bei Leerlauf.

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

Um die Antwort des Ziels zu untersuchen, führe eine Paketaufzeichnung des Ziels für den Zeitraum, in dem das Problem auftritt, durch.

Um eine Paketaufzeichnung für Linux durchzuführen, führe den folgenden Befehl aus:

sudo tcpdump -i any -w filename.pcap

Wichtig: Wenn die Ziel-Instance ein hohes Verkehrsaufkommen hat, kann die von der tcpdump-Sammlung erzeugte Packet-Capture-Datei (PCAP) den Speicherplatz beeinträchtigen. Ein hohes Verkehrsaufkommen kann sich auch auf die Services deiner Ziel-Instance auswirken.

Lade für Microsoft Windows die Wireshark-Anwendung auf der Wireshark-Website herunter und verwende sie.

Informationen zur Verwendung von tcpdump zum Testen von Paketaufzeichnungsproben findest du unter Wie behebe ich Netzwerkleistungsprobleme zwischen Amazon Elastic Compute Cloud (Amazon EC2) Linux- oder Windows-Instances in einer Amazon Virtual Private Cloud (Amazon VPC) und einem On-Premises-Host über das Internet-Gateway?

Der Load Balancer stößt auf einen SSL-Handshake-Fehler, wenn er sich mit einem Ziel verbindet

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

Wenn die Zielgruppe das HTTPS-Protokoll verwendet, führe eine Paketaufzeichnung auf dem Ziel für den Zeitraum des Problems durch.

Dein Server muss eine TLS-Cipher-Suite verwenden, die von der Sicherheitsrichtlinie, die dein Load Balancer für Backend-Verbindungen verwendet, unterstützt wird.

Die verstrichene Verzögerungszeit für eine Anfrage, die ein abgemeldetes Ziel verwaltet

Suche in deinen AWS CloudTrail-Ereignissen nach der DeregisterTargets-API während des Zeitraums des Problems. Wenn das Ziel zu früh abgemeldet wurde, tritt ein HTTP 502-Fehler auf. Um dieses Problem zu beheben, verlängere die Verzögerungsfrist der Abmeldung damit langwierige Vorgänge abgeschlossen werden können.

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

Überprüfe bei fehlgeschlagenen Anfragen an eine AWS Lambda-Funktion die Lambda-Fehlergrundcodes im Feld error_reason in den Zugriffsprotokollen des Load Balancer.

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

Um das Problem zu bestätigen, prüfe, ob es einen Datenpunkt für die Metrik LambdaUserError gibt. Alternativ kannst du prüfen, ob das Feld error_reason im Zugriffsprotokoll des Load Balancers auf LambdaResponseTooLarge gesetzt ist.

Um das Problem zu beheben, aktualisiere deinen Lambda-Code und füge Logik zur Fehlerbehandlung hinzu.

Das Ziel ist eine Lambda-Funktion, die nicht vor dem konfigurierten Timeout geantwortet hat

Um das Problem zu bestätigen, prüfe, ob es einen Datenpunkt für die Metrik LambdaUserError gibt. Prüfe alternativ, 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 Lambda hat die Funktion gedrosselt

Um festzustellen, ob Lambda die Funktion gedrosselt hat, prüfe die Metrik Drosselungen für einen Datenpunkt. Wenn Lambda die Funktion gedrosselt hat, verwende AWS Service Quotas, um eine Kontingenterhöhung für die gleichzeitige Ausführung von Lambda anzufordern.

Weitere Informationen findest du unter Lambda-Aufrufdrosselungsgrenzen verstehen.