O que é proxy reverso (e por que seu app precisa)

Quando você abre um site, quase nunca fala direto com o programa que gera a página. No meio do caminho há um servidor que recebe a sua requisição e a entrega ao app. Esse intermediário é o proxy reverso, e ele está por trás da maioria dos sites e APIs que você usa.

Entender esse conceito resolve dúvidas comuns: onde o HTTPS é configurado, por que o app enxerga o IP errado, como rodar dois apps nas mesmas portas públicas e por que o WebSocket cai depois de um minuto.

O que é um proxy reverso?#

Um proxy reverso é um servidor que recebe requisições em nome de outros servidores e as encaminha. O cliente conversa só com ele. O servidor que fica atrás, chamado upstream ou backend, não recebe conexões diretas da internet.

O nome vem do contraste com o proxy comum. Um forward proxy age em nome do cliente: uma empresa o usa para filtrar o que os funcionários acessam, e o site de destino vê o IP do proxy. Um proxy reverso age em nome do servidor: o cliente vê o endereço do proxy e não sabe quantos apps existem atrás.

Exemplos conhecidos: nginx, Caddy, HAProxy, Traefik e Envoy. Serviços de CDN também funcionam como proxy reverso global.

Como um proxy reverso funciona?#

O caminho de uma requisição tem cinco passos:

1. O navegador resolve o domínio por DNS e conecta ao IP do proxy.
2. O proxy aceita a conexão e, se for HTTPS, faz o handshake TLS.
3. Ele lê a requisição (método, caminho, cabeçalho Host) e decide para qual upstream enviá-la.
4. Abre uma conexão com o upstream, que costuma ficar na mesma máquina ou na mesma rede privada, e repassa a requisição.
5. Recebe a resposta e a devolve ao cliente.

Como o proxy lê a requisição, ele pode alterá-la no caminho: adicionar cabeçalhos, reescrever caminhos, guardar a resposta em cache ou recusar a conexão.

Para que serve um proxy reverso?#

• HTTPS em um lugar só. O proxy termina o TLS e fala HTTP simples com o app, na rede interna. Seu código não lida com certificados. Veja o que é SSL/TLS.
• Vários apps em um IP. Pelo cabeçalho Host, o proxy envia api.exemplo.com para um app e exemplo.com para outro, ambos nas portas 80 e 443.
• Balanceamento. O proxy reparte as requisições entre várias cópias do app. É o tema de o que é um load balancer.
• Cache. Respostas que não mudam saem da memória ou do disco do proxy, sem acionar o app. Em escala global, isso é uma CDN.
• Proteção. O app não fica exposto. O proxy pode limitar requisições por IP, bloquear padrões de ataque e esconder detalhes da infraestrutura.
• Compressão e HTTP/2. O proxy comprime respostas e fala protocolos modernos com o cliente, mesmo que o app só entenda HTTP/1.1.

Como configurar um proxy reverso com nginx?#

Suponha um app Node.js escutando em 127.0.0.1:3000. O arquivo abaixo manda tudo que chega ao domínio para ele:

server {
    listen 80;
    server_name exemplo.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        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 que cada linha faz:

• proxy_pass define o upstream. Pode ser http://, https:// ou um socket Unix.
• Por padrão, o nginx envia ao upstream Host: $proxy_host, ou seja, o endereço do upstream. proxy_set_header Host $host repassa o domínio que o cliente pediu, o que muitos frameworks esperam.
• X-Forwarded-For carrega a lista de IPs por onde a requisição passou. $proxy_add_x_forwarded_for acrescenta o IP de quem conectou ao proxy ao valor que o cliente já mandou.
• X-Forwarded-Proto informa se o cliente usou http ou https, necessário para o app gerar links e redirecionamentos corretos.

Teste a sintaxe com nginx -t e recarregue com nginx -s reload.

E se o app usar WebSocket?#

Upgrade e Connection são cabeçalhos "hop-by-hop": o nginx não os repassa sozinho. Sem eles, a conexão WebSocket falha. Adicione um location próprio:

location /ws/ {
    proxy_pass http://127.0.0.1:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600s;
}

Por padrão, o nginx fecha a conexão se o upstream não enviar dados por 60 segundos. Para conexões ociosas, aumente proxy_read_timeout como acima ou faça o app enviar frames de ping periodicamente.

Como o app descobre o IP real do usuário?#

Atrás de um proxy, a conexão que chega ao app vem do proxy, então o IP de origem é o dele. O IP do cliente viaja em X-Forwarded-For, no formato cliente, proxy1, proxy2. O MDN descreve o cabeçalho como padrão de fato; o padronizado é o Forwarded, bem menos usado.

Há um risco: qualquer cliente pode mandar um X-Forwarded-For falso. Para limite de requisições ou controle de acesso, use apenas os IPs adicionados por proxies em que você confia, contando a partir da direita da lista. Se o app puder ser acessado direto pela internet, nenhuma parte do cabeçalho é confiável. Os frameworks têm uma opção para isso, como trust proxy no Express.

Quando não preciso de um proxy reverso?#

• Bots que só fazem conexões de saída (Discord, Telegram via long polling) não recebem requisições.
• Um único app simples em uma plataforma que já entrega HTTPS na frente dele dispensa instalar nginx por conta própria.
• Protocolos não HTTP, como a conexão direta a um banco de dados, precisam de proxy TCP (camada 4) ou de nenhum proxy.

Cada camada extra é mais uma peça para configurar e monitorar, e mais um ponto que pode falhar. Adicione uma quando houver um motivo concreto.

Como fazer isso na Square Cloud#

Na Square Cloud você não instala nem configura um proxy reverso para o caso comum. Toda aplicação web ganha um subdomínio *.squareweb.app com HTTPS em qualquer plano, e o TLS é automático. A borda recebe o HTTPS, redireciona HTTP para HTTPS e encaminha a requisição para o seu app, que só precisa escutar em 0.0.0.0 na porta da variável PORT.

A rede tem CDN Anycast com mais de 200 pontos de presença, HTTP/3, WebSockets, WAF e mitigação de DDoS L3/L4/L7. O proxy não corta conexões longas: WebSocket e SSE passam sem buffer.

A partir do plano Standard, você aponta um domínio próprio criando no seu registrador os registros DNS mostrados no painel. O domínio continua registrado em seu nome, e o painel mostra o status de validação em tempo real.

Para repartir o tráfego entre cópias do app, o load balancing serve um mesmo domínio personalizado por várias aplicações, com round-robin e failover passivo, sem sticky session: até 2 aplicações por domínio no Standard, até 5 no Pro e até 10 no Enterprise.

Confira os detalhes da camada de rede em Rede e CDN.