Você já pensou que o maior inimigo do seu servidor pode ser você mesmo? Ou, pior, o arquivo de configuração que você copiou de um tutorial em 2018? Pois bem. Em um data center na Zona Sul de São Paulo, um servidor dedicado com 64 GB de RAM e CPU AMD EPYC rodava um marketplace de veículos. Durante um pico de tráfego legítimo — um feriado de Black Friday — o site simplesmente apagou. 47 minutos de downtime. Prejuízo estimado: R$ 340 mil. A perícia forense apontou DDoS? Não. Atribuíram a um bug no kernel? Errado. A causa: uma regra de rate-limit no Nginx, configurada por um estagiário dois anos antes, que usava limit_req_zone com uma zona de 10 MB e uma taxa de 5 requisições por segundo por IP. O pico de tráfego legítimo veio de um único bloco /22 de IPs de um provedor de CDN. O rate-limit transformou cada IP legítimo em um ‘inimigo’. O servidor começou a responder com 503 para todos. O cache do WordPress? Inútil. O Redis? Cheio de locks. O cenário perfeito para um colapso. Isso não é teoria. Aconteceu. E o pior: ninguém desconfiou do rate-limit até o sexto café da manhã de debug. Vamos dissecar cada camada dessa sabotagem silenciosa. Se você administra VPS ou servidores dedicados, preste atenção. Este é o estudo de caso reverso que ninguém quer que você leia.