Códigos de status de erro do ALB - Server Load Balancer: Central de Documentação do Alibaba Cloud

Recomendamos habilitar os logs de acesso do ALB para solucionar rapidamente erros HTTP originados no ALB. Primeiro, compare o código de status do ALB (campo status) com o código de status do backend (campo upstream_status) no log de acesso. Se os valores forem idênticos, provavelmente o ALB apenas repassou o código de status do servidor de backend. Nesse caso, priorize a investigação do serviço de backend.

Cinco verificações rápidas

Antes de solucionar problemas por código de status, execute estas cinco verificações. Elas abordam as causas raiz mais comuns de falhas no ALB.

Execute a ferramenta de diagnóstico da instância ALB. Na página Instances, localize a instância desejada. Na coluna Instance Diagnostics, clique em Diagnose para verificar automaticamente problemas comuns nas configurações da instância, listeners e serviços de backend.
Verifique se o Health Check Status do listener está como Healthy. Na página Listener Details, confira o Health Check Status do grupo de servidores de backend. Se o status for Unhealthy, consulte Solucionar falhas na verificação de integridade do ALB.
Garanta que o ECS de backend não bloqueie o bloco CIDR do vSwitch onde a instância ALB reside. O ALB comunica-se com os servidores de backend usando um Local IP atribuído pelo vSwitch. Se regras de iptables ou softwares de segurança de terceiros em uma instância ECS de backend bloquearem o bloco CIDR do vSwitch, o ALB não conseguirá alcançar o backend, o que pode gerar erros como 502 ou 504.
Confirme se a porta configurada para um servidor de backend no grupo de servidores corresponde à porta em que o serviço de backend realmente escuta. A porta definida para cada servidor de backend em um grupo de servidores do ALB deve ser igual à porta que o processo da aplicação utiliza. Por exemplo, se a porta estiver configurada como 8080 no grupo de servidores, mas o serviço de backend estiver escutando na porta 80, a conexão falhará. Para verificar, execute ss -tlnp | grep ':<port> ' ou netstat -tlnp | grep ':<port> ' no ECS de backend.
Para listeners HTTPS, valide se o certificado não expirou e se seu domínio corresponde ao domínio de acesso. Na página Listener Details, verifique o certificado vinculado e sua data de validade. Um certificado expirado ou incompatibilidade de domínio pode causar falhas no handshake SSL ou retornar um código de status de erro.

502 Bad Gateway

Esse erro ocorre quando um listener HTTP ou HTTPS recebe uma requisição do cliente, mas o ALB não consegue encaminhar a requisição para um servidor de backend ou receber uma resposta dele.

Abordagem de solução de problemas: Primeiro, verifique o valor do campo upstream_status no log de acesso para determinar os próximos passos.

Se upstream_status = 502: O ALB repassou o código de status 502 do servidor de backend. O problema está no próprio serviço de backend. Investigue o serviço de backend. Por exemplo, verifique se uma camada Nginx ou gateway de backend está tentando fazer proxy reverso para um upstream inacessível.
Se upstream_status for outro valor (como 504, 444 ou 500): O status que o ALB retorna ao cliente difere do upstream_status, indicando que o ALB alterou o código de status. Investigue por que o serviço de backend está retornando esse código específico verificando os logs do Nginx de backend, gateway ou aplicação.
Se upstream_status for - ou estiver vazio: O ALB não recebeu nenhuma resposta do backend. Isso significa que a requisição nunca chegou ao backend ou que a conexão foi encerrada anormalmente antes do envio de uma resposta. Verifique as seguintes causas nesta ordem:
- A comunicação TCP entre o ALB e o servidor de backend está falhando. Verifique se o serviço de backend está em execução, se a porta do serviço está escutando corretamente e se nenhuma regra de iptables ou software de segurança de terceiros no ECS de backend está bloqueando o bloco CIDR do vSwitch onde a instância ALB está localizada. O ALB comunica-se com os servidores de backend usando um Local IP atribuído pelo vSwitch. Capture pacotes para verificar se o handshake TCP foi bem-sucedido.
- O backlog do servidor de backend está cheio. Isso faz com que o servidor descarte novas solicitações de conexão. Execute netstat -s | grep -i listen no servidor de backend e procure por um contador de drop.
- O servidor de backend não conseguiu processar a requisição a tempo. Analise os logs do servidor de backend e revise o uso de CPU e memória para identificar gargalos de desempenho.
- O tamanho do pacote da requisição do cliente excede a MTU do servidor de backend. Isso pode fazer com que pacotes curtos (como verificações de integridade) tenham sucesso, enquanto pacotes longos falham. Capture pacotes no servidor de backend para analisar se o comprimento do pacote está dentro dos limites exigidos.
- A resposta do servidor de backend tem um formato inválido ou contém cabeçalhos HTTP inválidos. Capture pacotes no servidor de backend para analisar se o formato da resposta está em conformidade com os padrões.

400 Bad Request

O formato da requisição é inválido.

O backend retorna 400 diretamente: Verifique o log de acesso. Se upstream_status for 400, provavelmente o ALB repassou o código de status do backend. Investigue o serviço de backend.
Uma requisição HTTP é enviada para um listener HTTPS: Um listener HTTPS do ALB rejeita requisições não HTTPS e retorna um código de status 400. Verifique se o cliente está enviando incorretamente uma requisição HTTP para uma porta HTTPS.
O tamanho do cabeçalho da requisição excede o limite: O ALB exige que cada cabeçalho de requisição HTTP não seja maior que 32 KB. Se esse limite for ultrapassado, o ALB retorna um código de status 400. Reduza o tamanho do cabeçalho da requisição.
O cliente não enviou a requisição completa: O cliente fechou a conexão antes de enviar a requisição HTTP inteira. Capture pacotes no cliente para identificar a causa.
O formato do cabeçalho da requisição é inválido: Por exemplo, o valor de Content-Length não corresponde ao comprimento real do corpo da requisição. Capture pacotes no cliente, analise o formato da requisição HTTP e compare-o com uma requisição válida.

405 Method Not Allowed

O método de requisição não é suportado.

Restrição do ALB: O ALB não suporta o método de requisição TRACE. Utilize um método diferente.
Restrição do serviço de backend: Exceto pelo TRACE, o suporte a outros métodos de requisição depende do servidor de backend. Para validar, execute curl -X METHOD http://<backend_service_IP>:<service_port>, onde METHOD é o método de requisição usado pelo cliente.

408 Request Timeout

A requisição atingiu o tempo limite e o ALB encerrou a conexão.

Transmissão lenta de dados pelo cliente: Dentro do período de tempo limite da requisição do cliente para o ALB (padrão: 60s), o cliente enviou apenas dados parciais, como somente o HTTP Header sem o HTTP Body. Capture pacotes no cliente para verificar gargalos de desempenho ou outros problemas.
Baixa qualidade de rede entre o cliente e o ALB: O Tempo de Ida e Volta (RTT) TCP está alto ou existem outros problemas de rede, como perda de pacotes. Recomendamos verificar os campos request_time e tcpinfo_rtt no log de acesso ou executar diagnósticos de rede no cliente.
Limitação de largura de banda da instância ALB: O tráfego elevado para a instância ALB acionou a limitação de largura de banda e a perda de pacotes. Verifique as métricas outbound bandwidth e Dropped Connections no Cloud Monitor.

414 URI Too Long

O comprimento da URI da requisição excede o limite, e o ALB ou o servidor de backend rejeitou a requisição.

Restrição do ALB: O ALB exige que a URI da requisição não ultrapasse 32 KB. Caso contrário, um código de status 414 é retornado. Encurte a URI. Para transmitir grandes volumes de dados, utilize o método POST e coloque os dados no corpo da requisição. O ALB suporta um corpo de requisição POST de até 50 GB.
Restrição do serviço de backend: Se o comprimento da URI não exceder o limite do ALB, mas o serviço de backend tiver um limite mais restritivo, o ALB repassará o código de status 414 retornado pelo backend. Investigue o serviço de backend.

463

O código de status 463 é retornado apenas quando o listener está associado a um grupo de servidores do tipo IP.

Existe um loop no caminho da requisição. Quando uma requisição passa pelo ALB, o sistema anexa um campo ALICLOUD-ALB-TRACE ao HTTP Header. O valor do campo é um hash de 16 caracteres gerado a partir do ID da regra. Se IDs de regra duplicados forem detectados, ou se o número de campos ALICLOUD-ALB-TRACE exceder 16, o ALB identifica um loop. O ALB então interrompe o encaminhamento da requisição para evitar uma tempestade de rede e retorna um código de status 463.

Configuração incorreta do serviço de backend: O serviço de backend está mal configurado, fazendo com que envie requisições de volta ao ALB em um loop. Verifique a configuração do serviço de backend do seu ALB.
Falha na arquitetura de rede: Por exemplo, múltiplas instâncias de balanceamento de carga existem no caminho de encaminhamento de uma única requisição. Recomendamos otimizar a arquitetura de rede.

499 Client Closed Request

O cliente encerrou ativamente a conexão.

Baixa qualidade de rede entre o cliente e o ALB: O RTT TCP está alto ou existem outros problemas de rede, como perda de pacotes. Recomendamos verificar os campos request_time e tcpinfo_rtt no log de acesso ou executar diagnósticos de rede no cliente.
Limitação de largura de banda da instância ALB: O tráfego elevado para a instância ALB acionou a limitação de largura de banda e a perda de pacotes. Verifique as métricas outbound bandwidth e Dropped Connections no Cloud Monitor.
Tempo prolongado de processamento no backend: O tempo de processamento do backend excedeu o período de tempo limite do cliente. Verifique o campo upstream_response_time no log de acesso, que indica o tempo de processamento do backend. Se esse valor for consistentemente alto, investigue o serviço de backend em busca de gargalos de desempenho.
O tempo limite da requisição do cliente é muito curto: O cliente fechou a conexão devido a um tempo limite antes de terminar de enviar a requisição. Consulte o campo request_time no log de acesso, que indica o tempo total da requisição. Use esse valor como referência para definir um tempo limite de requisição mais adequado no lado do cliente.
O cliente encontrou um problema desconhecido: O cliente fechou a conexão antes que a requisição fosse concluída. Investigue o cliente em busca de comportamentos que possam causar o encerramento prematuro da conexão.

500 Internal Server Error

O servidor de backend encontrou um erro interno e não pôde processar a requisição.

O backend retorna 500 diretamente: Verifique o log de acesso. Se upstream_status for 500, provavelmente o ALB repassou o código de status do backend. Investigue o serviço de backend.
O servidor de backend fechou a conexão inesperadamente: O servidor de backend encerrou a conexão antes de enviar uma resposta completa. Capture pacotes no servidor de backend para identificar a causa do fechamento inesperado da conexão.

503 Service Temporarily Unavailable

O servidor está temporariamente indisponível, geralmente devido a tráfego acima dos limites ou a um serviço de backend indisponível.

O backend retorna 503 diretamente: Verifique o log de acesso. Se upstream_status for 503, provavelmente o ALB repassou o código de status do backend. Investigue o serviço de backend.
A requisição do cliente aciona a limitação do ALB:
- No Cloud Monitor, verifique a métrica Requests per second.
- O Cloud Monitor exibe dados no nível de minuto e pode não refletir picos no nível de segundo. Verifique o log de acesso. Se o campo upstream_status for -, a requisição não chegou ao servidor de backend.
- Verifique o cabeçalho do pacote de resposta. Se ele contiver o campo ALB-QPS-Limited:Limited, a requisição acionou a limitação do ALB.
Acesso direto por IP ou resolução DNS anormal: Isso pode concentrar o tráfego em poucos endereços IP e acionar a limitação. Acesse o ALB através do seu nome de domínio (consulte Configurar um CNAME para uma instância ALB) e verifique se a resolução DNS funciona conforme esperado.
O listener não possui servidores de backend configurados, ou os servidores de backend configurados têm peso 0.

504 Gateway Timeout

O ALB atingiu o tempo limite enquanto aguardava uma resposta do servidor de backend.

O backend retorna 504 diretamente: Verifique o log de acesso. Se upstream_status for 504, provavelmente o ALB repassou o código de status do backend. Investigue o serviço de backend.
A tentativa de conexão do ALB com o servidor de backend atinge o tempo limite: Esse tempo limite é de 5 segundos por padrão e não pode ser alterado. Capture pacotes para identificar por que o servidor de backend não está respondendo a tempo.
Tempo limite de resposta do backend: O tempo limite da requisição de conexão é de 60 segundos por padrão. Verifique a métrica UpstreamResponseTime no Cloud Monitor e o campo upstream_response_time no log de acesso para determinar se a resposta do servidor de backend atingiu o tempo limite.