Proxy reverso: quando colocar um na frente da aplicação e quando não colocar

Autor: Pedro Tebaldi PM do KeepGreen

Publicado set/2026

A aplicação sobe em dois containers, cada um querendo escutar a porta 443, que o sistema operacional entrega ao primeiro que chegou. Duas semanas depois entra um terceiro serviço, depois um subdomínio novo, depois um certificado que precisa ser renovado em quatro lugares diferentes. Nesse ponto alguém sugere um proxy reverso na frente de tudo.

A sugestão quase sempre está certa, embora a conversa raramente chegue à outra metade: o proxy resolve quatro problemas conhecidos enquanto cria três novos. Todos ficam silenciosos até o dia em que a aplicação devolve 502 sem que nenhum backend tenha caído.

Este texto trata da decisão de arquitetura, não do passo a passo de instalação. Aqui estão os sintomas que justificam a camada extra e as situações em que ela só adiciona um ponto de falha. Depois vem a fronteira entre proxy reverso, load balancer, API gateway e WAF, além do que a operação passa a ser obrigada a medir.

Os quatro sintomas que colocam um proxy reverso na mesa

Nenhum time adota um proxy reverso por elegância de arquitetura: adota porque bateu em uma destas quatro paredes.

Vários serviços disputando uma porta é o sintoma mais comum, porque o sistema operacional deixa apenas um processo escutar a 443 de cada endereço. A segunda aplicação em HTTPS na mesma máquina obriga alguém a decidir quem fica com ela.

Certificado espalhado vem logo em seguida, porque cada aplicação com par de chaves próprio carrega sua própria data de expiração. Com quatro serviços publicados, são quatro relógios correndo em paralelo, cada um com seu jeito de falhar.

Backend exposto é o terceiro sintoma: sem intermediário, o endereço interno aparece em redirecionamento, cabeçalho de erro e log de cliente. A topologia interna vaza sem que ninguém tenha decidido publicá-la, o que estreita as opções de quem precisar mudar um endereço depois.

Escala além de uma instância fecha a lista, já que duas máquinas rodando a mesma aplicação exigem alguém para distribuir a requisição entre elas. Esse alguém também precisa tirar a instância doente da rotação e devolvê-la quando ela voltar a responder.

O que é um proxy reverso e onde ele fica na arquitetura

Um proxy reverso é o servidor que recebe as requisições em nome da aplicação, escolhe qual serviço interno atende cada uma e devolve a resposta. Do lado de fora existe um endereço público só, enquanto do lado de dentro ficam quantos backends forem necessários, invisíveis para o cliente.

Toda a diferença para o proxy tradicional está em quem cada um representa. O proxy direto trabalha para o cliente, escondendo quem faz a requisição do servidor de destino. Já o reverso trabalha para o servidor, escondendo a infraestrutura de quem pede: mesma mecânica de intermediação, lados opostos da conversa.

Quando vale a pena colocar um proxy reverso na frente da aplicação

Cada cenário abaixo vem com o sintoma que o antecede, porque sem o sintoma o cenário não é argumento, apenas lista de recursos.

Terminação de TLS centralizada em um único ponto de borda

Com 90,0% dos sites já usando HTTPS como protocolo padrão, segundo o levantamento de setembro de 2026 da W3Techs, o certificado virou requisito.

Concentrar a terminação em um ponto só transforma quatro renovações anuais em uma. A borda também vira o lugar onde a equipe pode adotar versões mais novas do protocolo sem tocar no código da aplicação.

Encerrar a criptografia na borda deixa o tráfego interno seguir em texto claro dentro de uma rede controlada. Quando a política exigir identidade dos dois lados, ele sobe para autenticação mútua entre borda e backend, decisão que passa a ter um lugar único.

Vários backends respondendo por trás de um único hostname público

Quando a aplicação cresce em serviços, cada um passa a responder por um caminho diferente da mesma URL. O proxy lê o caminho ou o cabeçalho Host e roteia: /api para um lugar, /admin para outro, o restante para o front.

Sem essa camada, a alternativa é publicar porta alta ou subdomínio para cada serviço.

Em ambiente containerizado o argumento fica mais forte, já que os endereços internos mudam a cada deploy. O ingress de um cluster é um proxy reverso com descoberta automática. Por isso quem opera clusters Kubernetes em produção não discute se vai ter um: discute qual.

Distribuição de carga entre várias instâncias iguais da mesma aplicação

Duas instâncias da mesma aplicação já obrigam alguém a escolher para qual delas cada requisição vai. O proxy resolve isso com verificação de saúde: a instância que falha o health check sai da rotação e volta assim que responde de novo.

Cache e compressão de conteúdo estático servido na borda da aplicação

Conteúdo estático servido pela própria aplicação consome processo de aplicação, que é o recurso mais caro da pilha. Mover esses arquivos para o proxy tira a carga do backend e reduz o tempo de resposta percebido, sem alterar uma linha de código.

Compensa principalmente quando o mesmo arquivo é pedido milhares de vezes por hora.

Os quatro casos em que o proxy reverso não compensa

Poucos artigos sobre o tema escrevem esta seção, embora ela decida mais casos do que a anterior. Um proxy reverso é infraestrutura: infraestrutura sem dono custa mais do que resolve.

Plataforma que já termina TLS por você torna o proxy próprio um salto extra. Aplicação única publicada em PaaS, App Service ou container gerenciado costuma receber certificado, roteamento e distribuição da própria plataforma. Colocar um proxy seu na frente disso adiciona um salto que ninguém pediu.

Serviço único, tráfego baixo, sem previsão de crescer é o segundo caso. Com uma aplicação, um hostname e um certificado, o proxy apenas duplica o número de componentes que precisam estar de pé.

Ninguém para operar a camada nova é o motivo que mais aparece na prática. Um proxy reverso tem arquivo de configuração, ciclo de renovação de certificado, política de timeout e comportamento próprio sob carga. Sem alguém responsável por isso, a camada vira caixa-preta na primeira madrugada de incidente.

Segurança de aplicação como objetivo real pede outra ferramenta, não esta. Esconder o backend dificulta o reconhecimento, porém não inspeciona conteúdo de requisição. Quem precisa bloquear injeção de SQL ou abuso de formulário está procurando o componente da próxima seção.

Proxy reverso, load balancer, API gateway e WAF: onde cada um decide

Todos os quatro ocupam a mesma posição da arquitetura, na frente da aplicação, o que explica a confusão. Eles não competem entre si: descrevem responsabilidades diferentes que muitas vezes rodam no mesmo processo.

Em uma linha: o proxy reverso descreve a posição, enquanto o balanceamento descreve a escolha do alvo. O gateway acrescenta política de consumo por identidade; o WAF acrescenta inspeção de conteúdo. Um mesmo Nginx pode exercer os quatro papéis, razão pela qual a pergunta certa nunca é qual deles instalar.

Vale perguntar, em vez disso, qual responsabilidade a sua equipe vai operar. Cada uma tem métrica própria, dono próprio e modo de falha próprio.

As métricas que um balanceador precisa expor pouco se parecem com as que interessam na inspeção de requisição na camada de aplicação. Isso continua valendo mesmo quando o binário que faz as duas coisas é o mesmo.

O que o proxy custa: latência, ponto único e o 502 que não é do backend

Toda camada intermediária cobra pedágio, com valor pequeno em condições normais. Justamente por isso ela engana: o problema aparece nas bordas, quando a configuração padrão encontra um backend que se comporta diferente do previsto.

Um salto a mais no caminho de cada requisição do usuário

Cada requisição ganha uma conexão a mais, um parse de requisição e um parse de resposta, que em rede local somam poucos milissegundos.

Para a maioria das aplicações esse número é irrelevante, porém ele passa a importar quando a operação já disputa orçamento de latência em aplicações críticas. Também importa quando o proxy roda em uma região diferente do backend.

Um componente novo que também precisa estar sempre de pé

Antes do proxy, a aplicação caía quando a aplicação caía. Depois dele, o serviço cai quando o proxy cai, quando alguém recarrega a configuração com erro de sintaxe ou quando o certificado da borda expira.

Proxy sem par redundante troca vários pontos de falha independentes por um ponto de falha compartilhado. Isso contraria a própria ideia de arquitetura de alta disponibilidade, que existe para remover pontos únicos.

Os erros 502 e 504 que o proxy inventa sozinho

Nesta lista, a armadilha mais cara vem da configuração padrão.

Segundo a documentação oficial do Nginx, as diretivas proxy_connect_timeout, proxy_read_timeout e proxy_send_timeout valem 60 segundos cada uma por padrão.

Relatório pesado ou importação de arquivo que passe de 60 segundos no backend, o proxy corta e devolve como 504 Gateway Timeout. O backend continua processando sem erro nenhum no log da aplicação, enquanto o cliente já recebeu a falha.

Buffers seguem a mesma lógica: por padrão somam oito blocos de 4k ou 8k conforme a plataforma. Cabeçalho de resposta maior que isso, típico de sessão com muitos cookies ou token longo, produz 502 Bad Gateway com o backend íntegro.

# rota de relatorio: excecao explicita ao default de 60s
location /relatorios/ {
    proxy_pass         http://app_backend;
    proxy_read_timeout 300s;
    proxy_send_timeout 300s;
    # cabecalho grande de sessao nao pode virar 502
    proxy_buffer_size  16k;
    proxy_buffers      8 16k;
}

Decorar valores não é a lição: ela está em reconhecer que o proxy passou a ter opinião sobre o que é uma resposta aceitável. Quem escreveu essa opinião empacotou o software, sem conhecer a sua aplicação.

O que passa a ser obrigatório monitorar depois que o proxy entra

Depois que o proxy entra, a frase “a aplicação está lenta” perde sentido, porque agora existem dois lugares onde ela pode estar lenta. Enquanto a operação medir só o resultado final, a equipe segue reiniciando serviço por tentativa. Cinco medidas separam as camadas antes que a suposição vire madrugada perdida.

Código de status na borda contra código no backend são séries diferentes que precisam de coleta separada. Divergência entre elas é o sinal mais rápido de que o problema mora no proxy. Backend registrando 200 enquanto a borda registra 504 significa timeout, não falha de aplicação.

Tempo de upstream contra tempo total mede o custo real da camada. O tempo total inclui o processamento do proxy, enquanto o tempo de upstream mede apenas a espera pelo backend. A diferença entre os dois só aparece quando as duas séries convivem no mesmo painel.

Saturação de worker e de conexão avisa bem antes de qualquer erro aparecer. Todo proxy tem teto de conexões simultâneas e de processos de trabalho, de modo que a fila cresce assim que esse teto encosta. O usuário sente lentidão enquanto todos os gráficos de aplicação seguem verdes.

Validade do certificado da borda passou a concentrar todo o risco de expiração. A centralização que simplificou a renovação também juntou tudo em um ponto: o certificado que vencer agora derruba tudo o que está atrás dele.

Alerta com semanas de antecedência deixou de ser zelo, conforme mostra a disciplina de acompanhamento de validade de certificados.

Taxa de erro por upstream, não só agregada, evita que a média esconda a instância doente. Com vários backends atrás do mesmo endereço, uma instância doente entre quatro aparece como um quarto das requisições falhando naquele upstream. No gráfico consolidado, ela vira apenas sujeira.

Na operação do Instituto Butantan, a plataforma de gestão de documentos sofria quedas sem causa visível, com espera de 3 a 5 minutos por operação. A resposta padrão era reiniciar o serviço ou aumentar hardware.

Só quando passamos a medir consumo por processo, capturar a query exata no banco e correlacionar traces é que a causa apareceu. O raciocínio vale aqui: com mais de uma camada no caminho, medir o agregado é escolher não saber. O relato completo está no case de observabilidade do Instituto Butantan.

Em vídeo, a equipe da OpServices mostra como instrumentar uma aplicação sem tocar no código, que é exatamente o que a posição de borda oferece.

Como escolher a ferramenta de borda

Boa parte dessa escolha o mercado já fez, segundo o levantamento de servidores web da W3Techs de setembro de 2026. O Nginx aparece em 31,3% dos sites, o Cloudflare Server em 30,1%, o Apache em 22,4% e o LiteSpeed em 14,6%.

Grande parte desse uso corresponde justamente a posição de borda.

Nginx é o padrão de fato para publicação de aplicação web, com a maior base de exemplos e de gente experiente. Vira a escolha de menor risco quando o requisito é rotear caminho, terminar TLS e servir estático.

Quem opera precisa depois cuidar das métricas que o servidor expõe em produção, sob pena de ficar cego na camada que acabou de criar.

HAProxy nasceu para balanceamento e continua sendo a referência quando o requisito é distribuir carga com verificação de saúde sofisticada e observabilidade nativa de fila.

Traefik resolve o caso containerizado, porque descobre serviço por label do orquestrador em vez de arquivo estático. Faz sentido quando os endereços internos mudam a cada deploy.

Caddy entrega HTTPS automático com configuração mínima, o que encurta caminho em ambiente pequeno. Envoy só se paga em malha de serviços, onde a política de tráfego é distribuída e o proxy vira parte do plano de dados.

Escolha pela responsabilidade principal que a equipe vai operar, nunca pela lista de recursos. Ferramenta que faz tudo acaba obrigando alguém do time a saber tudo.

A decisão, resumida em uma pergunta que você pode responder hoje

Vale a camada quando mais de um serviço, mais de uma instância ou mais de um certificado disputam a mesma porta pública.

Fora disso, ele é apenas um componente a mais entre o usuário e a resposta, com configuração própria para manter. Esse componente traz um modo de falha novo, que alguém terá de diagnosticar de madrugada.

Resta uma pergunta, que resolve a maioria dos casos: quantas coisas diferentes precisam responder pelo mesmo endereço? Se a resposta for uma, o proxy pode esperar mais um trimestre. Duas ou mais, ele já deveria estar lá, com par redundante e com as cinco métricas da seção anterior configuradas antes do primeiro deploy.

Quem já tem o proxy no ar sem separar o status da borda do status do backend opera às cegas em metade do caminho. Para discutir como instrumentar essa camada sem reescrever a aplicação, converse com um especialista da OpServices.