Reverse Proxy vs Load Balancer: Quando Usar Cada um com Nginx

Você provavelmente já ouviu os termos "reverse proxy" e "load balancer" sendo usados de forma intercambiável. Mas quando você está configurando o Nginx, saber a diferença importa—isso afeta como você arquiteta sua infraestrutura, lida com SSL e escala sua aplicação.

Este guia elimina a confusão. Você aprenderá o que cada um faz, quando usar um em vez do outro e como configurá-los no Nginx com exemplos claros e práticos.

O que é um Reverse Proxy?

Um reverse proxy fica entre os clientes e seus servidores backend. Ele recebe as requisições dos clientes, encaminha para o backend apropriado e retorna a resposta. O cliente nunca fala diretamente com seu backend.

Usos comuns:

• Terminação SSL: Lidar com HTTPS no proxy, para que os backends lidem apenas com HTTP.
• Cache: Armazenar assets estáticos ou respostas de API para reduzir a carga do backend.
• Segurança: Ocultar detalhes do backend, filtrar requisições e mitigar DDoS.
• Compressão: Respostas Gzip ou Brotli antes de enviar aos clientes.

O Nginx é frequentemente usado como reverse proxy na frente de servidores de aplicação como Node.js, Python (Gunicorn/uWSGI) ou Java (Tomcat).

O que é um Load Balancer?

Um load balancer distribui o tráfego de entrada entre vários servidores backend. Seu objetivo principal é melhorar a disponibilidade, escalabilidade e tolerância a falhas.

Principais recursos:

• Distribuição de tráfego: Espalhar requisições usando algoritmos como round-robin, least connections ou IP hash.
• Health checks: Parar automaticamente de enviar tráfego para servidores não saudáveis.
• Persistência de sessão: Manter um usuário no mesmo backend quando necessário.

Load balancers podem ser de hardware (F5, Citrix) ou software (Nginx, HAProxy, LB de nuvem). O módulo upstream do Nginx o torna um load balancer de software capaz.

Reverse Proxy vs Load Balancer: Principais Diferenças

Na prática, um load balancer é um reverse proxy especializado. Muitas ferramentas, incluindo o Nginx, podem fazer ambos simultaneamente.

Quando Usar um Reverse Proxy

Use um reverse proxy quando você precisar:

• Servir um único servidor backend, mas quiser SSL, cache ou compressão.
• Hospedar várias aplicações em caminhos ou subdomínios diferentes atrás de um IP.
• Adicionar uma camada extra de segurança ao não expor seu backend diretamente.

Exemplo: Uma API Node.js rodando na porta 3000, com o Nginx lidando com HTTPS e servindo arquivos estáticos.

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate /etc/nginx/ssl/api.example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/api.example.com.key;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Quando Usar um Load Balancer

Use um load balancer quando você tiver:

• Vários servidores backend para lidar com alto tráfego.
• Necessidade de alta disponibilidade—se um servidor falhar, outros assumem.
• Implantações graduais (rolling deployments) ou blue-green.

Exemplo: Três instâncias Node.js atrás do Nginx usando round-robin.

upstream backend {
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    server 10.0.0.3:3000;
}

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

O Nginx distribuirá as requisições uniformemente. Você pode adicionar health checks e outros parâmetros para ajustar o comportamento.

Combinando Ambos os Papéis no Nginx

A maioria das configurações do mundo real usa o Nginx como reverse proxy e load balancer. Por exemplo:

upstream app_servers {
    least_conn;
    server 10.0.0.1:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.2:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.3:3000 backup;
}

server {
    listen 443 ssl;
    server_name app.example.com;

    ssl_certificate /etc/nginx/ssl/app.example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/app.example.com.key;

    location /static/ {
        root /var/www/static;
        expires 30d;
    }

    location / {
        proxy_pass http://app_servers;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Aqui, o Nginx termina o SSL, serve arquivos estáticos e faz balanceamento de carga entre três servidores de aplicação com health checks.

Boas Práticas para Nginx como Reverse Proxy / Load Balancer

• Defina cabeçalhos adequados: Sempre passe Host, X-Real-IP e X-Forwarded-For para que seu backend saiba qual é o cliente original.
• Habilite HTTP/2: Adicione http2 à sua diretiva listen para melhor desempenho.
• Ajuste buffers e timeouts: Ajuste proxy_buffer_size, proxy_read_timeout com base no comportamento da sua aplicação.
• Use health checks: O Nginx Open Source tem verificações passivas; o Nginx Plus oferece verificações ativas.
• Faça logs com sabedoria: Use um formato de log personalizado para capturar tempos de resposta do upstream para depuração.

Analisar os logs do Nginx é crucial para identificar gargalos. Ferramentas como o Nginx Log Analyzer podem ajudar você a analisar logs de acesso e identificar upstreams lentos ou erros rapidamente.

FAQ

O Nginx pode ser tanto um reverse proxy quanto um load balancer?

Sim. O Nginx pode terminar SSL, fazer cache de conteúdo e distribuir requisições entre vários backends simultaneamente. O bloco upstream define o pool de backends, enquanto a diretiva proxy_pass encaminha as requisições.

Preciso de um load balancer se eu tiver apenas um servidor backend?

Não necessariamente. Um reverse proxy sozinho pode lidar com SSL, cache e segurança. Mas adicionar um load balancer com vários backends melhora a disponibilidade—se um servidor falhar, outros podem atender o tráfego.

Como o Nginx escolhe para qual backend enviar uma requisição?

Por padrão, o Nginx usa round-robin. Você pode mudar isso com diretivas como least_conn (menos conexões), ip_hash (sessões fixas baseadas no IP do cliente) ou hash (chave personalizada).

Pronto para otimizar sua configuração do Nginx? Comece analisando seus logs com nosso analisador de logs Nginx gratuito para descobrir problemas de desempenho e ajustar sua configuração.