Nginx como proxy reverso para Docker: configuração segura

Resposta rápida

O Nginx deve ser a porta pública e o container da aplicação deve ficar em uma rede Docker sem ports exposto ao mundo. O proxy encaminha para http://app:8080, adiciona headers de encaminhamento e é validado com nginx -t antes do reload.

Veja a infraestrutura: planos de VPS da You Secure para colocar este projeto no ar.

Por que usar um proxy reverso

O proxy concentra TLS, domínio, limites e logs. A aplicação continua ouvindo na porta interna do Compose, o que reduz conflitos e permite trocar a versão do container sem alterar o endereço público. Isso não é uma barreira absoluta: a rede e o host ainda precisam de atualização, autenticação e firewall.

Compose mínimo

services:
  app:
    image: exemplo/app:stable
    expose:
      - "8080"
    networks: [frontend]
  nginx:
    image: nginx:stable-alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d:ro
    depends_on:
      - app
    networks: [frontend]
networks:
  frontend:

expose documenta a porta para a rede interna; ports publica no host. Não use ports na aplicação quando o acesso deve passar pelo Nginx.

Configuração do proxy

server {
    listen 80;
    server_name app.exemplo.com;

    location / {
        proxy_pass http://app:8080;
        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;
        proxy_read_timeout 60s;
    }
}

O nome app é resolvido pelo DNS interno do Compose. Não use localhost: dentro do container do Nginx, localhost aponta para o próprio Nginx.

Valide antes de recarregar

docker compose config
docker compose up -d
docker compose exec nginx nginx -t
curl -I -H 'Host: app.exemplo.com' http://127.0.0.1

Depois confira docker compose logs --tail=100 nginx app. Um 502 normalmente significa que o upstream não está escutando, o nome está errado ou a aplicação ainda inicializa.

TLS e operação

Em produção, associe o certificado ao Nginx e redirecione HTTP para HTTPS. Defina limites e timeouts com base no comportamento real da aplicação; um timeout alto pode manter conexões ocupadas e um baixo pode interromper uploads válidos. Healthchecks devem avaliar uma rota representativa, não apenas o processo aberto.

Para publicar containers com uma base organizada, veja a VPS para Docker.

FAQ

Posso apontar proxy_pass para o IP do container?

Prefira o nome do serviço. IPs de containers podem mudar a cada recriação.

O Nginx substitui um firewall?

Não. Ele controla HTTP; o firewall e as políticas do provedor controlam o tráfego de rede.

Checklist de publicação

• [ ] Somente o proxy publica portas no host.
• [ ] O upstream usa nome de serviço, não IP efêmero.
• [ ] nginx -t passou antes do reload.
• [ ] TLS, timeouts e tamanho de corpo foram revisados.
• [ ] Logs do proxy e da aplicação estão correlacionados.

Se a aplicação usa WebSocket ou upload grande, adicione as diretivas específicas somente após testar esse fluxo. Uma configuração copiável é um ponto de partida; o limite real deve ser observado em homologação.