quarta-feira, 16 de setembro de 2026 · Edição online
Digitorack
Digitorack

Proxy Reverso: Configuração Passo a Passo (Guia 2024)

ResumoO proxy reverso Nginx é uma solução eficiente para gerenciar tráfego web, direcionando solicitações a servidores internos. A configuração envolve editar o arquivo de configuração do Nginx, definir um bloco de servidor com o domínio desejado e usar a diretiva `proxy_pass` para encaminhar requisições ao backend. O guia de 2024 simplifica o processo, permitindo implementação em minutos.

Configurar um proxy reverso parece complexo, mas com este guia passo a passo você terá seu Nginx encaminhando solicitações em minutos. Veja como fazer.

Letícia Sampaio Khoury Letícia Sampaio Khoury · Editora de Gadgets e Consumo Tech
· · 6 min de leitura
Proxy Reverso: Configuração Passo a Passo (Guia 2024)
Foto: Imagem ilustrativa · Digitorack

Configurar um proxy reverso parece complexo, mas com este guia passo a passo você terá seu Nginx encaminhando solicitações em minutos. Veja como fazer.

Configurar um proxy reverso é uma daquelas tarefas que parecem complicadas até você fazer a primeira vez. A boa notícia: com o Nginx, o processo é mais curto do que você imagina. Neste guia, vou te mostrar o caminho completo, do zero até o tráfego passando pelo proxy, com as armadilhas que eu mesmo já pisei para você não pisar.

Se você tem um servidor web rodando em uma porta específica (como 3000, 8080 ou 5000) e quer acessá-lo pela porta 80 ou 443 sem expor a porta original, o proxy reverso resolve. Ele recebe as solicitações do cliente, encaminha para o servidor de origem e devolve a resposta. Simples assim.

Pré-requisitos

Antes de começar, separe o que você vai precisar:

  • Um servidor Linux (Ubuntu ou Debian funcionam bem) com acesso sudo.
  • O Nginx instalado. Se não tiver, o comando sudo apt install nginx resolve no Ubuntu.
  • Um serviço web rodando em alguma porta, por exemplo, uma aplicação Node.js na porta 3000 ou um servidor Apache na 8080.
  • Acesso ao arquivo de configuração do site no Nginx, geralmente em /etc/nginx/sites-available/.

Não precisa de domínio, um IP público ou local já basta para o teste.

Passo 1: Instalar o Nginx

Se o Nginx ainda não está no seu sistema, instale com o gerenciador de pacotes. No Ubuntu e Debian, o comando é:

sudo apt update sudo apt install nginx

Depois da instalação, o serviço já inicia sozinho. Para confirmar que está rodando, use sudo systemctl status nginx. Você deve ver o status como active (running).

Erro comum: esquecer de liberar as portas 80 e 443 no firewall. Se o site não abre, verifique com sudo ufw status e, se necessário, sudo ufw allow 'Nginx Full'.

Passo 2: Identificar o endereço do servidor de origem

O proxy reverso precisa saber para onde encaminhar as solicitações. Anote o endereço do serviço que você quer proteger. Pode ser http://localhost:3000, http://127.0.0.1:8080 ou até um IP interno como http://192.168.0.10:5000.

Dica: use localhost ou 127.0.0.1 quando o serviço estiver na mesma máquina. Isso evita tráfego desnecessário na rede.

Passo 3: Criar um arquivo de configuração para o site

No Nginx, cada site tem um arquivo próprio. Vamos criar um novo em sites-available. O nome pode ser o do seu domínio ou algo descritivo como meuapp.

sudo nano /etc/nginx/sites-available/meuapp

Dentro do arquivo, cole a estrutura básica:

server { listen 80; server_name exemplo.com;

location / { proxy_pass http://localhost:3000; 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; } }

A linha proxy_pass é o coração da configuração. Ela aponta para o endereço do serviço de origem. As linhas proxy_set_header preservam informações importantes do cliente original, como IP e protocolo, para o servidor de origem.

Erro comum: esquecer o proxy_set_header Host $host;. Sem isso, o servidor de origem pode receber o IP interno em vez do domínio, o que quebra aplicações que usam host virtual.

Passo 4: Ativar o site e testar a configuração

Com o arquivo criado, você precisa criar um link simbólico para a pasta sites-enabled:

sudo ln -s /etc/nginx/sites-available/meuapp /etc/nginx/sites-enabled/

Antes de recarregar, teste se a configuração está correta:

sudo nginx -t

Se aparecer syntax is ok e test is successful, recarregue o Nginx:

sudo systemctl reload nginx

Dica: o nginx -t é seu melhor amigo. Ele detecta erros de sintaxe antes de derrubar o serviço.

Passo 5: Testar o proxy reverso

Abra o navegador e acesse o IP ou domínio do servidor. Se tudo funcionou, você verá a mesma aplicação que rodava na porta 3000, agora acessível pela porta 80, sem expor a porta original.

Para confirmar que o proxy está agindo, você pode verificar os logs do Nginx:

sudo tail -f /var/log/nginx/access.log

Cada requisição feita pelo navegador vai aparecer no log, com o IP do cliente e o status da resposta.

Erro comum: se a página aparece, mas sem estilos ou imagens, o problema pode ser o caminho dos recursos estáticos. Nesse caso, você pode adicionar uma regra location específica para servir arquivos estáticos diretamente, sem passar pelo proxy.

Passo 6: Configurar HTTPS (opcional, mas recomendado)

Se você tem um domínio apontando para o servidor, vale a pena ativar o HTTPS com o Certbot. O comando abaixo instala e configura o certificado automaticamente:

sudo apt install certbot python3-certbot-nginx sudo certbot --nginx -d exemplo.com

O Certbot altera a configuração do Nginx para usar HTTPS e ainda configura o redirecionamento automático de HTTP para HTTPS.

Dica: o HTTPS não é só para sites de comércio. Qualquer login, formulário ou dado sensível merece a camada extra de segurança.

Checklist do que você acabou de fazer

  • [ ] Nginx instalado e rodando
  • [ ] Endereço do serviço de origem identificado
  • [ ] Arquivo de configuração criado em sites-available
  • [ ] Link simbólico criado em sites-enabled
  • [ ] nginx -t passou sem erros
  • [ ] Nginx recarregado
  • [ ] Proxy reverso respondendo na porta 80
  • [ ] HTTPS ativado (se aplicável)

Perguntas frequentes sobre proxy reverso

Proxy reverso e proxy comum são a mesma coisa?

Não. O proxy comum fica do lado do cliente, escondendo o IP do usuário e filtrando o acesso à internet. O proxy reverso fica do lado do servidor, recebendo as solicitações externas e distribuindo para os servidores internos. Um protege o cliente, o outro protege o servidor.

Preciso de um domínio para configurar proxy reverso?

Não. Você pode configurar com IP puro. Mas o domínio facilita a configuração de HTTPS e o acesso por um nome amigável. Em testes locais, um IP ou localhost já resolve.

Qual a diferença entre proxy reverso e balanceador de carga?

O proxy reverso encaminha solicitações para um servidor específico. O balanceador de carga distribui o tráfego entre vários servidores para evitar sobrecarga. O Nginx pode fazer os dois, e o proxy reverso muitas vezes usa o balanceamento quando há mais de um servidor de origem.

O proxy reverso deixa o servidor mais lento?

Em geral, o ganho de segurança e flexibilidade compensa. O Nginx é eficiente e adiciona pouquíssima latência. Em aplicações bem configuradas, o impacto é imperceptível para o usuário final.

Como faço para o proxy reverso funcionar com WebSocket?

Para WebSocket, você precisa adicionar dois cabeçalhos na configuração: proxy_set_header Upgrade $http_upgrade; e proxy_set_header Connection "upgrade";. Sem eles, a conexão WebSocket é fechada pelo proxy.

Posso usar o Apache como proxy reverso?

Sim, o Apache também faz proxy reverso com os módulos mod_proxy e mod_proxy_http. O Nginx é mais comum em guias e, na minha experiência, mais simples para essa função, mas o Apache funciona bem se você já usa ele como servidor principal.

Compartilhar:
Letícia Sampaio Khoury

Letícia Sampaio Khoury

Editora de Gadgets e Consumo Tech

Testa o gadget no dia a dia real, avalia se vale a grana sem deslumbre de novidade.

Ver todos os artigos →

Leia também

Blue Green Deployment: o que é e como fazer
Apps e Software

Blue Green Deployment: o que é e como fazer

Blue green deployment é um modelo de release que mantém dois ambientes idênticos e troca o tráfego de um para o outro. O ganho é rollback quase instantâneo; o preço é manter infraestrutura duplicada.

16 de setembro de 2026 · Letícia Sampaio Khoury
OpenTelemetry observabilidade: guia de configuração
Apps e Software

OpenTelemetry observabilidade: guia de configuração

Configurar OpenTelemetry para observabilidade exige decidir o que instrumentar, subir um coletor e exportar dados para um backend. Neste guia mostro o caminho que uso em projetos reais, com os erros que aparecem no meio.

16 de setembro de 2026 · Letícia Sampaio Khoury
Helm vs Kustomize: qual gerenciador Kubernetes escolher
Apps e Software

Helm vs Kustomize: qual gerenciador Kubernetes escolher

Helm e Kustomize resolvem problemas diferentes no mesmo cluster. Um empacota e versiona; o outro adapta YAML nativo sem template. Veja em qual cenário cada abordagem encaixa melhor para o seu time.

16 de setembro de 2026 · Letícia Sampaio Khoury

Gostou? Receba mais análises

Newsletter quinzenal · curadoria editorial · sem spam