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á.
# Solução dos problemas de um Classic Load Balancer: erros de HTTP
O método HTTP (também chamado *verbo*) especifica a ação a ser executada no recurso que recebe uma solicitação HTTP. Os métodos padrão para solicitações HTTP são definidos na RFC 2616, [Definições do método](http://tools.ietf.org/html/rfc2616#section-9). Entre os métodos padrão estão GET, POST, PUT, HEAD e OPTIONS. Alguns aplicativos Web exigem (e, às vezes, introduzem) métodos que são extensões de métodos HTTP/1.1. Exemplos comuns de métodos estendidos de HTTP incluem PATCH, REPORT, MKCOL, PROPFIND, MOVE e LOCK. O Elastic Load Balancing aceita todos os métodos HTTP padrão e não padrão.
As solicitações de HTTP e as respostas usam campos de cabeçalho para enviar informações sobre as mensagens HTTP. Os campos de cabeçalho são pares de nome-valor separados por dois pontos separados por um retorno de carro (CR) e um avanço de linha (LF). Um conjunto padrão de campos de cabeçalho HTTP está definido na RFC 2616, [ Cabeçalhos de mensagem](http://tools.ietf.org/html/rfc2616#section-4.2). Para obter mais informações, consulte [Cabeçalhos HTTP e balanceadores de carga clássicos](x-forwarded-headers.md).
Quando um load balancer receber uma solicitação HTTP, ele verificará solicitações malformadas e tamanho do método. O tamanho total do método em uma solicitação HTTP para um load balancer não deve ultrapassar 127 caracteres. Se a solicitação HTTP for aprovada nas duas verificações, o load balancer enviará a solicitação à instância EC2. Se o campo do método na solicitação estiver malformada, o load balancer responderá com um erro [HTTP 400: BAD\_REQUEST](#ts-elb-errorcodes-http400). Se a duração do método na solicitação exceder 127 caracteres, o load balancer responderá com um erro [HTTP 405: METHOD\_NOT\_ALLOWED](#ts-elb-errorcodes-http405).
A instância EC2 processa uma solicitação válida ao implementar o método na solicitação e enviar uma resposta de volta para o cliente. Suas instâncias deverão ser configuradas para lidar com métodos suportados e não suportados.
A seguir estão mensagens de erro apresentadas pelo seu load balancer, as possíveis causas e as etapas que você pode tomar para resolver o problema.
**Topics**
+ [HTTP 400: BAD\_REQUEST](#ts-elb-errorcodes-http400)
+ [HTTP 405: METHOD\_NOT\_ALLOWED](#ts-elb-errorcodes-http405)
+ [HTTP 408: Request Timeout (HTTP 408: limite de tempo de solicitação)](#ts-elb-errorcodes-http408)
+ [HTTP 502: Bad Gateway (HTTP 502: gateway incorreto)](#ts-elb-errorcodes-http502)
+ [HTTP 503: Service Unavailable (HTTP 503: serviço indisponível)](#ts-elb-errorcodes-http503)
+ [HTTP 504: Gateway Timeout (HTTP 504: limite de tempo do gateway)](#ts-elb-errorcodes-http504)
## HTTP 400: BAD\_REQUEST
**Descrição**: indica que o cliente enviou uma solicitação incorreta.
**Cause 1 (Causa 1)**: o cliente enviou uma solicitação malformada que não atende às especificações de HTTP. Por exemplo, uma solicitação não pode ter espaços no URL.
**Causa 2**: o cliente usou o método HTTP CONNECT, que não é compatível com o Elastic Load Balancing.
**Solução**: conecte-se diretamente à instância e capture os detalhes da solicitação do cliente. Analise os cabeçalhos e o URL quanto a solicitações malformadas. Verifique se a solicitação atende às especificações de HTTP. Verifique se o HTTP CONNECT não foi usado.
## HTTP 405: METHOD\_NOT\_ALLOWED
**Descrição**: indica que o tamanho do método não é válido.
**Causa**: o tamanho do método no cabeçalho da solicitação excede 127 caracteres.
**Solução**: verifique o tamanho do método.
## HTTP 408: Request Timeout (HTTP 408: limite de tempo de solicitação)
**Descrição**: indica que o cliente cancelou a solicitação ou não enviou uma solicitação completa.
**Causa 1**: uma interrupção da rede ou uma construção de solicitação incorreta, como cabeçalhos parcialmente formados, o tamanho do conteúdo especificado não corresponder ao tamanho real do conteúdo transmitido, etc.
**Solução 1**: inspecione o código que está fazendo a solicitação e tente enviá-lo diretamente às instâncias registradas (ou um ambiente de desenvolvimento/teste) onde você tem mais controle sobre a inspeção da solicitação em si.
**Causa 2**: a conexão com o cliente está fechada (o load balancer não pôde enviar uma resposta).
**Solução 2**: verifique se o cliente não está fechando a conexão antes de uma resposta ser enviada usando um packet sniffer (analisador de pacotes) na máquina fazendo a solicitação.
## HTTP 502: Bad Gateway (HTTP 502: gateway incorreto)
**Descrição**: indica que o load balancer não conseguiu analisar a resposta enviada de uma instância registrada.
**Causa**: uma resposta malformada da instância ou, possivelmente, um problema com o load balancer.
**Solução**: verifique se a resposta sendo enviada da instância está em conformidade com as especificações de HTTP. Vá para o [AWS Support Center](https://console.aws.amazon.com/support/home#/) para obter assistência.
## HTTP 503: Service Unavailable (HTTP 503: serviço indisponível)
**Descrição**: indica que o load balancer ou as instâncias registradas estão causando o erro.
**Causa 1**: capacidade insuficiente no load balancer para lidar com a solicitação.
**Solução 1**: deve ser um problema temporário que deve durar apenas alguns minutos. Se o problema persistir, vá para o [AWS Support Center](https://console.aws.amazon.com/support/home#/) para obter assistência.
**Cause 2 (Causa 2)**: não há nenhuma instância registrada.
**Solução 2**: registre pelo menos uma instância em cada zona de disponibilidade em que seu load balancer foi configurado para responder. Verifique isso examinando as `HealthyHostCount` métricas em CloudWatch. Se você não puder garantir que uma instância é registrada em cada Zona de disponibilidade, recomendamos ativar o balanceamento de carga entre zonas. Para obter mais informações, consulte [Configurar o balanceamento de carga entre zonas para seu Classic Load Balancer](enable-disable-crosszone-lb.md).
**Cause 3 (Causa 3)**: não há nenhuma instância íntegra.
**Solução 3**: verifique se você tem instâncias íntegras em cada zona de disponibilidade em que seu load balancer foi configurado para responder. Verifique isso analisando a métrica `HealthyHostCount`.
**Cause 4 (Causa 4)**: a fila de pico está cheia.
**Solution 4 (Solução 4)**: garanta que suas instâncias tenham capacidade suficiente para lidar com a taxa de solicitações. Verifique isso analisando a métrica `SpilloverCount`.
## HTTP 504: Gateway Timeout (HTTP 504: limite de tempo do gateway)
**Descrição**: indica que o load balancer fechou uma conexão, pois uma solicitação não foi concluída dentro do tempo limite de inatividade.
**Causa 1**: o aplicativo leva mais tempo para responder do que o tempo limite de inatividade configurado.
**Solução 1**: monitore as métricas `HTTPCode_ELB_5XX` e `Latency`. Se houver um aumento nessas métricas, pode ser porque o aplicativo não respondeu dentro do período de tempo limite de inatividade. Para obter detalhes sobre as solicitações que ultrapassam esse limite, habilite os logs de acesso no balanceador de carga e analise os códigos de resposta 504 nos logs gerados pelo Elastic Load Balancing. Se necessário, você pode aumentar a capacidade ou aumentar o tempo limite de inatividade configurado de forma que as operações demoradas (como o upload de um arquivo grande) possam ser concluídas. Para obter mais informações, consulte [Configurar o tempo limite de inatividade da conexão para seu Classic Load Balancer](config-idle-timeout.md) e [Como solucionar problemas de alta latência do Elastic Load Balancing](https://repost.aws/knowledge-center/elb-latency-troubleshooting).
**Causa 2**: as instâncias registradas estão fechando a conexão ao Elastic Load Balancing.
**Solução 2**: habilite as configurações do keep-alive nas instâncias do EC2 e verifique se o tempo limite do keep-alive é maior do que as configurações de tempo limite de inatividade do load balancer.