Como Corrigir o Erro 520 do Cloudflare: Guia Completo de Diagnóstico e Resolução

O Erro 520 do Cloudflare é um código de status HTTP retornado quando a rede de borda do Cloudflare recebe uma resposta vazia, inesperada ou de outra forma ininterpretável do seu servidor de origem. Ao contrário de um 502 ou 504, que indicam um tempo limite de gateway ou gateway inválido, um 520 é o código genérico do Cloudflare para respostas que ficam fora de qualquer especificação HTTP reconhecida — o que significa que o servidor de origem tecnicamente respondeu, mas o que enviou de volta era inválido, truncado ou estruturalmente malformado.

Do ponto de vista prático, o Erro 520 significa que a conexão TCP entre o Cloudflare e o seu servidor de origem foi estabelecida, mas o handshake da camada HTTP falhou. O utilizador vê uma página de erro com a marca Cloudflare com a mensagem "O servidor web está a retornar um erro desconhecido" — e o seu site fica efetivamente offline para eles.

O Que Desencadeia o Erro 520: Causas Raiz Explicadas

Compreender o modo de falha exato é essencial antes de tocar em qualquer configuração. O Erro 520 não é um problema único — é uma classe de sintomas. As seguintes causas são as mais comuns, classificadas por frequência em ambientes de produção.

Servidor de origem a retornar um corpo de resposta vazio sem linha de status HTTP. Este é o gatilho mais frequente. O Apache ou Nginx pode falhar a meio de uma resposta, deixando o Cloudflare com um socket TCP aberto sem dados a chegar.

Firewall ou software de segurança a bloquear os intervalos de IP do Cloudflare. Ferramentas como ModSecurity, Fail2Ban, CSF (ConfigServer Security & Firewall), ou plugins de camada de aplicação como o Wordfence podem descartar silenciosamente pacotes dos IPs de saída do Cloudflare, fazendo com que a conexão seja redefinida sem uma resposta HTTP adequada.

Incompatibilidade de handshake SSL/TLS entre o Cloudflare e a origem. Se o Cloudflare estiver definido para o modo "Full (Strict)" mas o seu servidor de origem tiver um certificado expirado, autoassinado ou mal configurado, a negociação TLS falha antes de qualquer dado HTTP ser trocado.

Cabeçalhos de resposta HTTP malformados ou demasiado grandes. O Cloudflare impõe um limite rígido de 32 KB nos cabeçalhos de resposta. Qualquer cabeçalho único ou conjunto de cabeçalhos combinados que exceda este limite causa um 520. Este é um caso extremo comum com aplicações PHP mal escritas que despejam grandes dados de sessão ou saída de depuração nos cabeçalhos.

Falha no processo do servidor de origem ou eliminação por OOM (Out-of-Memory). Se o processo do worker do servidor web (por exemplo, um worker do Nginx ou pool PHP-FPM) for eliminado pelo OOM killer do Linux a meio de um pedido, a conexão cai abruptamente.

Exceções ao nível da aplicação antes de os cabeçalhos serem enviados. Um erro fatal de PHP, uma exceção Python não tratada, ou uma falha do Node.js que ocorre antes de res.writeHead() ser chamado resulta numa resposta vazia que o Cloudflare não consegue analisar.

Conexão redefinida pela origem (TCP RST). O servidor de origem redefine ativamente a conexão TCP, que o Cloudflare interpreta como uma resposta desconhecida.

Erro 520 vs. Outros Erros 5xx do Cloudflare

Distinguir o 520 de erros semelhantes do Cloudflare evita esforço de diagnóstico desperdiçado.

Se estiver a ver o 521, o processo do seu servidor web não está em execução. Se estiver a ver o 524, a sua aplicação está em execução mas é demasiado lenta. Se estiver a ver o 520, o servidor está em execução e a responder — mas o que envia de volta está quebrado.

Correção Passo a Passo para o Erro 520

Passo 1: Verificar a Saúde e Conectividade do Servidor de Origem

Antes de tocar no Cloudflare, confirme que o servidor de origem está ativo e que o daemon do servidor web está em execução.

Verifique se o processo do servidor web está ativo:

# For Nginx
sudo systemctl status nginx

# For Apache
sudo systemctl status apache2

# For LiteSpeed
sudo systemctl status lsws

Teste a conectividade direta ao IP de origem, contornando o proxy do Cloudflare. Recupere o seu IP de origem do painel DNS do Cloudflare e teste-o diretamente:

curl -I --resolve yourdomain.com:80:YOUR_ORIGIN_IP http://yourdomain.com/
curl -I --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com/

Se curl retornar um status HTTP válido (200, 301, etc.), o servidor de origem está funcional e o problema está na camada de comunicação entre o Cloudflare e a origem. Se curl retornar uma resposta vazia ou uma redefinição de conexão, o problema está do lado da origem.

Verifique a pressão dos recursos do sistema:

# Memory usage
free -h

# CPU load
uptime

# Check for OOM kills in the last boot
dmesg | grep -i "oom|killed process"

# Check for PHP-FPM pool exhaustion
sudo systemctl status php8.1-fpm

Passo 2: Inspecionar os Registos de Erros do Servidor de Origem

Os registos do servidor de origem são a fonte de diagnóstico mais valiosa. Não ignore este passo.

Para Nginx:

sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/nginx/access.log

Para Apache:

sudo tail -n 100 /var/log/apache2/error.log
sudo tail -n 100 /var/log/apache2/access.log

Procure especificamente por:

• Entradas de nível [crit] ou [emerg]

upstream prematurely closed connection (Nginx + PHP-FPM)
Premature end of script headers (Apache + CGI/PHP)
worker_connections are not enough (limite de workers do Nginx atingido)
Erros fatais de PHP registados no registo de erros do servidor web

Correlacione os timestamps dos registos com quando ocorreram os erros 520. O painel do Cloudflare em Analytics > Traffic mostra os timestamps dos picos de 520 que pode usar para correlação.
Passo 3: Adicionar os Intervalos de IP do Cloudflare à Lista Branca do Firewall
Se um firewall estiver a bloquear os IPs de saída do Cloudflare, a conexão será redefinida silenciosamente. O Cloudflare publica os seus intervalos de IP atuais em https://www.cloudflare.com/ips/.
Para UFW (Ubuntu/Debian):
# Download Cloudflare IPv4 ranges and whitelist them
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  sudo ufw allow from $ip to any port 80,443 proto tcp
done

# Repeat for IPv6
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
  sudo ufw allow from $ip to any port 80,443 proto tcp
done

sudo ufw reload
Para CSF (ConfigServer Firewall):
Adicione os intervalos de IP do Cloudflare a /etc/csf/csf.allow, depois reinicie o CSF:
sudo csf -r
Para ModSecurity: Se suspeitar que o ModSecurity é o culpado, verifique o seu registo de auditoria:
sudo tail -n 200 /var/log/modsec_audit.log
Procure correspondências de regras contra endereços IP do Cloudflare. Pode adicionar os IPs do Cloudflare à lista branca na sua configuração do ModSecurity ou definir a diretiva SecRemoteRules para os excluir.
Nota crítica: Nunca desative permanentemente o seu firewall ou ModSecurity. Adicione à lista branca apenas os intervalos de IP publicados pelo Cloudflare e reative todos os controlos de segurança imediatamente após os testes.
Passo 4: Auditar e Corrigir os Cabeçalhos de Resposta HTTP
Cabeçalhos malformados ou demasiado grandes são uma causa frequentemente ignorada dos erros 520. Use curl com saída detalhada para inspecionar exatamente o que a sua origem está a enviar:
curl -v --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com/ 2>&1 | head -80
Fique atento a:

Cabeçalhos com caracteres não-ASCII ou caracteres de controlo
Cabeçalhos Set-Cookie com valores extremamente longos (comum em configurações incorretas de sessão PHP)
Cabeçalhos Content-Type em falta ou malformados
Cabeçalhos Content-Length duplicados com valores conflituantes

Se estiver a executar uma aplicação PHP, verifique php.ini para as definições output_buffering. Um buffer de saída desativado combinado com um erro fatal a meio de uma resposta pode causar transmissão parcial de cabeçalhos.
Especificamente para sites WordPress: Plugins que injetam grandes quantidades de dados em cabeçalhos HTTP (alguns plugins de segurança ou cache fazem isto) podem ultrapassar o limite de 32 KB do Cloudflare. Audite os plugins ativos e teste em modo seguro.
Passo 5: Validar a Configuração SSL/TLS do Cloudflare
Uma incompatibilidade SSL entre o Cloudflare e a origem é uma fonte comum de falhas da classe 520 que se disfarça como um erro desconhecido genérico.
Navegue até Cloudflare Dashboard > SSL/TLS > Overview e verifique o modo de encriptação:



Modo SSL do Cloudflare
Requisito de Origem
Recomendado Para








—
—
—








Off
Sem SSL na origem
Nunca recomendado








Flexible
Sem SSL necessário na origem
Apenas para configurações legadas; risco de segurança








Full
Qualquer certificado SSL na origem (incluindo autoassinado)
Ambientes de desenvolvimento








Full (Strict)
Certificado SSL válido e confiável na origem
Todos os sites em produção





Se a sua origem usar um certificado autoassinado e o Cloudflare estiver definido para Full (Strict), o handshake TLS falhará. Instale um certificado válido na origem (um certificado gratuito Let’s Encrypt funciona) ou mude temporariamente para o modo Full enquanto corrige o certificado.
Se precisar de um certificado devidamente confiável para o seu servidor de origem, os Certificados SSL de uma CA confiável eliminam completamente o problema do certificado autoassinado e são compatíveis com o modo Full (Strict) do Cloudflare.
Passo 6: Pausar o Proxy do Cloudflare para Diagnóstico Direcionado
Remover temporariamente o Cloudflare do caminho do pedido isola se o problema está na configuração do Cloudflare ou no servidor de origem.
Método 1: Desativar o proxy num registo DNS específico
No painel DNS do Cloudflare, clique no ícone de nuvem laranja ao lado do seu registo A ou CNAME para o tornar cinzento. Isto contorna o proxy do Cloudflare enquanto mantém a resolução DNS através do Cloudflare. A propagação DNS demora até 5 minutos.
Método 2: Pausar o Cloudflare globalmente para o domínio
Navegue até Cloudflare Dashboard > Overview > Advanced Actions > Pause Cloudflare on Site. Isto encaminha todo o tráfego diretamente para a sua origem.
Após pausar, teste o seu site. Se carregar corretamente, o problema está na configuração do Cloudflare. Se ainda falhar, o problema está no servidor de origem independentemente do Cloudflare.
Reative o Cloudflare imediatamente após os testes — um Cloudflare pausado significa que o seu site perde a proteção DDoS, o cache CDN e a cobertura WAF.
Passo 7: Verificar a Precisão dos Registos DNS
Um registo DNS A mal configurado a apontar para um endereço IP errado ou desatualizado faz com que o Cloudflare encaminhe o tráfego para o servidor errado, que retornará uma resposta inesperada.
No painel DNS do Cloudflare:

Verifique se o registo A para o seu domínio raiz (@) aponta para o IP atual do seu servidor de origem
Verifique se o CNAME para www resolve corretamente
Se migrou recentemente de servidor, confirme que o IP antigo já não é referenciado em nenhum lugar

Confirme para que IP o Cloudflare está realmente a enviar tráfego:
dig +short yourdomain.com @1.1.1.1
Compare isto com o IP real do seu servidor de origem. Se forem diferentes, atualize o registo DNS no Cloudflare.
Passo 8: Escalar os Recursos do Servidor de Origem
Se o seu servidor de origem estiver consistentemente sob alta carga, os erros 520 ocorrerão intermitentemente durante picos de tráfego à medida que os processos worker ficam esgotados e as conexões são descartadas.
Diagnostique o esgotamento de recursos:
# Check Nginx worker connections
sudo nginx -T | grep worker_connections

# Check PHP-FPM pool limits
cat /etc/php/8.1/fpm/pool.d/www.conf | grep -E "pm.|max_children"

# Monitor real-time connections
ss -s
Opções de ajuste sem atualização de hardware:

Aumente worker_connections em /etc/nginx/nginx.conf

• Aumente pm.max_children na configuração do pool PHP-FPM
• Ative a diretiva keepalive do Nginx para conexões upstream
• Implemente cache de objetos (Redis ou Memcached) para reduzir a pressão na base de dados
• Ative a regra de página Cache Everything do Cloudflare para descarregar a entrega de ativos estáticos

Para aplicações que superaram a infraestrutura partilhada, migrar para um ambiente de Alojamento VPS dá-lhe controlo total sobre os limites de processos worker, alocação de memória e ajuste TCP ao nível do kernel — nenhum dos quais está disponível em planos partilhados.

Se a sua aplicação lida com cargas de trabalho computacionalmente intensivas (inferência ML, processamento de vídeo, operações de grandes conjuntos de dados) que causam falhas intermitentes de workers, o Alojamento GPU descarrega essas tarefas dos processos do seu servidor web, eliminando uma fonte comum de falhas a meio de resposta.

Passo 9: Rever as Regras de Firewall e Segurança do Cloudflare

As próprias funcionalidades de segurança do Cloudflare podem ocasionalmente interferir com a comunicação legítima com a origem, particularmente se as Regras de Firewall personalizadas ou as regras WAF estiverem mal configuradas.

Verifique Cloudflare Dashboard > Security > WAF > Custom Rules para quaisquer regras que possam estar a intercetar pedidos antes de chegarem à origem. Reveja também Security > Settings > Browser Integrity Check — em casos raros, isto pode causar comportamento inesperado com determinados agentes de utilizador ou pedidos automatizados.

Reveja o registo Security > Events para ver se o Cloudflare está a bloquear ou a desafiar pedidos que deveriam chegar à sua origem.

Passo 10: Escalar para o Seu Fornecedor de Alojamento ou Suporte do Cloudflare

Se todos os passos acima foram esgotados sem resolução, escale com informações precisas.

Ao contactar o seu fornecedor de alojamento, forneça:

• Os timestamps exatos das ocorrências de 520 (do Cloudflare Analytics)
• Excertos relevantes do registo de erros do seu servidor web
• A saída de curl -v contra o seu IP de origem
• Métricas atuais de utilização de recursos (CPU, RAM, contagem de conexões)

Fornecedores que executam infraestrutura gerida em Servidores Dedicados podem realizar diagnósticos ao nível do kernel, capturas de pacotes (tcpdump) e inspeção ao nível de socket que não estão disponíveis em ambientes partilhados.

Ao contactar o Suporte do Cloudflare, inclua:

• O seu Ray ID da página de erro 520 (visível no HTML de erro do Cloudflare)
• Um ficheiro HAR capturado das Ferramentas de Desenvolvimento do Chrome durante o erro
• O seu modo SSL/TLS atual e quaisquer Regras de Firewall personalizadas

O Ray ID é crítico — permite aos engenheiros do Cloudflare recuperar a entrada exata do registo do nó de borda para o seu pedido falhado.

Diagnóstico Avançado: Capturar a Falha Exata com tcpdump

Para erros 520 persistentes ou intermitentes que resistem à resolução de problemas padrão, uma captura de pacotes no servidor de origem revela exatamente o que está a acontecer na camada TCP/HTTP quando o Cloudflare se conecta.

# Capture traffic from Cloudflare IPs on port 443
sudo tcpdump -i eth0 -w /tmp/cloudflare_capture.pcap 'src net 103.21.244.0/22 or src net 103.22.200.0/22 or src net 103.31.4.0/22 or src net 104.16.0.0/13 or src net 104.24.0.0/14' and port 443

Abra o ficheiro .pcap resultante no Wireshark e filtre por tcp.flags.reset == 1 para identificar pacotes TCP RST, que indicam que a origem está a redefinir ativamente as conexões. Filtre por http para inspecionar quaisquer respostas HTTP parciais que estejam a ser enviadas.

Este nível de análise identifica definitivamente se o 520 é causado por um RST de firewall, uma falha de aplicação a meio de uma resposta, ou uma falha TLS.

Prevenção do Erro 520: Medidas Proativas

A resolução de problemas reativa é dispendiosa. Estas medidas reduzem significativamente a probabilidade de ocorrência de 520.

Implemente Verificações de Saúde do Cloudflare. Em Traffic > Health Checks, configure uma verificação de saúde contra a sua origem. O Cloudflare irá alertá-lo antes que os utilizadores comecem a ver erros 520.

Ative a funcionalidade Always Online do Cloudflare (em Caching > Configuration). Embora não corrija o problema subjacente, serve versões em cache das suas páginas aos utilizadores durante interrupções da origem, evitando um apagão completo do serviço.

Configure monitorização do servidor de origem com ferramentas como UptimeRobot, Pingdom, ou uma solução auto-alojada como o Uptime Kuma. Monitorize o IP de origem diretamente (não o domínio com proxy do Cloudflare) para detetar falhas de origem independentemente do Cloudflare.

Automatize a lista branca de IPs do Cloudflare. Os intervalos de IP do Cloudflare mudam ocasionalmente. Use um cron job para atualizar a lista branca do seu firewall:

# /etc/cron.weekly/update-cloudflare-ips
#!/bin/bash
CF_IPS=$(curl -s https://www.cloudflare.com/ips-v4)
# Add logic to update UFW/CSF/iptables rules

Use os Authenticated Origin Pulls do Cloudflare. Esta funcionalidade configura a sua origem para aceitar apenas conexões HTTPS que apresentem o certificado de cliente do Cloudflare, bloqueando quaisquer pedidos diretos à origem que contornem o proxy. Isto também elimina uma classe de erros 520 causados por tráfego não-Cloudflare a atingir a sua origem e a desencadear respostas de software de segurança.

Para equipas que gerem múltiplos domínios e aplicações web, um VPS com cPanel fornece acesso centralizado a registos, gestão de firewall e gestão de certificados SSL em todos os domínios alojados — reduzindo significativamente o tempo de diagnóstico para eventos 520.

Matriz de Decisão: Diagnosticar o Seu Cenário Específico de 520

Lista de Verificação Técnica de Pontos-Chave

Antes de escalar para o suporte, confirme que completou cada um dos seguintes:

• Verificou que o processo do servidor web de origem está em execução (systemctl status)
• Testou a conectividade direta à origem com curl -v --resolve contornando o Cloudflare
• Reviu os registos de erros da origem para os timestamps exatos dos eventos 520
• Confirmou que os intervalos de IP do Cloudflare estão na lista branca de todos os firewalls ativos (UFW, CSF, iptables, ModSecurity)
• Validou que os cabeçalhos de resposta estão abaixo de 32 KB e não contêm valores malformados
• Confirmou que o modo SSL/TLS do Cloudflare corresponde ao tipo de certificado de origem
• Verificou que os registos DNS A apontam para o IP de origem atual e correto
• Verificou a memória do sistema e CPU para eliminações por OOM ou esgotamento de recursos
• Capturou o Ray ID da página de erro 520 para escalação ao suporte do Cloudflare
• Reviu o registo de Eventos de Segurança do Cloudflare para interferência de regras WAF

Perguntas Frequentes

Qual é a diferença entre o Erro 520 e o Erro 521 do Cloudflare?

O Erro 521 significa que o Cloudflare chegou com sucesso ao IP do seu servidor de origem mas o processo do servidor web recusou a conexão TCP — tipicamente porque o Nginx ou Apache não está em execução. O Erro 520 significa que a conexão TCP foi estabelecida mas a resposta HTTP estava vazia, truncada ou malformada. Se vir o 521, inicie o seu servidor web. Se vir o 520, o servidor está em execução mas a enviar respostas quebradas.

O Erro 520 pode ser causado pelo próprio Cloudflare, e não pelo servidor de origem?

Raramente, mas sim. Problemas no nó de borda do Cloudflare podem causar erros 520 que não são reproduzíveis ao aceder à origem diretamente. Verifique cloudflarestatus.com para incidentes ativos. Se a origem responder corretamente via curl direto e a página de status do Cloudflare mostrar um incidente ativo, aguarde que o Cloudflare o resolva em vez de fazer alterações ao seu servidor.

Por que é que o Erro 520 ocorre apenas intermitentemente e não de forma consistente?

Os erros 520 intermitentes indicam quase sempre esgotamento de recursos — pools de workers PHP-FPM a ficar sem filhos disponíveis, Nginx a atingir os limites worker_connections, ou o OOM killer do Linux a terminar processos sob pressão de memória. Estas condições ocorrem durante picos de carga e resolvem-se quando o tráfego diminui, criando o padrão intermitente. Erros 520 consistentes apontam para um problema de configuração.

Pausar o Cloudflare corrige o Erro 520?

Pausar o Cloudflare remove-o do caminho do pedido, por isso se o seu site funcionar após pausar, o problema está na configuração do Cloudflare (modo SSL, regras WAF, registos DNS). Se o seu site ainda falhar após pausar, o problema está no servidor de origem. Pausar o Cloudflare é um passo de diagnóstico, não uma correção — remove a proteção DDoS e o cache CDN enquanto está ativo.

Como encontro o Ray ID para reportar um erro 520 ao Cloudflare?

O Ray ID é exibido na parte inferior da página de erro 520 do Cloudflare mostrada aos utilizadores. Parece uma string hexadecimal de 16 caracteres (por exemplo, 7a3f2b9c1d4e8f0a). Também pode encontrá-lo no cabeçalho de resposta CF-Ray, visível nas Ferramentas de Desenvolvimento do Chrome no separador Network. Inclua sempre este ID ao abrir um ticket de suporte do Cloudflare — permite aos engenheiros do Cloudflare recuperar a entrada exata do registo de borda para o seu pedido falhado.