O que é um proxy reverso? Um guia prático de DNS e web

Um proxy reverso é um servidor que recebe requisições em nome de um ou mais servidores de backend e as encaminha ao destino apropriado. Do ponto de vista do visitante, o proxy costuma ser o endpoint público; o navegador não se conecta diretamente ao servidor da aplicação. Um proxy reverso pode encerrar o HTTPS, rotear requisições por nome de host ou caminho, balancear o tráfego, guardar respostas em cache, comprimir conteúdo e aplicar controles de segurança. O DNS normalmente aponta um nome de host público para o proxy ou para um endereço gerenciado por um provedor à frente dele. O proxy então usa sua própria configuração de roteamento para alcançar a aplicação upstream.

Proxy reverso versus proxy direto

Um proxy direto (forward proxy) atua em nome dos clientes: o cliente envia requisições por meio dele para alcançar serviços externos, muitas vezes por motivos de política, privacidade ou acesso à rede. Um proxy reverso atua em nome dos servidores: clientes externos se conectam a ele, e ele encaminha as requisições aos serviços de backend. A palavra “proxy”, sozinha, é portanto ambígua. Na arquitetura de um site, um proxy reverso normalmente apresenta o endpoint público do serviço e esconde os detalhes do conjunto de backends. Ele pode rotear vários domínios na mesma infraestrutura e direcionar caminhos diferentes para aplicações diferentes, mantendo um único ponto de conexão público.

O DNS e um proxy reverso resolvem partes diferentes da conexão. O DNS mapeia um nome de host para um endereço público ou alias. Depois que o cliente se conecta, o proxy usa as informações de host do HTTP, o SNI (indicação de nome de servidor) do TLS e sua própria configuração para escolher o serviço correto. Isso explica por que requisitar um IP puro pode mostrar uma página padrão ou um aviso de certificado mesmo quando o domínio funciona: a requisição pode não incluir o contexto de nome de host esperado. Da mesma forma, alterar o DNS não cria automaticamente uma rota correspondente no proxy nem provisiona um certificado. As duas camadas precisam concordar sobre o nome de host e o destino.

Formas comuns de o proxy fazer parte de uma queda

Um domínio pode resolver corretamente enquanto o proxy reverso aponta para um upstream morto, usa a porta errada ou rejeita um nome de host que não foi configurado para atender. Falhas de TLS podem ocorrer se a borda não tiver um certificado válido ou se um upstream criptografado estiver mal configurado. Um proxy também pode retornar um timeout quando um backend está sobrecarregado ou inacessível. Por outro lado, uma aplicação saudável pode parecer indisponível se o DNS direciona os clientes ao endereço de proxy errado. Comece registrando a resposta DNS e, depois, inspecione em ordem a resposta HTTP, a conexão TLS, os logs do proxy e a saúde do backend.

• Confirme que o DNS aponta para o endpoint público de proxy pretendido.
• Verifique se o proxy tem uma regra de host e um upstream saudável para o domínio.
• Confira as configurações de TLS da borda e do upstream quando o HTTPS falhar.
• Use os logs do proxy para distinguir erros de roteamento de erros da aplicação.
• Evite presumir que uma consulta de IP revela o servidor de backend.

Limites de segurança e operacionais

Um proxy reverso pode reduzir a exposição direta dos serviços de backend, mas não é automaticamente um limite de segurança, a menos que as regras de acesso sejam configuradas e mantidas. A origem deve aceitar tráfego somente pelos caminhos pretendidos, quando a arquitetura permitir. Interfaces administrativas não devem ser colocadas em rotas públicas sem autenticação adequada. Mantenha o software do proxy atualizado, restrinja o acesso de gerenciamento e valide os cabeçalhos encaminhados, porque o proxy se torna um intérprete confiável das informações do cliente e do upstream. Documente qual equipe é responsável pelo DNS, pelas regras do proxy, pelos certificados e pelo backend, para que a resposta a incidentes não trave enquanto cada grupo presume que outra camada é a responsável.

Para entender a relação entre a borda pública e o backend, leia o que é um servidor de origem. Para redes globais de proxy, veja como as CDNs usam o DNS. Uma verificação pública de domínio para IP pode confirmar o endereço apresentado pelo DNS, mas a rota do proxy reverso e a saúde da aplicação exigem suas próprias verificações operacionais. Manter essas responsabilidades distintas torna o diagnóstico mais preciso e evita que um resultado de endereço seja confundido com um diagnóstico completo da infraestrutura.

Torne explícita a responsabilidade pelas regras do proxy

Um proxy reverso fica em um ponto crítico de transição, então registre quem é responsável pelo DNS, pelo roteamento de hosts, pelos certificados, pelas definições de upstream e pelas políticas de acesso. Uma alteração pode estar correta em uma camada e ainda assim falhar porque outra camada não foi atualizada: o DNS aponta para o proxy, mas o proxy não tem um host virtual; a rota existe, mas o certificado é de outro nome; ou o upstream está saudável, mas um firewall bloqueia a sub-rede do proxy. Mantenha um diagrama simples do caminho e uma requisição sabidamente correta para cada nome de host em produção. Durante um incidente, compare a resposta DNS pública, o log de acesso do proxy, a saúde do upstream e o log da aplicação usando o mesmo horário de requisição ou ID de correlação.