NGINX: proxy reverso, servidor web e balanceador de carga

O que é NGINX e por que ele é diferente do Apache

A filosofia de design que tornou o NGINX indispensável em produção

NGINX nasceu em 2004 para resolver o problema C10K — a dificuldade do Apache em lidar com 10 mil conexões simultâneas devido ao seu modelo de processo-por-conexão. Enquanto o Apache cria um processo ou thread para cada conexão, o NGINX usa um modelo event-driven assíncrono onde um número fixo de worker processes lida com milhares de conexões simultaneamente. Essa diferença arquitetural faz o NGINX consumir muito menos memória que o Apache sob alta carga, tornando-o a escolha padrão para servidores web de alto tráfego. Hoje o NGINX é usado como servidor web, reverse proxy, load balancer, cache de conteúdo e terminador SSL por empresas como Netflix, Dropbox e GitHub.

Arquitetura event-driven — como NGINX lida com conexões

O modelo assíncrono que permite alta concorrência com baixo uso de recursos

O NGINX usa um processo master que lê a configuração e gerencia os worker processes, e um número de workers geralmente igual ao número de CPUs para maximizar utilização de hardware. Cada worker usa um event loop baseado em epoll (Linux) ou kqueue (BSD) para monitorar múltiplos file descriptors simultaneamente sem bloquear em operações de I/O. Quando uma requisição chega, o worker a processa de forma não-bloqueante — se precisar ler um arquivo ou proxiar para um backend, registra um callback e passa para a próxima conexão. Esse modelo significa que um único worker NGINX pode lidar com dezenas de milhares de conexões simultâneas, comparado a centenas no modelo threaded do Apache.

Configuração básica — server blocks, locations, upstreams

Os blocos fundamentais de configuração do NGINX

Server blocks são o equivalente NGINX dos virtual hosts do Apache, permitindo hospedar múltiplos domínios na mesma instância usando a diretiva server_name para distingui-los. Location blocks dentro de cada server definem como processar requisições para diferentes paths, suportando correspondência exata, prefixo, regex e a combinação desses para roteamento preciso. Upstream blocks definem grupos de servidores backend para proxy reverso e load balancing, com suporte a algoritmos como least_conn e ip_hash. A herança de contexto do NGINX — http, server, location — significa que diretivas definidas em nível mais alto são herdadas pelos níveis mais específicos, a menos que sobrescritas.

Proxy reverso — roteando requisições para aplicações backend

Configurando o NGINX como intermediário para aplicações Node.js, .NET e outros

A diretiva proxy_pass é o coração do reverse proxy no NGINX, encaminhando requisições para um backend local ou remoto e retornando a resposta ao cliente. Headers como X-Real-IP, X-Forwarded-For e X-Forwarded-Proto devem ser configurados explicitamente para que a aplicação backend receba o IP real do cliente e o protocolo original da requisição. O buffer de proxy — proxy_buffer_size, proxy_buffers e proxy_buffering — controla se o NGINX lê a resposta completa do backend antes de enviá-la ao cliente, impactando latência e uso de memória. Timeouts como proxy_connect_timeout, proxy_read_timeout e proxy_send_timeout devem ser ajustados baseados nas características da aplicação para evitar tanto falhas prematuras quanto conexões penduradas.

SSL/TLS no NGINX — certificados e HTTPS

Configurando HTTPS seguro com boas práticas de segurança

A configuração SSL no NGINX requer as diretivas ssl_certificate com o caminho para o certificado e ssl_certificate_key para a chave privada, além de listen 443 ssl para aceitar conexões HTTPS. Restringir os protocolos a TLS 1.2 e 1.3 com ssl_protocols e definir cipher suites seguras com ssl_ciphers é essencial para evitar vulnerabilidades como POODLE e BEAST. O HSTS header (Strict-Transport-Security) instruiu navegadores a sempre usar HTTPS para o domínio por um período definido, protegendo contra downgrade attacks. Let's Encrypt com Certbot pode automatizar a emissão e renovação de certificados gratuitos, com suporte a renovação automática via cron sem downtime usando o modo standalone ou webroot.

Cache de conteúdo estático e dinâmico

Reduzindo carga no backend com cache eficiente no NGINX

O NGINX pode servir arquivos estáticos diretamente do filesystem sem proxiar para o backend, usando a diretiva root ou alias junto com location blocks para CSS, JS, imagens e outros assets. Para conteúdo dinâmico, o proxy_cache_path define onde e como o NGINX armazena respostas em cache, com controles de tamanho, tempo de expiração e zona de memória para o cache de metadados. A diretiva proxy_cache_valid configura diferentes TTLs para diferentes status codes — cacheando respostas 200 por horas mas 404 por apenas minutos. Headers de cache do backend como Cache-Control e Expires são respeitados pelo NGINX, e X-Cache-Status pode ser adicionado às respostas para depuração.

Rate limiting e proteção contra abuso

Limitando requisições para proteger a aplicação de sobrecarga e ataques

O módulo limit_req do NGINX implementa rate limiting usando o algoritmo leaky bucket, definindo uma taxa máxima de requisições por IP com a diretiva limit_req_zone e um zone compartilhado entre workers na memória compartilhada. A diretiva burst permite um número de requisições acima do limite que são enfileiradas temporariamente, e nodelay processa essas requisições imediatamente em vez de introduzir delay artificial. Diferentes zonas de rate limiting podem ser aplicadas a diferentes location blocks — limites mais restritivos para endpoints de autenticação e mais permissivos para conteúdo estático. Retornando 429 Too Many Requests em vez de 503 Service Unavailable comunica corretamente ao cliente que é um limite temporário, não uma falha do servidor.

NGINX como load balancer — algoritmos e health checks

Distribuindo tráfego entre múltiplos backends com NGINX

O NGINX suporta múltiplos algoritmos de load balancing dentro de blocos upstream: round-robin padrão, least_conn para menor número de conexões e ip_hash para afinidade de sessão por IP do cliente. A diretiva weight em cada server dentro do upstream permite balanceamento proporcional, enviando mais tráfego para instâncias mais poderosas. O parâmetro max_fails e fail_timeout habilitam health checks passivos, marcando um backend como temporariamente indisponível após um número de falhas em uma janela de tempo. O NGINX Plus (versão comercial) oferece health checks ativos, mas na versão open-source essa funcionalidade pode ser simulada com upstream_check_module ou delegada para soluções externas.

Logs, monitoramento e debugging

Observabilidade e diagnóstico de problemas com NGINX

O access_log do NGINX registra cada requisição com formato configurável via log_format, permitindo incluir tempo de resposta, upstream usado, cache status e qualquer header customizado para análise de performance. O error_log captura erros em diferentes níveis de severidade (debug, info, warn, error, crit) e é essencial para diagnosticar problemas de proxy, SSL e permissões de arquivo. A variável $request_time mede o tempo total da requisição enquanto $upstream_response_time mede apenas o tempo de resposta do backend, separando latência de rede da latência de aplicação. Ferramentas como GoAccess processam logs NGINX em tempo real ou histórico, gerando relatórios de tráfego, top IPs e análise de erros sem necessidade de ELK stack.

Conclusão — NGINX como infraestrutura essencial

Um único binário que resolve proxy, SSL, cache e rate limiting

O NGINX é uma das ferramentas mais versáteis e confiáveis da infraestrutura web moderna, capaz de substituir ou complementar diversas outras ferramentas com excelente performance e baixo consumo de recursos. Dominar sua configuração — desde server blocks até rate limiting e cache — é uma das habilidades mais valiosas para qualquer engenheiro que opera sistemas em produção. Continue em: Fundamentos obrigatórios antes de produção.