

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 do seu Classic Load Balancer
<a name="elb-troubleshooting"></a>

As tabelas a seguir listam os recursos para soluções de problemas que você achará úteis à medida que trabalhar com um Classic Load Balancer.


**Erros de API**  

| Erro | 
| --- | 
| [CertificateNotFound: Indefinido](ts-elb-error-api-response.md#ts-elb-error-message-certificate) | 
| [OutofService: Ocorreu um erro transitório](ts-elb-error-api-response.md#ts-elb-error-message-service) | 


**Erros de HTTP**  

| Erro | 
| --- | 
| [HTTP 400: BAD\$1REQUEST](ts-elb-error-message.md#ts-elb-errorcodes-http400) | 
| [HTTP 405: METHOD\$1NOT\$1ALLOWED](ts-elb-error-message.md#ts-elb-errorcodes-http405) | 
| [HTTP 408: Request Timeout (HTTP 408: limite de tempo de solicitação)](ts-elb-error-message.md#ts-elb-errorcodes-http408) | 
| [HTTP 502: Bad Gateway (HTTP 502: gateway incorreto)](ts-elb-error-message.md#ts-elb-errorcodes-http502) | 
| [HTTP 503: Service Unavailable (HTTP 503: serviço indisponível)](ts-elb-error-message.md#ts-elb-errorcodes-http503) | 
| [HTTP 504: Gateway Timeout (HTTP 504: limite de tempo do gateway)](ts-elb-error-message.md#ts-elb-errorcodes-http504) | 


**Métricas do código de resposta**  

| Métrica do código de resposta | 
| --- | 
| [HTTPCode\$1ELB\$14XX](ts-elb-http-errors.md#ts-elb-error-metrics-ELB_4XX) | 
| [HTTPCode\$1ELB\$15XX](ts-elb-http-errors.md#ts-elb-error-metrics-ELB_5XX) | 
| [HTTPCode\$1Backend\$12xx](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_2XX) | 
| [HTTPCode\$1Backend\$13xx](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_3XX) | 
| [HTTPCode\$1Backend\$14xx](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_4XX) | 
| [HTTPCode\$1Backend\$15xx](ts-elb-http-errors.md#ts-elb-error-metrics-Backend_5XX) | 


**Problemas de verificação de integridade**  

| Problema | 
| --- | 
| [Erro na página de destino da verificação de integridade](ts-elb-healthcheck.md#ts-elb-healthcheck-targetpage) | 
| [A conexão com as instâncias expirou](ts-elb-healthcheck.md#ts-elb-healthcheck-failed) | 
| [A autenticação de chave pública não está funcionando](ts-elb-healthcheck.md#ts-elb-healthcheck-publickey) | 
| [A instância não está recebendo tráfego do load balancer](ts-elb-healthcheck.md#ts-elb-healthcheck-securitygroup) | 
| [As portas da instância não estão abertas](ts-elb-healthcheck.md#ts-elb-healthcheck-ports) | 
| [As instâncias em um grupo do Auto Scaling estão falhando na verificação de integridade do ELB](ts-elb-healthcheck.md#ts-elb-healthcheck-autoscaling) | 


**Problemas de conectividade**  

| Problema | 
| --- | 
| [Os clientes não conseguem se conectar a um balanceador de carga voltado para a Internet](ts-elb-connection-failed.md#client-cannot-connect) | 
| [As solicitações enviadas para um domínio personalizado não são recebidas pelo balanceador de carga.](ts-elb-connection-failed.md#custom-domain-request) | 
| [As solicitações HTTPS enviadas ao balanceador de carga retornam “NET::ERR\$1CERT\$1COMMON\$1NAME\$1INVALID”](ts-elb-connection-failed.md#https-cert-invalid) | 


**Problemas de registro de instância**  

| Problema | 
| --- | 
| [O registro de uma instância EC2 está demorando muito](ts-elb-register-instance.md#ts-elb-register-too-long) | 
| [Não é possível registrar uma instância iniciada a partir de uma AMI paga](ts-elb-register-instance.md#ts-elb-paid-ami-instance) | 

# Solução dos problemas de um Classic Load Balancer: erros da API
<a name="ts-elb-error-api-response"></a>

A seguir, estão mensagens de erro apresentadas pela API do Elastic Load Balancing, as possíveis causas e as etapas que você pode seguir para resolver os problemas.

**Topics**
+ [CertificateNotFound: Indefinido](#ts-elb-error-message-certificate)
+ [OutofService: Ocorreu um erro transitório](#ts-elb-error-message-service)

## CertificateNotFound: Indefinido
<a name="ts-elb-error-message-certificate"></a>

**Causa 1**: há um atraso na propagação do certificado para todas as regiões quando ele é criado usando o Console de gerenciamento da AWS. Quando esse atraso ocorre, a mensagem de erro é mostrada na última etapa do processo de criação do load balancer.

**Solução 1**: aguarde aproximadamente 15 minutos e tente novamente. Se o problema persistir, vá para o [AWS Support Center](https://console.aws.amazon.com/support/home#/) para obter assistência.

**Causa 2**: Se você estiver usando a API AWS CLI ou diretamente, poderá receber esse erro se fornecer um Amazon Resource Name (ARN) para um certificado que não existe.

**Solução 2**: use a ação AWS Identity and Access Management (IAM) [GetServerCertificate](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServerCertificate.html)para obter o ARN do certificado e verificar se você forneceu o valor correto para o ARN.

## OutofService: Ocorreu um erro transitório
<a name="ts-elb-error-message-service"></a>

**Causa**: há um problema interno temporário dentro do serviço do Elastic Load Balancing ou da rede subjacente. Esse problema temporário também poderá ocorrer quando o Elastic Load Balancing consultar a integridade do balanceador de carga e de suas instâncias registradas.

**Solução**: tentar a chamada de API novamente. Se o problema persistir, vá para o [AWS Support Center](https://console.aws.amazon.com/support/home#/) para obter assistência.

# Solução dos problemas de um Classic Load Balancer: erros de HTTP
<a name="ts-elb-error-message"></a>

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\$1REQUEST](#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\$1NOT\$1ALLOWED](#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\$1REQUEST](#ts-elb-errorcodes-http400)
+ [HTTP 405: METHOD\$1NOT\$1ALLOWED](#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\$1REQUEST
<a name="ts-elb-errorcodes-http400"></a>

**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\$1NOT\$1ALLOWED
<a name="ts-elb-errorcodes-http405"></a>

**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)
<a name="ts-elb-errorcodes-http408"></a>

**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)
<a name="ts-elb-errorcodes-http502"></a>

**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)
<a name="ts-elb-errorcodes-http503"></a>

**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)
<a name="ts-elb-errorcodes-http504"></a>

**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. 

# Solução dos problemas de um Classic Load Balancer: métricas do código de resposta
<a name="ts-elb-http-errors"></a>

Seu balanceador de carga envia métricas para a Amazon CloudWatch para os códigos de resposta HTTP enviados aos clientes, identificando a origem dos erros como o balanceador de carga ou as instâncias registradas. Você pode usar as métricas retornadas CloudWatch pelo seu balanceador de carga para solucionar problemas. Para obter mais informações, consulte [CloudWatch métricas para seu Classic Load Balancer](elb-cloudwatch-metrics.md).

A seguir estão as métricas do código de resposta retornadas CloudWatch pelo seu balanceador de carga, as possíveis causas e as etapas que você pode seguir para resolver os problemas.

**Topics**
+ [HTTPCode\$1ELB\$14XX](#ts-elb-error-metrics-ELB_4XX)
+ [HTTPCode\$1ELB\$15XX](#ts-elb-error-metrics-ELB_5XX)
+ [HTTPCode\$1Backend\$12xx](#ts-elb-error-metrics-Backend_2XX)
+ [HTTPCode\$1Backend\$13xx](#ts-elb-error-metrics-Backend_3XX)
+ [HTTPCode\$1Backend\$14xx](#ts-elb-error-metrics-Backend_4XX)
+ [HTTPCode\$1Backend\$15xx](#ts-elb-error-metrics-Backend_5XX)

## HTTPCode\$1ELB\$14XX
<a name="ts-elb-error-metrics-ELB_4XX"></a>

**Causa**: uma solicitação malformada ou cancelada do cliente.

**Soluções**
+ Consulte [HTTP 400: BAD\$1REQUEST](ts-elb-error-message.md#ts-elb-errorcodes-http400).
+ Consulte [HTTP 405: METHOD\$1NOT\$1ALLOWED](ts-elb-error-message.md#ts-elb-errorcodes-http405).
+ Consulte [HTTP 408: Request Timeout (HTTP 408: limite de tempo de solicitação)](ts-elb-error-message.md#ts-elb-errorcodes-http408).

## HTTPCode\$1ELB\$15XX
<a name="ts-elb-error-metrics-ELB_5XX"></a>

**Causa**: o load balancer ou a instância registrada está causando o erro ou o load balancer não está conseguindo analisar a resposta.

**Soluções**
+ Consulte [HTTP 502: Bad Gateway (HTTP 502: gateway incorreto)](ts-elb-error-message.md#ts-elb-errorcodes-http502).
+ Consulte [HTTP 503: Service Unavailable (HTTP 503: serviço indisponível)](ts-elb-error-message.md#ts-elb-errorcodes-http503).
+ Consulte [HTTP 504: Gateway Timeout (HTTP 504: limite de tempo do gateway)](ts-elb-error-message.md#ts-elb-errorcodes-http504).

## HTTPCode\$1Backend\$12xx
<a name="ts-elb-error-metrics-Backend_2XX"></a>

**Causa**: uma resposta normal e bem-sucedida das instâncias registradas.

**Solução**: nenhuma.

## HTTPCode\$1Backend\$13xx
<a name="ts-elb-error-metrics-Backend_3XX"></a>

**Causa**: uma resposta de redirecionamento enviada das instâncias registradas.

**Solução**: visualize os logs de acesso ou os logs de erro na instância para determinar a causa. Envie solicitações diretamente para a instância (ignorando o load balancer) para exibir as respostas.

## HTTPCode\$1Backend\$14xx
<a name="ts-elb-error-metrics-Backend_4XX"></a>

**Causa**: uma resposta de erro do cliente enviada pelas instâncias registradas.

**Solução**: visualize os logs de acesso ou de erro nas instâncias para determinar a causa. Envie solicitações diretamente para a instância (ignore o load balancer) para exibir as respostas.

**nota**  
Se o cliente cancelar uma solicitação HTTP iniciada com um cabeçalho `Transfer-Encoding: chunked`, há um problema conhecido no qual o load balancer encaminha a solicitação para a instância, ainda que o cliente tenha cancelado a solicitação. Isso pode causar erros de back-end.

## HTTPCode\$1Backend\$15xx
<a name="ts-elb-error-metrics-Backend_5XX"></a>

**Causa**: uma resposta de erro do servidor enviada das instâncias registradas.

**Solução**: visualize os logs de acesso ou os logs de erro nas instâncias para determinar a causa. Envie solicitações diretamente para a instância (ignore o load balancer) para exibir as respostas.

**nota**  
Se o cliente cancelar uma solicitação HTTP iniciada com um cabeçalho `Transfer-Encoding: chunked`, há um problema conhecido no qual o load balancer encaminha a solicitação para a instância, ainda que o cliente tenha cancelado a solicitação. Isso pode causar erros de back-end.

# Solução dos problemas de um Classic Load Balancer: verificações de integridade
<a name="ts-elb-healthcheck"></a>

Seu balanceador de carga verifica a integridade das instâncias registradas usando a configuração padrão de verificação de integridade fornecida pelo Elastic Load Balancing ou uma configuração de verificação de integridade personalizada que você especificar. A configuração de verificação de integridade contém informações como protocolo, porta de ping, caminho de ping, tempo limite de resposta e intervalo de verificação de integridade. Uma instância é considerada íntegra se retornar um código de resposta 200 dentro do intervalo de verificação de integridade. Para obter mais informações, consulte [Verificações de integridade para as instâncias do Classic Load Balancer](elb-healthchecks.md).

Se o estado atual de algumas ou todas as suas instâncias for `OutOfService` e o campo de descrição exibir a mensagem `Instance has failed at least the Unhealthy Threshold number of health checks consecutively`, as instâncias terão falhado na verificação de integridade do load balancer. A seguir estão os problemas a serem procurados, as possíveis causas e as etapas que você pode tomar para resolver os problemas.

**Topics**
+ [Erro na página de destino da verificação de integridade](#ts-elb-healthcheck-targetpage)
+ [A conexão com as instâncias expirou](#ts-elb-healthcheck-failed)
+ [A autenticação de chave pública não está funcionando](#ts-elb-healthcheck-publickey)
+ [A instância não está recebendo tráfego do load balancer](#ts-elb-healthcheck-securitygroup)
+ [As portas da instância não estão abertas](#ts-elb-healthcheck-ports)
+ [As instâncias em um grupo do Auto Scaling estão falhando na verificação de integridade do ELB](#ts-elb-healthcheck-autoscaling)

## Erro na página de destino da verificação de integridade
<a name="ts-elb-healthcheck-targetpage"></a>

**Problema**: uma solicitação HTTP GET emitida para a instância na porta e no caminho de ping especificados (por exemplo, HTTP:80/index.html) recebe um código de resposta diferente de 200.

**Causa 1**: nenhuma página de destino foi configurada na instância.

**Solução 1**: crie uma página de destino (por exemplo, `index.html`) em cada instância registrada e especifique seu caminho como o caminho de ping.

**Causa 2**: o valor do cabeçalho Content-Length na resposta não está definido.

**Solução 2**: se a resposta inclui um corpo, defina o cabeçalho Content-Length para um valor maior ou igual a zero ou defina o valor de Transfer-Encoding para "chunked" (em partes).

**Causa 3**: o aplicativo não foi configurado para receber solicitações do load balancer nem para retornar um código de resposta 200.

**Solução 3**: verifique o aplicativo na instância para investigar a causa.

## A conexão com as instâncias expirou
<a name="ts-elb-healthcheck-failed"></a>

**Problema**: as solicitações de verificação de integridade do load balancer para as instâncias do EC2 estão expirando ou apresentando falhas intermitentemente.

Primeiro, verifique o problema conectando-se diretamente com a instância. Recomendamos que você se conecte à sua instância de dentro da rede usando o endereço IP privado da instância.

Use o comando a seguir para uma conexão TCP:

```
telnet private-IP-address-of-the-instance port
```

Use o comando a seguir para uma conexão HTTP ou HTTPS:

```
curl –I private-IP-address-of-the-instance:port/health-check-target-page
```

Se você estiver usando uma HTTP/HTTPS conexão e obtendo uma resposta diferente de 200, consulte[Erro na página de destino da verificação de integridade](#ts-elb-healthcheck-targetpage). Se você for capaz de se conectar diretamente com a instância, verifique o seguinte:

**Causa 1**: a instância está falhando ao responder dentro do tempo limite de resposta configurado.

**Solução 1**: ajuste as configurações de tempo limite de resposta na configuração de verificação de integridade do load balancer.

**Causa 2**: a instância está sob uma carga significativa e está demorando mais do que o tempo limite de resposta configurado para responder.

**Solução 2**:
+ Verifique o gráfico de monitoramento quanto à superutilização de CPU. Para obter mais informações, consulte [Obter estatísticas para uma instância do EC2 específica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/US_SingleMetricPerInstance.html) no *Guia do usuário do Amazon EC2*.
+ Verifique a utilização de recursos de outros aplicativos, como memória ou limites, conectando-se às suas instâncias EC2.
+ Se necessário, adicione mais instâncias ou habilite o Auto Scaling. Para obter mais informações, consulte o [Guia do usuário do Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/).

**Causa 3**: se você está usando uma conexão HTTP ou HTTPS e a verificação de integridade está sendo executada em uma página de destino especificada no campo de caminho de ping (por exemplo, `HTTP:80/index.html`), pode ser que a página de destino precise de mais tempo para responder do que o tempo limite configurado.

**Solução 3**: use uma página de destino de verificação de integridade mais simples ou ajuste as configurações do intervalo de verificação de integridade.

## A autenticação de chave pública não está funcionando
<a name="ts-elb-healthcheck-publickey"></a>

**Problema**: um load balancer configurado para usar o protocolo HTTPS ou SSL com a autenticação de back-end habilitada falha ao autenticar a chave pública.

**Causa**: a chave pública no certificado SSL não corresponde à chave pública configurada no load balancer. Use o comando `s_client` para ver a lista de certificados no servidor na cadeia de certificação. Para obter mais informações, consulte [s\$1client](https://www.openssl.org/docs/man1.1.1/man1/openssl-s_client.html) na documentação do OpenSSL.

**Solução**: talvez você precise atualizar seu certificado SSL. Se o seu certificado SSL estiver atualizado, tente reinstalá-lo no seu load balancer. Para obter mais informações, consulte [Substituir o certificado SSL do seu Classic Load Balancer](elb-update-ssl-cert.md).

## A instância não está recebendo tráfego do load balancer
<a name="ts-elb-healthcheck-securitygroup"></a>

**Problema**: o security group da instância está bloqueando o tráfego do load balancer.

Faça uma captura de pacotes na instância para verificar o problema. Use o seguinte comando:

```
# tcpdump port health-check-port
```

**Causa 1**: o security group associado à instância não permite tráfego do load balancer.

**Solução 1**: edite o security group da instância para permitir o tráfego do load balancer. Adicione uma regra para permitir todo o tráfego do security group do load balancer.

**Causa 2**: o grupo de segurança do balanceador de carga não permite tráfego para as instâncias do EC2.

**Solução 2**: edite o security group do load balancer para permitir o tráfego para as sub-redes e instâncias do EC2.

Para obter informações sobre como gerenciar grupo de seguranças, consulte [Configurar grupos de segurança para o Classic Load Balancer](elb-vpc-security-groups.md).

## As portas da instância não estão abertas
<a name="ts-elb-healthcheck-ports"></a>

**Problema**: a verificação de integridade enviada à instância do EC2 pelo load balancer está bloqueada pela porta ou por um firewall.

Verifique o problema usando o seguinte comando:

```
netstat –ant
```

**Causa**: a porta de integridade ou a porta do listener especificada (se configurada de outra maneira) não está aberta. Tanto a porta especificada para a verificação de integridade quanto a porta do listener devem estar abertas e ouvindo.

**Solução**: abra a porta do listener e a porta especificadas na configuração de verificação de integridade (se configurada de outra maneira) nas instâncias para receber tráfego do load balancer.

## As instâncias em um grupo do Auto Scaling estão falhando na verificação de integridade do ELB
<a name="ts-elb-healthcheck-autoscaling"></a>

**Problema**: as instâncias no grupo do Auto Scaling são aprovadas na verificação de integridade padrão do Auto Scaling, mas não na verificação de integridade do ELB.

**Causa**: o Auto Scaling usa as verificações de status do EC2 para detectar problemas de hardware e software com as instâncias, mas o balanceador executa verificações de integridade enviando uma solicitação à instância e aguardando um código de resposta 200 ou estabelecendo uma conexão TCP (para uma verificação de integridade baseada em TCP) com a instância.

Uma instância pode falhar na verificação de integridade do ELB porque um aplicativo em execução na instância tem problemas que fazem com que o load balancer a considere fora de serviço. Essa instância pode ser aprovada na verificação de integridade do Auto Scaling. Ela não seria substituída pela política do Auto Scaling, porque é considerada íntegra com base na verificação de status do EC2.

**Solução**: use a verificação de integridade do ELB para o grupo do Auto Scaling. Quando você usa a verificação de integridade do ELB, o Auto Scaling determina o status da integridade de suas instâncias ao verificar os resultados tanto da verificação de status da instância quanto da verificação de integridade do ELB. Para obter mais informações, consulte [Adicionar verificações de integridade do Elastic Load Balancing ao grupo do Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html) no *Manual do usuário do Amazon EC2 Auto Scaling*.

# Solução dos problemas de um Classic Load Balancer: conectividade do cliente
<a name="ts-elb-connection-failed"></a>

## Os clientes não conseguem se conectar a um balanceador de carga voltado para a Internet
<a name="client-cannot-connect"></a>

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 gateway da Internet para sua Virtual Private Cloud (VPC).

**Um security group ou Network ACL não permite o tráfego**  
O grupo de segurança do balanceador de carga e qualquer rede ACLs das sub-redes do balanceador de carga deve permitir tráfego de entrada dos clientes e tráfego de saída para os clientes nas portas do ouvinte. Para obter mais informações, consulte [Configurar grupos de segurança para o Classic Load Balancer](elb-vpc-security-groups.md).

## As solicitações enviadas para um domínio personalizado não são recebidas pelo balanceador de carga.
<a name="custom-domain-request"></a>

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 sejam correspondentes.

## As solicitações HTTPS enviadas ao balanceador de carga retornam “NET::ERR\$1CERT\$1COMMON\$1NAME\$1INVALID”
<a name="https-cert-invalid"></a>

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`.

# Solução dos problemas de um Classic Load Balancer: registro de instância
<a name="ts-elb-register-instance"></a>

Quando você registra uma instância com seu load balancer, há uma série de etapas executadas antes de o load balancer começar a enviar solicitações para sua instância.

A seguir estão problemas que seu load balancer pode encontrar ao registrar suas instâncias EC2, as possíveis causas e as etapas que você pode tomar para resolver os problemas.

**Topics**
+ [O registro de uma instância EC2 está demorando muito](#ts-elb-register-too-long)
+ [Não é possível registrar uma instância iniciada a partir de uma AMI paga](#ts-elb-paid-ami-instance)

## O registro de uma instância EC2 está demorando muito
<a name="ts-elb-register-too-long"></a>

**Problema**: as instâncias do EC2 registradas estão demorando muito mais do que o esperado para entrarem no estado `InService`.

**Causa**: sua instância pode estar sendo reprovada na verificação de integridade. Após as etapas iniciais do registro da instância serem concluídas (pode levar aproximadamente 30 segundos), o load balancer iniciará o envio de solicitações de verificação de integridade. Sua instância não estará `InService` até que uma verificação de integridade seja bem-sucedida.

**Solução**: consulte [A conexão com as instâncias expirou](ts-elb-healthcheck.md#ts-elb-healthcheck-failed).

## Não é possível registrar uma instância iniciada a partir de uma AMI paga
<a name="ts-elb-paid-ami-instance"></a>

**Problema**: o Elastic Load Balancing não está registrando uma instância iniciada usando uma AMI paga.

**Causa**: suas instâncias podem ter sido lançadas usando uma AMI paga da [Amazon DevPay](https://aws.amazon.com/devpay/). 

**Solução**[: O Elastic Load Balancing não oferece suporte ao registro de instâncias iniciadas usando pagamentos da AMIs Amazon. DevPay](https://aws.amazon.com/devpay/) Observe que você pode usar o pago AMIs do [AWS Marketplace](https://aws.amazon.com/marketplace). Se você já estiver usando uma AMI paga AWS Marketplace e não conseguir registrar uma instância executada a partir dessa AMI paga, acesse o [AWS Support Centro](https://console.aws.amazon.com/support/home#/) para obter ajuda.