ALB error status codes - Server Load Balancer: Central de Documentação do Alibaba Cloud

Recomendamos habilitar o ALB access logs para solucionar erros HTTP do ALB com mais agilidade. 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 iguais, o ALB provavelmente repassou o código de status do servidor backend. Nesse caso, priorize a investigação do service backend.

Cinco verificações rápidas

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

Execute a ferramenta de diagnóstico da instância do ALB. Na página Instances, localize a instância desejada. Na coluna Instance Diagnostics, clique em Diagnose para execute uma verificação automática de problemas comuns em configurações de instância, listeners e serviços backend.
Verifique se o Health Check Status do listener está como Healthy. Na página Listener Details, verifique o Health Check Status do grupo de servidores backend. Se o status for Unhealthy, consulte Troubleshoot ALB health check failures.
Certifique-se de que o ECS backend não bloqueie o bloco CIDR do vSwitch onde a instância do ALB reside. O ALB se comunica com os servidores backend por meio de um Local IP atribuído pelo seu vSwitch. Se regras de iptables ou softwares de segurança de terceiros em uma instância ECS 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 que a porta configurada para o servidor backend no grupo de servidores corresponde à porta em que o service backend realmente escuta. A porta configurada para cada servidor backend em um grupo de servidores do ALB deve coincidir com a porta em que o processo da aplicação escuta. Por exemplo, se a porta estiver configurada como 8080 no grupo de servidores, mas o service backend estiver escutando na porta 80, a conexão falhará. Execute ss -tlnp | grep ':<port> ' ou netstat -tlnp | grep ':<port> ' no ECS backend para verifique.
Para listeners HTTPS, verifique se o certificado não expirou e se seu domínio corresponde ao domínio de acesso. Na página Listener Details, confira o certificado vinculado e sua data de expiração. Um certificado expirado ou uma incompatibilidade de domínio pode causar falhas no handshake SSL ou retornar um código de status de erro.

502 Bad Gateway

Este erro ocorre quando um listener HTTP ou HTTPS recebe uma requisição do cliente, mas o ALB não consegue encaminhá-la a um servidor backend nem receber uma resposta dele.

Abordagem de solução de problemas: 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 backend. O problema está no próprio service backend. Investigue o service backend — por exemplo, verifique se um Nginx ou uma camada de gateway no backend está tentando fazer proxy reverso para um upstream inacessível.
Se upstream_status tiver outro valor (como 504, 444 ou 500): O status retornado pelo ALB ao cliente é diferente do upstream_status, o que indica que o ALB alterou o código de status. Investigue por que o service backend está retornando aquele código específico verificando os logs do Nginx, do gateway ou da aplicação backend.
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 de forma anormal antes que uma resposta fosse enviada. Verifique as seguintes causas na ordem apresentada:
- A comunicação TCP entre o ALB e o servidor backend está falhando. Confirme que o service backend está em execução, que a porta do service está escutando corretamente e que nenhuma regra de iptables ou software de segurança de terceiros no ECS backend está bloqueando o bloco CIDR do vSwitch onde a instância do ALB está localizada. O ALB se comunica com os servidores backend usando um Local IP atribuído pelo vSwitch. Capture pacotes para verifique se o handshake TCP é bem-sucedido.
- O backlog do servidor backend está cheio. Isso faz com que o servidor descarte novas requisições de conexão. Execute netstat -s | grep -i listen no servidor backend e verifique o contador de drop.
- O servidor backend não processou a requisição a tempo. Analise os logs do servidor 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 o MTU do servidor backend. Isso pode fazer com que pacotes curtos (como health checks) tenham sucesso enquanto pacotes longos falham. Capture pacotes no servidor backend para analisar se o tamanho dos pacotes está dentro dos limites exigidos.
- A resposta do servidor backend tem formato inválido ou contém headers HTTP inválidos. Capture pacotes no servidor backend para verifique 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, o ALB provavelmente repassou o código de status do backend. Investigue o service backend.
Uma requisição HTTP é enviada a um listener HTTPS: Um listener HTTPS do ALB rejeita requisições que não sejam HTTPS e retorna o código de status 400. Verifique se o cliente está enviando incorretamente uma requisição HTTP para uma porta HTTPS.
O tamanho do header da requisição excede o limite: O ALB exige que cada header de requisição HTTP tenha no máximo 32 KB. Se esse limite for excedido, o ALB retorna o código de status 400. Reduza o tamanho do header da requisição.
O cliente não enviou a requisição completa: O cliente encerrou a conexão antes de enviar a requisição HTTP completa. Capture pacotes no cliente para identificar a causa.
O formato do header da requisição é inválido: Por exemplo, o valor de Content-Length não corresponde ao tamanho real do corpo da requisição. Capture pacotes no cliente, analise o formato da requisição HTTP e compare com uma requisição válida.

405 Method Not Allowed

O método da 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 service backend: Com exceção do TRACE, o suporte a outros métodos de requisição depende do servidor backend. Para verifique, execute curl -X METHOD http://<backend_service_IP>:<service_port>, onde METHOD é o método de requisição utilizado pelo cliente.

408 Request Timeout

A requisição expirou e o ALB encerrou a conexão.

Transmissão de dados lenta pelo cliente: Dentro do período de timeout da requisição do cliente para o ALB (padrão: 60s), o cliente enviou apenas dados parciais — por exemplo, enviou apenas o HTTP Header, mas não o HTTP Body. Capture pacotes no cliente para verifique gargalos de desempenho ou outros problemas.
Qualidade de rede ruim entre o cliente e o ALB: O TCP Round Trip Time (RTT) está alto, ou existem outros problemas de rede como perda de pacotes. Verifique os campos request_time e tcpinfo_rtt no log de acesso, ou execute diagnósticos de rede no cliente.
Throttling de largura de banda na instância do ALB: Alto tráfego na instância do ALB acionou o throttling de largura de banda e causou perda de pacotes. Verifique as métricas outbound bandwidth e Dropped Connections no Cloud Monitor.

413 Request Entity Too Large

O corpo da requisição é muito grande. Primeiro, verifique o valor do campo upstream_status no log de acesso para determinar se o código de status 413 foi retornado pelo ALB ou repassado do servidor backend.

Se upstream_status = 413: O servidor backend retornou o código de status 413 e o ALB o repassou. Este é o caso mais comum, geralmente causado por um limite de tamanho do corpo da requisição configure em um proxy backend (como o Nginx). Investigue a configuração relevante do service backend — por exemplo, o parâmetro client_max_body_size do Nginx.
Se upstream_status for - ou estiver vazio: O ALB retornou o código de status 413 por conta própria, o que significa que o corpo da requisição excede o limite do próprio ALB (50 GB). Este caso é raro. Reduza o tamanho do corpo da requisição do cliente.

414 URI Too Long

O tamanho do URI da requisição excede o limite e o ALB ou o servidor backend rejeitou a requisição.

Restrição do ALB: O ALB exige que um URI de requisição tenha no máximo 32 KB. Caso contrário, o código de status 414 é retornado. Encurte o 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 service backend: Se o tamanho do URI não exceder o limite do ALB, mas o service backend tiver um limite mais restritivo, o ALB repassa o código de status 414 retornado pelo backend. Investigue o service backend.

463

O código de status 463 é retornado somente 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 acrescenta um campo ALICLOUD-ALB-TRACE ao HTTP Header. O valor desse 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 o código de status 463.

Configure incorreta do service backend: O service backend está configure incorretamente, fazendo com que ele reenvie requisições ao ALB em loop. Verifique a configuração do service backend do seu ALB.
Falha na arquitetura de rede: Por exemplo, múltiplas instâncias SLB existem no caminho de encaminhamento de uma única requisição. Otimize a arquitetura de rede.

499 Client Closed Request

O cliente encerrou a conexão ativamente.

Qualidade de rede ruim entre o cliente e o ALB: O TCP RTT está alto, ou existem outros problemas de rede como perda de pacotes. Verifique os campos request_time e tcpinfo_rtt no log de acesso, ou execute diagnósticos de rede no cliente.
Throttling de largura de banda na instância do ALB: Alto tráfego na instância do ALB acionou o throttling de largura de banda e causou perda de pacotes. Verifique as métricas outbound bandwidth e Dropped Connections no Cloud Monitor.
Tempo de processamento longo no backend: O tempo de processamento no backend excedeu o período de timeout do cliente. Verifique o campo upstream_response_time no log de acesso, que indica o tempo de processamento do backend. Se esse valor estiver consistentemente alto, investigue o service backend em busca de gargalos de desempenho.
Timeout de requisição do cliente muito curto: O cliente encerrou a conexão por timeout antes de concluir o envio da requisição. Verifique o campo request_time no log de acesso, que indica o tempo total da requisição. Use esse valor como referência para defina um timeout de requisição do lado do cliente mais adequado.
Problema desconhecido no cliente: O cliente encerrou a conexão antes de a requisição ser concluída. Investigue o cliente em busca de comportamentos que possam causar o encerramento prematuro da conexão.

500 Internal Server Error

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

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

503 Service Temporarily Unavailable

O servidor está temporariamente indisponível, geralmente devido ao tráfego exceder os limites ou ao service backend estar indisponível.

O backend retorna 503 diretamente: Verifique o log de acesso. Se upstream_status for 503, o ALB provavelmente repassou o código de status do backend. Investigue o service backend.
A requisição do cliente aciona o throttling do ALB:
- No Cloud Monitor, verifique a métrica Requests per second.
- O Cloud Monitor exibe dados em nível de minuto e pode não refletir picos em nível de segundo. Verifique o log de acesso. Se o campo upstream_status for -, a requisição não chegou ao servidor backend.
- Verifique o header do pacote de resposta. Se ele contiver o campo ALB-QPS-Limited:Limited, a requisição acionou o throttling do ALB.
Acesso direto por IP ou resolução DNS anormal: Isso pode concentrar o tráfego em apenas alguns endereços IP e acionar o throttling. Acesse o ALB pelo seu nome de domínio (consulte Configure a CNAME for an ALB instance) e verifique se a resolução DNS funciona conforme esperado.
O listener não possui servidores backend configure, ou os servidores backend configure têm peso 0.

A regra de encaminhamento padrão do ALB Ingress causa 503

Após instale o componente ALB Ingress em um cluster ACK, o componente cria automaticamente uma regra de encaminhamento padrão e um grupo de servidores correspondente na instância do ALB. O grupo de servidores fica inicialmente vazio.

Quando uma requisição chega ao ALB sem corresponder a nenhuma das regras de encaminhamento de Ingress baseadas em domínio configure, ela é roteada para essa regra de encaminhamento padrão. Como o grupo de servidores padrão está vazio, o ALB não tem backend para encaminhar a requisição e retorna o erro 503 Service Temporarily Unavailable.

Esse é o comportamento esperado e não é necessário exclua manualmente a regra de encaminhamento padrão. Para resolver o problema, configure as regras de encaminhamento de Ingress baseadas em domínio corretas no cluster ACK para rotear o tráfego de negócios para os grupos de servidores backend correspondentes.

Configure incorreta de caminho com wildcard causa 503

Quando o tipo de correspondência de caminho de uma regra de encaminhamento do ALB é Exact match and wildcard, o caractere wildcard * corresponde a uma string de qualquer tamanho. O caminho /zhpt/* corresponde a caminhos que começam com /zhpt/ (como /zhpt/test), mas não inclui o caminho base /zhpt em si. Portanto, quando uma regra é configure apenas com /zhpt/*, uma requisição para /zhpt não corresponde à regra e cai na ação de encaminhamento padrão. Se o grupo de servidores padrão estiver vazio, o ALB retorna o erro 503 Service Temporarily Unavailable. Para mais informações sobre regras de correspondência de caminho, consulte Forwarding rule configuration examples and domain name and path matching rules.

Soluções: escolha uma das opções a seguir com base no intervalo de caminhos que você precisa corresponder:

Se você precisar corresponder apenas ao caminho base /zhpt, altere o caminho da regra de /zhpt/* para /zhpt.
Se precisar corresponder tanto ao caminho base /zhpt quanto aos seus subcaminhos /zhpt/*, configure duas regras de encaminhamento separadas (/zhpt e /zhpt/*) e preste atenção à ordem das regras.
Para uma correspondência de caminho mais flexível, altere o tipo de correspondência para Regular expression match e escreva o caminho como uma expressão regular (por exemplo, use ^/zhpt(/.*)?$ para corresponder tanto a /zhpt quanto aos seus subcaminhos). Delimite a expressão regular com ^ e $ para evitar correspondências indesejadas, como /zhptxxx.

504 Gateway Timeout

O ALB expirou enquanto aguardava uma resposta do servidor backend.

O backend retorna 504 diretamente: Verifique o log de acesso. Se upstream_status for 504, o ALB provavelmente repassou o código de status do backend. Investigue o service backend.
A tentativa de conexão do ALB ao servidor backend expira: Esse timeout é de 5 segundos por padrão e não pode ser alterado. Capture pacotes para identificar por que o servidor backend não está respondendo a tempo.
Timeout de resposta do backend: O connection request timeout é 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 backend expirou.