Tutoriais de VPS
Cloudflare 521 / 522 em um site em VPS: o que fazer (2026): diagnóstico de origem, firewall e timeouts do Nginx
Depois que um site em VPS é colocado atrás do Cloudflare, um erro 521 Web Server Is Down ou 522 Connection Timed Out normalmente não significa que o Cloudflare esteja com problema. Na maioria das vezes, a origem recusa conexões, nada está escutando em 80/443, um firewall ou security group está bloqueando o tráfego, o Nginx/Apache/Caddy não está em execução, a origem está sobrecarregada, os IPs de retorno à origem estão bloqueados ou a configuração de TLS/proxy não corresponde. Este artigo faz o diagnóstico camada por camada, começando pela diferença entre 521 e 522, depois curl para a origem, IPs do Cloudflare, logs do Nginx, firewalls e timeouts.
Quando aparece um 521 ou 522 em uma página do Cloudflare, a primeira reação de muitas pessoas é: o Cloudflare caiu?
Na maioria das vezes, não.
Os dois erros acontecem na etapa em que o Cloudflare se conecta de volta à origem do seu VPS, mas significam coisas diferentes:
- 521 Web Server Is Down: o Cloudflare chegou ao IP da origem, mas a origem recusou a conexão ou o serviço web não está ativo.
- 522 Connection Timed Out: o Cloudflare tentou se conectar à origem, mas a conexão expirou; normalmente é um problema de rede, firewall, carga ou caminho de retorno à origem.
Em resumo: o 521 é mais como "a porta está fechada"; o 522 é mais como "bateram e ninguém respondeu".
Não trate todos os 5xx do Cloudflare como se fossem a mesma coisa.
| Erro | Significado comum | Verificar primeiro |
|---|---|---|
| 521 | A origem recusa a conexão / o serviço web não escuta | Nginx/Apache/Caddy, escuta em 80/443, recusa do firewall |
| 522 | O tempo de conexão do Cloudflare à origem expirou | Security group, UFW, carga da origem, roteamento, timeout |
| 523 | O Cloudflare não encontra uma rota para a origem | IP da origem, DNS, problemas de roteamento |
| 525 | Falha no handshake SSL | Modo SSL do Cloudflare, certificado, configuração TLS |
| 526 | Certificado da origem inválido | Em Full strict, o certificado não é confiável ou está expirado |
Este artigo aborda apenas os 521 e 522 mais comuns. Para falhas de renovação de certificado, consulte: O que fazer quando a renovação do certificado Let's Encrypt falha em um VPS.
Primeiro confirme se a própria origem do seu VPS está acessível.
Se você souber o IP da origem:
curl -I http://源站IP
curl -I https://源站IP
Se o site depende do cabeçalho Host, use:
curl -I http://源站IP -H 'Host: example.com'
curl -I https://源站IP -H 'Host: example.com' -k
Se até a conexão direta falhar, o problema está na origem, não no Cloudflare.
Resultados comuns:
Connection refused: o serviço não está escutando ou a conexão foi recusada, mais parecido com 521.Connection timed out: firewall, security group, roteamento ou a origem travada, mais parecido com 522.SSL certificate problem: é preciso verificar o certificado ou o modo SSL do Cloudflare.- Acessível diretamente, mas não pelo Cloudflare: concentre-se em verificar se os IPs de retorno à origem do Cloudflare estão sendo bloqueados.
No VPS, execute:
sudo ss -lntp | egrep ':80 |:443 '
Você deve ver o Nginx, Apache, Caddy ou sua aplicação escutando.
Se nada estiver escutando:
sudo systemctl status nginx --no-pager
sudo systemctl status apache2 --no-pager
sudo systemctl status caddy --no-pager
Verifique os logs:
sudo journalctl -u nginx -n 100 --no-pager
sudo journalctl -u apache2 -n 100 --no-pager
sudo journalctl -u caddy -n 100 --no-pager
Se o reload do Nginx falhar, a configuração tiver erro de sintaxe ou o caminho do certificado estiver errado, o Cloudflare pode ver um 521. Para diagnosticar a configuração do Nginx, consulte: O que fazer quando a configuração do Nginx está errada em um VPS.
Firewall local:
sudo ufw status verbose
sudo iptables -S
sudo nft list ruleset
Se usar firewalld:
sudo firewall-cmd --list-all
No mínimo, permita 80 e 443:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
Mas permitir as portas no firewall do sistema não é suficiente. Verifique também o security group / firewall do provedor de nuvem:
- O tráfego de entrada 80/tcp está permitido?
- O tráfego de entrada 443/tcp está permitido?
- Você permitiu apenas o seu próprio IP, mas não os IPs de retorno à origem do Cloudflare?
- Há alguma política de região, rota ou DDoS bloqueando o tráfego?
O retorno à origem do Cloudflare não acessa a origem a partir do seu computador local; ele acessa o seu VPS a partir dos nós de borda do Cloudflare. O fato de você conseguir acessar localmente não significa que o Cloudflare consiga.
Muitas pessoas instalam Fail2Ban, um WAF, regras deny do Nginx ou um firewall na nuvem e depois bloqueiam os IPs de retorno à origem do Cloudflare como tráfego suspeito.
Primeiro verifique o log access/error do Nginx:
sudo tail -n 100 /var/log/nginx/access.log
sudo tail -n 100 /var/log/nginx/error.log
Se você não vir nenhuma requisição do Cloudflare, elas podem estar sendo bloqueadas antes de chegar ao firewall do sistema ou ao security group.
Se você vir requisições, mas elas retornarem 403/444/499/5xx, verifique o Nginx, a aplicação ou as regras do WAF.
Em cenários com Fail2Ban, verifique:
sudo fail2ban-client status
sudo fail2ban-client status sshd
Se você restringe o acesso à origem por lista de IPs permitidos, lembre-se de usar os intervalos de IP publicados oficialmente pelo Cloudflare e mantê-los atualizados. Não escreva à mão alguns intervalos antigos e os deixe sem revisão por muito tempo.
Um 522 não significa necessariamente que a porta esteja fechada. É mais comum ser um timeout enquanto o Cloudflare estabelece uma conexão com a origem.
Verifique a carga no VPS:
uptime
free -h
df -h
top
Verifique a E/S de disco:
iostat -x 1
Verifique os logs do Nginx / da aplicação:
sudo journalctl -u nginx -n 100 --no-pager
sudo tail -n 100 /var/log/nginx/error.log
Se CPU, memória e E/S de disco da origem estiverem todas altas, as conexões do Cloudflare podem expirar. Para E/S de disco alta, consulte: O que fazer quando a E/S de disco do VPS está muito alta.
Causas comuns:
- O upstream do PHP-FPM / Gunicorn / Node está travado;
- Consultas lentas ao banco de dados seguram as requisições;
- Memória insuficiente aciona swap ou OOM;
- A espera de E/S de disco está muito alta;
- O pool de conexões do backend está esgotado;
- Tráfego de rastreadores ou de ataques satura o servidor.
Embora 521/522 não sejam exatamente erros de SSL, um modo SSL errado complica o diagnóstico.
Modos comuns:
- Flexible: do navegador ao Cloudflare é HTTPS, do Cloudflare à origem é HTTP;
- Full: do Cloudflare à origem também é HTTPS, mas o certificado não é verificado estritamente;
- Full strict: do Cloudflare à origem é HTTPS e o certificado da origem precisa ser válido.
Para sites em produção, recomenda-se Full strict, com Let's Encrypt ou um Cloudflare Origin Certificate instalado na origem.
Se a sua origem só escuta em 80, mas o Cloudflare faz o retorno por HTTPS, haverá problemas. Verifique:
sudo ss -lntp | egrep ':80 |:443 '
curl -I https://源站IP -H 'Host: example.com' -k
Se o certificado estiver expirado ou o domínio não corresponder, normalmente é mais parecido com 525/526, mas muitos usuários encontram isso durante o diagnóstico de 521/522.
Os registros A/AAAA no DNS do Cloudflare devem apontar para a origem real.
Verifique:
dig +short example.com
Se o proxy de nuvem laranja estiver ativado, um dig externo vê IPs do Cloudflare, não o IP da origem. Você precisa verificar no painel do Cloudflare se o IP da origem no registro DNS está correto.
Problemas comuns:
- O DNS do Cloudflare não foi atualizado depois que o IP do VPS mudou;
- O registro A foi atualizado, mas o registro AAAA ainda aponta para o IPv6 antigo;
- A origem desativou o IPv6, mas o Cloudflare continua fazendo o retorno por AAAA;
- Vários registros DNS apontam para máquinas diferentes.
Para problemas de configuração de IPv6, consulte: Guia de configuração de IPv6 em VPS.
Se você precisa urgentemente determinar se é um problema no caminho do Cloudflare, pode mudar temporariamente o registro DNS de nuvem laranja para nuvem cinza, para que o tráfego vá direto à origem.
Mas atenção:
- A nuvem cinza expõe o IP da origem;
- Se o HTTPS não estiver bem configurado na origem, os usuários podem ver erros de certificado;
- Isso é apenas um método de diagnóstico, não uma solução de longo prazo;
- Alterações de DNS podem ter atraso de cache.
Uma abordagem mais segura é usar curl -H 'Host: 域名' 源站IP para testar a origem diretamente, sem alterar imediatamente o DNS de produção.
Se você for abrir um ticket, não diga apenas "Cloudflare 522". Recomenda-se fornecer:
date
curl -I http://源站IP -H 'Host: example.com'
curl -I https://源站IP -H 'Host: example.com' -k
sudo ss -lntp | egrep ':80 |:443 '
sudo ufw status verbose
sudo journalctl -u nginx -n 100 --no-pager
sudo tail -n 100 /var/log/nginx/error.log
uptime
free -h
df -h
Se você suspeitar que os IPs de retorno à origem do Cloudflare estão bloqueados, anexe capturas de tela do firewall e do security group. Assim fica mais fácil localizar o problema do que enviando apenas uma captura da página de erro.
Ao encontrar Cloudflare 521 / 522, verifique nesta ordem:
- Confirme o código de erro: 521 é conexão recusada, 522 é tempo de conexão esgotado.
- Use
curl -H 'Host: 域名' 源站IPpara se conectar diretamente à origem. - No VPS, use
ss -lntppara confirmar se 80/443 está escutando. - Verifique o status e os logs do serviço Nginx/Apache/Caddy.
- Verifique UFW, iptables/nftables, firewalld.
- Verifique se o security group do provedor de nuvem permite o retorno à origem do Cloudflare.
- Verifique se IPs do Cloudflare estão sendo bloqueados por engano.
- Em cenários 522, verifique CPU, memória, E/S de disco e serviços upstream.
- Verifique os registros DNS do Cloudflare e se A/AAAA apontam para a origem correta.
- Verifique se o modo SSL corresponde à escuta da origem e ao certificado.
O ponto central do Cloudflare 521 / 522 não é "o Cloudflare está com problema", mas sim que o caminho do Cloudflare até a origem do seu VPS tem um problema.
Para 521, verifique primeiro se o serviço web está iniciado, se 80/443 está escutando e se o firewall está recusando conexões; para 522, verifique primeiro o firewall/security group, a carga da origem, a rede e os timeouts. Primeiro use curl para contornar o Cloudflare e se conectar diretamente à origem, depois verifique ss, journalctl, os logs do Nginx e as regras do security group; com isso, você basicamente reduzirá o problema à origem, à rede ou à configuração do Cloudflare.