Estudo de caso: Cloudflare 403 vs. indisponibilidade real

Uma equipe de suporte relatou «site fora do ar» após receber respostas 403 nas verificações de monitoramento. Usuários finais ainda conseguiam carregar a página inicial nos navegadores. Este caso explica como resolver essa contradição.

Sintomas observados

• Verificações automatizadas retornaram HTTP 403.
• Usuários no navegador viram páginas de desafio ocasionais e depois sucesso.
• Sem evidência de quedas do servidor de origem ou erros 5xx.

Sequência de diagnóstico utilizada

1. Execute a URL no Verificador de Sites e capture o texto de status e as notas.
2. Verifique se a resposta inclui padrões de proteção contra bots (indícios de desafio Cloudflare).
3. Teste no navegador e compare com o comportamento da verificação no servidor.
4. Inspecione os limites de política WAF/rate limit nas configurações de edge.

Causa raiz

O site estava online, mas as configurações WAF tratavam tráfego não navegador como suspeito. Verificações sintéticas foram bloqueadas no edge antes de alcançar o conteúdo completo da página.

Correção e validação

• Regras de bot/WAF ajustadas para o comportamento de monitoramento esperado.
• Configurações agressivas de rate limit reduzidas para endpoints de diagnóstico.
• Reteste: o verificador passou de status bloqueado/limitado para respostas online estáveis.

Conclusões

• 403 nem sempre significa indisponibilidade.
• Tipos diferentes de requisição podem receber resultados diferentes.
• Cruze o status do verificador com logs de segurança no edge antes de declarar uma interrupção.

Leituras relacionadas: Guia 500/502/503 e Metodologia.