Otimizar erro 522 da Cloudflare: SSL, firewall e origem

Otimizar erro 522 da Cloudflare significa confirmar se a borda da Cloudflare consegue alcançar o servidor de origem nas portas corretas, com DNS apontando para o IP atual, firewall liberando o tráfego e SSL válido na origem. Para corrigir sem desativar o HTTPS, siga estes passos:

1. Confirme se o registro DNS na Cloudflare aponta para o IP público correto do servidor de origem.
2. Teste a resposta direta da origem nas portas 80 e 443 usando o domínio e o IP real.
3. Verifique se Nginx, Apache ou outro serviço web está ativo e escutando publicamente.
4. Revise firewall local, painel de hospedagem e regras intermediárias que possam bloquear a Cloudflare.
5. Valide o certificado SSL na origem antes de alterar o modo SSL da Cloudflare.
6. Analise logs do servidor para identificar timeout, recusa, limitação ou queda do serviço web.

Pré-requisitos

• Acesso ao painel da Cloudflare do domínio afetado para revisar DNS, proxy e modo SSL.
• Acesso SSH ao servidor de origem com usuário administrativo ou permissões equivalentes.
• Servidor Linux atual, como Debian 13, Rocky Linux 10 ou AlmaLinux 10, com Nginx, Apache ou stack web equivalente.
• Ferramentas de diagnóstico disponíveis: curl, ss, openssl, journalctl, dig ou resolvectl.
• Conhecimento do IP público correto da origem, por exemplo 203.0.113.10 em comandos demonstrativos.
• Certificado TLS instalado na origem quando o site usa HTTPS por trás da Cloudflare.

Otimizar erro 522 da Cloudflare no DNS de origem

Erro 522 da Cloudflare com SSL ativo começa quase sempre pelo caminho de rede entre a Cloudflare e a origem, não pelo navegador do visitante. O primeiro diagnóstico é confirmar se a Cloudflare está enviando requisições para o IP público correto. Se o registro A ou CNAME aponta para um endereço antigo, para um IP privado, para uma origem desativada ou para uma camada que não responde em 80 e 443, a Cloudflare tenta conectar e acaba exibindo 522 por falta de resposta no tempo esperado.

No painel da Cloudflare, verifique os registros do tipo A e CNAME do domínio principal e do subdomínio com erro. Se você usa seudominio.com.br e www.seudominio.com.br, ambos devem apontar para a origem correta ou para o destino intermediário correto. Para revisar conceitos de zona DNS sem misturar registros, veja também Guia de zona DNS: registros A, MX, CNAME e TXT do zero.

1. Consulte o IP retornado publicamente pelo domínio.
2. Compare com o IP real do servidor de origem.
3. Teste a conexão direta forçando o domínio a resolver para a origem.

dig +short seudominio.com.br

Output esperado:
203.0.113.10

curl -I --connect-timeout 10 --resolve seudominio.com.br:443:203.0.113.10 https://seudominio.com.br/

Output esperado:
HTTP/2 200
server: nginx
content-type: text/html

Se o primeiro comando retorna outro IP, ajuste o DNS na Cloudflare antes de mexer em firewall ou SSL. Se o segundo comando demora, expira ou não retorna cabeçalho HTTP, o problema está na origem, na rota até ela, no serviço web ou em alguma filtragem antes da aplicação.

Checar portas 80 e 443 para corrigir Cloudflare 522

Cloudflare 522 timeout ocorre quando a borda consegue iniciar a tentativa de conexão, mas a origem não responde dentro do prazo esperado. Por isso, depois do DNS, o passo técnico mais importante é validar se há um processo realmente escutando nas portas públicas 80 e 443. Não basta o site abrir localmente via painel ou responder em localhost; ele precisa aceitar conexão externa no IP público usado pela Cloudflare.

Ao rodar o comando abaixo no servidor, você verá quais processos estão escutando nas portas HTTP e HTTPS. Em uma hospedagem com Nginx, o processo costuma aparecer associado ao Nginx. Em uma hospedagem com Apache, o processo pode aparecer como httpd ou apache2. O nome exato depende da distribuição e do pacote instalado, mas o objetivo é o mesmo: confirmar escuta em 0.0.0.0, no IP público ou em ::: para IPv6 quando aplicável.

sudo ss -ltnp | grep -E ':80|:443'

Output esperado:
LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("nginx",pid=842,fd=6))
LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("nginx",pid=842,fd=7))

Se nada aparecer para 80 ou 443, verifique o serviço web. Em servidores com Nginx, rode:

sudo systemctl status nginx --no-pager -l

Output esperado:
Active: active (running)

Se você usa Apache, adapte o serviço conforme a distribuição:

sudo systemctl status apache2 --no-pager -l

Output esperado:
Active: active (running)

Quando o serviço estiver parado, investigue antes de reiniciar repetidamente. Logs de falha apontam arquivo de configuração inválido, porta em conflito, certificado ausente ou permissão incorreta. Para problemas de serviços que não sobem após reinicialização, a referência Como solucionar problemas de inicialização de serviços no VPS Linux: Guia Completo pode ajudar na leitura de systemd e logs.

Validar SSL na origem sem desativar HTTPS

SSL ativo na Cloudflare não substitui a necessidade de uma origem acessível quando o modo exige conexão HTTPS até o servidor. Um certificado vencido costuma gerar outros tipos de falha, mas uma origem que não responde na porta 443 pode aparecer para o visitante como erro 522. Portanto, o caminho seguro é testar a camada TLS da origem sem desligar SSL, sem remover redirecionamentos e sem mudar o site para HTTP em produção.

Use o openssl para verificar se o handshake TLS responde quando o domínio correto é enviado como SNI. Isso é importante porque muitos servidores hospedam vários domínios no mesmo IP e entregam certificados diferentes conforme o nome do host. Se o teste por IP puro falha, mas com SNI funciona, o problema pode estar no vhost, no certificado ou na regra que seleciona o site correto.

openssl s_client -connect 203.0.113.10:443 -servername seudominio.com.br -brief

Output esperado:
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Verification: OK

Depois, teste a resposta HTTP sobre TLS forçando o IP de origem. Esse teste simula a ida direta ao servidor mantendo o cabeçalho de domínio correto.

curl -vk --resolve seudominio.com.br:443:203.0.113.10 https://seudominio.com.br/ -I

Output esperado:
HTTP/2 200
server: nginx

Se aparecer falha de certificado, corrija o certificado na origem antes de alterar modos da Cloudflare. Se aparecer timeout, volte para firewall, porta 443 e serviço web. Se aparecer redirecionamento em loop, revise regras de HTTP para HTTPS e a lógica da aplicação. Para redirecionamento básico e correto, consulte Como redirecionar um site http para https?.

Ajustar firewall para permitir conexões da Cloudflare

Firewall bloqueando Cloudflare é uma das causas mais comuns quando o site abre direto em algumas redes, mas falha ao passar pelo proxy. A origem pode aceitar seu IP de administração e ao mesmo tempo limitar, derrubar ou negar conexões vindas da camada da Cloudflare. Esse bloqueio pode estar no firewall do Linux, em regras do painel de hospedagem, em proteção contra ataques, em rate limiting agressivo ou em uma ACL aplicada antes do servidor web.

Atenção: alterações de firewall podem bloquear seu próprio acesso SSH. Antes de aplicar mudanças, mantenha uma sessão aberta, confirme a regra de SSH e use os IPs oficiais atuais da Cloudflare no ambiente real. Os IPs abaixo são apenas exemplos de documentação e devem ser substituídos pelos endereços corretos antes de qualquer uso em produção.

Primeiro, liste regras relevantes. Em servidores modernos com nftables, procure regras que aceitam ou negam portas 80 e 443.

sudo nft list ruleset | grep -E 'dport 80|dport 443|drop|reject'

Output esperado:
tcp dport 80 accept
tcp dport 443 accept

Se você usa UFW, confira o estado e a política padrão:

sudo ufw status verbose

Output esperado:
Status: active
80/tcp ALLOW IN Anywhere
443/tcp ALLOW IN Anywhere

Em uma política restritiva, a abordagem correta é permitir 80 e 443 a partir das faixas reais da Cloudflare e manter SSH protegido. O exemplo abaixo é didático e usa rede reservada para documentação.

sudo ufw allow from 198.51.100.0/24 to any port 443 proto tcp
sudo ufw allow from 198.51.100.0/24 to any port 80 proto tcp
sudo ufw status numbered

Output esperado:
443/tcp ALLOW IN 198.51.100.0/24
80/tcp ALLOW IN 198.51.100.0/24

Se o ambiente usa painel de controle, WAF do provedor ou regras de segurança externas, revise essas camadas também. O erro 522 pode persistir mesmo com o firewall local correto quando há bloqueio antes do Linux. Para acessar seu ambiente de gestão e revisar serviços contratados, veja Como acessar o painel de gerenciamento dos meus Serviços..

Analisar logs para encontrar a causa real do 522

Diagnóstico do erro 522 fica muito mais confiável quando você cruza horário do erro, logs do serviço web e testes de conexão. Se as requisições nem aparecem no access log, a falha provavelmente ocorre antes da aplicação: DNS errado, firewall, porta fechada ou rota até a origem. Se aparecem entradas com demora, encerramento ou erro interno, a aplicação pode estar sobrecarregada ou o servidor web pode estar recusando conexões.

Comece olhando o status recente do serviço web e os logs do systemd. Ao executar, procure mensagens no mesmo minuto em que a Cloudflare exibiu 522.

sudo journalctl -u nginx --since "30 minutes ago" --no-pager

Output esperado:
Started nginx.service
reload complete

Em Apache, use o nome do serviço correspondente:

sudo journalctl -u apache2 --since "30 minutes ago" --no-pager

Output esperado:
Started apache2.service

Depois, confira se chegam requisições ao site no momento do teste. O caminho do log varia conforme a distribuição e o painel, mas estes locais são comuns em instalações padrão.

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

Output esperado:
203.0.113.20 - - "GET / HTTP/2.0" 200
no critical errors in recent lines

Se o access log permanece vazio durante o teste pela Cloudflare, concentre-se em DNS, firewall e porta pública. Se o error log mostra falhas de upstream, processo esgotado ou conexão recusada internamente, o 522 pode ser efeito de uma aplicação sem capacidade de responder no tempo esperado. Nesse caso, reiniciar sem análise pode mascarar o problema temporariamente; prefira identificar fila de conexões, serviço parado ou limite de processos.

Problemas comuns e como resolver

Sintoma: site abre pelo IP, mas mostra erro 522 pela Cloudflare

Causa: a origem aceita conexões diretas, mas bloqueia, limita ou descarta conexões vindas da Cloudflare. Também pode haver DNS apontando para IP antigo no painel da Cloudflare. Solução: compare o IP do registro A com o IP real, teste com curl usando --resolve e revise firewall local, painel de hospedagem e qualquer proteção intermediária.

Sintoma: HTTPS direto fica carregando até expirar

Causa: a porta 443 não está escutando publicamente, o serviço web está parado ou há bloqueio de firewall. O SSL pode estar instalado, mas sem um processo respondendo na porta correta. Solução: use ss para validar 443, systemctl para checar Nginx ou Apache e openssl s_client para confirmar handshake TLS com SNI.

Sintoma: HTTP funciona, mas HTTPS gera 522

Causa: a porta 80 responde, porém a porta 443 está fechada, filtrada ou com vhost TLS incorreto. Isso é comum após migração, renovação de certificado ou mudança de painel. Solução: valide firewall para 443, teste o certificado na origem, confira o vhost do domínio e só depois revise o modo SSL da Cloudflare.

Sintoma: erro 522 aparece apenas em horários de pico

Causa: a origem pode estar demorando para aceitar conexões por sobrecarga, backlog, aplicação travada ou limite agressivo de conexões. A Cloudflare interpreta a falta de resposta como timeout. Solução: correlacione horários com journalctl, access log e error log, verifique processos do serviço web e ajuste capacidade da aplicação antes de culpar o SSL.

Perguntas frequentes sobre otimizar erro 522 da Cloudflare

O que significa erro 522 da Cloudflare com SSL ativo?

O erro 522 indica que a Cloudflare conseguiu iniciar a conexão com o servidor de origem, mas não recebeu resposta dentro do tempo esperado. Mesmo com SSL ativo, o problema normalmente está em conectividade, firewall, serviço web parado, porta bloqueada ou IP de origem incorreto no DNS.

SSL vencido causa erro 522 na Cloudflare?

Um certificado SSL vencido ou inválido tende a gerar erros de handshake ou aviso de certificado, não necessariamente o 522. No 522, a prioridade é confirmar se o servidor responde nas portas 80 e 443, se o firewall permite a Cloudflare e se o serviço web está ativo.

Como saber se o firewall está bloqueando a Cloudflare?

Verifique as regras do firewall do servidor, do painel de hospedagem e de qualquer camada de segurança intermediária. Se o site abre direto pelo IP de origem, mas falha pela Cloudflare, há forte indício de bloqueio, limitação ou filtragem aplicada às conexões vindas da Cloudflare.

Por que meu site abre direto no servidor, mas dá erro 522 na Cloudflare?

Isso geralmente acontece quando o servidor aceita conexões comuns, mas bloqueia ou limita as conexões encaminhadas pela Cloudflare. Também pode ocorrer quando o registro DNS na Cloudflare aponta para um IP antigo ou quando o serviço web responde apenas localmente e não nas portas públicas.

Devo desativar o SSL para corrigir erro 522 da Cloudflare?

Não desative o SSL como primeira tentativa, pois isso pode criar novos erros de segurança e redirecionamento. O caminho correto é diagnosticar conectividade, DNS, firewall, portas 80/443, serviço web e logs do servidor mantendo o certificado TLS válido na origem.

Conclusão

• Valide primeiro DNS e IP de origem, porque um apontamento incorreto torna qualquer ajuste de SSL ou firewall inútil.
• Teste portas 80 e 443 diretamente na origem com curl, ss e openssl antes de alterar configurações da Cloudflare.
• Revise firewall, logs e serviço web em conjunto para separar bloqueio de rede, falha TLS e indisponibilidade da aplicação.

Leia também

• Comparativo DNSSEC Registro.br e Cloudflare em domínio Linux
• Otimizar o Desempenho do Firewall com Iptables Persistente em VPS Linux e Servidor Dedicado
• Otimizar Firewall Linux: por que a distro muda a segurança

Precisa de ajuda com erro 522 da Cloudflare em site com SSL ativo?

A AviraHost pode apoiar a análise de hospedagem, DNS, SSL e conectividade da origem para reduzir indisponibilidades sem mudanças arriscadas no ambiente. Um diagnóstico técnico evita desativar proteções importantes apenas para contornar o sintoma.

Conheça as opções de hospedagem de sites