Como soluciono problemas de erros HTTP 502 do Application Load Balancer?

Data da última atualização: 17/5/2022

Eu continuo recebendo erros HTTP 502 com o meu Application Load Balancer. Como corrigir esses erros?

Breve descrição

Há várias causas possíveis para erros HTTP 502: gateway inválido e a fonte pode ser do seu destino ou do Application Load Balancer. Você pode usar métricas e logs de acesso do Amazon CloudWatch para identificar a fonte e a causa do erro.

Antes de começar a solucionar o erro do Application Load Balancer, certifique-se de habilitar o registro de acesso. Para entender o que cada campo significa no log de acesso, consulte Entradas do log de acesso.

Se o destino for uma função do AWS Lambda, consulte Solucionar problemas de erros HTTP 502 quando o destino for uma função do Lambda na seção Resolução.

Resolução

Encontre a fonte dos erros HTTP 502

Usando métricas do CloudWatch

Se os pontos de dados aparecerem sob a métrica HTTPCode_ELB_502_Count, o balanceador de carga será a fonte dos erros HTTP 502. Se eles aparecerem sob a métrica HTTP_Target_5XX_Count, seu destino será a fonte.

Usando logs de acesso

Se o elb_status_code for “502” e o target_status_code for “-”, o balanceador de carga será a fonte dos erros HTTP 502. Se o elb_status_code for “502” e o target_status_code for “502”, seu destino será a fonte dos erros.

Solucionar erros de HTTP 502

Observação: filtre os logs de acesso por elb_status_code = "502" e target_status_code para ajudá-lo a determinar a causa. Em seguida, conclua as etapas específicas ao seu caso de uso.

O balanceador de carga recebeu um TCP RST do destino ao tentar estabelecer uma conexão.

Receber um TCP RST do destino ao estabelecer uma conexão significa que o balanceador de carga não pode estabelecer um handshake de três vias TCP com o destino. Como resultado, o balanceador de carga não pode encaminhar a solicitação do usuário para o destino.

  • Verifique se há pontos de dados para a métrica TargetConnectErrorCount. Essa métrica representa o número de conexões que não foram estabelecidas com êxito entre o balanceador de carga e o destino.
  • Verifique se os campos request_processing_time, target_processing_time eresponse_processing_time, nos logs de acesso estão definidos para o valor -1. Esse valor significa que o balanceador de carga não pode despachar a solicitação para o destino porque precisa de uma conexão bem-sucedida.

Veja a seguir um exemplo de uma entrada de log de acesso:

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"

Observação: na entrada anterior do log de acesso, request_processing_time, target_processing_time e response_processing_time são definidos como -1.

O balanceador de carga recebeu uma resposta inesperada do destino, como “ICMP Destination unreachable (Host unreachable)” (Destino ICMP inacessível (Host inacessível)), ao tentar estabelecer uma conexão

  • Verifique se os campos request_processing_time, target_processing_time e response_processing_time nos logs de acesso estão todos definidos para o valor -1.
  • Verifique se o tráfego é permitido das sub-redes do balanceador de carga para os destinos na porta de destino.

O destino fechou a conexão com um TCP, RST ou TCP FIN, enquanto o balanceador de carga tinha uma solicitação pendente para o destino.

O balanceador de carga recebe uma solicitação e a encaminha para o destino. O destino recebe a solicitação e começa a processá-la, mas fecha a conexão com o balanceador de carga muito cedo. Isso geralmente ocorre quando a duração do tempo limite de manutenção de atividade para o destino é menor do que o valor de tempo limite ocioso 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 ocioso.

Verifique os valores dos campos request_processing_time, target_processing_time e response_processing_time.

Exemplo de entrada de log de acesso:

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"

Observação: na entrada anterior do log de acesso, o request_processing_time é 0.001, o target_processing_time é 4.205, e o response_processing_time é -1.

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

Execute uma captura de pacote no destino durante o período de tempo do problema para entender a resposta do alvo.

O balanceador de carga encontrou um erro de handshake SSL ou tempo limite de handshake SSL (10 segundos) ao se conectar a um destino

A conexão TCP do balanceador de carga com o ouvinte HTTPS do destino é bem-sucedida, mas o handshake SSL subsequente atinge o tempo limite. Como resultado, o balanceador de carga não pode encaminhar a solicitação para o destino.

Verifique se o grupo-alvo está usando o protocolo HTTPS. Caso contrário, o tempo limite do handshake SSL não é a causa. Se o grupo-alvo estiver usando o protocolo HTTPS, tente o seguinte:

  • Verifique se os campos request_processing_time, target_processing_time e response_processing_time nos logs de acesso estão todos definidos para o valor -1.
  • Verifique se há pontos de dados para a métrica TargetTLSNegotiationErrorCount.
  • Execute uma captura de pacote no destino durante o período de tempo do problema para validar se ele está relacionado a um handshake SSL. Se estiver, conclua as etapas na seção Executar uma captura de pacotes.
  • Verifique se as cifras ou protocolos são incompatíveis.

O período de atraso de cancelamento de registro decorrido para uma solicitação que é tratada por um alvo cujo registro foi cancelado

Em seus eventos do CloudTrail, verifique se há uma chamada de API com a ação DeregisterTargets durante o período do problema. Se uma chamada de API com DeregisterTargets ocorreu durante o período do problema, o erro será causado por um destino cujo registro foi cancelado muito cedo. Para resolver esse problema, aumente o período de atraso do cancelamento de registro para que operações demoradas possam ser concluídas sem falhas.

Solucionar problemas dos erros HTTP 502 quando o destino for uma função Lambda

Observação: para solicitações para uma função do Lambda que falham, o balanceador de carga armazenacódigos de motivo de erro específicos do Lambda no campo error_reason dos logs de acesso.

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

  • Verifique se há um ponto de dados para a métrica LambdaUserError.
  • Verifique se o campo error_reason no log de acesso do balanceador de carga está definido como LambdaResponseTooLarge.

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

  • Verifique a configuração do tempo limite da função Lambda.
  • Verifique se há um ponto de dados para a métrica LambdaUserError.
  • 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 a função foi limitada pelo serviço Lambda

Entre em contato com o AWS Support para obter orientação sobre controle de utilização de serviços.

Realizar uma captura de pacotes

Para o Linux, execute o seguinte comando:

sudo tcpdump -i any -w filename.pcap

Para o Microsoft Windows, baixe e use o aplicativo Wireshark (no site da Wireshark).


Este artigo ajudou?


Precisa de ajuda com faturamento ou suporte técnico?