Quando uma aplicação começa a receber mais acessos, simplesmente aumentar CPU, memória ou armazenamento de um único servidor pode deixar de ser a melhor estratégia. Em determinado momento, torna-se necessário distribuir as requisições entre diferentes servidores.
É nesse cenário que entra o load balancer.
Um load balancer recebe as conexões dos clientes e distribui o tráfego entre dois ou mais servidores backend. Dependendo da arquitetura, ele também pode realizar health checks, remover servidores com problemas, manter sessões, terminar conexões TLS e contribuir para alta disponibilidade.
Na prática, o balanceamento de carga pode ser utilizado em ambientes com VPS, servidores dedicados e infraestrutura cloud, desde aplicações pequenas até plataformas com múltiplos servidores web.
Neste guia, você verá como funciona um load balancer, quais são os principais métodos de distribuição, como implementar a solução com Nginx e HAProxy, como monitorar o ambiente e quais problemas precisam ser considerados em produção.
O que é load balancer?
Um load balancer é um componente responsável por distribuir requisições recebidas entre múltiplos servidores.
Em uma arquitetura tradicional, podemos ter:
Cliente
|
v
Servidor Web
|
v
Banco de DadosQuando o tráfego cresce, essa arquitetura pode evoluir para:
+----------------+
| Clientes |
+-------+--------+
|
v
+----------------+
| Load Balancer |
+-------+--------+
|
+----------+----------+
| |
v v
+-------------+ +-------------+
| Web Server 1| | Web Server 2|
+------+------+ +------+------+
| |
+----------+----------+
|
v
+-------------+
| Database |
+-------------+
Nesse cenário, o cliente não precisa saber diretamente qual servidor está processando a requisição.
O load balancer atua como ponto de entrada da aplicação.
Como funciona um load balancer?
Imagine que você tenha dois servidores:
web01 = 10.0.0.11
web02 = 10.0.0.12O domínio aponta para:
app.exemplo.comO DNS direciona o domínio para o endereço público do balanceador:
app.exemplo.com
|
v
203.0.113.10
|
v
Load Balancer
/ \
/ \
web01 web02Quando um usuário acessa:
https://app.exemplo.coma requisição chega ao balanceador.
Ele decide para qual backend encaminhar a conexão.
Por exemplo:
Request 1 → web01
Request 2 → web02
Request 3 → web01
Request 4 → web02Dessa forma, o tráfego é distribuído.
Por que utilizar load balancer?
Existem vários motivos para implementar balanceamento de carga.
1. Distribuir tráfego
O principal objetivo é evitar que um único servidor concentre todas as requisições.
Em vez de:
10.000 requisições
|
v
servidorpodemos ter:
10.000 requisições
|
v
Load Balancer
/ \
/ \
5000 5000
| |
v v
web01 web022. Aumentar capacidade
Quando a aplicação precisa suportar mais tráfego, novos servidores podem ser adicionados.
Por exemplo:
Antes:
LB
|
+-- Web01Depois:
LB
|
+-- Web01
+-- Web02
+-- Web03
+-- Web04Isso permite uma estratégia de scale-out, também conhecida como escalabilidade horizontal.
Escalabilidade vertical x horizontal
É importante diferenciar os dois modelos.
Escalabilidade vertical
Consiste em aumentar os recursos de um servidor.
Por exemplo:
4 CPU
8 GB RAM
↓
8 CPU
16 GB RAMEssa abordagem é simples, mas possui limites físicos e financeiros.
Escalabilidade horizontal
Consiste em adicionar servidores.
Servidor
↓
2 servidores
↓
4 servidores
↓
8 servidoresO load balancer é um dos principais componentes necessários para esse modelo.
3. Alta disponibilidade
Outra vantagem importante é permitir que um backend seja retirado do tráfego quando apresentar problemas.
Por exemplo:
Load Balancer
/ \
/ \
ONLINE OFFLINE
| X
v
Web01 Web02
O balanceador pode detectar que o Web02 não está respondendo corretamente.
Nesse caso:
Cliente
|
v
Load Balancer
|
+----> Web01
|
X----> Web02As novas requisições continuam sendo encaminhadas ao servidor saudável.
Isso aumenta a disponibilidade da aplicação.
Load balancer não é apenas distribuição
Uma implementação moderna pode executar várias funções.
Entre elas:
- distribuição de requisições;
- health checks;
- failover;
- TLS termination;
- controle de conexões;
- rate limiting;
- roteamento por domínio;
- roteamento por URL;
- persistência de sessão;
- controle de acesso;
- observabilidade;
- proteção da infraestrutura.
Por isso, o balanceador frequentemente se torna uma peça central da arquitetura.
Principais métodos de balanceamento
Existem diferentes algoritmos para distribuir as requisições.
Round Robin
É um dos métodos mais simples.
As requisições são distribuídas sequencialmente.
Request 1 → Web01
Request 2 → Web02
Request 3 → Web01
Request 4 → Web02É adequado quando os servidores possuem capacidades semelhantes.
Weighted Round Robin
Quando os servidores possuem capacidades diferentes, podemos utilizar pesos.
Por exemplo:
Web01 → peso 3
Web02 → peso 1O Web01 receberá aproximadamente três vezes mais tráfego que o Web02.
Isso é interessante quando temos:
Web01
16 CPU
32 GB RAM
Web02
8 CPU
16 GB RAMO servidor mais potente pode receber uma parcela maior das requisições.
Least Connections
Nesse método, o balanceador direciona a nova conexão para o backend com menos conexões ativas.
Exemplo:
Web01 → 120 conexões
Web02 → 80 conexõesA próxima conexão poderá ser enviada para:
Web02Esse método pode ser interessante para aplicações em que as conexões possuem duração variável.
IP Hash
O balanceador utiliza o endereço IP do cliente para determinar o backend.
Por exemplo:
Cliente A → Web01
Cliente B → Web02
Cliente C → Web01A vantagem é ajudar a manter determinado cliente associado ao mesmo servidor.
Entretanto, esse método possui limitações e não substitui uma arquitetura corretamente preparada para sessões compartilhadas.
Health checks
Um dos recursos mais importantes de um load balancer é verificar se os servidores estão realmente funcionando.
Não basta verificar se a porta 80 está aberta.
Uma aplicação pode estar:
Nginx → funcionando
PHP → funcionando
Banco → indisponívelNesse caso:
HTTP 200?
Sim.
Aplicação funcionando?
Não.Por isso, é interessante utilizar endpoints específicos.
Por exemplo:
GET /healthA aplicação pode responder:
{
"status": "ok"
}O balanceador utiliza esse endpoint para determinar se o backend está saudável.
Load balancer com Nginx
O Nginx pode funcionar como reverse proxy e balanceador HTTP/HTTPS.
Imagine:
Load Balancer
IP: 10.0.0.10
Web01
10.0.0.11
Web02
10.0.0.12Uma configuração básica seria:
upstream backend {
server 10.0.0.11;
server 10.0.0.12;
}
server {
listen 80;
server_name app.exemplo.com;
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}O Nginx distribuirá as requisições entre os servidores definidos no upstream.
Load balancer com pesos
Podemos definir pesos:
upstream backend {
server 10.0.0.11 weight=3;
server 10.0.0.12 weight=1;
}Nesse cenário, o primeiro servidor terá maior participação na distribuição.
Nginx com least connections
Também podemos utilizar:
upstream backend {
least_conn;
server 10.0.0.11;
server 10.0.0.12;
}Agora o Nginx priorizará o servidor com menor quantidade de conexões ativas.
Configuração de timeout
Timeouts são extremamente importantes em produção.
Exemplo:
location / {
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
proxy_pass http://backend;
}Esses parâmetros precisam ser ajustados de acordo com o comportamento da aplicação.
Timeout excessivamente alto pode manter conexões presas durante muito tempo.
Timeout excessivamente baixo pode causar erros em operações legítimas.
Preservando o IP do cliente
Quando existe um proxy intermediário, a aplicação pode enxergar o IP do balanceador em vez do IP real do cliente.
Por isso, normalmente utilizamos:
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;A aplicação precisa estar configurada para confiar corretamente nesses headers.
Isso é especialmente importante para:
- logs;
- segurança;
- rate limiting;
- auditoria;
- análise de tráfego.
Load balancer com HAProxy
O HAProxy é outra solução extremamente utilizada para balanceamento.
Uma configuração básica pode ser:
frontend http_front
bind *:80
default_backend web_servers
backend web_servers
balance roundrobin
server web01 10.0.0.11:80 check
server web02 10.0.0.12:80 checkO parâmetro:
checkpermite verificar a disponibilidade dos backends.
HAProxy com least connections
Podemos alterar o algoritmo:
backend web_servers
balance leastconn
server web01 10.0.0.11:80 check
server web02 10.0.0.12:80 checkIsso direciona novas conexões de acordo com a quantidade de conexões existentes.
Health check HTTP no HAProxy
Também podemos validar uma URL específica:
backend web_servers
option httpchk GET /health
server web01 10.0.0.11:80 check
server web02 10.0.0.12:80 checkAgora o balanceador verifica:
GET /healthem cada backend.
Arquitetura prática com dois servidores
Uma arquitetura simples para uma aplicação web seria:
Internet
|
v
+-------------+
| Load Balancer|
+------+------+
|
+--------+--------+
| |
v v
+---------+ +---------+
| Web 01 | | Web 02 |
+----+----+ +----+----+
| |
+--------+--------+
|
v
+---------+
| Database|
+---------+
Porém, existe um detalhe importante.
Se os dois servidores web dependem de arquivos locais diferentes, o balanceamento pode gerar problemas.
O problema dos arquivos locais
Imagine:
Web01
/home/site/uploads/foto.jpgmas o arquivo não existe em:
Web02Um usuário pode acessar:
Web01 → imagem funciona
Web02 → imagem não encontradaIsso acontece porque o conteúdo não está sincronizado.
Em arquiteturas distribuídas, arquivos precisam ser tratados de forma adequada.
Algumas alternativas incluem:
- armazenamento compartilhado;
- object storage;
- replicação;
- CDN;
- sincronização controlada;
- armazenamento externo.
Sessões também precisam de atenção
Imagine que o usuário faça login no:
Web01e a sessão seja armazenada somente naquele servidor.
Na próxima requisição:
Cliente
|
v
Load Balancer
|
v
Web02O Web02 pode não encontrar a sessão.
Resultado:
Usuário aparentemente deslogadoEsse problema pode ser resolvido utilizando:
- sessões compartilhadas;
- Redis;
- banco de dados;
- session affinity, quando apropriado;
- arquitetura stateless.
Load balancer + Redis
Redis pode ser utilizado para armazenar sessões compartilhadas.
Arquitetura:
Load Balancer
/ \
/ \
Web01 Web02
\ /
\ /
Redis
Agora ambos os servidores acessam o mesmo armazenamento de sessão.
Isso facilita a distribuição das requisições.
Load balancer e banco de dados
É importante entender que colocar dois servidores web atrás de um balanceador não significa automaticamente que o banco também esteja altamente disponível.
Podemos ter:
LB
|
+-- Web01
+-- Web02
|
v
DatabaseO banco continua sendo um possível ponto único de falha.
Para ambientes críticos, pode ser necessário trabalhar também com:
- replicação;
- cluster;
- failover;
- backups;
- servidores de banco redundantes;
- serviços gerenciados.
TLS no load balancer
Outra possibilidade é terminar o HTTPS no balanceador.
Arquitetura:
Cliente
|
HTTPS
|
v
Load Balancer
|
HTTP
|
+---- Web01
|
+---- Web02Nesse caso, o certificado SSL/TLS fica no balanceador.
Também é possível utilizar HTTPS entre o balanceador e os backends:
Cliente
|
HTTPS
v
Load Balancer
|
HTTPS
+---- Web01
|
+---- Web02Para ambientes que exigem maior isolamento, essa segunda arquitetura pode ser mais apropriada.
Load balancer em VPS
Em uma infraestrutura pequena, podemos utilizar:
VPS 1
Load Balancer
VPS 2
Web01
VPS 3
Web02Por exemplo:
Internet
|
v
VPS - LB
|
+-------+-------+
| |
v v
VPS Web01 VPS Web02
Essa arquitetura já permite separar a função de entrada das aplicações.
Load balancer em servidor dedicado
Em ambientes maiores, podemos utilizar um servidor dedicado exclusivamente para o balanceamento.
Exemplo:
Internet
|
v
Dedicated LB
|
+--------+--------+
| | |
v v v
Web01 Web02 Web03Essa arquitetura pode ser interessante quando os servidores backend possuem alta capacidade.
Load balancer em cloud
Em ambientes cloud, normalmente existem serviços de balanceamento gerenciados.
A arquitetura pode ser:
Internet
|
v
Cloud Load Balancer
|
+---- VM01
+---- VM02
+---- VM03Uma das vantagens desse modelo é reduzir a quantidade de componentes que precisam ser administrados manualmente.
Dependendo do provedor, o serviço pode oferecer:
- health checks;
- TLS;
- escalabilidade;
- integração com autoscaling;
- métricas;
- logs;
- múltiplas zonas;
- integração com redes privadas.
DNS não substitui um load balancer
É comum confundir DNS round robin com balanceamento de carga.
No DNS, podemos ter:
app.exemplo.com
A → 203.0.113.10
A → 203.0.113.11O DNS pode entregar diferentes endereços aos clientes.
Porém, isso não oferece necessariamente os mesmos recursos de um balanceador.
Por exemplo:
Servidor A caiuO DNS não necessariamente removerá o servidor imediatamente de todas as caches.
Já um balanceador pode detectar a falha através de health checks.
Como dimensionar um load balancer?
O balanceador também precisa de recursos suficientes.
Não adianta ter:
Web01 → 32 CPU
Web02 → 32 CPU
Web03 → 32 CPU
LB → 1 CPU / 512 MB RAMe esperar que ele processe qualquer volume de tráfego.
É necessário observar:
- conexões simultâneas;
- requests por segundo;
- tráfego em Mbps/Gbps;
- TLS;
- número de backends;
- keepalive;
- logs;
- compressão;
- regras de firewall;
- processamento adicional.
Monitorando o load balancer
Monitoramento é fundamental.
Algumas métricas importantes:
CPU
Verifique:
topou:
htopMemória
free -hConexões
ss -sTambém:
ss -antTráfego
ip -s linkCarga
uptimeou:
cat /proc/loadavgMétricas importantes dos backends
Não monitore apenas o balanceador.
É necessário acompanhar também:
LB
|
+-- Web01
+-- Web02
+-- Web03Para cada servidor:
- CPU;
- RAM;
- load average;
- disco;
- latência;
- conexões;
- erros HTTP;
- PHP-FPM;
- banco;
- processos;
- rede.
Um balanceador pode estar perfeitamente saudável enquanto todos os backends estão saturados.
Monitorando HTTP
Uma verificação simples:
curl -I https://app.exemplo.comPara testar um backend diretamente:
curl -I http://10.0.0.11E:
curl -I http://10.0.0.12Isso ajuda a diferenciar problemas do balanceador de problemas dos servidores web.
Testando failover
Uma das melhores formas de validar uma arquitetura é testar a falha.
Imagine:
Web01 → OK
Web02 → OKPare o serviço do Web01.
Depois teste:
curl -I https://app.exemplo.comO balanceador deve continuar encaminhando as requisições para o Web02.
Depois restaure o Web01.
Esse tipo de teste deve fazer parte de uma rotina controlada de validação.
Problemas comuns
502 Bad Gateway
Pode indicar problemas entre o balanceador e o backend.
Verifique:
curl http://10.0.0.11Depois:
curl http://10.0.0.12Também confira:
- firewall;
- porta;
- serviço web;
- timeout;
- DNS interno;
- rota;
- aplicação.
503 Service Unavailable
Pode ocorrer quando nenhum backend saudável está disponível.
Exemplo:
LB
|
+-- Web01 OFF
|
+-- Web02 OFFNesse cenário, o balanceador não possui para onde encaminhar a requisição.
504 Gateway Timeout
Normalmente está relacionado a timeout entre o proxy e o backend.
Investigue:
Cliente
|
v
LB
|
X---- Web01 demoraPossíveis causas:
- aplicação lenta;
- PHP-FPM saturado;
- banco lento;
- I/O elevado;
- rede;
- timeout mal configurado.
Como evitar um único ponto de falha
Existe uma armadilha importante.
Imagine:
Internet
|
v
LB
/ \
Web01 Web02Se o único LB cair, toda a aplicação pode ficar indisponível.
Portanto:
LB únicopode ser um SPOF — Single Point of Failure.
Uma arquitetura mais robusta pode utilizar dois balanceadores:
Internet
|
+-----+-----+
| |
LB01 LB02
| |
+-----+-----+
|
+--------+--------+
| |
Web01 Web02
O mecanismo de failover pode variar de acordo com a infraestrutura.
Load balancer e firewall
Os backends não deveriam necessariamente aceitar conexões HTTP de qualquer origem.
Uma arquitetura mais segura é:
Internet
|
v
Load Balancer
|
v
Firewall
|
+-- Web01
+-- Web02Os servidores web podem aceitar tráfego somente do endereço ou da rede do balanceador.
Isso reduz a superfície de exposição.
Exemplo de arquitetura de produção
Uma arquitetura mais completa poderia ser:
Internet
|
v
+---------------+
| Load Balancer |
+-------+-------+
|
+-----------+-----------+
| |
v v
+-----------+ +-----------+
| Web01 | | Web02 |
+-----+-----+ +-----+-----+
| |
+-----------+-----------+
|
v
Redis
|
v
Database
Podemos adicionar:
CDN
|
v
Load Balancer
|
+---------+---------+
| | |
Web01 Web02 Web03
Essa arquitetura oferece mais possibilidades de crescimento.
Quando utilizar load balancer?
O balanceamento de carga começa a fazer sentido quando existem necessidades como:
- múltiplos servidores web;
- alto volume de tráfego;
- necessidade de failover;
- alta disponibilidade;
- escalabilidade horizontal;
- manutenção sem indisponibilidade;
- distribuição geográfica;
- múltiplas instâncias da aplicação.
Não é necessário implementar um balanceador simplesmente porque ele é tecnicamente possível.
Para um site pequeno em uma única VPS, por exemplo, a complexidade adicional pode não trazer benefício proporcional.
Load balancer para WordPress
WordPress também pode utilizar essa arquitetura.
Exemplo:
Load Balancer
/ \
/ \
WordPress01 WordPress02
\ /
\ /
Database
Porém, é necessário resolver:
- uploads;
- sessões;
- cache;
- cron;
- banco;
- arquivos compartilhados;
- plugins que dependem de armazenamento local.
Uma arquitetura WordPress distribuída precisa ser pensada como um sistema, e não simplesmente como duas cópias do mesmo servidor.
Load balancer + cache
Uma arquitetura eficiente pode combinar:
Cliente
|
v
CDN / Cache
|
v
Load Balancer
|
+---+---+
| |
Web01 Web02Quanto mais requisições forem atendidas por cache, menor será a carga nos servidores de aplicação.
Isso pode reduzir:
- CPU;
- PHP-FPM;
- consultas ao banco;
- I/O;
- latência.
Boas práticas
Ao implementar um load balancer, considere:
1. Utilize health checks
Não envie tráfego para servidores indisponíveis.
2. Monitore os backends
O balanceador não substitui monitoramento.
3. Planeje sessões
Evite depender de armazenamento local quando houver múltiplos servidores.
4. Planeje arquivos
Uploads e arquivos persistentes precisam de uma estratégia distribuída.
5. Configure timeouts
Evite valores arbitrariamente altos ou baixos.
6. Proteja os backends
Permita acesso apenas das origens necessárias.
7. Monitore erros HTTP
Acompanhe:
2xx
3xx
4xx
5xx8. Teste falhas
Simule indisponibilidade dos servidores.
9. Planeje o próprio balanceador
Um único LB pode se tornar um ponto único de falha.
10. Documente a arquitetura
Tenha registrado:
- IPs;
- portas;
- backends;
- health checks;
- certificados;
- DNS;
- firewall;
- timeouts;
- procedimentos de failover.
Conclusão
Um load balancer é muito mais do que um mecanismo para dividir requisições entre servidores. Ele pode ser utilizado como uma camada central para distribuição de tráfego, health checks, failover, TLS, controle de conexões e escalabilidade.
Em ambientes com VPS, servidores dedicados ou cloud, uma arquitetura baseada em múltiplos servidores permite evoluir de um modelo vertical para uma infraestrutura horizontal.
Entretanto, adicionar servidores não resolve automaticamente todos os problemas. Sessões, uploads, banco de dados, cache, Redis, armazenamento e monitoramento precisam ser planejados para que a aplicação realmente funcione de forma distribuída.
Uma arquitetura prática pode começar simples:
Internet
|
Load Balancer
|
+-- Web01
+-- Web02e evoluir posteriormente para:
CDN
|
Load Balancers
/ \
LB01 LB02
\ /
\ /
Web Cluster
/ | \
Web01 Web02 Web03
\ | /
Redis
|
Database
O objetivo não é simplesmente adicionar complexidade, mas construir uma infraestrutura capaz de distribuir carga, detectar falhas e crescer conforme a demanda.
FAQ — Load Balancer
Um load balancer é um componente que recebe requisições e distribui o tráfego entre múltiplos servidores backend.
Um reverse proxy intermedia as conexões entre clientes e servidores. Um load balancer pode utilizar essa função para distribuir as requisições entre vários backends.
Sim. O Nginx pode atuar como reverse proxy e distribuir requisições entre múltiplos servidores utilizando recursos como upstream, round robin e least_conn.
Sim. O HAProxy é uma solução amplamente utilizada para proxy e balanceamento de tráfego TCP e HTTP.
Ele pode melhorar a capacidade de atendimento ao distribuir as requisições entre vários servidores. Porém, o resultado depende da arquitetura completa e da capacidade dos backends.
Pode aumentar a disponibilidade ao detectar servidores indisponíveis e encaminhar novas requisições para backends saudáveis. O próprio balanceador também precisa ser projetado para evitar ponto único de falha.
Sim. É possível utilizar uma VPS como balanceador e outras VPS como servidores backend.
Sim, mas é necessário planejar corretamente arquivos, uploads, sessões, cache, cron e banco de dados.
Depende do nível de disponibilidade desejado. Um único balanceador pode se tornar um ponto único de falha.
Não. São componentes com funções diferentes. Uma CDN pode armazenar e distribuir conteúdo próximo dos usuários, enquanto o balanceador distribui conexões entre backends.
Veja Também:
Como Otimizar VPS, Servidor Dedicado ou Cloud: Guia Completo
VPS vs Servidor Dedicado em 2026 (Guia Técnico)
Definitivo: Como Dominar o Comando Sar Linux para Monitoramento
Diagnóstico de VPS Lento: Checklist Completo e Definitivo
Servidor Dedicado Lento? 15 Causas e Soluções Definitivas (2026)
Como Otimizar o Uso de CPU em uma VPS Linux: Guia Definitivo
Servidor dedicado lento? 10 causas comuns e como resolver