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

3 min 1 Docker
Resumir com:
ChatGPT Claude Gemini Perplexity Grok
Compartilhar:
WhatsApp LinkedIn X

Se este conteúdo faz parte do seu projeto

Escolha a VPS pelo uso, não pelo excesso

Escolha pelo uso: Basic para projetos pequenos, Performance para produção com múltiplos serviços e Ultra para cargas maiores.

PlanoRecursosMensalPerfil
Basic4 vCPU · 4 GB RAM · 100 GB NVMeR$ 99Site e projeto pequeno
Performance6 vCPU · 12 GB RAM · 150 GB NVMeR$ 169Produção e múltiplos serviços
Ultra8 vCPU · 20 GB RAM · 200 GB NVMeR$ 269Cargas maiores e mais margem
Prova técnica: no benchmark publicado da VM Performance, medimos 1.855 ev/s em 6 threads, 288 ev/s em 1 thread, 11.858 MiB/s de memória e 338 MB/s de escrita sequencial, com teste direto na VM e sem Cloudflare.
Escolher Performance Falar no WhatsApp

Valores mensais exibidos para referência. A renovação segue o ciclo e o preço vigente informado no checkout antes da contratação.

--- queue_position: 21 title: "Nginx como proxy reverso para Docker: configuração segura" slug: nginx-proxy-reverso-docker-configuracao-segura site_key: host-yousecure canonical: https://yousecure.io/blog/nginx-proxy-reverso-docker-configuracao-segura category: docker cluster: proxy-reverso search_intent: informacional-pratica funnel_stage: meio author: "Host You Secure Team" created_at: "2026-09-09T11:29:43-03:00" planned_scheduled_at: null status: queued-review meta_description: "Use Nginx na frente de containers Docker com proxy reverso, headers corretos, healthcheck e uma exposição de portas menor." excerpt: "Um padrão simples para publicar um container sem transformar a porta interna da aplicação em serviço público." quick_answer: "Deixe a aplicação escutando em uma rede Docker privada, publique somente Nginx e encaminhe a requisição pelo nome do serviço, preservando o host e o protocolo." featured_image: images/21-nginx-reverse-proxy.png featured_image_alt: "Gateway luminoso direcionando tráfego para containers isolados" tags: [nginx, docker, proxy-reverso, ssl, devops] evidence_type: reproducible_procedure evidence_environment: Docker Compose com Nginx e uma aplicação HTTP na mesma rede evidence_procedure: "Criar rede, manter a porta da aplicação interna, configurar proxy_pass e validar nginx -t." evidence_observed_result: "O proxy expõe uma entrada controlada enquanto o container fica acessível pelo nome do serviço." evidence_limitation: "TLS, timeouts e headers precisam ser ajustados à aplicação e ao volume de tráfego." information_gain: "Mostra o limite entre rede interna do Compose e portas publicadas no host." primary_cta: "Ver VPS para Docker" landing: /vps-docker-portainer-coolify --- # 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. ## 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 ```yaml 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 ```nginx 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 ```bash 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](https://yousecure.io/vps-docker-portainer-coolify). ## 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.

Comentários (0)

Ainda não há comentários. Seja o primeiro!