Come posso risolvere i problemi relativi agli errori HTTP 502 di Application Load Balancer?

Breve descrizione

Esistono diverse cause possibili per gli errori HTTP 502: gateway non valido. L'origine dell'errore può provenire dalla destinazione o da Application Load Balancer. Per identificare l'origine dell'errore, utilizza le [metriche e i log di accesso di Amazon CloudWatch](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-cloudwatch-metrics.html).

Prima di risolvere i problemi relativi all'errore da Application Load Balancer, assicurati di abilitare la registrazione degli accessi. Per capire cosa significa ogni campo nel log di accesso, vedi le Voci dei log di accesso.

Se la destinazione è una funzione AWS Lambda, consulta Risoluzione dei problemi relativi agli errori HTTP 502 quando la destinazione è una funzione Lambda nella sezione Risoluzione.

Soluzione

Trova l'origine degli errori HTTP 502

Utilizzo delle metriche CloudWatch

Se i punti dati vengono visualizzati nella metrica HTTPCode_ELB_502_Count, il sistema di bilanciamento del carico è l'origine degli errori HTTP 502. Se compaiono nella metrica HTTPCode_Target_5XX_Count, la destinazione è l'origine.

Utilizzo dei log di accesso

Se elb_status_code è "502" e target_status_code è "-", il sistema di bilanciamento del carico è l'origine degli errori HTTP 502. Se elb_status_code è "502" e target_status_code è "502", la destinazione è l'origine degli errori.

Risoluzione dei problemi relativi agli errori HTTP 502

Nota: Filtra i log di accesso per elb_status_code = "502" e target_status_code per aiutarti a determinare la causa. Quindi, completa i passaggi specifici per il tuo caso d'uso.

Il sistema di bilanciamento del carico ha ricevuto un RST TCP dalla destinazione durante il tentativo di connessione

Potresti ricevere un TCP RST dalla destinazione quando stabilisci una connessione. Questo messaggio viene visualizzato quando il load balancer non riesce a stabilire un handshake TCP a 3 vie con il target. Di conseguenza, il sistema di bilanciamento del carico non può inoltrare la richiesta dell'utente alla destinazione.

Controlla se i campi request_processing_time, target_processing_time e response_processing_time nei log di accesso sono impostati ciascuno sul valore -1. Questo valore indica che il sistema di bilanciamento del carico non può inviare la richiesta alla destinazione perché necessita di una connessione riuscita correttamente.

Di seguito è riportato un esempio di voce del log di accesso:

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"

Nota: In questa voce del log di accesso, request_processing_time, target_processing_time e response_processing_time sono impostati ciascuno su -1.

Il sistema di bilanciamento del carico ha ricevuto una risposta imprevista dalla destinazione, ad esempio "Destinazione ICMP non raggiungibile (Host non raggiungibile)" durante il tentativo di connessione

• Verifica se i campi request_processing_time, target_processing_time e response_processing_time nei log di accesso sono tutti impostati sul valore -1.
• Verifica se il traffico è consentito dalle sottoreti del sistema di bilanciamento del carico alle destinazioni sulla porta di destinazione.

La destinazione ha chiuso la connessione con un RST TCP o un FIN TCP mentre il sistema di bilanciamento del carico aveva una richiesta in sospeso verso la destinazione

Il sistema di bilanciamento del carico riceve una richiesta e la inoltra alla destinazione. La destinazione riceve la richiesta e inizia a elaborarla, ma chiude la connessione al sistema di bilanciamento del carico troppo presto. Ciò si verifica in genere quando la durata del timeout keep-alive per la destinazione è inferiore al valore del timeout di inattività del sistema di bilanciamento del carico. Assicurati che la durata del timeout keep-alive sia maggiore del valore del timeout di inattività.

Verifica i valori per i campi request_processing_time, target_processing_time e response_processing_time.

Vedi il seguente esempio di voce del log di accesso:

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"

Nota: In questa voce del log di accesso, request_processing_time è 0.001, target_processing_time è 4.205 e response_processing_time è -1.

La risposta della destinazione non è conforme o contiene intestazioni HTTP non valide

Esegui un'acquisizione di pacchetti sulla destinazione per l'intervallo di tempo in cui si è verificato il problema per comprendere la risposta della destinazione.

Il sistema di bilanciamento del carico ha rilevato un errore dell'handshake SSL o un timeout dell'handshake SSL (10 secondi) durante la connessione a una destinazione

La connessione TCP dal sistema di bilanciamento del carico all'ascoltatore HTTPS del target è stata eseguita con successo, ma il successivo handshake SSL è scaduto. Di conseguenza, il sistema di bilanciamento del carico non può inoltrare la richiesta alla destinazione.

Verifica se il gruppo di destinazione utilizza il protocollo HTTPS. In caso contrario, il timeout dell'handshake SSL non è la causa del problema. Se il gruppo di destinazione utilizza il protocollo HTTPS, controlla i seguenti punti:

• Verifica se i campi request_processing_time, target_processing_time e response_processing_time nei log di accesso sono tutti impostati sul valore -1.
• Verifica se sono presenti punti dati per la metrica TargetTLSNegotiationErrorCount.
• Esegui un'acquisizione di pacchetti sulla destinazione per il periodo di tempo in cui si è verificato il problema per controllare che sia correlato a un handshake SSL. In tal caso, completa i passaggi nella sezione Eseguire una acquisizione di pacchetti.
• Verifica che i cifrari o i protocolli corrispondano.

Il periodo di ritardo per l'annullamento della registrazione è scaduto per una richiesta gestita da una destinazione per cui è stata annullata la registrazione

Nei tuoi eventi CloudTrail, verifica la presenza di una chiamata API con l'azione DeregisterTargets durante l'intervallo di tempo in cui si è verificato il problema. Una chiamata API con DeregisterTargets che si verifica durante l'intervallo di tempo del problema causa un errore. Questo errore si verifica quando la registrazione della destinazione è stata annullata troppo presto. Per risolvere questo problema, aumenta il periodo di ritardo di annullamento della registrazione in modo che le operazioni lunghe possano essere completate senza errori.

Risoluzione degli errori HTTP 502 quando la destinazione è una funzione Lambda

Nota: per le richieste a una funzione Lambda che hanno esito negativo, il sistema di bilanciamento del carico archivia i codici di motivo dell'errore specifici di Lambda nel campo error_reason dei log di accesso.

La destinazione è una funzione Lambda e il corpo della risposta supera 1 MB

• Verifica se è presente un punto dati per la metrica LambdaUserError.
• Verifica se il campo error_reason nel log di accesso del sistema di bilanciamento del carico è impostato su LambdaResponseTooLarge.

La destinazione è una funzione Lambda che non ha risposto entro il raggiungimento del timeout configurato

• Verifica la configurazione del timeout della funzione Lambda.
• Verifica se è presente un punto dati per la metrica LambdaUserError.
• Verifica se il campo error_reason nel log di accesso del sistema di bilanciamento del carico è impostato su LambdaUnhandled.

La destinazione è una funzione Lambda che ha restituito un errore oppure la funzione è stata limitata dal servizio Lambda

• Verifica che ci sia un punto dati per la metrica Limitatori.
• Contatta Supporto AWS per ricevere indicazioni sulla limitazione del servizio.

Esegui un’acquisizione di pacchetti

Per Linux, usa il seguente comando:

sudo tcpdump -i any -w filename.pcap

Per Microsoft Windows, scarica e utilizza l'applicazione Wireshark (dal sito Web Wireshark).

Per istruzioni su come testare campioni di acquisizione di pacchetti con tcpdump o acquisire un pacchetto di acquisizione, vedi How do I troubleshoot network performance issues between EC2 Linux or Windows instances in an Amazon Virtual Private Cloud and an on-premises host over the internet gateway?