Reverse proxy

Um reverse proxy é um servidor que fica na frente de um ou mais servidores web, interceptando as requisições dos clientes e encaminhando-as para o servidor backend apropriado, e depois devolvendo a resposta do servidor ao cliente como se ela tivesse origem no próprio proxy. Ele age como intermediário, apresentando uma interface unificada aos clientes externos enquanto gerencia os recursos internos dos servidores.

O que é um reverse proxy?

Um reverse proxy opera na borda da rede, entre os clientes e os servidores de origem. Quando um cliente faz uma requisição por um recurso, a requisição é primeiro direcionada ao reverse proxy. O reverse proxy então decide qual servidor backend deve atender a requisição, encaminha a requisição para esse servidor, recebe a resposta e a repassa ao cliente. Esse processo é transparente para o cliente, que percebe a resposta como vinda diretamente do reverse proxy.

Essa arquitetura contrasta com a de um forward proxy, que fica na frente dos clientes e encaminha as requisições deles para servidores externos na internet. Um forward proxy protege o anonimato do cliente e filtra o tráfego de saída, enquanto um reverse proxy protege e otimiza os servidores backend.

Por que você precisa de um reverse proxy

Implementar um reverse proxy traz várias vantagens para aplicações e serviços web, principalmente em segurança, desempenho e confiabilidade.

Segurança reforçada

Um reverse proxy funciona como uma camada de segurança crítica para a infraestrutura backend.
* Abstração: ele oculta os endereços IP e as características dos servidores de origem. Os clientes se comunicam apenas com o reverse proxy, o que evita a exposição direta dos detalhes dos servidores backend.
* Mitigação de ataques: reverse proxies podem filtrar tráfego malicioso, identificar e bloquear padrões comuns de ataque (por exemplo, SQL injection, cross-site scripting) e absorver grandes volumes de requisições durante um ataque de negação de serviço distribuída (DDoS), protegendo os servidores backend contra sobrecarga.
* Políticas de segurança centralizadas: políticas de segurança, como regras de Web Application Firewall (WAF) ou controles de acesso, podem ser aplicadas de forma uniforme no nível do reverse proxy para todas as aplicações backend.

Balanceamento de carga

Para aplicações que exigem alta disponibilidade e escalabilidade, o balanceamento de carga é essencial.
* Distribuição de tráfego: um reverse proxy distribui as requisições recebidas entre vários servidores backend. Isso evita que um único servidor vire gargalo e garante o uso ideal dos recursos.
* Alta disponibilidade: se um servidor backend falhar ou parar de responder, o reverse proxy detecta o problema e roteia automaticamente o tráfego para servidores saudáveis, mantendo a continuidade do serviço.
* Algoritmos de balanceamento de carga: vários algoritmos podem ser usados, entre eles:
* Round Robin: distribui as requisições sequencialmente para cada servidor.
* Least Connections: roteia as requisições para o servidor com menos conexões ativas.
* IP Hash: direciona as requisições de um mesmo IP de cliente sempre para o mesmo servidor backend, útil para manter a persistência de sessão.

Cache

Reverse proxies podem melhorar bastante o desempenho da aplicação por meio de cache.
* Menos carga nos servidores de origem: conteúdo estático (por exemplo, imagens, arquivos CSS, JavaScript) e conteúdo dinâmico acessado com frequência podem ser armazenados no cache do reverse proxy. As requisições seguintes por esse conteúdo são atendidas diretamente pelo cache, reduzindo a carga nos servidores backend.
* Tempos de resposta menores: ao servir conteúdo de um cache geograficamente mais próximo ou prontamente disponível, os reverse proxies reduzem a latência e melhoram a velocidade percebida pelos clientes.

Terminação SSL/TLS

Lidar com comunicação criptografada pode consumir muita CPU dos servidores backend.
* Descarregamento da criptografia: um reverse proxy pode terminar as conexões SSL/TLS dos clientes. Ele descriptografa as requisições recebidas, encaminha-as (sem criptografia ou recriptografadas) aos servidores backend e criptografa as respostas antes de enviá-las de volta aos clientes.
* Ganho de desempenho: transferir as operações criptográficas para o reverse proxy libera recursos dos servidores backend, permitindo que eles se concentrem na lógica da aplicação.
* Gerenciamento centralizado de certificados: todos os certificados SSL/TLS podem ser gerenciados em um único ponto, simplificando a renovação e a implantação.

Compressão

Otimizar o tamanho dos dados transferidos é fundamental para o desempenho.
* Economia de banda: reverse proxies podem comprimir as respostas do servidor (por exemplo, usando Gzip ou Brotli) antes de enviá-las aos clientes. Isso reduz o volume de dados trafegados na rede, economiza banda e acelera o carregamento das páginas, especialmente para clientes em conexões mais lentas.

Reescrita de URL e testes A/B

Reverse proxies oferecem flexibilidade no gerenciamento do roteamento de requisições.
* Regras de roteamento flexíveis: eles podem reescrever URLs, modificar cabeçalhos ou direcionar requisições específicas para diferentes serviços backend com base em regras definidas (por exemplo, caminho da URL, cabeçalhos HTTP, cookies). Isso facilita arquiteturas de microsserviços e funcionalidades de API gateway.
* Testes A/B: ao rotear uma porcentagem dos usuários ou segmentos específicos para uma versão diferente da aplicação (por exemplo, o deploy de um novo recurso), os reverse proxies viabilizam testes A/B sem exigir mudanças no lado do cliente nem alterações de DNS.

Logging e monitoramento centralizados

Todas as requisições dos clientes passam pelo reverse proxy, o que cria um ponto único de coleta de dados.
* Fonte de dados unificada: logs de requisições, padrões de acesso e métricas de desempenho podem ser coletados e analisados centralmente no reverse proxy. Isso simplifica o monitoramento, o diagnóstico de problemas e a auditoria de segurança de vários serviços backend.

Como funciona um reverse proxy

O fluxo operacional de um reverse proxy envolve várias etapas:
1. Requisição do cliente: o cliente envia uma requisição HTTP/S para o nome de domínio associado ao reverse proxy.
2. Recepção da requisição: o reverse proxy recebe a requisição.
3. Aplicação de políticas: o reverse proxy aplica as regras configuradas, que podem incluir:
* Verificações de segurança (WAF, rate limiting).
* Consulta ao cache (se o conteúdo estiver em cache, é servido diretamente).
* Terminação SSL/TLS (quando aplicável).
* Aplicação do algoritmo de balanceamento de carga para escolher um servidor backend.
4. Encaminhamento da requisição: o reverse proxy encaminha a requisição ao servidor backend escolhido. Ele pode modificar cabeçalhos (por exemplo, X-Forwarded-For, para preservar o IP original do cliente).
5. Processamento no backend: o servidor backend processa a requisição e gera uma resposta.
6. Recepção da resposta: o reverse proxy recebe a resposta do servidor backend.
7. Modificação da resposta: o reverse proxy pode aplicar outras modificações, como compressão, antes de enviar a resposta ao cliente.
8. Resposta ao cliente: o reverse proxy envia a resposta final ao cliente, aparecendo como se fosse o servidor de origem.

Reverse proxy vs. forward proxy

Embora os dois tipos de proxy atuem como intermediários, seu propósito e sua posição são bem diferentes.

Softwares comuns de reverse proxy

Várias soluções de software robustas são amplamente usadas para implementar reverse proxies:
* Nginx: servidor web de alto desempenho, também reconhecido por seus recursos de reverse proxy, balanceador de carga e cache HTTP.
* Apache HTTP Server: com módulos como mod_proxy, o Apache pode funcionar como reverse proxy, embora o Nginx costume ser preferido para proxying de alto tráfego.
* HAProxy: projetado especificamente para balanceamento de carga de alta disponibilidade e proxying de aplicações baseadas em TCP e HTTP.
* Envoy Proxy: proxy de borda e de serviço open source, projetado para aplicações cloud-native e muito usado em arquiteturas de service mesh.
* Cloudflare: uma Content Delivery Network (CDN) popular que também funciona como serviço global de reverse proxy, oferecendo recursos de segurança, desempenho e confiabilidade.

Exemplo de configuração de reverse proxy no Nginx

Uma configuração básica do Nginx como reverse proxy distribuindo requisições para dois servidores backend (por exemplo, backend1.example.com e backend2.example.com):

http {
    # Define um grupo de servidores backend para balanceamento de carga
    upstream backend_servers {
        # Definições dos servidores backend. O Nginx usa round-robin por padrão.
        server backend1.example.com;
        server backend2.example.com;
        # server 192.168.1.100:8080; # Também é possível usar IP:porta
    }

    server {
        listen 80; # Escuta requisições HTTP na porta 80
        server_name yourdomain.com www.yourdomain.com; # Seu nome de domínio

        # Define como tratar requisições para a raiz e subcaminhos
        location / {
            # Encaminha a requisição para o grupo upstream definido acima
            proxy_pass http://backend_servers;

            # Preserva o cabeçalho Host original do cliente
            proxy_set_header Host $host;
            # Preserva o endereço IP original do cliente
            proxy_set_header X-Real-IP $remote_addr;
            # Anexa o IP do cliente ao cabeçalho X-Forwarded-For
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            # Preserva o protocolo original (HTTP ou HTTPS)
            proxy_set_header X-Forwarded-Proto $scheme;

            # Opcional: configurações de timeout
            proxy_connect_timeout 60s;
            proxy_send_timeout 60s;
            proxy_read_timeout 60s;
        }

        # Exemplo para HTTPS (terminação SSL no proxy)
        # listen 443 ssl;
        # ssl_certificate /etc/nginx/ssl/yourdomain.com.crt;
        # ssl_certificate_key /etc/nginx/ssl/yourdomain.com.key;
        # ... outras configurações de SSL ...
        # location / {
        #     proxy_pass http://backend_servers; # O tráfego até o backend pode ser HTTP
        #     ... cabeçalhos ...
        # }
    }
}