Solucionar problemas em seus Application Load Balancers - Elastic Load Balancing
Um destino registrado não está em serviçoOs clientes não conseguem se conectar a um balanceador de carga voltado para a InternetAs solicitações enviadas para um domínio personalizado não são recebidas pelo balanceador de carga.As solicitações HTTPS enviadas ao balanceador de carga retornam “NET::ERR_CERT_COMMON_NAME_INVALID”O balanceador de carga mostra tempos elevados de processamentoO load balancer envia um código de resposta de 000O load balancer gera um erro de HTTPUm destino gera um erro HTTPNão há um certificado AWS Certificate Manager disponível para usoNão há compatibilidade com cabeçalhos de várias linhas.Solucionar problemas de destinos não íntegros usando o mapa de recursos

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Solucionar problemas em seus Application Load Balancers

As informações a seguir podem ajudar na solução de problemas com seu Application Load Balancer.

Um destino registrado não está em serviço

Se um destino estiver levando mais tempo que o esperado para entrar no estado InService, ele pode estar falhando nas verificações de integridade. O destino não entrará em serviço até ser aprovado em uma verificação de integridade. Para ter mais informações, consulte Verificações de integridade para grupos de destino do Application Load Balancer.

Verifique se a sua instância está falhando nas verificações de integridade e verifique os seguintes problemas:

Um security group não permite o tráfego

O security group associado a uma instância deve permitir tráfego do load balancer usando a porta de verificação de integridade e o protocolo de verificação de integridade. Você pode adicionar uma regra ao security group da instância para permitir todo o tráfego do security group do load balancer. Além disso, o security group para seu load balancer deve permitir o tráfego para as instâncias.

Uma lista de controle de acesso (ACL) à rede não permite o tráfego

A Network ACL associada às sub-redes para suas instâncias deve permitir tráfego de entrada na porta de verificação de integridade e tráfego de saída nas portas efêmeras (1024-65535). A Network ACL associada às sub-redes para os nós do seu load balancer devem permitir tráfego de entrada nas portas efêmeras e tráfego de saída na verificação de integridade e nas portas efêmeras.

O caminho de ping não existe

Crie uma página de destino para a verificação de integridade e especifique seu caminho como caminho de ping.

A conexão expira

Primeiro, verifique se você pode se conectar ao destino diretamente de dentro da rede usando o endereço IP privado do destino e o protocolo de verificação de integridade. Se você não conseguir se conectar, verifique se a instância está superutilizada e adicione mais destinos ao seu grupo de destino se estiver muito ocupado para responder. Se você puder se conectar, é possível que a página de destino não esteja respondendo antes do período do tempo limite da verificação de integridade. Escolha uma página de destino mais simples para a verificação de integridade ou ajuste as configurações de verificação de integridade.

O destino não retorna um código de resposta bem-sucedido

Por padrão, o código de sucesso é 200, mas você também pode especificar códigos de sucesso adicionais ao configurar as verificações de integridade. Confirme os códigos de sucesso que o load balancer está esperando e se seu aplicativo está configurada para retornar esses códigos com sucesso.

O código de resposta do destino estava mal formado ou houve um erro na conexão com o destino

Verifique se a aplicação responde às solicitações de verificação de integridade do balanceador de carga. Algumas aplicações exigem configuração adicional para responder às verificações de integridade, como uma configuração de host virtual para responder ao cabeçalho do host HTTP enviado pelo balanceador de carga. O valor do cabeçalho do host contém o endereço IP privado do destino, seguido pela porta de verificação de integridade quando não estiver usando uma porta padrão. Se o destino usar uma porta de verificação de integridade padrão, o valor do cabeçalho do host conterá apenas o endereço IP privado do destino. Por exemplo, se o endereço IP privado do seu destino for 10.0.0.10 e a porta de verificação de integridade for 8080, o cabeçalho HTTP Host enviado pelo balanceador de carga nas verificações de integridade será Host: 10.0.0.10:8080. Se o endereço IP privado do seu destino for 10.0.0.10 e a porta de verificação de integridade for 80, o cabeçalho HTTP Host enviado pelo balanceador de carga nas verificações de integridade será Host: 10.0.0.10. Pode ser necessário realizar uma configuração de host virtual para responder a esse host ou uma configuração padrão para verificar a integridade da aplicação com sucesso. As solicitações de verificação de integridade têm os seguintes atributos: User-Agent é definido como ELB-HealthChecker/2.0, o terminador de linha para campos de cabeçalho de mensagem é a sequência CRLF e o cabeçalho termina na primeira linha vazia seguida por um CRLF.

Os clientes não conseguem se conectar a um balanceador de carga voltado para a Internet

Se o balanceador de carga não estiver respondendo às solicitações, verifique os seguintes problemas possíveis:

Seu balanceador de carga voltado para a Internet está anexado a uma sub-rede privada

É necessário que você especifique sub-redes públicas para o seu balanceador de carga. Uma sub-rede pública tem uma rota para o Internet Gateway para sua Virtual Private Cloud (VPC).

Um security group ou Network ACL não permite o tráfego

O security group para o load balancer e quaisquer Network ACLs para as sub-redes do load balancer devem permitir tráfego de entrada dos clientes e de saída para os clientes nas portas do listener.

As solicitações enviadas para um domínio personalizado não são recebidas pelo balanceador de carga.

Se o balanceador de carga não estiver recebendo solicitações enviadas para um domínio personalizado, verifique os seguintes problemas:

O nome de domínio personalizado não corresponde ao endereço IP do balanceador de carga.

  • Confirme para qual endereço IP o nome de domínio personalizado é resolvido usando uma interface da linha de comando.

    • Linux, macOS ou Unix: você pode usar o comando dig no Terminal. Ex.dig example.com

    • Windows: você pode usar o comando nslookup no Prompt de comando. Ex.nslookup example.com

  • Confirme para qual endereço IP o nome DNS dos balanceadores de carga é resolvido usando uma interface da linha de comando.

  • Compare os resultados das duas saídas. É necessário que os endereços IP correspondam.

Se estiver usando o Route 53 para hospedar seu domínio personalizado, consulte Meu domínio não está disponível na Internet no Guia do desenvolvedor do Amazon Route 53.

As solicitações HTTPS enviadas ao balanceador de carga retornam “NET::ERR_CERT_COMMON_NAME_INVALID”

Se as solicitações HTTPS estiverem recebendo NET::ERR_CERT_COMMON_NAME_INVALID do balanceador de carga, verifique as seguintes causas possíveis:

  • O nome de domínio usado na solicitação HTTPS não corresponde ao nome alternativo especificado no certificado do ACM associado aos receptores.

  • O nome DNS padrão dos balanceadores de carga está em uso. Não é possível usar o nome DNS padrão para fazer solicitações HTTPS, pois um certificado público não pode ser solicitado para o domínio *.amazonaws.com.

O balanceador de carga mostra tempos elevados de processamento

O balanceador de carga conta os tempos de processamento de maneira diferente com base na configuração.

  • Se o AWS WAF estiver associado ao seu Application Load Balancer e um cliente enviar uma solicitação HTTP POST, o tempo de envio dos dados para solicitações POST será refletido no campo request_processing_time nos registros de acesso do balanceador de carga. Espera-se esse comportamento para solicitações HTTP POST.

  • Se o AWS WAF não estiver associado ao seu Application Load Balancer e um cliente enviar uma solicitação HTTP POST, o tempo de envio dos dados para solicitações POST será refletido no campo target_processing_time nos registros de acesso do balanceador de carga. Espera-se esse comportamento para solicitações HTTP POST.

O load balancer envia um código de resposta de 000

Com conexões HTTP/2, se o tamanho comprimido de qualquer um dos cabeçalhos exceder 8 K ou se o número de solicitações enviado atendido por meio de uma conexão ultrapassar 10.000, o balanceador de carga enviará um quadro GOAWAY e fechará a conexão com um TCP FIN.

O load balancer gera um erro de HTTP

Os seguintes erros de HTTP são gerados pelo load balancer. O load balancer envia o código HTTP para o cliente, salva a solicitação no log de acesso e incrementa a métrica HTTPCode_ELB_4XX_Count ou HTTPCode_ELB_5XX_Count.

HTTP 400: solicitação inválida

Causas possíveis:

  • O cliente enviou uma solicitação malformada que não atende às especificações de HTTP.

  • O cabeçalho de solicitação excedeu 16 K por linha de solicitação, 16 K por cabeçalho único ou 64 K para o cabeçalho da solicitação inteira.

  • O cliente fechou a conexão antes de enviar o corpo completo da solicitação.

HTTP 401: Não autorizado

Você configurou uma regra de listener para autenticar usuários, mas uma das seguintes afirmações é verdadeira:

  • Você configurou OnUnauthenticatedRequest para rejeitar usuários não autenticados ou o IdP negou acesso.

  • O tamanho das solicitações retornadas pelo IdP excedeu o tamanho máximo permitido pelo load balancer.

  • Um cliente enviou uma solicitação HTTP/1.0 sem um cabeçalho de host e o load balancer não conseguiu gerar uma URL de redirecionamento.

  • O escopo solicitado não retorna um token de ID.

  • Você não conclui o processo de login antes da expiração do tempo limite de login do cliente. Para obter mais informações, consulte Tempo limite de login do cliente.

HTTP 403: negado

Você configurou uma lista de controle de acesso da Web (ACL da Web) do AWS WAF para monitorar as solicitações para seu Application Load Balancer e ela bloqueou uma solicitação.

HTTP 405: método não permitido

O cliente usou o método TRACE, que não é compatível com Application Load Balancers.

HTTP 408: Request Timeout (HTTP 408: limite de tempo de solicitação)

O cliente não enviou dados antes que o tempo limite de inatividade expirasse. Enviar um keep-alive do TCP. não impede esse limite. Envie pelo menos 1 byte de dados antes que transcorra cada período de tempo limite de inatividade. Aumente a duração do período do tempo limite de inatividade conforme o necessário.

HTTP 413: carga útil muito grande

Causas possíveis:

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

  • O cabeçalho de solicitação excedeu 16 K por linha de solicitação, 16 K por cabeçalho único ou 64 K para o cabeçalho da solicitação inteira.

HTTP 414: URI muito longo

A URL da solicitação ou os parâmetros da string de consulta são muito grandes.

HTTP 460

O load balancer recebeu uma solicitação de um cliente, mas o cliente encerrou a conexão com ele antes de decorrido o tempo limite de inatividade.

Verifique se o período de tempo de espera do cliente é maior do que o período de tempo limite de inatividade para o load balancer. Verifique se seu destino fornece uma resposta ao cliente antes do fim do tempo limite do cliente ou aumente o período do tempo limite do cliente de acordo com o tempo limite de inatividade do load balancer, se o cliente for compatível com este.

HTTP 463

O balanceador de carga recebeu um cabeçalho de solicitação X-Forwarded-For com muitos endereços IP. O limite superior para endereços IP é 30.

HTTP 464

O balanceador de carga recebeu um protocolo de solicitação de entrada que é incompatível com a configuração da versão do protocolo do grupo de destino.

Causas possíveis:

  • O protocolo de solicitação é HTTP/1.1, enquanto a versão do protocolo do grupo de destino é gRPC ou HTTP/2.

  • O protocolo de solicitação é gRPC, enquanto a versão do protocolo do grupo de destino é HTTP/1.1.

  • O protocolo de solicitação é HTTP/2 e a solicitação não é POST, enquanto a versão do protocolo do grupo de destino é gRPC.

HTTP 500: erro interno do servidor

Causas possíveis:

  • Você configurou uma lista de controle de acesso da Web (ACL da Web) do AWS WAF e ocorreu um erro ao executar as regras da ACL da Web.

  • O load balancer não consegue se comunicar com o endpoint de token do IdP ou o endpoint de informações do usuário do IdP.

    • Verifique se é possível resolver o DNS do IdP publicamente.

    • Verifique se os security groups para seu load balancer e as ACLs de rede para a VPC permitem que acesso de saída a esses endpoints.

    • Verifique se a VPC tem acesso à Internet. Se você tiver um load balancer interno, use um gateway NAT para permitir acesso à internet.

  • A reivindicação do usuário recebida do IdP tem tamanho superior a 11 KB.

HTTP 501: não implementado

O load balancer recebeu um cabeçalho Transfer-Encoding (Codificação de transferência) com um valor não compatível. Os valores compatíveis para Transfer-Encoding (Codificação de transferência) são chunked e identity. Como alternativa, você pode usar o cabeçalho Content-Encoding.

HTTP 502: Bad Gateway (HTTP 502: gateway incorreto)

Causas possíveis:

  • O load balancer recebeu um TCP RST do destino ao tentar estabelecer uma conexão.

  • O load balancer 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 o tráfego é permitido das sub-redes do load balancer para os destinos na porta de destino.

  • O destino fechou a conexão com um TCP RST ou TCP FIN enquanto o load balancer tinha uma solicitação pendente para o destino. Verifique se a duração de keep-alive do destino é mais curta que o valor do tempo limite de inatividade do load balancer.

  • A resposta de destino é malformada ou contém cabeçalhos HTTP inválidos.

  • O cabeçalho de resposta de destino excedeu 32 K para o cabeçalho de resposta inteiro.

  • O período de atraso no cancelamento do registro decorrido para uma solicitação processada por um destino que foi cancelado. Aumente o período de atraso para que operações demoradas possam ser concluídas.

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

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

  • O destino é uma função do Lambda que retornou um erro ou a função passou por controle de utilização pelo serviço Lambda.

  • O balanceador de carga encontrou um erro do handshake do SSL ao se conectar a um destino.

Para obter mais informações, consulte Como solucionar erros HTTP 502 do Application Load Balancer no Centro de Conhecimentos do AWS Support.

HTTP 503: Service Unavailable (HTTP 503: serviço indisponível)

Os grupos de destino para o load balancer não têm destinos registrados.

HTTP 504: Gateway Timeout (HTTP 504: limite de tempo do gateway)

Causas possíveis:

  • O load balancer não conseguiu estabelecer uma conexão com o destino antes da expiração do tempo limite de conexão (10 segundos).

  • O load balancer estabeleceu uma conexão com o destino, mas o destino não respondeu antes de decorrido o tempo limite de inatividade.

  • As ACL das redes ou as políticas SecurityGroup não permitiram o tráfego dos destinos para os nós do balanceador de carga nas portas temporárias (1024-65535).

  • O destino retorna um cabeçalho content-length maior do que o corpo da entidade. O load balancer atingiu o tempo limite enquanto aguardava pelos bytes faltantes.

  • O destino é uma função do Lambda e o serviço do Lambda não respondeu antes da expiração do tempo limite da conexão.

  • O balanceador de carga encontrou um tempo limite do handshake de SSL (10 segundos) ao se conectar a um destino.

HTTP 505: versão incompatível

O balanceador de carga recebeu uma solicitação inesperada de versão HTTP. Por exemplo, o balanceador de carga estabeleceu uma conexão HTTP/1, mas recebeu uma solicitação HTTP/2.

HTTP 507: armazenamento insuficiente

O URL de redirecionamento é muito longo.

HTTP 561: Não autorizado

Você configurou uma regra do listener para autenticar usuários, mas o IdP retornou um código de erro ao autenticar o usuário. Verifique seus logs de acesso para ver o código do motivo do erro relacionado.

Um destino gera um erro HTTP

O load balancer encaminhará respostas HTTP válidas dos destinos para o cliente, incluindo erros de HTTP. Os erros HTTP gerados por um destino são registrados nas métricas HTTPCode_Target_4XX_Count e HTTPCode_Target_5XX_Count.

Não há um certificado AWS Certificate Manager disponível para uso

Ao decidir usar um receptor HTTPS com seu Application Load Balancer, o AWS Certificate Manager requer a validação da propriedade do domínio antes de emitir um certificado. Se essa etapa for omitida durante a configuração, o certificado permanecerá no estado Pending Validation e não estará disponível para uso até que seja validado.

  • Se estiver usando a validação de e-mail, consulte Validação de e-mail no Guia do usuário do AWS Certificate Manager.

  • Se estiver usando a validação de DNS, consulte Validação de DNS no Guia do usuário do AWS Certificate Manager.

Não há compatibilidade com cabeçalhos de várias linhas.

Os Application Load Balancers não são compatíveis com cabeçalhos de várias linhas, incluindo o cabeçalho do tipo de mídia message/http. Quando um cabeçalho de várias linhas é fornecido, o Application Load Balancer acrescenta um caractere de dois pontos, “:”, antes de transmiti-lo para o destino.

Solucionar problemas de destinos não íntegros usando o mapa de recursos

Se os destinos do Application Load Balancer estiverem falhando nas verificações de integridade, você poderá usar o mapa de recursos para encontrar destinos não íntegros e realizar ações com base no código do motivo da falha. Para ter mais informações, consulte Exibir o mapa de recursos do Application Load Balancer.

O mapa de recursos fornece duas exibições: Visão geral e Mapa de destino não íntegro. A opção Visão geral é selecionada por padrão e exibe todos os recursos do balanceador de carga. Selecionar a exibição Mapa de destino não íntegro mostrará somente os destinos não íntegros em cada grupo de destino associado ao Application Load Balancer.

nota

Você deve habilitar a opção Mostrar detalhes do recurso para exibir o resumo da verificação de integridade e as mensagens de erro de todos os recursos aplicáveis no mapa de recursos. Quando não habilitado, você deve selecionar cada recurso para exibir os detalhes.

A coluna Grupos de destino exibe um resumo dos destinos íntegros e não íntegros de cada grupo de destino. Isso pode ajudar a determinar se todos os destinos estão falhando nas verificações de integridade ou somente destinos específicos. Se todos os destinos em um grupo de destino falharem nas verificações de integridade, averigue a configuração do grupo de destino. Selecione o nome de um grupo de destino para abrir a página de detalhes em uma nova guia.

A coluna Destinos exibe o TargetID e o status atual da verificação de integridade de cada destino. Quando um destino não está íntegro, o código do motivo da falha da verificação de integridade é exibido. Quando um único destino falha em uma verificação de integridade, verifique se o destino tem recursos suficientes e confirme se as aplicações em execução no destino estão disponíveis. Selecione um ID de destino para abrir a página de detalhes em uma nova guia.

Selecionar Exportar oferece a opção de exportar a exibição atual do mapa de recursos do Application Load Balancer como PDF.

Verifique se a instância está falhando nas verificações de integridade e, com base no código do motivo da falha, verifique os seguintes problemas:

  • Não íntegro: incompatibilidade de resposta HTTP

    • Verifique se a aplicação em execução no destino está enviando a resposta HTTP correta às solicitações de verificação de integridade do Application Load Balancer.

    • Como alternativa, você pode atualizar a solicitação de verificação de integridade do Application Load Balancer para corresponder à resposta da aplicação em execução no destino.

  • Não íntegro: a solicitação atingiu o tempo limite

    • Verifique se os grupos de segurança e as listas de controle de acesso (ACL) à rede associados aos seus destinos e ao Application Load Balancer não estão bloqueando a conectividade.

    • Verifique se o destino tem recursos suficientes disponíveis para aceitar conexões do Application Load Balancer.

    • Verifique o status de todas as aplicações em execução no destino.

    • As respostas da verificação de integridade do Application Load Balancer podem ser exibidas nos logs da aplicação de cada destino. Para obter mais informações, consulte Health check reason codes.

  • Não íntegro: FailedHealthChecks

    • Verifique o status de todas as aplicações em execução no destino.

    • Verifique se o destino está recebendo tráfego na porta de verificação de integridade.

      Ao usar um receptor HTTPS

      Você escolhe a política de segurança usada para conexões frontend. A política de segurança usada em conexões de backend é selecionada automaticamente com base na política de segurança de frontend em uso.

      • Se o receptor HTTPS estiver usando uma política de segurança TLS 1.3 para conexões frontend, a política de segurança ELBSecurityPolicy-TLS13-1-0-2021-06 será usada para conexões backend.

      • Se seu receptor HTTPS não estiver usando uma política de segurança TLS 1.3 para conexões frontend, a política de segurança ELBSecurityPolicy-2016-08 será usada para conexões backend.

      Para obter mais informações, consulte Políticas de segurança.

    • Verifique se o destino está fornecendo um certificado e uma chave de servidor no formato correto especificado pela política de segurança.

    • Verifique se o destino oferece suporte a uma ou mais cifras correspondentes e a um protocolo fornecido pelo Application Load Balancer para estabelecer handshakes de TLS.