Ir para o conteúdo principal

Guias / Corrigir: guias para os erros que aparecem de verdade

Erro 520 da Cloudflare: o que significa e como corrigir

O erro 520 da Cloudflare significa que a Cloudflare conectou ao seu servidor de origem, mas recebeu uma resposta vazia, irreconhecível ou muito quebrada para ser repassada ao visitante. A Cloudflare usa o código de erro 520 como uma categoria geral: algo voltou da origem, mas não algo que siga as regras de uma resposta HTTP normal.

O que significa o erro 520

A Cloudflare fica entre o visitante e o seu servidor web como um proxy reverso. Em uma requisição normal, ela abre uma conexão TCP com a sua origem, envia a requisição e repassa a resposta HTTP que volta. O erro 520 acontece quando essa última etapa falha: a conexão TCP é estabelecida, mas os bytes que vêm em seguida não formam uma resposta HTTP válida, ou nenhum byte chega antes da conexão ser fechada.

Isso coloca o 520 em uma categoria diferente dos outros códigos 5xx da Cloudflare. O erro 521 significa que a origem recusou a conexão de forma direta. O erro 522 significa que a tentativa de conexão estourou o tempo limite. O erro 520 significa que a origem respondeu alguma coisa, mas a Cloudflare não conseguiu interpretar essa resposta nem repassá-la adiante.

Como o erro 520 aparece

No navegador, a Cloudflare mostra a própria página de erro, "Error 520: web server returned an unknown error", junto com um Ray ID que você vai precisar caso entre em contato com o suporte da Cloudflare. Uma requisição simples com curl contra o domínio mostra o mesmo código de status:

curl -I https://example.com
HTTP/2 520

No lado da Cloudflare, as abas Security ou Analytics do painel mostram um pico de respostas 5xx, e contas Enterprise com acesso a Logpull ou Logpush conseguem extrair o colo de borda específico e o Ray ID de cada requisição que falhou. Nada disso mostra o que a origem realmente enviou, então o próximo lugar para olhar é o seu próprio servidor.

Na origem, verifique os logs do servidor web e da aplicação no mesmo horário das falhas. Procure por um reinício de processo, uma falha de segmentação, uma morte por falta de memória no log do sistema (dmesg ou journalctl -k), ou um erro da aplicação que interrompeu a requisição no meio da resposta. Se os logs da aplicação não mostrarem nada fora do comum, o problema é mais provável que seja uma resposta que tecnicamente terminou, mas quebrou alguma regra do HTTP, como um cabeçalho grande demais.

O que causa o erro 520

  • O processo da origem travou ou reiniciou durante o processamento da requisição. A conexão se fecha antes de uma resposta completa ser enviada. Essa é a causa mais comum.
  • A origem encerrou a conexão TCP de forma abrupta (RST) em vez de fechar de forma limpa. Servidores de aplicação sob pressão de memória ou que atingem o tempo limite de um worker costumam fazer isso.
  • Cabeçalhos de resposta acima do limite de 16 KB da Cloudflare. Um cabeçalho set-cookie grande, uma pilha de cabeçalhos de debug ou cabeçalhos CORS extensos podem empurrar o total além do que a Cloudflare aceita.
  • Um cookie, ou o conjunto de cabeçalhos de cookie, grande demais. Dados de sessão, cookies de rastreamento ou um gerenciador de cookies mal configurado podem crescer além dos limites do navegador e do proxy com o tempo.
  • Uma linha de status ausente ou malformada. Alguns frameworks devolvem uma string de erro bruta em vez de uma resposta HTTP correta quando uma exceção não tratada chega à camada do servidor web.
  • A origem devolveu dados que não são HTTP na porta HTTP(S). Isso acontece depois de um proxy reverso mal configurado, um mapeamento de porta errado, ou um serviço que ocupa a porta antes do servidor web real subir.
  • Um appliance de segurança ou WAF na frente da origem encerrou a conexão no meio da resposta. Alguns WAFs e balanceadores de carga locais derrubam conexões que disparam uma regra, o que parece idêntico a uma falha vista do lado da Cloudflare.

Como saber de quem é a culpa

Como a Cloudflare de fato recebeu uma resposta da origem, o erro 520 é um forte indício de que o problema está do lado da origem, e não na rede da Cloudflare, diferente do erro 521 ou 522, em que a própria conexão falha. A dúvida costuma ser se o erro afeta todos os visitantes ou só alguns.

A forma mais rápida de descobrir isso é rodar uma verificação HTTP a partir de vários locais ao mesmo tempo. Se uma verificação contra o domínio público falha a partir de todos os locais no mesmo momento em que os usuários estão reportando o erro, a própria origem está fora do ar ou travando para todo mundo, não só para um data center de borda específico. Se ela só falha de forma intermitente ou a partir de regiões específicas, a origem pode estar sobrecarregada com o tráfego daquela região, ou uma camada de cache ou balanceamento de carga presente só em parte da sua configuração está envolvida. A verificação HTTP da HostTracker roda a partir de pontos de verificação em vários países e reporta o resultado de cada um separadamente, um detalhe que um único curl feito da sua própria mesa não consegue dar.

Você também pode isolar a origem da Cloudflare completamente, chamando-a diretamente com o cabeçalho Host do domínio, contornando a rede de borda para que qualquer erro visto seja, sem dúvida, da origem:

curl -v -H "Host: example.com" https://ORIGIN_IP/

Substitua ORIGIN_IP pelo endereço IP real do seu servidor. Se essa requisição direta também falhar ou devolver a mesma resposta quebrada, a falha é da origem, confirmada.

Como corrigir o erro 520

Se você é um visitante

  1. Recarregue a página depois de um ou dois minutos. Muitos erros 520 vêm de uma falha ou reinício breve que o próprio supervisor de processos do site recupera automaticamente.
  2. Tente uma janela anônima ou privada, ou uma rede diferente. Isso descarta um cache local desatualizado ou uma extensão do navegador com mau comportamento, embora um 520 raramente seja causado por algo do seu lado.
  3. Verifique se o site publica uma página de status própria, caso tenha uma, para conferir se há uma interrupção conhecida.
  4. Não há nada para configurar do seu lado para corrigir um 520. Ele é gerado pelo próprio servidor do site, não pelo seu navegador, seu provedor de internet ou o seu resolvedor de DNS.

Se você administra o site

  1. Verifique os logs do servidor web e da aplicação no horário exato das falhas, procurando por uma falha, uma exceção não tratada ou um reinício de worker.
  2. Contorne a Cloudflare e consulte a origem diretamente com o cabeçalho Host (mostrado acima), ou use a opção "Pause Cloudflare on Site" da Cloudflare, para confirmar que a resposta está quebrada independente do proxy.
  3. Meça o tamanho dos seus cabeçalhos de resposta e cookies. Um único cabeçalho set-cookie grande ou uma pilha de cabeçalhos de debug deixados ativos em produção pode levar o total acima de 16 KB; reduza o que não é necessário e mova dados de sessão grandes para o lado do servidor.
  4. Procure por respostas malformadas: um proxy reverso ou balanceador de carga apontando para o upstream errado, uma aplicação devolvendo texto puro em uma porta HTTP, ou uma linha de status ausente vinda do tratador de erro padrão de um framework.
  5. Verifique se há esgotamento de recursos na origem: limites de memória, limites do pool de conexões, ou um gerenciador de processos (systemd, pm2, um pool de workers do Gunicorn ou uWSGI) preso em um loop de reinício.
  6. Se houver um WAF, um proxy de antivírus ou um balanceador de carga entre a internet e o seu servidor de aplicação, verifique os próprios logs dele por conexões derrubadas ou encerradas no mesmo horário.

Como prevenir

O erro 520 costuma aparecer primeiro como um chamado de suporte, não como um alerta, porque nada na origem necessariamente registra um handshake que falhou com a borda da Cloudflare da mesma forma que registra uma exceção da aplicação. Uma verificação de disponibilidade que roda fora da sua própria rede detecta a mesma falha que um visitante veria, do mesmo ponto de vista, antes que alguém precise reportar. Rodar a verificação a partir de vários países também mostra na hora se um 520 é global ou limitado a uma região, o que é o detalhe que decide por onde começar a investigar.

Erros relacionados

Perguntas frequentes

O erro 520 é culpa da Cloudflare ou minha?

Quase sempre é da origem. A Cloudflare recebeu uma resposta e não conseguiu interpretá-la nem repassá-la, o que significa que o servidor de origem, e não a rede da Cloudflare, produziu a resposta quebrada.

O erro 520 significa que o meu site inteiro está fora do ar?

Não necessariamente. Significa que a requisição específica que disparou o erro falhou. Se a origem está travando sob carga, ela pode devolver 520 para algumas requisições e respostas normais para outras até que o problema de fundo seja corrigido.

Dá para corrigir o erro 520 só pelo painel da Cloudflare?

Raramente. Como a causa é quase sempre da origem, as configurações do painel não vão corrigir uma aplicação travando ou um cabeçalho de resposta grande demais. A exceção é verificar se o seu modo SSL/TLS e as configurações de origem correspondem ao que o seu servidor realmente faz, o que ao menos descarta uma configuração errada do lado da Cloudflare.

Qual a diferença entre o erro 520 e um 502 Bad Gateway comum?

O 502 é o status HTTP geral para uma resposta inválida de um servidor upstream, usado por qualquer proxy reverso. A Cloudflare usa o 520 especificamente como a própria categoria geral para uma resposta tão quebrada que não se encaixa em nenhum dos outros códigos 5xx nomeados da Cloudflare, e é por isso que aparece a página de erro da Cloudflare com o Ray ID em vez de uma página 502 genérica.

Um cookie grande pode mesmo causar um 520?

Sim. A Cloudflare aplica um limite ao tamanho total dos cabeçalhos de resposta, atualmente por volta de 16 KB, e os cookies entram nessa conta. Uma aplicação que fica adicionando dados a um cookie de sessão, ou que define vários cookies grandes de uma vez, pode ultrapassar esse limite e disparar um 520 mesmo quando a aplicação em si não tem nenhum bug.

Tentar de novo resolve o problema?

Às vezes, se a causa foi uma falha ou reinício passageiro na origem que já se recuperou. Se a origem está enviando respostas quebradas de forma consistente, por exemplo por causa de um cabeçalho grande demais em toda requisição, tentar de novo não vai ajudar até que a origem seja corrigida.

Verificar agora

Faça a verificação gratuita no seu próprio site, sem precisar de conta.

HTTP check

Monitorar permanentemente

Seja avisado no momento em que algo quebrar: o HostTracker verifica de mais de 300 localidades e notifica você por e-mail, SMS, Slack, Telegram e mais.

Recursos do HostTracker

Mais nesta seção: Corrigir: guias para os erros que aparecem de verdade