Como Proteger Servidor Apache Contra Bots e Eliminar o Erro 524 no Cloudflare

Aprenda a mitigar picos de tráfego malicioso e eliminar o erro 524 do Cloudflare blindando sua infraestrutura Apache contra bots abusivos.

Como Proteger Servidor Apache Contra Bots e Eliminar o Erro 524 no Cloudflare

Receber alertas frequentes de Error 524: A Timeout Occurred na tela do Cloudflare é um sintoma claro de sobrecarga no servidor de origem. Esse erro específico indica que a conexão TCP entre a borda (edge) do Cloudflare e o servidor Apache foi estabelecida com sucesso, mas o Apache demorou mais de 100 segundos para enviar a resposta HTTP.

Na maioria dos casos em que o site experimenta picos repentinos de tráfego, o vilão não é um aumento orgânico de usuários, mas sim requisições automatizadas abusivas: raspadores de dados (web scrapers), bots de força bruta ou ataques de negação de serviço de camada 7 (HTTP Flood). Quando centenas de conexões simultâneas atingem endpoints pesados do Apache, a fila de processos esgota os workers disponíveis e a infraestrutura trava.

Abaixo, analisamos as causas técnicas desse cenário e como estruturar uma defesa em camadas para blindar o Apache.


1. Por que o Apache trava com tráfego de bots?

O servidor web Apache, dependendo do módulo de multiprocessamento (MPM) configurado, pode gerenciar conexões de forma ineficiente sob alta concorrência:

  • MPM Prefork vs. MPM Event: O mpm_prefork aloca um processo dedicado por requisição. Se 150 bots enviarem requisições a URLs dinâmicas simultaneamente, o consumo de memória RAM atinge o limite do hardware, levando o servidor à exaustão e travando novas respostas.
  • Fila de Execução Ocupada: Enquanto o Apache processa consultas lentas geradas por bots, requisições legítimas esperam na fila até o Cloudflare estourar o tempo limite de espera (100 segundos no plano padrão), resultando no erro 524.
  • Bypass de Cache: Bots costumam variar parâmetros de URL (?utm_source=, queries aleatórias) para forçar o cache do Cloudflare a repassar cada requisição diretamente para o servidor Apache de origem.

2. Restringindo a Origem e Restaurando IPs Reais

Antes de configurar regras de bloqueio, o Apache precisa enxergar o IP real do visitante e rejeitar conexões diretas que não passem pela borda do Cloudflare.

Habilitar o mod_remoteip

Como o tráfego passa pelo proxy reverso do Cloudflare, os logs do Apache registram apenas os IPs dos nós da CDN. Para restaurar os IPs originais para fins de auditoria e rate limiting, ative o módulo:

apache

Configuração no apache2.conf ou remoteip.conf

RemoteIPHeader CF-Connecting-IP
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
RemoteIPTrustedProxy 103.22.200.0/22

Adicionar todas as faixas oficiais de IP do Cloudflare

Bloquear acessos diretos ao IP do servidor

Bots costumam contornar as proteções do Cloudflare acessando diretamente o IP público do servidor Apache. Feche essa brecha via firewall (iptables ou ufw), liberando as portas 80 e 443 estritamente para as faixas de IP oficiais do Cloudflare.


3. Otimização do Apache contra Ataques L7

Em sistemas que desenvolvo, a primeira camada de contenção no servidor de origem combina a modernização do MPM com módulos de limitação de taxa agressivos:

  1. Migração para mpm_event: Permite que conexões keep-alive não prendam threads ativas desnecessariamente, multiplicando a capacidade de requisições simultâneas com menor uso de memória.
  2. Ajuste de Timeouts: Reduza o Timeout padrão do Apache de 60 ou 300 segundos para valores mais curtos (ex: 15 a 30 segundos) e limite o KeepAliveTimeout para 2 a 5 segundos.
  3. Módulo mod_qos ou mod_evasive: Implemente limitação de taxa no nível do servidor para derrubar conexões de IPs que fazem dezenas de requisições por segundo a scripts pesados.

4. Mitigação na Borda (Cloudflare WAF e Bot Management)

A melhor requisição é aquela que sequer alcança o Apache. O tratamento primário deve ocorrer na borda:

  • Ativação do Bot Fight Mode / Super Bot Fight Mode: Desafia automaticamente tráfego originado de data centers conhecidos por operar crawlers não autorizados.
  • Rate Limiting Rules no WAF: Crie regras específicas para endpoints dinâmicos (login, busca interna, rotas de API). Por exemplo: se um mesmo IP requisitar a mesma rota dinâmica mais de 20 vezes em 10 segundos, aplicar desafio interativo (Managed Challenge).
  • Bloqueio de User-Agents Maliciosos: Crie regras personalizadas de WAF para descartar padrões comuns de ferramentas de automação (como curl, python-requests, Go-http-client) que não tenham justificativa de negócio.

Fluxo de Estabilização Recomendado

  1. Diagnóstico dos Logs: Identifique nos logs de acesso do Apache quais endpoints e padrões de user-agent estão concentrando as requisições lentas nos momentos de pico.
  2. Isolamento de Rede: Force todo o tráfego a passar exclusivamente pelo Cloudflare, fechando a origem no firewall.
  3. Criação de Regras de WAF: Adicione regras granulares de desafio (Managed Challenge) e rate limiting para as URLs alvo identificadas.
  4. Tuning de Processos: Ajuste os limites de MaxRequestWorkers do Apache de acordo com a memória RAM disponível para evitar swap durante picos residuais.

Precisa de suporte especializado para sua infraestrutura?

Se o seu servidor continua sofrendo com quedas, gargalos de desempenho e erros de timeout provocados por tráfego malicioso, uma auditoria profunda de arquitetura pode estancar o problema definitivamente.

Entre em contato para avaliar uma consultoria técnica focada em blindagem de servidores, otimização de Apache/Nginx e integração avançada com Cloudflare WAF.

Preencha o formulário abaixo para que eu consiga entrar em contato com você.