Como usar o Nginx como reverse proxy

O Nginx como reverse proxy não é só um passo operacional, é uma decisão de segurança estrutural. Ao tirar o aplicativo da linha de frente, você elimina dezenas de vetores de ataque que exigiriam implementação manual no código: timeout mal configurado vira vetor de slowloris, certificado expirado vira falha de TLS, upload sem limite vira DoS por memória. O artigo atual mostra bem o 'como', mas omite o 'por que agora': com o ingress-nginx em EOL desde março de 2026 (CVE-2026-24512 ativo) e a CNCF já migrando para Envoy Gateway, o Nginx *standalone* ganhou urgência como camada de proteção autônoma, especialmente em ambientes que ainda não migraram para Kubernetes Gateway API ou que rodam apps legados fora de cluster.

Essa camada intermediária também é crítica para agentes de IA que acessam APIs: sem headers como X-Forwarded-For e X-Forwarded-Proto, ferramentas como RAG ou web scrapers baseados em LLMs perdem contexto de origem, falham em redirecionamentos HTTPS e quebram lógicas de rate limiting. O guia CEVIU de 27/05 sobre preparação para agentes de IA reforça isso, mas não menciona que o Nginx é o ponto mais eficaz para injetar esses headers de forma confiável, antes mesmo do tráfego tocar qualquer app ou gateway.

A cobertura anterior tratava do ingress-nginx dentro de Kubernetes, uma abstração gerenciada que escondia detalhes de configuração. Agora, com o EOL do projeto e a migração forçada para Gateway API, o foco voltou ao Nginx *como serviço independente*, onde o administrador controla diretamente cada timeout, buffer e header. Isso muda o risco: antes, falhas vinham de bugs no controller do ingress; hoje, vêm de má configuração local, como proxy_buffering on em endpoints de streaming de logs ou client_body_timeout muito alto em formulários públicos, facilitando ataques de exaustão de recursos.

Empresas que ainda usam Nginx como proxy único, sem Kubernetes, estão na linha de frente da nova onda de ataques diretos a aplicações web. Vulnerabilidades como CVE-2026-3288 exploram justamente a falta de validação de cabeçalhos entre proxy e backend. Se seu app confia cegamente em X-Real-IP sem que o Nginx o defina corretamente, qualquer cliente pode forjar o IP. Isso compromete não só logs e bloqueios, mas também políticas de compliance como LGPD, onde a origem do acesso deve ser auditável e inalterável. Não é mais 'apenas' performance: é cadeia de confiança.