Como soluciono os erros HTTP 502 do Application Load Balancer?

Resolução

Identificar a origem dos erros HTTP 502

Há várias causas possíveis para os erros HTTP 502: Bad Gateway. A origem do erro pode ser seu destino ou seu balanceador de carga. Para identificar a origem do erro, use métricas do CloudWatch ou logs de acesso.

Usar métricas do CloudWatch

Se a métrica HTTPCode_ELB_502_Count tiver pontos de dados, seu balanceador de carga será a origem do erro. Se a métrica HTTPCode_Target_5XX_Count tiver pontos de dados, seu destino é a origem dos erros.

Usar logs de acesso

Se elb_status_code é “502” e target_status_code é ”-”, então o balanceador de carga é a origem do erro. Se elb_status_code é “502” e target_status_code é “502”, então o destino é a origem do erro.

Solucionar erros de HTTP 502

Para determinar a causa, filtre os logs de acesso por elb_status_code = "502" e target_status_code. Em seguida, conclua a resolução do problema que você está enfrentando.

O balanceador de carga recebe um TCP RST do destino quando tenta estabelecer uma conexão

Você pode receber uma mensagem TCP RST do destino ao estabelecer uma conexão. Essa mensagem aparece quando o balanceador de carga não consegue estabelecer um handshake TCP tridirecional com o destino. Como resultado, o balanceador de carga não poderá encaminhar a solicitação do usuário para o destino.

Verifique a métrica TargetConnectionErrorCount quanto aos pontos de dados que mostram que o destino está rejeitando conexões do balanceador de carga com um TCP RST.

Nos logs de acesso, defina os campos request_processing_time, target_processing_time e response_processing_time com o valor -1. Quando você define o valor como \ -1, o balanceador de carga não pode enviar a solicitação ao destino porque você precisa conectar o balanceador de carga.

Veja a seguir um exemplo de uma entrada de log de acesso que tem request_processing_time, target_processing_time e response_processing_time definidos como -1:

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"

O balanceador de carga recebe uma resposta inesperada do destino, como “Destino ICMP inacessível (Host inacessível)”, quando o balanceador de carga tenta se conectar

Defina os campos request_processing_time, target_processing_time e response_processing_time nos logs de acesso com o valor -1. Em seguida, confirme se as sub-redes do balanceador de carga permitem tráfego para os destinos na porta de destino.

O destino fecha a conexão com uma mensagem TCP, RST ou TCP FIN quando o balanceador de carga tem uma solicitação pendente para o destino

O balanceador de carga recebe uma solicitação e a encaminha para o destino. O destino começa a processar a solicitação, mas fecha a conexão com o balanceador de carga muito cedo. Isso ocorre quando a duração do tempo limite de manutenção de atividade que você configurou no destino é menor do que o valor do tempo limite de inatividade do balanceador de carga. Certifique-se de que a duração do tempo limite de manutenção de atividade seja maior do que o valor do tempo limite de inatividade.

A resposta de destino está malformada ou contém cabeçalhos HTTP que não são válidos

Para solucionar o problema da resposta de destino, realize uma captura de pacote no destino durante o período do problema.

Para realizar uma captura de pacotes para Linux, execute o seguinte comando:

sudo tcpdump -i any -w filename.pcap

Importante: Se a instância de destino tiver uma grande quantidade de tráfego, o arquivo Packet Capture (PCAP) gerado pela coleção tcpdump poderá afetar seu espaço em disco. Uma grande quantidade de tráfego também pode afetar os serviços da sua instância de destino.

Para Windows, baixe e use a aplicação Wireshark no site da Wireshark.

Para usar tcpdump para testar amostras de captura de pacotes, consulte Como soluciono problemas de desempenho de rede entre instâncias Linux ou Windows do Amazon Elastic Compute Cloud (Amazon EC2) em uma Amazon Virtual Private Cloud (Amazon VPC) e um host on-premises pelo gateway da Internet?

O balanceador de carga encontra um erro de handshake SSL ao se conectar a um destino

A conexão TCP do balanceador de carga com o receptor HTTPS do destino foi bem-sucedida, mas o handshake SSL subsequente encontra um erro. Como resultado, o balanceador de carga não pode encaminhar a solicitação para o destino.

Se o grupo de destino usar o protocolo HTTPS, execute uma captura de pacotes no destino durante o período do problema.

Seu servidor deve usar um conjunto de cifras TLS compatível com a política de segurança que seu balanceador de carga usa para conexões de back-end.

O período de atraso no cancelamento do registro expirou para uma solicitação gerenciada por um destino com registro cancelado

Em seus eventos do AWS CloudTrail, verifique a ação da API DeRegisterTargets durante o período do problema. Se o registro do destino for cancelado muito cedo, ocorrerá um erro HTTP 502. Para resolver o problema, aumente o período de atraso do cancelamento do registro para que operações demoradas possam ser concluídas.

Solucionar erros HTTP 502 quando o destino é uma função do Lambda

Para solicitações que apresentam falha em uma função do AWS Lambda, verifique os códigos de motivo de erro do Lambda no campo error_reason dos logs de acesso do balanceador de carga.

O destino é uma função do Lambda e o corpo da resposta excede 1 MB

Para confirmar o problema, verifique se há um ponto de dados na métrica LambdaUserError. Ou verifique se o campo error_reason no log de acesso do balanceador de carga está definido como LambdaResponseTooLarge.

Para solucionar o problema, atualize o código do Lambda e adicione a lógica de tratamento de erros.

O destino é uma função do Lambda que não respondeu antes do tempo limite configurado

Para confirmar o problema, verifique se há um ponto de dados na métrica LambdaUserError. Ou verifique se o campo error_reason no log de acesso do balanceador de carga está definido como LambdaUnhandled.

O destino é uma função do Lambda que retornou um erro, ou o Lambda limitou a função

Para confirmar se o Lambda limitou a função, verifique a métrica Throttles para ver se há um ponto de dados. Se o Lambda limitou a função, use as Service Quotas da AWS para solicitar um aumento de cota para a execução simultânea do Lambda.

Para mais informações, consulte Entender os limites de controle de utilização de invocação do Lambda.