Load Balancer com HAProxy no Ubuntu: guia passo a passo

Quando um único servidor não aguenta mais o tráfego — ou você não pode ter downtime se ele cair — a solução é distribuir as requisições entre várias máquinas. O HAProxy é o load balancer open source mais usado para isso: leve, gratuito e capaz de rodar em produção com milhões de conexões simultâneas. Neste guia você instala o HAProxy no Ubuntu 24.04, configura o balanceamento HTTP entre dois ou mais servidores com verificação de saúde automática e ativa o painel de estatísticas.

Por que usar HAProxy em vez de deixar tudo em um servidor só

Dois motivos concretos justificam o esforço de configurar um load balancer: disponibilidade e capacidade. Se um dos servidores de back-end trava ou entra em manutenção, o HAProxy detecta a falha pelo health check e para de enviar tráfego para ele automaticamente — o usuário nem percebe. E se o volume de acesso cresce, você soma capacidade horizontalmente (mais servidores) em vez de depender de upgrade vertical (máquina maior), que tem teto físico e custa mais caro proporcionalmente.

Pré-requisitos

• Um servidor Ubuntu 24.04 para rodar o HAProxy (pode ser uma VM pequena — 1 vCPU e 512 MB já bastam para começar)
• Dois ou mais servidores de back-end (web, API, o que for) já respondendo na porta que você vai balancear
• Acesso root ou sudo no servidor do HAProxy

1. Instale o HAProxy

O repositório padrão do Ubuntu 24.04 traz o HAProxy 2.8.5 — uma branch LTS estável e mantida, suficiente para a maioria dos casos:

sudo apt update
sudo apt install -y haproxy
haproxy -v

Se você precisa de recursos mais recentes (HTTP/3 sobre QUIC, melhorias de SSL), a distribuição oficial mantida por Vincent Bernat entrega a branch LTS 3.2 via PPA:

sudo apt install --no-install-recommends software-properties-common
sudo add-apt-repository ppa:vbernat/haproxy-3.2 -y
sudo apt update
sudo apt install -y haproxy=3.2.*

Para o objetivo deste guia — balanceamento HTTP com health check — a versão do repositório padrão resolve. Confirme que o serviço subiu e está marcado para iniciar com o sistema:

sudo systemctl enable --now haproxy
sudo systemctl status haproxy

2. Entenda as seções do arquivo de configuração

Tudo fica em /etc/haproxy/haproxy.cfg. Antes de editar, tire um backup — é mais rápido reverter do que reconstruir de cabeça:

sudo cp /etc/haproxy/haproxy.cfg /etc/haproxy/haproxy.cfg.bak

O arquivo se divide em quatro blocos, e entender o papel de cada um evita configuração por tentativa e erro:

• global — parâmetros do processo: usuário, limites de conexão, log.
• defaults — valores herdados por frontend e backend (timeouts, modo tcp/http), para não repetir em cada seção.
• frontend — onde o HAProxy escuta e recebe as conexões do cliente.
• backend — a lista de servidores reais que vão receber o tráfego, e o algoritmo usado para escolher qual deles atende cada requisição.

3. Configure o frontend e o backend

Abra o arquivo e adicione ao final (substitua os IPs pelos da sua rede):

sudo nano /etc/haproxy/haproxy.cfg

frontend http_front
    bind *:80
    mode http
    default_backend web_servers

backend web_servers
    mode http
    balance roundrobin
    option httpchk GET /
    http-check expect status 200
    server web1 10.0.0.11:80 check
    server web2 10.0.0.12:80 check
    server web3 10.0.0.13:80 check backup

O que cada linha decide, na prática:

• bind *:80 — o HAProxy escuta a porta 80 em todas as interfaces. Se algo mais já ocupa essa porta na máquina, o serviço não sobe — libere a porta antes.
• balance roundrobin — distribui as requisições em rodízio simples. Alternativas: leastconn (manda para quem tem menos conexões abertas — melhor para requisições longas ou desiguais) e source (fixa o cliente sempre no mesmo servidor pelo IP de origem — útil quando a aplicação não tem sessão compartilhada entre back-ends).
• option httpchk + http-check expect status 200 — o HAProxy faz uma requisição HTTP real a cada servidor e só envia tráfego para quem responde 200. Sem isso, ele só checa se a porta TCP está aberta, o que não garante que a aplicação por trás esteja funcionando.
• check no fim da linha do server — ativa o health check para aquele servidor especificamente.
• backup — esse servidor só recebe tráfego se todos os outros estiverem fora do ar. Útil para reservar capacidade sem balancear direto nela.

4. Valide a configuração antes de aplicar

O HAProxy tem um modo de checagem de sintaxe que evita subir uma configuração quebrada em produção — rode sempre antes de reiniciar:

sudo haproxy -c -f /etc/haproxy/haproxy.cfg

A saída esperada é Configuration file is valid. Só depois disso recarregue o serviço:

sudo systemctl reload haproxy

reload é a diferença importante aqui: ele reinicia o HAProxy de forma graciosa, terminando as conexões em andamento antes de trocar para a nova configuração, sem derrubar requisições em curso. restart corta na marra — evite em produção.

5. Ative o painel de estatísticas

O HAProxy tem um painel web nativo que mostra, em tempo real, quantas conexões cada servidor está recebendo, quantos health checks falharam e o tempo de resposta. Adicione ao final do arquivo:

listen stats
    bind *:8404
    mode http
    stats enable
    stats uri /
    stats refresh 5s
    stats auth admin:TrocaEssaSenha123

Valide e recarregue de novo (haproxy -c -f ... e systemctl reload haproxy), depois acesse http://IP-DO-HAPROXY:8404/ com o usuário e senha definidos. Troque a senha do exemplo — deixar credencial padrão em um painel exposto é o tipo de descuido que vira porta de entrada.

6. Libere as portas no firewall

Se o UFW estiver ativo no servidor do HAProxy, libere a porta do frontend e, se for usar, a do painel de estatísticas:

sudo ufw allow 80/tcp
sudo ufw allow 8404/tcp
sudo ufw reload

7. Teste o balanceamento

Com tudo no ar, confirme que as requisições realmente alternam entre os back-ends. Em cada servidor de back-end, deixe algo identificável na resposta (por exemplo, o hostname na página inicial) e rode do lado do HAProxy:

for i in $(seq 1 10); do curl -s http://localhost/ | grep -i hostname; sleep 1; done

Se a resposta variar entre os servidores a cada chamada, o round robin está funcionando. Para testar a detecção de falha, pare o serviço em um dos back-ends e observe no painel de estatísticas (/8404/) o servidor mudar para o estado DOWN — o tráfego para automaticamente naquele nó, sem intervenção manual.

Perguntas frequentes

HAProxy ou Nginx para load balancing — qual escolher?
Os dois fazem balanceamento HTTP bem. O HAProxy tem vantagem em cenários TCP puro (bancos de dados, filas), algoritmos de balanceamento mais granulares e um painel de estatísticas nativo sem plugin. O Nginx leva vantagem se você já usa ele como servidor web ou proxy reverso e não quer mais uma peça na stack.

O HAProxy faz terminação SSL/HTTPS?
Sim, na versão gratuita. Basta trocar bind *:80 por bind *:443 ssl crt /caminho/para/certificado.pem no frontend, com um certificado (Let’s Encrypt, por exemplo) no formato PEM combinando chave e certificado no mesmo arquivo.

Preciso reiniciar o HAProxy toda vez que altero a lista de servidores?
Sim, mudanças no arquivo haproxy.cfg exigem reload para valer. Para adicionar e remover servidores sem tocar no arquivo, é possível usar a Runtime API do HAProxy (socket de administração) — fica para um próximo guia.

O que acontece se todos os servidores de backend caírem?
O HAProxy retorna erro 503 Service Unavailable para o cliente, em vez de travar ou aceitar conexões que não teriam para onde ir. Configurar um servidor backup, como no passo 3, evita esse cenário na maioria dos casos.

Dá para balancear outra coisa além de HTTP, como banco de dados?
Sim. Trocando mode http por mode tcp no frontend e no backend, o HAProxy balanceia qualquer protocolo TCP — MySQL, PostgreSQL, Redis, SMTP — sem inspecionar a camada de aplicação.

Conclusão

Com o frontend, o backend e o health check configurados, você já tem um load balancer funcional que tira automaticamente da rotação qualquer servidor que pare de responder. Os próximos passos naturais são a terminação SSL no próprio HAProxy, sessões persistentes com balance source ou cookies, e alta disponibilidade do próprio HAProxy com Keepalived e um IP virtual — para eliminar o balanceador como ponto único de falha.