HAProxy vs Nginx: qual balanceador de carga usar no SaaS

Escolher entre HAProxy vs Nginx parece briga de torcida, mas a decisão costuma ser mais simples do que os fóruns fazem parecer. Os dois aguentam muito mais tráfego do que a maioria dos SaaS brasileiros vai gerar nos próximos anos. O gargalo raramente é a ferramenta. Quase sempre é a forma como ela foi configurada, monitorada e colocada em alta disponibilidade.

A resposta curta: se o seu problema principal é distribuir tráfego entre vários servidores de aplicação com controle fino, health checks ativos e mudanças sem reload, o HAProxy leva vantagem. Se você precisa de um proxy reverso que também sirva arquivos estáticos, faça cache e termine TLS para poucos backends, o Nginx resolve com menos peças. Em muitos SaaS maduros, os dois convivem, cada um na camada em que é melhor. O resto deste texto explica o porquê, com os detalhes que só aparecem depois de alguns incidentes em produção.

HAProxy vs Nginx: a resposta direta

O HAProxy é um balanceador de carga dedicado, otimizado para distribuir conexões TCP e HTTP entre servidores com health checks ativos e ajustes em tempo de execução. O Nginx é um servidor web que também atua como proxy reverso e balanceador. Para balanceamento puro em SaaS com muitos backends, HAProxy. Para borda simples com estáticos e cache, Nginx.

Essa é a regra geral. Ela muda conforme o tamanho da equipe, o número de servidores atrás do balanceador e o quanto você depende de recursos que, no Nginx, só existem na versão comercial. Falamos disso mais abaixo.

Um critério prático: conte quantos servidores de aplicação você tem hoje e quantos espera ter em 12 meses. Com dois ou três backends estáveis, qualquer um dos dois serve, e o Nginx provavelmente já está instalado. Se a frota sobe e desce com frequência, com deploys várias vezes ao dia e nós entrando e saindo de rotação, o HAProxy começa a se pagar em horas de operação economizadas.

O que cada ferramenta é de verdade

As duas ferramentas nasceram para problemas diferentes. Muita confusão vem daí, porque a sobreposição de recursos cresceu tanto que parece que fazem a mesma coisa.

HAProxy: um balanceador que só quer balancear

O HAProxy (High Availability Proxy) foi criado para uma tarefa: receber conexões e repassá-las para um conjunto de servidores da forma mais eficiente e observável possível. Ele não serve arquivos do disco. Não executa PHP. O cache embutido é pequeno e pensado para objetos leves, não para substituir uma CDN.

Esse foco aparece em tudo. Os logs trazem, por padrão, o tempo que a requisição ficou na fila, o tempo para conectar no backend, o tempo de resposta e um código de término que diz quem encerrou a conexão e por quê. A página de estatísticas mostra o estado de cada servidor em tempo real. A Runtime API, via socket, permite tirar um servidor de rotação, mudar pesos ou colocá-lo em modo de drenagem sem tocar no arquivo de configuração.

Nginx: um servidor web que aprendeu a fazer proxy

O Nginx surgiu como servidor web de alta concorrência, com arquitetura orientada a eventos, para resolver o problema de milhares de conexões simultâneas que derrubavam servidores tradicionais. O proxy reverso veio junto e virou um dos usos mais comuns. O módulo upstream faz balanceamento, e o módulo stream cobre TCP e UDP.

A força do Nginx está na versatilidade. No mesmo bloco de configuração você termina TLS, comprime respostas, serve o /static direto do disco, faz cache de respostas da API e encaminha o resto para a aplicação. Para um SaaS pequeno, isso significa uma peça a menos na arquitetura.

Pense assim: o HAProxy é um controlador de tráfego aéreo, enquanto o Nginx é um aeroporto inteiro. Se você só precisa coordenar pousos entre várias pistas, o controlador é mais preciso. Se precisa de terminal, estacionamento e esteira de bagagem, o aeroporto vem com tudo.

Existe ainda a questão de licença e edição. Ambos têm versão open source e versão comercial. No caso do Nginx, a divisão pesa mais: alguns recursos que um balanceador de carga de SaaS costuma querer, como health checks ativos nativos e sessões persistentes por cookie, ficam na edição paga (NGINX Plus). No HAProxy, a versão comunitária já entrega a maior parte do que importa para balanceamento.

Comparação técnica lado a lado

A tabela abaixo considera as versões open source, que é o que a maioria das PMEs e agências de fato roda. Recursos das edições comerciais aparecem marcados.

Performance ficou fora da tabela de propósito. Em benchmarks sintéticos, um ganha aqui, outro ganha ali, e a diferença depende de versão, número de threads, configuração de TLS e do tipo de carga. Na prática, num SaaS típico, a aplicação e o banco de dados saturam muito antes do balanceador. Se o seu proxy está no limite, o problema provavelmente é configuração (keepalive desligado para os backends, buffers mal dimensionados, TLS sem reaproveitamento de sessão) e não a escolha da ferramenta.

Um detalhe que pesa mais do que parece: o Nginx open source não reabre conexões ao upstream de forma eficiente se você esquecer de configurar keepalive. Sem a diretiva keepalive no bloco upstream e sem proxy_http_version 1.1 com o header Connection limpo, cada requisição abre uma nova conexão TCP com o backend. Sob carga, isso enche a tabela de conexões em TIME_WAIT e gera latência que ninguém consegue explicar.

Health checks, reload e as pegadinhas da operação

A diferença real entre os dois aparece na operação, não na instalação. É aqui que a escolha do balanceador de carga para SaaS se justifica.

Health check passivo deixa o usuário descobrir a falha primeiro

No Nginx open source, o servidor só é marcado como fora do ar depois que requisições reais falham. Com max_fails=3 e fail_timeout=30s, três usuários (ou três chamadas de API de clientes) levam erro ou timeout antes do backend sair de rotação. E, passado o fail_timeout, o Nginx manda tráfego real de novo para testar se o servidor voltou.

O HAProxy faz o contrário: consulta um endpoint, como /health, a cada poucos segundos, por conta própria. Se o backend parar de responder, sai de rotação antes de receber tráfego de cliente. Dá para exigir várias falhas seguidas para derrubar e várias respostas OK seguidas para reativar, o que evita o efeito "pisca-pisca" de um servidor instável.

Uma pegadinha que vale para os dois: health check que só devolve 200 sem testar nada é quase inútil. Se a aplicação está de pé mas perdeu conexão com o banco, o endpoint precisa refletir isso. Ao mesmo tempo, não faça o health check consultar tudo. Se ele depende do banco e o banco tem um soluço de dois segundos, todos os backends falham juntos, o balanceador tira todos de rotação e você transforma uma lentidão em indisponibilidade total.

Reload com conexões longas

Os dois fazem reload sem derrubar conexões em andamento. O Nginx sobe novos workers com a configuração nova e deixa os antigos terminarem o que estavam fazendo. O HAProxy, desde as versões mais recentes, passa os sockets de escuta para o novo processo sem perder conexões.

O problema aparece com WebSockets, streaming e conexões gRPC de longa duração. Os processos antigos continuam vivos enquanto houver conexão aberta. Faça cinco reloads numa tarde de deploys e você pode ter cinco gerações de workers consumindo memória. No Nginx, ajuste worker_shutdown_timeout; no HAProxy, hard-stop-after. Os dois definem um limite para o processo antigo encerrar à força. Sem isso, um servidor com 2 GB de RAM pode ficar sem memória depois de um dia agitado.

Deploy sem erro 502

Imagine um SaaS de gestão financeira com quatro servidores de aplicação, fazendo deploy no meio da tarde. O fluxo correto é tirar um nó de rotação, esperar as requisições em andamento terminarem, atualizar, verificar e devolver. Com HAProxy, o pipeline de CI manda um comando para a Runtime API colocando o servidor em estado drain, monitora as conexões ativas até zerar, faz o deploy e muda para ready. Nada de editar arquivo nem recarregar processo.

No Nginx open source, o caminho usual é editar o upstream (marcar como down), recarregar, fazer o deploy, editar de novo e recarregar outra vez. Funciona, e muita gente opera assim por anos. Mas é mais frágil: um erro de sintaxe no arquivo editado por script trava o pipeline, e o down corta o tráfego novo sem a drenagem gradual.

Arquiteturas de balanceamento de carga para SaaS

Não existe arquitetura certa no abstrato. Existe a que cabe no estágio do seu produto. Os padrões abaixo cobrem a maior parte dos casos que vemos em empresas brasileiras, do MVP ao SaaS com milhares de clientes.

Estágio 1: um Nginx na frente de tudo

Para quem tem um ou dois servidores de aplicação, o Nginx como proxy reverso é suficiente e elegante. Ele termina TLS com certificados do Let's Encrypt (a automação com certbot é madura), serve o front-end compilado, encaminha /api para os backends e aplica rate limit básico.

O risco desse estágio é o Nginx virar ponto único de falha. Se a máquina dele cai, o produto inteiro cai, mesmo com dois backends saudáveis. Muita empresa passa anos assim sem perceber, até a primeira manutenção do provedor.

Estágio 2: HAProxy na borda, Nginx nos nós

Esse é o padrão mais comum em SaaS que já cresceu um pouco e, na nossa opinião, o melhor custo-benefício operacional. O HAProxy fica na frente, termina TLS (ou repassa em modo TCP, se preferir), faz o balanceamento com health checks ativos e roteia por host, path ou header. Em cada servidor de aplicação, um Nginx local cuida de estáticos, compressão e repassa para o PHP-FPM, Gunicorn, Puma ou Node.

Cada ferramenta fica na camada em que é melhor. O HAProxy decide para onde vai a requisição. O Nginx decide como ela é atendida dentro do nó.

Estágio 3: alta disponibilidade do próprio balanceador

Balanceador sem redundância só desloca o ponto único de falha para outro lugar. Em servidores dedicados ou VPS, a solução clássica é rodar dois nós de balanceamento com Keepalived, que usa VRRP para manter um IP flutuante. O nó ativo responde pelo IP; se ele cair, o secundário assume em poucos segundos.

Alguns cuidados que fazem diferença:

• Verifique se o provedor permite IP flutuante e tráfego VRRP. Várias redes virtualizadas bloqueiam multicast ou não deixam um IP migrar entre máquinas sem chamada de API. Às vezes é preciso configurar VRRP em unicast ou usar um script que move o IP via API do provedor.
• O Keepalived deve checar o processo do balanceador, não só a máquina. Se o HAProxy morre mas o servidor continua de pé, o IP precisa migrar mesmo assim. Configure um vrrp_script que teste o serviço.
• Mantenha as configurações sincronizadas. Um failover que leva tráfego para um nó com configuração de três semanas atrás é pior do que ficar fora do ar, porque gera comportamento estranho e difícil de diagnosticar. Versione no Git e aplique com Ansible ou ferramenta equivalente.
• Teste o failover de verdade, com tráfego. Desligue o nó ativo numa janela controlada. Muita configuração "redundante" só revela o defeito no dia do incidente.

SaaS multi-tenant com domínios próprios dos clientes

Esse é um cenário específico que pega muita gente. Quando cada cliente pode usar seu próprio domínio (app.clientedele.com.br), o balanceador precisa servir centenas ou milhares de certificados diferentes, escolhendo o certo via SNI.

O HAProxy lida bem com isso: você aponta para um diretório ou uma crt-list com os certificados e ele carrega todos, e versões recentes permitem atualizar certificados pela Runtime API sem reload. No Nginx, dá para usar variáveis em ssl_certificate (por exemplo, $ssl_server_name) e carregar o certificado conforme o domínio, mas isso tem custo de leitura de disco a cada handshake novo. O desafio maior, em qualquer um dos dois, é a emissão e renovação automática: você vai precisar de um processo próprio que emita certificados via ACME quando o cliente cadastra o domínio, e esse processo costuma dar mais trabalho que o balanceador em si.

Como escolher em poucos passos

1. Liste o que você precisa no proxy: só balancear, ou também estáticos, cache e compressão?
2. Conte os backends hoje e projete para 12 meses. Frota dinâmica favorece HAProxy.
3. Verifique se precisa de health check ativo e sticky session por cookie sem pagar licença comercial. Se sim, HAProxy.
4. Avalie a familiaridade da equipe. Um Nginx bem configurado por quem conhece vence um HAProxy configurado às pressas.
5. Planeje a redundância do balanceador desde o início, seja qual for a ferramenta.

Erros comuns e quando não usar nenhum dos dois

Alguns problemas aparecem com tanta frequência que valem uma seção própria. Quase nenhum tem a ver com a escolha da ferramenta.

Perder o IP real do cliente. Atrás de um proxy, a aplicação enxerga o IP do balanceador. Se você não repassa X-Forwarded-For (ou PROXY protocol, em modo TCP) e não configura a aplicação para confiar nesse header apenas vindo do balanceador, seus logs, rate limits e regras antifraude ficam cegos. O oposto também é perigoso: aplicação que confia em X-Forwarded-For vindo de qualquer origem deixa o atacante forjar o IP que quiser.

Timeouts desalinhados. O balanceador tem timeout de 60 segundos, o Nginx no nó tem 30, o PHP-FPM tem 120. Uma requisição lenta morre na camada do meio e o usuário recebe um 504 enquanto o processo continua rodando no backend, gastando CPU à toa. Defina os timeouts de fora para dentro, cada camada interna com valor menor ou igual à externa, e trate relatórios e exportações pesadas como jobs assíncronos em vez de esticar timeouts.

Sticky session como muleta. Fixar o usuário num servidor porque a sessão está em arquivo local resolve o sintoma e cria outro problema: quando aquele nó cai, os usuários dele perdem a sessão, e a carga fica desigual. Leve a sessão para Redis ou banco e deixe o balanceador livre para distribuir de verdade. Sticky faz sentido para casos específicos, como WebSockets ou cache local caro, não como padrão.

Algoritmo errado para o perfil de carga. Round robin assume que todas as requisições custam o mesmo. Num SaaS em que uma chamada lista dez registros e outra gera um PDF de 200 páginas, isso não é verdade. leastconn (HAProxy) ou least_conn (Nginx) costuma distribuir melhor quando o tempo de resposta varia muito.

Quando nenhum dos dois é a melhor resposta

Há situações em que gerenciar HAProxy ou Nginx por conta própria não compensa:

• Se você está em Kubernetes, o ingress controller é quem faz esse papel. Existem ingress controllers baseados em ambos, além de alternativas como Traefik e Envoy. A escolha ali envolve outros critérios, como integração com o cluster e suporte a CRDs.
• Se a sua arquitetura é de microsserviços com dezenas de serviços conversando entre si, um service mesh ou um proxy como o Envoy, com configuração dinâmica via API, tende a se encaixar melhor.
• Se a equipe não tem ninguém para manter balanceador, renovar certificado e testar failover, um balanceador gerenciado ou uma infraestrutura com suporte especializado sai mais barato do que o primeiro incidente de madrugada.

Perguntas frequentes

HAProxy é mais rápido que Nginx?

Para balanceamento puro, o HAProxy costuma ter leve vantagem em eficiência e latência, mas a diferença é irrelevante na maioria dos SaaS. A aplicação e o banco de dados saturam muito antes. Escolha pelos recursos operacionais (health checks, Runtime API, observabilidade) e pela familiaridade da equipe, não por benchmark.

Posso usar HAProxy e Nginx juntos?

Sim, e é uma das arquiteturas mais comuns. O HAProxy fica na borda distribuindo tráfego entre os servidores, e cada servidor roda um Nginx local que serve estáticos e repassa para a aplicação. Cada ferramenta atua onde tem mais vantagem, e a troca de um nó não afeta a camada de balanceamento.

O Nginx open source serve como balanceador de carga em produção?

Serve, e muita empresa roda assim com sucesso. As limitações principais são health checks apenas passivos, alterações de upstream que exigem reload e ausência de sticky session por cookie. Para poucos backends estáveis, isso raramente atrapalha. Com frota dinâmica e deploys frequentes, o atrito operacional cresce.

Preciso de dois balanceadores para ter alta disponibilidade?

Sim. Um único balanceador é ponto único de falha, não importa quantos backends existam atrás dele. O padrão em servidores próprios é usar dois nós com Keepalived e IP flutuante via VRRP. Confirme com o provedor se a rede permite migração de IP e teste o failover com tráfego real.

Qual é melhor para WebSocket e gRPC?

Os dois suportam WebSocket e gRPC sobre HTTP/2. O ponto de atenção é o reload: conexões longas mantêm processos antigos vivos. Configure hard-stop-after no HAProxy ou worker_shutdown_timeout no Nginx, e garanta que o cliente saiba reconectar quando a conexão for encerrada.

Qual algoritmo de balanceamento usar num SaaS?

Comece com least connections, que envia a requisição ao servidor com menos conexões ativas. Ele se adapta melhor quando o tempo de resposta varia entre endpoints. Round robin funciona bem se as requisições forem homogêneas. Hash por URI ou header só faz sentido quando há ganho real de cache local.

Conclusão

Na disputa HAProxy vs Nginx, não existe vencedor universal. Existe a ferramenta certa para cada camada. O HAProxy é a escolha natural quando o balanceador de carga precisa de health checks ativos, drenagem de servidores sem reload, rate limiting refinado e logs que mostram onde cada milissegundo foi gasto. O Nginx brilha como proxy reverso versátil, servindo estáticos, fazendo cache e simplificando a arquitetura de quem ainda tem poucos servidores.

Para a maioria dos SaaS em crescimento, o caminho que recomendamos é este: comece com Nginx se o produto é pequeno, planeje desde cedo a redundância do ponto de entrada e migre a borda para HAProxy quando a frota de servidores começar a mudar com frequência. Mais importante do que a ferramenta é alinhar timeouts, preservar o IP real do cliente, tirar sessão do disco local e testar o failover antes que um incidente faça isso por você.

Se você quer montar ou revisar a camada de balanceamento e alta disponibilidade do seu SaaS sem tirar a equipe do produto, a Toda Solução pode ajudar a desenhar a arquitetura, provisionar os servidores e acompanhar a operação, com gente que já resolveu esses problemas em produção.