30 de ago. de 2025·8 min
Nginx vs HAProxy: Escolhendo o Proxy Reverso Adequado
Compare Nginx e HAProxy como proxies reversos: desempenho, balanceamento de carga, TLS, observabilidade, segurança e topologias comuns para escolher o ajuste ideal.
Compare Nginx e HAProxy como proxies reversos: desempenho, balanceamento de carga, TLS, observabilidade, segurança e topologias comuns para escolher o ajuste ideal.
Um proxy reverso é um servidor que fica à frente de suas aplicações e recebe as requisições dos clientes primeiro. Ele encaminha cada requisição para o serviço de backend correto (seus servidores de aplicação) e devolve a resposta ao cliente. Usuários falam com o proxy; o proxy fala com suas aplicações.
Um proxy direto (forward proxy) funciona ao contrário: fica na frente dos clientes (por exemplo, dentro de uma rede corporativa) e encaminha suas requisições de saída para a internet. Ele serve principalmente para controlar, filtrar ou ocultar o tráfego dos clientes.
Um balanceador de carga muitas vezes é implementado como um proxy reverso, mas com foco específico: distribuir tráfego por múltiplas instâncias de backend. Muitos produtos (incluindo Nginx e HAProxy) fazem tanto proxy reverso quanto balanceamento, então os termos às vezes são usados de forma intercambiável.
A maioria das implantações começa por um ou mais destes motivos:
/api para um serviço de API, / para um app web).Proxies reversos normalmente ficam na frente de sites, APIs e microserviços — seja na borda (internet pública) ou internamente entre serviços. Em stacks modernos, também são usados como blocos de construção para gateways de ingresso, deploys blue/green e configurações de alta disponibilidade.
Nginx e HAProxy se sobrepõem, mas diferem na ênfase. Nas seções seguintes, vamos comparar fatores de decisão como desempenho sob muitas conexões, balanceamento de carga e health checks, suporte a protocolos (HTTP/2, TCP), recursos TLS, observabilidade e configuração/operação no dia a dia.
Nginx é amplamente usado tanto como servidor web quanto como proxy reverso. Muitas equipes começam com ele para servir um site público e depois expandem seu papel para ficar na frente de servidores de aplicação — tratando TLS, roteando tráfego e suavizando picos.
Nginx brilha quando seu tráfego é principalmente HTTP(S) e você quer uma única “porta de entrada” que faça um pouco de tudo. Ele é especialmente forte em:
X-Forwarded-For, headers de segurança)Como pode servir conteúdo e fazer proxy para apps, Nginx é uma escolha comum para setups pequenos a médios onde você quer menos peças em movimento.
Capacidades populares incluem:
Nginx costuma ser escolhido quando você precisa de um ponto de entrada para:
Se sua prioridade é um manuseio HTTP rico e você gosta da ideia de combinar servidor web e proxy reverso, Nginx frequentemente é o ponto de partida padrão.
HAProxy (High Availability Proxy) é mais comumente usado como um proxy reverso e balanceador de carga que fica na frente de um ou mais servidores de aplicação. Ele aceita tráfego, aplica regras de roteamento e encaminha requisições para backends saudáveis — frequentemente mantendo tempos de resposta estáveis sob alta concorrência.
Equipes tipicamente implantam HAProxy para gerenciamento de tráfego: distribuir requisições entre servidores, manter serviços disponíveis durante falhas e suavizar picos de tráfego. É escolha frequente na “borda” de um serviço (tráfego norte–sul) e também entre serviços internos (leste–oeste), especialmente quando você precisa de comportamento previsível e forte controle sobre o gerenciamento de conexões.
HAProxy é conhecido por manipular eficientemente um grande número de conexões concorrentes. Isso importa quando você tem muitos clientes conectados ao mesmo tempo (APIs ocupadas, conexões longas, microserviços chatos) e quer que o proxy mantenha responsividade.
Suas capacidades de balanceamento são uma grande razão para escolhê-lo. Além do round-robin simples, ele suporta vários algoritmos e estratégias que ajudam a:
Health checks são outro ponto forte. HAProxy pode verificar ativamente a saúde dos backends e remover automaticamente instâncias não saudáveis da rotação, readicionando-as quando se recuperam. Na prática, isso reduz downtime e evita que deploys “meio quebrados” afetem todos os usuários.
HAProxy pode operar em Camada 4 (TCP) e Camada 7 (HTTP).
A diferença prática: L4 é geralmente mais simples e muito rápido para forwarding de TCP, enquanto L7 oferece roteamento mais rico e lógica por requisição quando necessário.
HAProxy costuma ser a escolha quando o objetivo principal é balanceamento de carga confiável e de alto desempenho com health checks robustos — por exemplo, distribuir tráfego de API entre múltiplos servidores, gerenciar failover entre zonas de disponibilidade ou frontalizar serviços onde o volume de conexões e comportamento previsível importam mais que recursos avançados de servidor web.
Comparações de desempenho frequentemente falham porque as pessoas observam um único número (como “RPS máximo”) e ignoram o que os usuários realmente sentem.
Um proxy pode aumentar o throughput enquanto ainda piora a latência nas caudas se enfileirar trabalho demais sob carga.
Pense no “formato” da sua aplicação:
Se você benchmarka com um padrão e implanta outro, os resultados não se transferirão.
O buffering pode ajudar quando clientes são lentos ou trafegos são em rajadas, porque o proxy pode ler a requisição (ou resposta) inteira e alimentar seu app de forma mais constante.
O buffering pode prejudicar quando seu app se beneficia de streaming (server-sent events, downloads grandes, APIs em tempo real). Buffer extra adiciona pressão de memória e pode aumentar latência nas caudas.
Meça mais do que “RPS máximo”:
Se o p95 sobe muito antes de aparecerem erros, você está vendo sinais iniciais de saturação — não “headroom” livre.
Tanto Nginx quanto HAProxy podem ficar na frente de múltiplas instâncias de aplicação e distribuir tráfego, mas diferem na profundidade do conjunto de recursos de load-balancing prontos para uso.
Round-robin é a escolha padrão “boa o suficiente” quando seus backends são semelhantes (mesma CPU/memória, mesmo custo por requisição). É simples, previsível e funciona bem para apps stateless.
Least connections é útil quando as requisições variam em duração (downloads, chamadas longas de API, chat/WebSocket). Tende a manter servidores mais lentos menos sobrecarregados, pois favorece o backend com menos requisições ativas.
Balanceamento ponderado (round-robin com pesos, ou least connections ponderado) é a opção prática quando servidores não são idênticos — misturando nós antigos e novos, tamanhos de instância diferentes ou mudando tráfego durante uma migração.
Em geral, HAProxy oferece mais opções de algoritmo e controle fino em Camada 4/7, enquanto Nginx cobre os casos comuns de forma limpa (e pode ser estendido dependendo da edição/módulos).
Stickiness mantém um usuário roteado para o mesmo backend ao longo das requisições.
Use persistência só quando for necessário (sessões legadas no servidor). Apps stateless normalmente escalam e se recuperam melhor sem ela.
Health checks ativos sondam periodicamente os backends (endpoint HTTP, connect TCP, status esperado). Eles detectam falhas mesmo quando o tráfego é baixo.
Health checks passivos reagem ao tráfego real: timeouts, erros de conexão ou respostas ruins marcam um servidor como não saudável. São mais leves, mas podem demorar mais para detectar problemas.
HAProxy é amplamente conhecido por controles de health check e tratamento de falhas ricos (limiares, contagens de subida/descida, checks detalhados). Nginx suporta checagens sólidas também, com capacidades dependendo do build e da edição.
Para deploys rolling, procure:
Qualquer que seja sua escolha, combine draining com timeouts curtos e bem definidos e um endpoint de “ready/unready” para que o tráfego migre suavemente durante deploys.
Proxies reversos ficam na borda do seu sistema, então escolhas de protocolo e TLS afetam tudo, desde performance no browser até como serviços falam entre si.
Tanto Nginx quanto HAProxy podem “terminar” TLS: aceitar conexões criptografadas de clientes, descriptografar e então encaminhar requisições para suas aplicações via HTTP ou TLS recriptografado.
A realidade operacional é o gerenciamento de certificados. Você precisará de um plano para:
Nginx é frequentemente escolhido quando a terminação TLS vem acompanhada de recursos de servidor web (arquivos estáticos, redirects). HAProxy costuma ser escolhido quando TLS faz parte principalmente de uma camada de gerenciamento de tráfego (balanceamento, manejo de conexões).
HTTP/2 pode reduzir tempos de carregamento em browsers ao multiplexar múltiplas requisições sobre uma única conexão. Ambos suportam HTTP/2 no lado cliente.
Considerações chave:
Se você precisa rotear tráfego não-HTTP (bancos de dados, SMTP, Redis, protocolos customizados), precisa de proxy TCP em vez de roteamento HTTP. HAProxy é amplamente usado para balanceamento TCP de alto desempenho com controles finos de conexão. Nginx também pode proxyar TCP (via suas capacidades stream), o que pode ser suficiente para setups de passagem simples.
mTLS valida ambos os lados: clientes apresentam certificados, não apenas servidores. É adequado para comunicação serviço-a-serviço, integrações com parceiros ou designs zero-trust. Qualquer um dos proxies pode impor validação de certificado cliente na borda, e muitas equipes também usam mTLS internamente entre proxy e upstreams para reduzir suposições de “rede confiável”.
Proxies reversos ficam no meio de cada requisição, então frequentemente são o melhor lugar para responder “o que aconteceu?”. Boa observabilidade significa logs consistentes, um conjunto pequeno de métricas de alto sinal e uma maneira repetível de debugar timeouts e erros de gateway.
No mínimo, mantenha access logs e error logs habilitados em produção. Para access logs, inclua timing do upstream para que você saiba se a lentidão veio do proxy ou da aplicação.
No Nginx, campos comuns são o tempo da requisição e timing do upstream (ex.: $request_time, $upstream_response_time, $upstream_status). No HAProxy, habilite o modo de log HTTP e capture campos de timing (queue/connect/response) para separar “esperando por uma vaga no backend” de “backend lento”.
Mantenha logs estruturados (JSON se possível) e adicione um request ID (de um header recebido ou gerado) para correlacionar logs do proxy com os logs da aplicação.
Quer você scrape Prometheus ou envie métricas a outro lugar, exporte um conjunto consistente:
Nginx costuma usar o endpoint stub status ou um exporter Prometheus; HAProxy tem um endpoint de stats embutido que muitos exporters consomem.
Exponha um leve /health (processo está vivo) e /ready (consegue alcançar dependências). Use ambos em automação: health checks do balanceador, deploys e decisões de auto-scaling.
Ao diagnosticar, compare timing do proxy (connect/queue) com tempo de resposta do upstream. Se connect/queue estiver alto, adicione capacidade ou ajuste balanceamento; se o tempo do upstream estiver alto, foque na aplicação e no banco de dados.
Rodar um proxy reverso não é só sobre throughput de pico — é também sobre quão rápido sua equipe consegue fazer mudanças seguras às 14h (ou 2h da manhã).
A configuração do Nginx é baseada em diretivas e hierárquica. Ela se lê como “blocos dentro de blocos” (http → server → location), o que muitos acham acessível quando pensam em sites e rotas.
A configuração do HAProxy é mais “em pipeline”: você define frontends (o que aceitar), backends (para onde enviar) e então anexa regras (ACLs) para conectar os dois. Pode parecer mais explícito e previsível depois que você internaliza o modelo, especialmente para lógica de roteamento de tráfego.
Nginx normalmente recarrega a config iniciando novos workers e drainando graciosaente os antigos. Isso é amigável a atualizações frequentes de rota e renovações de certificado.
HAProxy também pode fazer reloads sem interrupção, mas equipes frequentemente o tratam mais como uma “appliance”: controle de mudanças mais estrito, config versionada e coordenação cuidadosa ao executar reloads.
Ambos suportam testes de configuração antes do reload (imprescindível para CI/CD). Na prática, você provavelmente manterá configs DRY gerando-as:
O hábito operacional chave: trate a config do proxy como código — revisada, testada e implantada como mudanças de aplicação.
À medida que o número de serviços cresce, a dispersão de certificados e rotas se torna o verdadeiro ponto de dor. Planeje para:
Se você espera centenas de hosts, considere centralizar padrões e gerar configs a partir de metadados de serviço em vez de editar arquivos manualmente.
Se você está construindo e iterando múltiplos serviços, um proxy reverso é só uma parte do pipeline de entrega — você ainda precisa de scaffolding repetível de app, paridade de ambiente e rollouts seguros.
Koder.ai pode ajudar equipes a mover mais rápido da “ideia” para serviços rodando ao gerar React web apps, backends Go + PostgreSQL e apps móveis Flutter via fluxo de chat, além de suportar exportação de código, deploy/hosting, domínios customizados e snapshots com rollback. Na prática, isso permite prototipar uma API + frontend, deployar e então decidir se Nginx ou HAProxy é a melhor porta de entrada com base em padrões reais de tráfego em vez de suposições.
Segurança raramente é sobre uma funcionalidade “mágica” — trata-se de reduzir raio de ação e apertar padrões ao redor de tráfego que você não controla totalmente.
Execute o proxy com o mínimo privilégio necessário: vincule portas privilegiadas via capabilities (Linux) ou um serviço de fronting, e mantenha processos workers sem privilégios. Tranque configs e material de chaves (chaves privadas TLS, parâmetros DH) como leitura apenas pela conta de serviço.
Na camada de rede, permita inbound apenas de fontes esperadas (internet → proxy; proxy → backends). Negue acesso direto aos backends sempre que possível, assim o proxy é o ponto único para autenticação, rate limits e logging.
Nginx tem primitivas de primeira classe como limit_req / limit_conn. HAProxy tipicamente usa stick tables para rastrear taxas de requisição, conexões concorrentes ou padrões de erro e então negar, “tarp” ou desacelerar clientes abusivos.
Escolha um approach que combine com seu modelo de ameaça:
Seja explícito sobre quais headers você confia. Aceite X-Forwarded-For (e similares) apenas de upstreams conhecidos; caso contrário, atacantes podem falsificar IPs de cliente e burlar controles baseados em IP. De modo similar, valide ou defina Host para prevenir ataques por host-header e envenenamento de cache.
Uma regra prática: o proxy deve definir headers de forwarded, não apenas repassá-los cegamente.
Request smuggling frequentemente explora parsing ambíguo (Content-Length vs Transfer-Encoding, espaços estranhos, headers mal formatados). Prefira modos de parsing HTTP estritos, rejeite headers malformados e defina limites conservadores:
Connection, Upgrade e headers hop-by-hopEsses controles têm sintaxe diferente entre Nginx e HAProxy, mas o resultado deve ser o mesmo: falhar fechado diante de ambiguidade e manter limites explícitos.
Proxies reversos tendem a ser introduzidos de duas maneiras: como uma porta dedicada para uma única aplicação, ou como um gateway compartilhado na frente de muitos serviços. Ambos Nginx e HAProxy podem fazer os dois — o que importa é quanto lógica de roteamento você precisa na borda e como quer operar isso no dia a dia.
Esse padrão coloca um proxy reverso diretamente na frente de uma aplicação web única (ou um pequeno conjunto de serviços fortemente relacionados). É ótimo quando você precisa principalmente de terminação TLS, HTTP/2, compressão, cache (se usar Nginx) ou separação clara entre “internet pública” e “app privado”.
Use quando:
Aqui, um (ou um pequeno cluster) de proxies roteia tráfego para múltiplas aplicações com base em hostname, caminho, headers ou outras propriedades. Isso reduz o número de pontos de entrada públicos mas aumenta a importância do gerenciamento limpo de configuração e controle de mudanças.
Use quando:
app1.example.com, app2.example.com) e quer uma camada de ingress única.Proxies podem dividir tráfego entre a versão “antiga” e a “nova” sem mudar DNS ou código da aplicação. Uma abordagem comum é definir dois pools upstream (blue e green) ou dois backends (v1 e v2) e deslocar tráfego gradualmente.
Usos típicos:
Isso é útil quando a sua ferramenta de deploy não faz rollouts ponderados ou quando você quer um mecanismo de rollout consistente entre equipes.
Um proxy único é um ponto único de falha. Padrões comuns de HA incluem:
Escolha baseado no seu ambiente: VRRP é popular em VMs/bare metal tradicionais; load balancers gerenciados costumam ser a opção mais simples na nuvem.
Uma cadeia típica “frente-para-trás” é: CDN (opcional) → WAF (opcional) → proxy reverso → aplicação.
Se você já usa CDN/WAF, mantenha o proxy focado em entrega de aplicação e roteamento, em vez de tentar transformá-lo na sua única camada de segurança.
Kubernetes muda a forma como você “frontaliza” aplicações: serviços são efêmeros, IPs mudam e decisões de roteamento frequentemente acontecem na borda do cluster via um controller de Ingress. Tanto Nginx quanto HAProxy podem se encaixar bem aqui, mas tendem a brilhar em papéis ligeiramente diferentes.
Na prática, a decisão raramente é “qual é melhor” e mais “qual se ajusta aos seus padrões de tráfego e quanto manipulação HTTP você precisa na borda”.
Se você roda um service mesh (ex.: mTLS e políticas de tráfego entre serviços), ainda pode manter Nginx/HAProxy na periferia para tráfego norte–sul (internet → cluster). A malha cuida do tráfego leste–oeste (serviço a serviço). Essa divisão mantém preocupações de borda — terminação TLS, WAF/rate limiting, roteamento básico — separadas de recursos internos de confiabilidade como retries e circuit breaking.
gRPC e conexões longas stressam proxies de forma diferente do que requisições HTTP curtas. Observe:
Qualquer que seja a escolha, teste com durações realistas (minutos/horas), não apenas testes rápidos.
Trate a config do proxy como código: mantenha no Git, valide mudanças no CI (linting, teste de config) e faça rollout via CD usando deploys controlados (canary ou blue/green). Isso torna upgrades mais seguros e fornece trilha de auditoria quando uma mudança de roteamento ou TLS afeta produção.
A forma mais rápida de decidir é começar pelo que você espera que o proxy faça no dia a dia: servir conteúdo, moldar tráfego HTTP, ou gerenciar conexões e lógica de balanceamento de forma estrita.
Se seu proxy é também uma “porta de entrada” web, Nginx costuma ser o default conveniente.
Se sua prioridade é distribuição precisa de tráfego e controle sob carga, HAProxy tende a se destacar.
Usar ambos é comum quando você quer conveniências de servidor web e balanceamento especializado:
Essa separação também ajuda a dividir responsabilidades: preocupações web vs engenharia de tráfego.
Pergunte a si mesmo:
Um proxy reverso fica na frente das suas aplicações: os clientes conectam-se ao proxy, que encaminha as requisições para o serviço de backend correto e retorna a resposta.
Um proxy direto (forward proxy) fica na frente dos clientes e controla o acesso à internet (comum em redes corporativas).
Um balanceador de carga foca em distribuir tráfego entre múltiplas instâncias de backend. Muitos balanceadores de carga são implementados como proxies reversos, por isso os termos se sobrepõem.
Na prática, você frequentemente usa uma ferramenta (como Nginx ou HAProxy) para fazer as duas coisas: proxy reverso + balanceamento de carga.
Coloque-o na fronteira onde você quer um ponto único de controle:
O importante é evitar que clientes atinjam os backends diretamente, para que o proxy seja o ponto de controle para políticas e observabilidade.
Terminar TLS significa que o proxy lida com HTTPS: ele aceita conexões criptografadas do cliente, descriptografa e encaminha o tráfego para os upstreams via HTTP ou TLS recriptografado.
Operacionalmente, você precisa planejar:
Escolha Nginx quando seu proxy também for a “porta de entrada” web:
Escolha HAProxy quando o gerenciamento de tráfego e previsibilidade sob carga forem prioridade:
Use round-robin para backends semelhantes e carga com custo uniforme por requisição.
Use least connections quando a duração das requisições variar (downloads, chamadas longas de API, conexões longas) para evitar sobrecarregar instâncias mais lentas.
Use variantes ponderadas quando os backends diferirem (tamanhos diversos, hardware misto, migrações graduais) para direcionar tráfego de forma intencional.
Stickiness mantém um usuário roteado para o mesmo backend entre requisições.
Evite stickiness quando possível: serviços stateless escalam e fazem failover/rollout de forma mais limpa sem ela.
O buffering pode ajudar ao suavizar clientes lentos ou tráfegar em rajadas, fazendo com que o app veja tráfego mais estável.
Pode prejudicar quando você precisa de comportamento de streaming (SSE, WebSockets, downloads grandes), pois buffering extra aumenta pressão de memória e pode piorar a latência nas caudas.
Se seu app for orientado a streams, teste e ajuste o buffering explicitamente em vez de confiar nos padrões.
Comece separando atraso do proxy do atraso do backend usando logs e métricas.
Significados comuns:
Sinais úteis a comparar:
As correções geralmente envolvem ajustar timeouts, aumentar capacidade de backend ou melhorar health checks/endpoints de readiness.