Um Caso Real de Bloqueio por Rajadas e Falso Positivo em NGINX
1. O Sintoma Que Não Fazia Sentido
Durante os testes de uma aplicação corporativa baseada em Delphi FMX + REST API, um comportamento curioso começou a ocorrer.
O sistema funcionava perfeitamente em qualquer rede externa, inclusive em conexões 4G, mas falhava de forma intermitente dentro da rede interna de uma empresa japonesa de grande porte.
A equipe técnica local relatava erros aleatórios ao tentar atualizar múltiplos registros de agendamento. O servidor estava ativo, os logs limpos, e o consumo de recursos mínimo. Mesmo assim, em determinados momentos o sistema retornava erro de “excesso de conexões simultâneas”.
Um problema de rede?
De servidor?
Nenhum dos dois isoladamente — e foi justamente isso que tornou o caso tão interessante.
2. O Ambiente Controlado
O ambiente técnico era sólido e bem projetado:
- Aplicativo cliente: Delphi FMX (Android/Windows) comunicando-se via REST.
- Servidor: ambiente AWS com múltiplas instâncias da API.
- Proxy reverso: NGINX balanceando as instâncias locais via estratégia least_conn.
O servidor operava com menos de 30% de memória e 3% de CPU, em plena estabilidade.
Nenhuma lentidão, nenhuma falha, nenhuma queda.
E ainda assim, os logs mostravam algo intrigante:
limiting requests, excess: 20.260 by zone "req_zone"
Ou seja: o próprio NGINX estava bloqueando as requisições.
Mas por quê? Não havia nenhum tráfego anormal, apenas uma máquina executando atualizações legítimas.
3. O Mecanismo Oculto: o Comportamento da Rede Corporativa
Após horas de análise comparativa, surgiu o padrão:
o erro ocorria apenas dentro da rede corporativa japonesa, nunca fora dela.
A hipótese — depois confirmada — era de que o firewall e os proxies internos da empresa estavam retendo e liberando as requisições em rajadas, em vez de encaminhá-las de forma contínua.
Esse comportamento é comum em redes corporativas modernas e pode ocorrer por diversas razões:
Inspeção HTTPS (SSL Inspection)
Firewalls corporativos avançados, como FortiGate ou Sophos, interceptam o tráfego HTTPS, descriptografam, inspecionam e recriptografam antes de repassar.
Esse processo introduz atrasos mínimos em cada requisição — que, somados, geram um buffer interno. Quando liberado, o servidor recebe um “pacote” de chamadas quase simultâneas.
- NAT (Network Address Translation)
Vários dispositivos internos compartilham o mesmo IP público.
Para o servidor, múltiplos usuários legítimos passam a parecer uma única máquina disparando diversas requisições simultâneas. - Execuções Paralelas do Cliente
Mesmo um único aplicativo pode enviar várias chamadas REST em sequência (por exemplo, ao atualizar dezenas de registros de uma vez).
Em redes normais isso é transparente, mas sob inspeção corporativa, todas essas chamadas podem ser liberadas ao mesmo tempo.
4. O Outro Lado: Quando a Segurança Interpreta Segurança Como Ataque
Do lado do servidor, a configuração do NGINX era deliberadamente rígida, visando proteger contra floods e automações indevidas:
limit_req_zone $binary_remote_addr zone=req_zone:10m rate=20r/s;
limit_req zone=req_zone burst=20 nodelay;
Essa configuração é padrão em ambientes com múltiplos clientes, pois evita sobrecarga e ataques automatizados. O problema é que, quando uma rede corporativa libera várias requisições de uma vez, o NGINX interpreta essa rajada como um ataque coordenado, emitindo erro 429 (“Too Many Requests”).
Do ponto de vista do servidor, tudo estava correto.
Do ponto de vista do usuário, o sistema parecia falhar de forma aleatória.
5. A Correção: Segurança Inteligente em Vez de Segurança Cega
A solução não foi relaxar a segurança, mas torná-la mais inteligente.
Em vez de rejeitar as rajadas, o NGINX passou a aceitá-las e processá-las com um pequeno atraso interno:
limit_req_zone $binary_remote_addr zone=req_zone:10m rate=50r/s;
limit_req zone=req_zone burst=100 delay=2;
Agora, quando várias requisições chegam quase simultaneamente, o servidor as coloca em fila e processa de forma cooperativa, sem bloqueá-las.
O resultado foi imediato:
- Nenhum erro 429.
- Nenhuma queda.
- Nenhum impacto perceptível no tempo de resposta.
6. A Lição: Camadas de Segurança Também Precisam Conversar
Este caso ensina algo fundamental:
A segurança é relacional, não isolada.
Uma política de segurança pode ser perfeita sozinha, mas ao interagir com outra igualmente segura, pode gerar um falso positivo.
Foi exatamente o que ocorreu aqui:
- Do lado do servidor, um mecanismo legítimo de proteção contra ataques.
- Do lado da empresa, uma rede corporativa cuidadosamente protegida.
O resultado? Um falso positivo de segurança.
Nenhum dos lados estava errado — apenas rígidos demais, ao mesmo tempo.
7. Reflexão Final
Na engenharia de software e infraestrutura, robustez não é sinônimo de rigidez. A verdadeira robustez está em entender o contexto, em reconhecer que nem toda anomalia é ameaça, e que cooperar é tão importante quanto proteger.
O ajuste no NGINX foi pequeno — mas o aprendizado foi grande.
Descobrimos que a segurança não é uma muralha, e sim uma ponte: precisa ser forte, mas flexível o suficiente para permitir que o que é legítimo continue fluindo.
TheCodeNaked Case Study — Outubro de 2025
Tema: Segurança cooperativa e interoperabilidade entre camadas.
Tags: Segurança, NGINX, Inspeção HTTPS, Delphi REST API, Falso Positivo, Redes Corporativas, Clean Architecture.
