# Solucionar problemas de códigos de status de resposta de erros no CloudFront
Se o CloudFront solicitar um objeto de sua origem, e a origem retornar um código de status HTTP 4xx ou 5xx, haverá um problema com a comunicação entre o CloudFront e a origem.
Este tópico também inclui etapas de solução de problemas para esses códigos de status ao usar o Lambda@Edge ou o CloudFront Functions.
Os tópicos a seguir fornecem explicações detalhadas das possíveis causas dessas respostas de erro e oferecem orientação passo a passo sobre como diagnosticar e resolver os problemas subjacentes.
**Topics**
+ [Código de status HTTP 400 (solicitação inválida)](http-400-bad-request.md)
+ [Código de status HTTP 401 (Não autorizado)](http-401-unauthorized.md)
+ [Código de status HTTP 403 (método inválido)](http-403-invalid-method.md)
+ [Código de status HTTP 403 (Permissão negada)](http-403-permission-denied.md)
+ [Código de status HTTP 404 (Não encontrado)](http-404-not-found.md)
+ [Código de status HTTP 412 (Falha na pré-condição)](http-412-precondition-failed.md)
+ [Código de status HTTP 500 (Erro interno do servidor)](http-500-internal-server-error.md)
+ [Código de status HTTP 502 (Gateway inválido)](http-502-bad-gateway.md)
+ [Código de status HTTP 503 (Serviço indisponível)](http-503-service-unavailable.md)
+ [Código de status HTTP 504 (tempo limite do gateway)](http-504-gateway-timeout.md)
# Código de status HTTP 400 (solicitação inválida)
O CloudFront exibe o erro “400 Solicitação inválida” quando o cliente envia alguns dados inválidos na solicitação, como conteúdo ausente ou incorreto na carga útil ou nos parâmetros. Isso também pode representar um erro genérico do cliente.
## A origem do Amazon S3 exibe um erro 400
Se você estiver usando uma origem do Amazon S3 com a distribuição do CloudFront, sua distribuição poderá enviar respostas com o código de status HTTP “400 Solicitação inválida” e uma mensagem semelhante à seguinte:
*The authorization header is malformed; the region '**' is wrong; expecting '**'*
Por exemplo:
*The authorization header is malformed; the region 'us-east-1' is wrong; expecting 'us-west-2'*
Esse problema pode ocorrer no seguinte cenário:
1. A origem da distribuição do CloudFront é um bucket do Amazon S3.
1. Você moveu o bucket do S3 de uma região da AWS para outra. Ou seja, você excluiu o bucket do S3 e, posteriormente, criou um novo bucket com o mesmo nome de bucket, mas em uma região da AWS diferente de onde o bucket original do S3 estava localizado.
Para corrigir esse erro, atualize a distribuição do CloudFront para que ele localize o bucket do S3 na região da AWS atual do bucket.
**Como atualizar a distribuição do CloudFront**
1. Faça login no Console de gerenciamento da AWS e abra o console do CloudFront em [https://console.aws.amazon.com/cloudfront/v4/home](https://console.aws.amazon.com/cloudfront/v4/home).
1. Escolha a distribuição que produz esse erro.
1. Escolha **Origins and Origin Groups (Origens e Grupos de Origem)**.
1. Localize a origem do bucket do S3 que você moveu. Marque a caixa de seleção ao lado dessa origem e escolha **Edit (Editar)**.
1. Escolha **Yes, Edit**. Você não precisa alterar nenhuma configuração antes de escolher **Yes, Edit (Sim, editar)**.
Ao concluir essas etapas, o CloudFront reimplantará sua distribuição. Enquanto a distribuição estiver sendo implantada, você verá o status **Implantando** na coluna **Última modificação**. Algum tempo depois que a implantação estiver concluída, você deverá parar de receber as respostas de erro `AuthorizationHeaderMalformed`.
## A origem do Application Load Balancer exibe um erro 400
Se estiver usando uma origem do Application Load Balancer com a distribuição do CloudFront, as possíveis causas do erro 400 são as seguintes:
+ 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.
# Código de status HTTP 401 (Não autorizado)
Um código de status de resposta “401 Não autorizado” indica que a solicitação do cliente não foi concluída porque não tem credenciais de autenticação válidas para o recurso solicitado. Esse código de status é enviado com um cabeçalho de resposta `WWW-Authenticate` HTTP que contém informações sobre como o cliente pode solicitar o recurso novamente depois de solicitar as credenciais de autenticação do usuário. Para ter mais informações, consulte [401 Não autorizado](https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/401).
No CloudFront, quando sua origem espera que um cabeçalho `Authorization` autentique as solicitações, o CloudFront precisa encaminhar o cabeçalho `Authorization` à origem para evitar um erro “401 Não autorizado”. Quando o CloudFront encaminha uma solicitação de visualizador para sua origem, o CloudFront remove alguns cabeçalhos de visualizador por padrão, incluindo o `Authorization` cabeçalho. Para garantir que sua origem sempre receba o `Authorization` cabeçalho em solicitações de origem, você tem as seguintes opções:
+ Adicione o cabeçalho `Authorization` à chave de cache usando uma política de cache. Todos os cabeçalhos na chave de cache são automaticamente incluídos nas solicitações de origem. Para obter mais informações, consulte [Controlar a chave de cache com uma política](controlling-the-cache-key.md).
+ Use uma política de solicitação de origem que encaminha todos os cabeçalhos do visualizador para a origem. Não é possível encaminhar o cabeçalho `Authorization` individualmente em uma política de solicitação de origem, mas ao encaminhar todos os cabeçalhos do visualizador, o CloudFront inclui o cabeçalho `Authorization` nas solicitações do visualizador. O CloudFront fornece a política gerenciada de solicitação de origem `AllViewer` para esse caso de uso. Para obter mais informações, consulte [Usar políticas de solicitação de origem gerenciadas](using-managed-origin-request-policies.md).
Para ter mais informações, consulte [Como configuro o CloudFront de forma que o cabeçalho Authorization seja encaminhado para a origem?](https://repost.aws/knowledge-center/cloudfront-authorization-header).
# Código de status HTTP 403 (método inválido)
O CloudFront exibirá o erro 403 (método inválido) se você estiver tentando usar um método HTTP que não tenha especificado na distribuição do CloudFront. É possível especificar uma das seguintes opções para sua distribuição:
+ O CloudFront encaminha somente as solicitações `GET` e `HEAD`.
+ O CloudFront encaminha somente as solicitações `GET`, `HEAD` e `OPTIONS`.
+ O CloudFront encaminha as solicitações `GET`, `HEAD`, `OPTIONS`, `PUT`, `PATCH`, `POST` e `DELETE`. (Se você selecionar essa opção, talvez seja necessário restringir o acesso ao bucket do Amazon S3 ou à origem personalizada para impedir que os usuários executem operações indesejadas.) Por exemplo, talvez não seja necessário que os usuários tenham permissões para excluir objetos de sua origem.
# Código de status HTTP 403 (Permissão negada)
Um erro HTTP 403 significa que o cliente não está autorizado a acessar o recurso solicitado. O cliente entende a solicitação, mas não pode autorizar o acesso do visualizador. As causas comuns para o CloudFront exibir esse código de status são as seguintes:
**Topics**
+ [O CNAME alternativo está configurado incorretamente.](#alternate-cname-incorrectly-configured)
+ [O AWS WAF está configurado na distribuição do CloudFront ou na origem.](#aws-waf-configured-on-distribution-origin)
+ [A origem personalizada exibe um erro 403](#custom-origin-returning-403)
+ [A origem do Amazon S3 exibe um erro 403](#s3-origin-403-error)
+ [Restrições geográficas exibem um erro 403](#geolocation-403)
+ [URL assinado ou configuração de cookie assinado exibe um erro 403](#signed-URLs-cookies-403)
+ [Distribuições empilhadas causam um erro 403](#stacked-distributions-403)
## O CNAME alternativo está configurado incorretamente.
Verifique se você especificou o CNAME correto para nossa distribuição. Para usar um CNAME alternativo em vez do URL padrão do CloudFront:
1. Crie um registro CNAME no DNS para apontar o CNAME para o URL de distribuição do CloudFront.
1. Adicione o CNAME à configuração de distribuição do CloudFront.
Se você criar o registro DNS e não adicionar o CNAME à configuração de distribuição do CloudFront, a solicitação exibirá um erro 403. Para ter mais informações sobre como configurar um CNAME personalizado, consulte [Usar URLs personalizados adicionando nomes de domínio alternativos (CNAMEs)](CNAMEs.md).
## O AWS WAF está configurado na distribuição do CloudFront ou na origem.
Quando o AWS WAF está entre o cliente e o CloudFront, o CloudFront não consegue diferenciar entre um código de erro 403 exibido por sua origem e um exibido pelo AWS WAF quando uma solicitação é bloqueada.
Para encontrar a origem do código de status 403, confira a regra de lista de controle de acesso (ACL) da web do AWS WAF para ver se há uma solicitação bloqueada. Para saber mais, consulte os seguintes tópicos:
+ [AWS WAF Listas de controle de acesso da web (ACLs da web) do)](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl.html)
+ [Testar e ajustar as proteções do AWS WAF](https://docs.aws.amazon.com/waf/latest/developerguide/web-acl-testing.html)
## A origem personalizada exibe um erro 403
Se você estiver usando uma origem personalizada, poderá ver um erro 403 se tiver uma configuração de firewall personalizada na origem. Para solucionar o problema, faça a solicitação diretamente na origem. Se você conseguir replicar o erro sem o CloudFront, isso significa que a origem está causando o erro 403.
Se a origem personalizada estiver causando o erro, confira os logs de origem para identificar o que pode estar causando o erro. Para ter mais informações, consulte os seguintes tópicos de solução de problemas:
+ [Como soluciono erros HTTP 403 do API Gateway?](https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-troubleshoot-403-forbidden/ )
+ [Como soluciono erros proibidos de HTTP 403 do Application Load Balancer?](https://repost.aws/knowledge-center/alb-http-403-error)
## A origem do Amazon S3 exibe um erro 403
Você pode ver um erro 403 pelos seguintes motivos:
+ O CloudFront não tem acesso ao bucket do Amazon S3. Isso poderá acontecer se a identidade do acesso de origem (OAI) ou o controle do acesso de origem (OAC) não estiverem habilitados para sua distribuição e o bucket for privado.
+ O caminho especificado no URL solicitado não está correto.
+ O objeto solicitado não existe.
+ O cabeçalho do host foi encaminhado com o endpoint da API REST. Para ter mais informações, consulte [Especificação de bucket do cabeçalho Host HTTP](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html#VirtualHostingSpecifyBucket), no *Guia do usuário do Amazon Simple Storage Service*.
+ Você configurou páginas de erro personalizadas. Para obter mais informações, consulte [Como o CloudFront processará erros quando páginas de erro personalizadas estiverem configuradas](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
## Restrições geográficas exibem um erro 403
Se você habilitou restrições geográficas (também conhecidas como bloqueios geográficos), para impedir que usuários em localizações geográficas específicas acessem o conteúdo que você está distribuindo por meio de uma distribuição do CloudFront, os usuários bloqueados receberão um erro 403.
Para obter mais informações, consulte [Restringir a distribuição geográfica do conteúdo](georestrictions.md).
## URL assinado ou configuração de cookie assinado exibe um erro 403
Se você habilitou **Restringir acesso do visualizador** para a configuração de comportamento da distribuição, as solicitações que não usam cookies assinados ou URLs assinados vão gerar um erro 403. Para saber mais, consulte os seguintes tópicos:
+ [Veicular conteúdo privado com URLs e cookies assinados](PrivateContent.md)
+ [Como soluciono problemas relacionados a um URL assinado ou cookies assinados no CloudFront?](https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-troubleshoot-signed-url-cookies/)
## Distribuições empilhadas causam um erro 403
Se você tiver duas ou mais distribuições em uma cadeia de solicitações para o endpoint de origem, o CloudFront exibirá um erro 403. Não recomendamos colocar uma distribuição na frente da outra.
# Código de status HTTP 404 (Não encontrado)
O CloudFront exibe o erro “404 (Não encontrado)” quando o cliente tenta acessar um recurso que não existe. Se você receber esse erro com a distribuição do CloudFront, as causas comuns são as seguintes:
+ O recurso não existe.
+ O URL está incorreto.
+ A origem personalizada está exibindo um erro 404.
+ Páginas de erro personalizadas estão exibindo um erro 404. (Qualquer código de erro pode ser convertido em 404.) Para obter mais informações, consulte [Como o CloudFront processará erros quando páginas de erro personalizadas estiverem configuradas](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
+ A página de erro personalizada foi excluída acidentalmente, gerando um erro 404 porque a solicitação procura a página de erro personalizada excluída. Para obter mais informações, consulte [Como o CloudFront processará erros se você não tiver configurado páginas de erro personalizadas](HTTPStatusCodes.md#HTTPStatusCodes-no-custom-error-pages).
+ Caminho de origem incorreto. Se o caminho de origem for preenchido, o valor será anexado ao caminho de cada solicitação do navegador antes que a solicitação seja encaminhada à origem. Para obter mais informações, consulte [Caminho de origem](DownloadDistValuesOrigin.md#DownloadDistValuesOriginPath).
# Código de status HTTP 412 (Falha na pré-condição)
O CloudFront exibe um código de erro “412 (Falha na pré-condição)” quando o acesso ao recurso de destino é negado. Em alguns casos, um servidor é configurado para aceitar solicitações somente depois de determinadas condições serem atendidas. Se alguma das condições especificadas não for atendida, o servidor não permitirá que o cliente acesse o recurso fornecido. Em vez disso, o servidor responderá com um código de erro 412.
As causas comuns de um erro 412 no CloudFront são:
+ Solicitações condicionais em métodos diferentes de `GET` ou `HEAD` quando a condição definida pelos cabeçalhos `If-Unmodified-Since` ou `If-None-Match` não é atendida. Nesse caso, a solicitação, geralmente um upload ou a modificação de um recurso, não pode ser feita.
+ Uma condição em um ou mais campos da solicitação na operação de API [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html) do CloudFront é avaliada como falsa.
# Código de status HTTP 500 (Erro interno do servidor)
Um código de status HTTP “500 (Erro interno do servidor)” indica que o servidor encontrou uma condição inesperada que o impediu de atender à solicitação. Veja a seguir algumas causas comuns de erros 500 no Amazon CloudFront.
**Topics**
+ [O servidor de origem exibe o erro 500 para o CloudFront](#origin-server-500-error)
## O servidor de origem exibe o erro 500 para o CloudFront
O servidor de origem pode estar exibindo um erro 500 para o CloudFront. Consulte os seguintes tópicos de solução de problemas para ter mais informações:
+ **Se o Amazon S3 exibir um erro 500**, consulte [Como solucionar um erro HTTP 500 ou 503 do Amazon S3?](https://repost.aws/knowledge-center/http-5xx-errors-s3).
+ **Se o API Gateway exibir um erro 500**, consulte [Como posso solucionar os erros 5xx da API REST do API Gateway?](https://repost.aws/knowledge-center/api-gateway-5xx-error).
+ **Se o Elastic Load Balancing exibir um erro 500**, consulte [HTTP 500: Internal server error](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-500-issues) no *Guia do usuário de Application Load Balancers*.
Se a lista anterior não resolver o erro 500, é provável que o problema seja que um ponto de presença do CloudFront Point está exibindo um erro interno do servidor. É possível entrar em contato com o [Suporte](https://console.aws.amazon.com/support/home#/) para receber assistência.
# Código de status HTTP 502 (Gateway inválido)
O CloudFront exibe um código de status HTTP “502 (Gateway inválido)” quando ele não consegue fornecer o objeto solicitado devido à impossibilidade de se conectar ao servidor de origem.
Se você estiver usando o Lambda@Edge, o problema pode ser um erro de validação do Lambda. Se você receber um erro HTTP 502 com o código de erro `NonS3OriginDnsError`, provavelmente há um problema de configuração de DNS que impede o CloudFront de se conectar à origem.
**Topics**
+ [Falha de negociação SSL/TLS entre o CloudFront e um servidor de origem personalizado](#ssl-negotitation-failure)
+ [A origem não está respondendo com criptografias/protocolos compatíveis](#origin-not-responding-with-supported-ciphers-protocols)
+ [O certificado SSL/TLS da origem expirou, é inválido ou autoassinado, ou a cadeia de certificados está no pedido errado](#ssl-certificate-expired)
+ [A origem não está respondendo nas portas especificadas nas configurações](#origin-not-responding-on-specified-ports)
+ [Erro de validação do Lambda](#http-502-lambda-validation-error)
+ [Erro de validação da função do CloudFront](#http-502-cloudfront-function-validation-error)
+ [Erro de DNS (`NonS3OriginDnsError`)](#http-502-dns-error)
+ [Erro 502 de origem do Application Load Balancer](#cloudfront-alb-502-error)
+ [Erro 502 de origem do API Gateway](#cloudfront-api-gateway-502-error)
## Falha de negociação SSL/TLS entre o CloudFront e um servidor de origem personalizado
Se você usar uma origem personalizada que exija HTTPS entre o CloudFront e a origem, nomes de domínio não correspondentes poderão causar erros. O certificado SSL/TLS em sua origem *deve* incluir um nome de domínio que corresponda ao **domínio de origem** que você especificou para a distribuição do CloudFront ou ao cabeçalho `Host` da solicitação de origem.
Se os nomes de domínio não coincidirem, o handshake SSL/TLS falhará e o CloudFront retornará um código de status HTTP 502 (gateway inválido) e definirá o cabeçalho `X-Cache` como `Error from cloudfront`.
Para determinar se os nomes de domínio no certificado correspondem ao **Domínio de origem** da distribuição ou ao cabeçalho `Host`, você pode usar um verificador SSL on-line ou o OpenSSL. Se os nomes de domínio não forem correspondentes, você tem duas opções:
+ Obtenha um novo certificado SSL/TLS que inclua os nomes de domínio aplicáveis.
Se você usar o AWS Certificate Manager (ACM), consulte [Solicitar um certificado](https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-request-public.html) no *Guia do usuário do AWS Certificate Manager* para solicitar um novo certificado.
+ Altere a configuração da distribuição para que o CloudFront não tente mais usar SSL para conectar-se à origem.
### Verificador SSL online
Para encontrar uma ferramenta de teste de SSL, pesquise na Internet por "verificador ssl online". Normalmente, você especifica o nome do seu domínio, e a ferramenta retorna uma variedade de informações sobre seu certificado SSL/TLS. Confirme se o certificado contém seu nome de domínio nos campos **Nome comum** ou **Nomes alternativos da entidade**.
### OpenSSL
Para ajudar a solucionar problemas de erros HTTP 502 no CloudFront, você pode usar o OpenSSL para tentar fazer uma conexão SSL/TLS com o servidor de origem. Se o OpenSSL não for capaz de fazer uma conexão, isso pode indicar um problema com a configuração de SSL/TLS do servidor de origem. Se o OpenSSL for capaz de fazer uma conexão, ele retornará informações sobre o certificado do servidor de origem, incluindo o nome comum (campo `Subject CN`) e o nome alternativo da entidade (campo `Subject Alternative Name`) do certificado.
Use o seguinte comando OpenSSL para testar a conexão com o servidor de origem (substitua o *domínio de origem* pelo nome de domínio do servidor de origem, como exemplo.com):
`openssl s_client -connect origin domain name:443`
Se o seguinte for verdadeiro:
+ Seu servidor de origem oferece suporte a vários nomes de domínio com vários certificados SSL/TLS
+ Sua distribuição está configurada para encaminhar o cabeçalho `Host` para a origem
Depois adicione a opção `-servername` ao comando do OpenSSL, como no exemplo a seguir (substitua *CNAME* pelo CNAME configurado em sua distribuição):
`openssl s_client -connect origin domain name:443 -servername CNAME`
## A origem não está respondendo com criptografias/protocolos compatíveis
O CloudFront se conecta a servidores de origem usando criptografias e protocolos. Para obter uma lista de criptografias e protocolos compatíveis com o CloudFront, consulte [Protocolos e criptografias compatíveis entre o CloudFront e a origem](secure-connections-supported-ciphers-cloudfront-to-origin.md). Caso a origem não responda com uma dessas criptografias ou protocolos na troca de SSL/TLS, ocorrerá uma falha na conexão do CloudFront. Você pode validar se a sua origem é compatível com as criptografias e os protocolos usando uma ferramenta online, como o [SSL Labs](https://www.ssllabs.com/ssltest). Digite o nome de domínio da sua origem no campo **Hostname** e, em seguida, escolha **Submit**. Analise os campos **Common names** e **Alternative names** do teste para ver se eles são correspondentes com o nome de domínio da sua origem. Após a conclusão do teste, encontre as seções **Protocols** e **Cipher Suites** nos resultados do teste para ver quais criptografias ou protocolos são compatíveis com sua origem. Compare o conteúdo com a lista de [Protocolos e criptografias compatíveis entre o CloudFront e a origem](secure-connections-supported-ciphers-cloudfront-to-origin.md).
## O certificado SSL/TLS da origem expirou, é inválido ou autoassinado, ou a cadeia de certificados está no pedido errado
Se o servidor de origem retornar o seguinte, o CloudFront interromperá a conexão TCP, retornará o código de status HTTP 502 (gateway inválido) e definirá o cabeçalho `X-Cache` como `Error from cloudfront`:
+ Um certificado expirado
+ Certificado inválido
+ Certificado autoassinado
+ Cadeia de certificados na ordem errada
**nota**
Se toda a cadeia de certificados, inclusive o certificado intermediário, não estiver presente, o CloudFront interromperá a conexão TCP.
Para obter informações sobre como instalar um certificado SSL/TLS no seu servidor de origem personalizado, consulte [Exigir HTTPS na comunicação entre o CloudFront e a origem personalizada](using-https-cloudfront-to-custom-origin.md).
## A origem não está respondendo nas portas especificadas nas configurações
Ao criar uma origem na distribuição do CloudFront, defina as portas de conexão do CloudFront com a origem para tráfego HTTP e HTTPS. Por padrão, são elas: TCP 80/443. Você tem a opção de modificar essas portas. Caso a origem esteja rejeitando o tráfego nessas portas por algum motivo ou o servidor de backend não esteja respondendo nas portas, ocorrerá uma falha na conexão do CloudFront.
Para solucionar esses problemas, marque todos os firewalls em execução na sua infraestrutura e valide se eles não são bloqueando os intervalos de IP compatíveis. Consulte mais informações em [Intervalos de endereços IP da AWS](https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-ranges.html) no *Guia do usuário da Amazon VPC*. Além disso, verifique se o seu servidor da web está em execução na origem.
## Erro de validação do Lambda
Se você estiver usando o Lambda@Edge, um código de status HTTP 502 poderá indicar que a resposta da função do Lambda foi formada incorretamente ou incluía conteúdo inválido. Para obter mais informações sobre a resolução de erros do Lambda@Edge, consulte [Testar e depurar as funções do Lambda@Edge](lambda-edge-testing-debugging.md).
## Erro de validação da função do CloudFront
Se você estiver usando funções do CloudFront, um código de status HTTP 502 poderá indicar que a função do CloudFront está tentando adicionar, excluir ou alterar um cabeçalho somente para leitura. Esse erro não é exibido durante o teste, mas aparecerá depois que você implantar a função e executar a solicitação. Para solucionar esse erro, verifique e atualize a função do CloudFront. Para obter mais informações, consulte [Atualizar funções](update-function.md).
## Erro de DNS (`NonS3OriginDnsError`)
Um erro HTTP 502 com o código de erro `NonS3OriginDnsError` indica que há um problema de configuração de DNS que impede o CloudFront de se conectar à origem. Se você receber esse erro do CloudFront, verifique se a configuração de DNS da origem está correta e funcionando.
Ao receber uma solicitação de um objeto expirado ou não armazenado no cache, o CloudFront faz uma solicitação para a origem obter o objeto. Para fazer uma solicitação bem-sucedida para a origem, o CloudFront executa uma resolução de DNS no domínio da origem. Se o serviço DNS do domínio estiver com problemas, o CloudFront não poderá resolver o nome de domínio para obter o endereço IP, o que resultará em um erro HTTP 502 (`NonS3OriginDnsError`). Para corrigir esse problema, entre em contato com o seu provedor de DNS ou, se estiver utilizando o Amazon Route 53, consulte [Why can't I access my website that uses Route 53 DNS services?](https://aws.amazon.com/premiumsupport/knowledge-center/route-53-dns-website-unreachable/) (Por que não consigo acessar meu site que usa os serviços de DNS do Route 53?)
Para resolver ainda mais esse problema, certifique-se de que os [servidores de nome autoritativos](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-authoritative-name-server) do domínio raiz da origem ou do apex de zona (como `example.com`) estejam funcionando corretamente. Você pode usar os seguintes comandos para encontrar os servidores de nome da origem do apex com uma ferramenta como [dig](https://en.wikipedia.org/wiki/Dig_(command)) ou [nslookup](https://en.wikipedia.org/wiki/Nslookup):
```
dig OriginAPEXDomainName NS +short
```
```
nslookup -query=NS OriginAPEXDomainName
```
Quando você tiver os nomes dos seus servidores de nome, use os seguintes comandos para consultar o nome de domínio da sua origem neles e garantir que cada um responda com uma resposta:
```
dig OriginDomainName @NameServer
```
```
nslookup OriginDomainName NameServer
```
**Importante**
Executa essa resolução de problemas de DNS usando um computador conectado à Internet pública. Como o CloudFront resolve o domínio de origem usando DNS público na internet, é importante solucionar problemas em um contexto semelhante.
Se a origem for um subdomínio cuja autoridade DNS está delegada a um servidor de nomes diferente do domínio raiz, verifique se os registros do servidor de nomes (`NS`) e início de autoridade (`SOA`) estão configurados corretamente para o subdomínio. É possível verificar esses registros usando comandos semelhantes aos exemplos anteriores.
Para obter mais informações sobre DNS, consulte [Conceitos de Domain Name System (DNS)](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/route-53-concepts.html#route-53-concepts-domain-name-system-dns) na documentação do Amazon Route 53.
## Erro 502 de origem do Application Load Balancer
Se você usa o Application Load Balancer como origem e recebe um erro 502, consulte [Como soluciono os erros HTTP 502 do Application Load Balancer?](https://repost.aws/knowledge-center/elb-alb-troubleshoot-502-errors).
## Erro 502 de origem do API Gateway
Se você usa o API Gateway e recebe um erro 502, consulte [Como faço para resolver erros HTTP 502 das APIs REST do API Gateway com integração de proxy do Lambda?](https://repost.aws/knowledge-center/malformed-502-api-gateway).
# Código de status HTTP 503 (Serviço indisponível)
Um código de status HTTP 503 (Serviço indisponível) normalmente indica um problema de performance no servidor de origem. Em casos raros, ele indica que o CloudFront não pode atender a uma solicitação temporariamente devido a uma limitação de recursos em um local da borda.
Se você estiver usando o Lambda@Edge ou o CloudFront Functions, o problema pode ser um erro de execução ou um erro de limite excedido do Lambda@Edge.
**Topics**
+ [O servidor de origem não tem capacidade suficiente para oferecer suporte à taxa de solicitação](#http-503-service-unavailable-not-enough-origin-capacity)
+ [O CloudFront provocou o erro devido a restrições de recursos no local da borda](#http-503-service-unavailable-limited-resources-at-edge-location)
+ [Erro de execução do Lambda@Edge ou do CloudFront Function](#http-503-lambda-execution-error)
+ [Limite do Lambda@Edge excedido](#http-503-lambda-limit-exceeded-error)
## O servidor de origem não tem capacidade suficiente para oferecer suporte à taxa de solicitação
Quando um servidor de origem não está disponível ou não consegue atender às solicitações recebidas, ele exibe um código de status HTTP 503 (serviço indisponível). O CloudFront então transmite o erro de volta para o usuário. Para resolver esse problema, tente as seguintes soluções:
+ **Se você usa o Amazon S3 como servidor de origem**:
+ É possível enviar 3.500 solicitações PUT/COPY/POST/DELETE ou 5.500 solicitações GET/HEAD por segundo por prefixo particionado do Amazon S3. Quando o Amazon S3 exibe uma resposta 503 Slow Down, isso normalmente indica uma taxa de solicitação excessiva em relação a um prefixo específico do Amazon S3.
Como as taxas de solicitação se aplicam por prefixo em um bucket do S3, os objetos devem ser distribuídos em vários prefixos. À medida que a taxa de solicitação nos prefixos aumenta de forma gradual, o Amazon S3 aumenta a escala verticalmente para lidar com as solicitações de cada um dos prefixos de maneira separada. Como resultado, a taxa geral de solicitações processada pelo bucket é um múltiplo do número de prefixos.
+ Para obter mais detalhes, consulte [Otimizar a performance do Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html), no *Guia do usuário do Amazon Simple Storage Service*.
+ **Se você usar o Elastic Load Balancing como servidor de origem**:
+ Garanta que suas instâncias de back-end possam responder às verificações de integridade.
+ Garanta que o balanceador de carga e as instâncias de back-end possam lidar com a carga.
Para obter mais informações, consulte:
+ [Como soluciono erros 503 exibidos ao usar o Classic Load Balancer?](https://repost.aws/knowledge-center/503-error-classic)
+ [Como soluciono erros 503 (serviço indisponível) do Application Load Balancer?](https://repost.aws/knowledge-center/alb-troubleshoot-503-errors)
+ **Se você usa uma origem personalizada**:
+ Examine os logs da aplicação para garantir que a origem tenha recursos suficientes, como memória, CPU e tamanho do disco.
+ Se você usa o Amazon EC2 como o backend, verifique se o tipo de instância tem os recursos apropriados para atender às solicitações recebidas. Para ter mais informações, consulte [Instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html), no *Guia do usuário do Amazon EC2*.
+ **Se você usa o API Gateway**:
+ Esse erro está relacionado à integração de back-end quando a API do API Gateway não consegue receber uma resposta. O servidor de back-end pode estar:
+ Sobrecarregado além da capacidade e incapaz de processar novas solicitações de clientes.
+ Em manutenção temporária.
+ Para resolver esse erro, consulte os logs da aplicação do API Gateway para determinar se há algum problema com a capacidade de back-end, a integração ou qualquer outra coisa.
## O CloudFront provocou o erro devido a restrições de recursos no local da borda
Você receberá esse erro se o CloudFront não puder encaminhar solicitações ao melhor local da borda seguinte disponível e, portanto, não poderá atender a uma solicitação. Esse erro é comum ao executar testes de carga na distribuição do CloudFront. Para evitar isso, siga as diretrizes de [Testes de carga do CloudFront](load-testing.md) para evitar erros 503 (capacidade excedida).
Se isso acontecer no ambiente de produção, entre em contato com o [Suporte](https://console.aws.amazon.com/support/home#/).
## Erro de execução do Lambda@Edge ou do CloudFront Function
Se você estiver usando o Lambda@Edge ou o CloudFront Functions, um código de status HTTP 503 pode indicar que sua função retornou um erro de execução.
Para ter mais detalhes sobre como identificar e resolver erros do Lambda@Edge, consulte [Testar e depurar as funções do Lambda@Edge](lambda-edge-testing-debugging.md).
Para ter mais informações sobre como testar o CloudFront Functions, consulte [Testar funções](test-function.md).
## Limite do Lambda@Edge excedido
Se você estiver usando o Lambda@Edge, um código de status HTTP 503 poderá indicar que o Lambda exibiu um erro. O erro pode ser causado por uma das seguintes situações:
+ O número de execuções de função excedeu uma das cotas que o Lambda define para limitar as execuções em uma Região da AWS (execuções simultâneas ou frequência de invocação).
+ A função excedeu a cota de tempo limite da função do Lambda.
Para ter mais informações sobre as cotas do Lambda@Edge, consulte [Cotas do Lambda@Edge](cloudfront-limits.md#limits-lambda-at-edge). Para ter mais detalhes sobre como identificar e resolver erros do Lambda@Edge, consulte [Testar e depurar as funções do Lambda@Edge](lambda-edge-testing-debugging.md). Você também pode ver as [Cotas do serviço do Lambda](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html) no *Guia do desenvolvedor do AWS Lambda*.
# Código de status HTTP 504 (tempo limite do gateway)
Um código de status HTTP 504 (tempo limite do gateway) indica que, quando o CloudFront encaminhou uma solicitação para a origem (porque o objeto solicitado não estava no cache de borda), ocorreu uma das seguintes situações:
+ A origem retornou um código de status HTTP 504 para o CloudFront.
+ A origem não respondeu antes que a solicitação expirasse.
O CloudFront retornará um código de status HTTP 504 se o tráfego estiver bloqueado para a origem por um firewall ou por um grupo de segurança ou se a origem não estiver acessível na Internet. Verifique esses problemas primeiro. Então, se o acesso não for o problema, explore os atrasos das aplicações e os tempos limite do servidor para ajudar a identificar e corrigir os problemas.
**Topics**
+ [Configurar o firewall no servidor de origem para permitir o tráfego do CloudFront](#http-504-gateway-timeout-configure-firewall)
+ [Configure os grupos de segurança no servidor de origem para permitir o tráfego do CloudFront](#http-504-gateway-timeout-configure-security-groups)
+ [Torne seu servidor de origem personalizado acessível na Internet](#http-504-gateway-timeout-make-origin-accessible)
+ [Encontre e corrija respostas atrasadas de aplicações no seu servidor de origem](#http-504-gateway-timeout-slow-application)
## Configurar o firewall no servidor de origem para permitir o tráfego do CloudFront
Se o firewall no servidor de origem bloquear o tráfego do CloudFront, este retornará um código de status HTTP 504. Portanto, verifique se o problema não é esse antes de examinar outras possibilidades.
O método usado para determinar se isso é um problema com o firewall depende do sistema usado pelo servidor de origem:
+ Se você usar um firewall IPTable em um servidor Linux, poderá pesquisar ferramentas e informações para ajudá-lo a trabalhar com IPTables.
+ Se você utiliza o Firewall do Windows em um servidor Windows, consulte [Adicionar ou editar regras de firewall](https://technet.microsoft.com/en-us/library/cc753558(v=ws.11).aspx), na documentação da Microsoft.
Ao avaliar a configuração do firewall no servidor de origem, procure por firewalls ou regras de segurança que bloqueiam o tráfego dos pontos de presença do CloudFront, com base no intervalo de endereços IP publicado. Para obter mais informações, consulte [Localizações e intervalos de endereço IP dos servidores de borda do CloudFront](LocationsOfEdgeServers.md).
Se o intervalo de endereços IP do CloudFront tiver permissão para se conectar ao servidor de origem, atualize as regras de segurança do servidor para incorporar as alterações. Você pode assinar um tópico do Amazon SNS e receber notificações quando o arquivo de intervalo de endereços IP for atualizado. Depois de receber a notificação, você poderá usar o código para recuperar o arquivo, analisá-lo e fazer ajustes de acordo com o seu ambiente local. Para obter mais informações, consulte [Assinar alterações de endereços IP público da AWS via Amazon SNS](https://aws.amazon.com/blogs/aws/subscribe-to-aws-public-ip-address-changes-via-amazon-sns/), no blog de notícias da AWS.
## Configure os grupos de segurança no servidor de origem para permitir o tráfego do CloudFront
Se a origem usar o Elastic Load Balancing, revise os [grupos de segurança do ELB](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-security-groups.html) e verifique se os grupos de segurança permitem o tráfego de entrada no CloudFront.
É possível usar o AWS Lambda para atualizar seus grupos de segurança automaticamente e permitir o tráfego de entrada do CloudFront.
## Torne seu servidor de origem personalizado acessível na Internet
Se o CloudFront não puder acessar o servidor de origem personalizado porque não está disponível publicamente na Internet, o CloudFront retornará um erro HTTP 504.
Os pontos de presença do CloudFront se conectam aos servidores de origem por meio da Internet. Se a origem personalizada estiver em uma rede privada, o CloudFront não poderá acessá-la. Por causa disso, não é possível usar servidores privados, incluindo [Classic Load Balancers internos](https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-internal-load-balancers.html), como servidores de origem com o CloudFront.
Para conferir se o tráfego da Internet pode se conectar ao servidor de origem, execute os seguintes comandos (em que *OriginDomainName* é o nome de domínio do servidor):
Para tráfego de HTTP:
+ nc -zv *OriginDomainName* 443
+ telnet *OriginDomainName* 443
Para tráfego HTTP:
+ nc -zv *OriginDomainName* 80
+ telnet *OriginDomainName* 80
## Encontre e corrija respostas atrasadas de aplicações no seu servidor de origem
Os tempos limite do servidor geralmente são resultado de um aplicativo que demora muito tempo para responder ou de um valor de tempo limite definido como muito baixo.
Uma solução rápida para ajudar a evitar erros HTTP 504 é definir um valor maior para o tempo limite do CloudFront para a distribuição. Mas recomendamos que você primeiro verifique se há problemas de performance e latência com o aplicativo e o servidor de origem. Em seguida, você pode definir um valor de tempo limite razoável que ajuda a evitar erros HTTP 504 e fornece boa capacidade de resposta para os usuários.
Veja a seguir uma visão geral das etapas que você pode realizar para encontrar problemas de performance e corrigi-los:
1. Meça a latência típica e de alta carga (capacidade de resposta) do seu aplicativo web.
1. Adicione outros recursos, como CPU ou memória, se necessário. Tome outras medidas para resolver problemas, como ajuste de consultas de banco de dados para acomodar cenários de alta carga.
1. Se necessário, ajuste o valor de tempo limite para sua distribuição do CloudFront.
Veja a seguir os detalhes sobre cada etapa.
### Meça a latência típica e de alta carga
Para determinar se um ou mais servidores de aplicativos web de backend estão com alta latência, execute o seguinte comando "curl" do Linux em cada servidor:
```
curl -w "DNS Lookup Time: %{time_namelookup} \nConnect time: %{time_connect} \nTLS Setup: %{time_appconnect} \nRedirect Time: %{time_redirect} \nTime to first byte: %{time_starttransfer} \nTotal time: %{time_total} \n" -o /dev/null https://www.example.com/yourobject
```
**nota**
Se executar o Windows nos servidores, você poderá procurar e fazer download do "curl" para que o Windows execute um comando semelhante.
Conforme você mede e avalia a latência de um aplicativo executado no seu servidor, lembre-se do seguinte:
+ Os valores de latência são relativos a cada aplicativo. No entanto, um tempo até o primeiro byte em milissegundos, em vez de segundos ou mais, é razoável.
+ Se você medir a latência da aplicação com carga normal e ela estiver boa, os visualizadores ainda poderão se deparar com tempo limite com alta carga. Quando há alta demanda, os servidores podem ter respostas atrasadas ou nem retornar respostas. Para ajudar a evitar problemas de latência de alta carga, verifique os recursos do servidor, como leituras e gravações de CPU e memória e disco, para garantir que os servidores tenham a capacidade de escalar para alta carga.
Você pode executar o seguinte comando do Linux para verificar a memória usada pelos processos do Apache:
`watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"`
+ A alta utilização da CPU no servidor pode reduzir significativamente a performance de uma aplicação. Se você usar uma instância do Amazon EC2 para o servidor de backend, revise as métricas do CloudWatch para o servidor verificar a utilização da CPU. Para obter mais informações, consulte o [Guia do usuário do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html). Ou se você estiver usando seu próprio servidor, consulte a respectiva documentação de ajuda para ter instruções sobre como conferir a utilização da CPU.
+ Verifique outros problemas possíveis com cargas altas, como consultas de banco de dados que são executadas lentamente quando há grande volume de solicitações.
### Adicione recursos e ajuste servidores e bancos de dados
Depois de avaliar a capacidade de resposta dos seus aplicativos e servidores, verifique se há recursos suficientes para tráfego típico e situações de carga alta:
+ Se você tiver seu próprio servidor, verifique se ele tem espaço em disco, CPU e memória suficiente para lidar com solicitações do visualizador, com base na sua avaliação.
+ Se você usar uma instância do Amazon EC2 como o servidor de backend, verifique se o tipo de instância tem os recursos apropriados para atender às solicitações de entrada. Para ter mais informações, consulte [Instance types](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html), no *Guia do usuário do Amazon EC2*.
Além disso, considere as seguintes etapas para ajudar a evitar tempos limite:
+ Se o valor de tempo para o primeiro byte retornado pelo comando "curl" for alto, execute etapas para melhorar a performance do seu aplicativo. Melhorar a capacidade de resposta do aplicativo ajudará a reduzir os erros de tempo limite.
+ Ajuste as consultas de banco de dados para garantir que elas manipulem volumes altos de solicitações sem performance lenta.
+ Configure as conexões [keep-alive (persistente)](https://www.w3.org/Protocols/HTTP/1.1/draft-ietf-http-v11-spec-01) no seu servidor de backend. Essa opção ajuda a evitar latências que ocorrem quando as conexões precisam ser restabelecidas para solicitações ou usuários subsequentes.
+ **Se você usar o Elastic Load Balancing como origem**, as causas de um erro 504 são as seguintes:
+ O balanceador de carga não conseguiu estabelecer conexão com o destino antes do término do tempo limite de conexão (dez segundos).
+ O balanceador de carga estabelece uma conexão com o destino, mas o destino não responde antes de decorrido o período de tempo limite de inatividade.
+ A lista de controle de acesso (ACL) da rede para a sub-rede não permite tráfego dos destinos para os nós do balanceador de carga nas portas efêmeras (1024-65535).
+ O destino retorna um cabeçalho content-length maior do que o corpo da entidade. O balanceador de carga atinge o tempo limite enquanto aguarda pelos bytes ausentes.
+ O destino é uma função do Lambda e o Lambda não responde antes do término do tempo limite de conexão.
Para ter mais informações sobre como reduzir a latência, consulte [Como soluciono problemas de alta latência em meu Classic Load Balancer do ELB?](https://repost.aws/knowledge-center/elb-latency-troubleshooting).
+ **Se você usa o MediaTailor como origem**, as possíveis causas de um erro 504 são as seguintes:
+ Se os URLs relativos forem mal processados, o MediaTailor poderá receber URLs malformados dos jogadores.
+ Se o MediaPackage for a origem do manifesto do MediaTailor, os erros de manifesto 404 do MediaPackage poderão fazer com que o MediaTailor exiba um erro 504.
+ A solicitação para o servidor de origem do MediaTailor leva mais de dois segundos para ser concluída.
+ **Se você usa o Amazon API Gateway como origem**, uma possível causa do erro 504 é a seguinte:
+ Uma solicitação de integração demora mais do que o parâmetro de tempo limite máximo de integração da API REST do API Gateway. Para ter mais informações, consulte [Como posso solucionar erros de tempo limite da API HTTP 504 com o API Gateway?](https://repost.aws/knowledge-center/api-gateway-504-errors).
### Se necessário, ajuste o valor de tempo limite do CloudFront
Se tiver avaliado e corrigido a performance lenta da aplicação, a capacidade do servidor de origem e outros problemas, mas os visualizadores ainda estiverem enfrentando erros HTTP 504, considere a possibilidade de alterar o tempo especificado no tempo limite de resposta de origem na sua distribuição. Para obter mais informações, consulte [Tempo limite de resposta](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).