Modos de rede do Docker: desempenho e quando usar bridge, host, none e container

Aquela linha verde, “Container started”, aparece no terminal. O serviço claramente subiu, mas o curl continua dando timeout. Você já conferiu docker logs três vezes e não há erro, o mapeamento de portas -p 8080:80 está configurado, a rota está certa e o firewall está desativado. Então onde está o problema?

Mais tarde, descobri que havia escolhido o modo de rede errado. Eu achava que bastava executar docker run -p, sem saber que o Docker oferece quatro modos de rede: bridge, host, none e container.

Se você também já viu um “contêiner em execução que simplesmente não responde”, ou entende apenas parte da configuração de rede do Docker, este artigo explica, sem rodeios, as diferenças, os princípios e os casos de uso desses quatro modos. Nada de mergulhar na teoria complexa de namespaces de rede do Linux: vamos falar apenas do que você realmente precisa saber na prática.

Primeiro, entenda a “base” da rede do Docker: a ponte docker0

O que é docker0? O “gateway do condomínio” dos contêineres

Depois que o Docker é instalado, uma interface de rede virtual chamada docker0 aparece automaticamente no sistema. Pense nela como o gateway de um condomínio: todos os contêineres, ou moradores, precisam passar por ela para acessar a rede externa.

Abra o terminal e teste este comando:

ip addr show docker0

Você verá uma saída parecida com esta:

docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

Viu o 172.17.0.1? Esse é o endereço IP da docker0. O Docker atribui a cada novo contêiner um IP da faixa 172.17.0.0/16, como 172.17.0.2 ou 172.17.0.3.

Agora veja a lista de redes do Docker:

docker network ls

NETWORK ID     NAME      DRIVER    SCOPE
7f8a2b3c9d4e   bridge    bridge    local

Essa rede bridge padrão usa a ponte docker0 por baixo dos panos.

veth pair: o “interfone” que conecta o contêiner

A docker0, sozinha, não basta. O contêiner fica em seu próprio “ambiente isolado” — tecnicamente, um namespace de rede. Como ele se comunica com a docker0?

A resposta é o veth pair. Ele funciona como um par de interfones: uma ponta fica dentro do contêiner e se chama eth0; a outra fica no host e se chama vethXXX, como veth9a7b4c. As duas pontas se comunicam diretamente.

Inicie um contêiner para testar:

docker run -d --name test-nginx nginx

Veja as interfaces de rede no host:

ip addr | grep veth

Você verá um novo dispositivo cujo nome começa com veth. Agora entre no contêiner e verifique:

docker exec test-nginx ip addr

Dentro do contêiner há uma interface eth0 com o IP 172.17.0.2. Essa eth0 e a vethXXX do host formam um par. O pacote sai pela eth0, chega imediatamente à vethXXX, passa pela docker0 e então sai pela interface de rede do host, como eth0 ou ens33, para acessar a internet.

O caminho completo é este:

Dentro do contêiner (172.17.0.2)
  ↓ eth0
  ↓ (veth pair)
  ↓ vethXXX
  ↓
Ponte docker0 (172.17.0.1)
  ↓ Encaminhamento NAT
  ↓
Interface de rede do host (por exemplo, 192.168.1.100)
  ↓
Internet

Parece um pouco indireto, mas funciona muito rápido. Ao executar ping para o IP do contêiner, a latência normalmente fica em alguns décimos de milissegundo.

Para ser sincero, também fiquei confuso na primeira vez que vi o conceito de veth pair. Depois percebi que é apenas um cabo de rede virtual: uma ponta ligada ao contêiner e outra à docker0. Só isso.

Modo bridge: a “opção padrão” do Docker

Por que bridge é o padrão?

Se você não especificar um modo de rede, o Docker usará bridge automaticamente. O motivo é simples: ele oferece um bom equilíbrio entre isolamento e facilidade de uso.

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

No modo bridge, cada contêiner tem um IP independente, o que evita conflitos de porta. Ao mesmo tempo, o parâmetro -p permite expor facilmente um serviço no host. Para a maioria dos cenários, isso já é suficiente.

Por exemplo, inicie dois contêineres Nginx:

docker run -d -p 8080:80 --name web1 nginx
docker run -d -p 8081:80 --name web2 nginx

Os dois escutam a porta 80, mas não entram em conflito porque cada um está em seu próprio namespace de rede. No host, você os acessa pelas portas 8080 e 8081; nos bastidores, o Docker faz o encaminhamento de portas por NAT.

Use docker inspect web1 para ver a configuração de rede:

"Networks": {
    "bridge": {
        "IPAddress": "172.17.0.2",
        "Gateway": "172.17.0.1"
    }
}

O contêiner recebeu o IP privado 172.17.0.2, e seu gateway é o endereço 172.17.0.1 da docker0.

Bridge padrão vs. bridge personalizada: uma diferença essencial

Há uma armadilha aqui. Na rede bridge padrão, ou seja, na docker0, os contêineres só conseguem se comunicar por IP; a resolução pelo nome do contêiner não é oferecida.

Teste o seguinte:

docker run -d --name db mysql
docker run -it --name app alpine ping db

O ping não funcionará. É preciso informar o IP diretamente, como em ping 172.17.0.2.

Agora crie uma rede bridge personalizada:

docker network create mynet
docker run -d --name db --network mynet mysql
docker run -it --name app --network mynet alpine ping db

Desta vez funciona. Redes bridge personalizadas incluem resolução DNS, então o nome do contêiner pode ser usado diretamente como nome de domínio.

Esse é também o motivo para recomendar uma rede personalizada, em vez da docker0 padrão, em produção: a descoberta de serviços fica muito mais simples e você não precisa fixar endereços IP no código ou na configuração.

O que existe por trás do parâmetro -p: encaminhamento NAT

Quando você usa -p 8080:80, o Docker adiciona uma regra NAT ao iptables do host:

iptables -t nat -L -n | grep 8080

Você verá algo parecido com isto:

DNAT  tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:8080 to:172.17.0.2:80

Isso significa que todo o tráfego enviado à porta 8080 do host é encaminhado para 172.17.0.2:80 no contêiner.

É por isso que http://IP-do-host:8080 abre o serviço do contêiner: o Docker faz a conversão de endereços para você.

Quando usar o modo bridge

Em resumo, bridge é indicado para estes cenários:

• Arquitetura de microsserviços: vários contêineres colaboram, precisam de isolamento e também devem se comunicar; use uma rede bridge personalizada
• Ambiente de desenvolvimento: você precisa subir serviços rapidamente para testar, e o bridge padrão resolve
• Aplicações web que exigem mapeamento de portas: por exemplo, um blog ou uma API

Em termos de desempenho, bridge acrescenta algum custo de NAT e veth pair. Mas, sinceramente, essa perda é desprezível para a maioria das aplicações. Poucos projetos encontram um gargalo real nesse ponto, então não vale a pena se preocupar com isso logo de início.

Modo host: a escolha para quem prioriza desempenho

O que é o modo host? Rede sem isolamento

O modo host é direto: o contêiner deixa de ter uma rede independente e passa a usar a pilha de rede do host.

Adicione --net=host ao iniciar o contêiner:

docker run -d --net=host --name web nginx

Nesse caso, o contêiner não tem um IP independente nem uma interface eth0 própria; ele compartilha diretamente as interfaces de rede do host. A configuração exibida por ip addr dentro do contêiner é igual à do host.

Mais importante: não é necessário usar -p para mapear portas. Se o serviço do contêiner escuta a porta 80, basta acessar IP-do-host:80 externamente.

De onde vem a vantagem de desempenho?

O modo host ignora a ponte docker0 e o veth pair, além de dispensar o encaminhamento NAT. Os pacotes entram e saem diretamente pela interface de rede do host, como se o processo estivesse sendo executado no próprio host.

Alguns testes mostram que, em cenários de alta concorrência, host pode ser de 5% a 10% mais rápido do que bridge. Pode parecer pouco, mas essa diferença importa em aplicações extremamente sensíveis à latência, como negociações de alta frequência e servidores de jogos em tempo real.

Já encontrei um caso em que o Nginx, usado como proxy reverso, processava dezenas de milhares de requisições por segundo. Depois da mudança para host, a latência P99 caiu de 12 ms para 9 ms. Foram apenas 3 milissegundos, mas, naquele projeto, essa redução valia dezenas de milhares de yuans.

Armadilhas e custos do modo host

O desempenho melhora, mas há várias desvantagens.

Armadilha 1: conflito de portas

Como o contêiner usa diretamente as portas do host, iniciar vários contêineres na mesma porta gera erro:

docker run -d --net=host nginx  # Escuta a porta 80
docker run -d --net=host nginx  # Tenta escutar a porta 80 novamente: Address already in use

Não há diferença em relação a iniciar dois processos Nginx diretamente no host. Quer executar várias instâncias? Você precisará alterar a porta de escuta dentro do contêiner ou deixar de usar o modo host.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Armadilha 2: o serviço no contêiner precisa escutar em 0.0.0.0

Se o serviço dentro do contêiner escutar apenas em 127.0.0.1, ele não poderá ser acessado externamente. Para receber conexões da rede externa, precisa escutar em 0.0.0.0.

Uma vez executei um serviço Node.js em modo host, mas o código usava app.listen(3000, 'localhost'). Não havia jeito de conectar de fora. O problema só foi resolvido depois que mudei para app.listen(3000, '0.0.0.0').

Armadilha 3: perda do isolamento de rede

O contêiner consegue acessar diretamente todos os recursos de rede do host, o que aumenta o risco de segurança. Se ele executa código de terceiros não confiável, usar host é criar um problema para você mesmo.

Quando usar o modo host?

Sendo direto: considere host somente quando houver um gargalo real de desempenho. Na maioria dos cenários, o pequeno custo do modo bridge simplesmente não é um problema.

Host é adequado para estes casos:

• Ferramentas de monitoramento: Prometheus, Grafana e ELK, que precisam acessar diretamente os recursos de rede do host
• Proxies de alto desempenho: Nginx e HAProxy usados para balanceamento de carga quando a menor latência possível é importante
• Bancos de dados: serviços sensíveis ao desempenho de rede, como MySQL e Redis, sempre avaliando os riscos de segurança

Se sua aplicação recebe apenas alguns milhares de requisições por segundo, não complique com host: bridge é suficiente.

Modos none e container: para casos especiais

Modo none: um sandbox totalmente desconectado

None significa exatamente isso: o contêiner não tem rede.

docker run -it --net=none alpine sh

Execute ip addr dentro do contêiner e você verá apenas a interface de loopback, lo. O contêiner não acessa a internet e também não pode ser acessado por outros contêineres.

Quando usar o modo none?

Para ser sincero, quase nunca usei none no trabalho. Seus casos de uso são bastante restritos:

• Testes de segurança: executar código não confiável com isolamento total da rede para evitar vazamento de dados
• Processamento offline de dados: o contêiner faz apenas cálculos locais e não precisa de comunicação de rede
• Configuração manual da rede: em situações muito raras, quando é necessário personalizar toda a rede, por exemplo, configurando veth manualmente com uma ferramenta como pipework

Se você não trabalha com pesquisa de segurança nem tem uma necessidade especial de configuração de rede, provavelmente não usará none.

Modo container: dois contêineres compartilhando a mesma rede

O modo container permite que um contêiner use o namespace de rede de outro. Parece complicado, mas o exemplo deixa claro:

# Primeiro, inicie um contêiner
docker run -d --name web nginx

# O segundo contêiner compartilha a rede de web
docker run -it --net=container:web alpine sh

Agora os dois contêineres compartilham a mesma configuração de rede: o mesmo endereço IP, o mesmo espaço de portas e as mesmas interfaces. No segundo contêiner, você pode acessar o Nginx em localhost:80.

Um uso típico do modo container: Pods do Kubernetes

Os Pods do Kubernetes são implementados com esse modelo de compartilhamento. Vários contêineres de um Pod compartilham a rede de um contêiner “pause”.

Por exemplo, um Pod pode executar o contêiner da aplicação e um contêiner sidecar que coleta logs. Os dois se comunicam por localhost, sem precisar expor portas externamente.

Porém, se você usa apenas Docker, e não Kubernetes, o modo container também aparece pouco. Uma rede bridge personalizada permite a comunicação entre contêineres e é mais flexível.

O papel desses dois modos

No fim, none e container funcionam mais como “recursos de baixo nível” do que como soluções do dia a dia. Eles oferecem flexibilidade para situações específicas, mas você não precisará deles em 80% dos casos.

Lembre-se:

• Modo none: use quando precisar de isolamento total da rede, algo raro
• Modo container: comum em orquestradores como Kubernetes, mas pouco usado diretamente com Docker

Decisão prática: como escolher o modo de rede certo

Um fluxograma de decisão

Diante de um projeto real, qual modo de rede usar? Este fluxo simples ajuda a decidir:

Você precisa de isolamento de rede?
│
├─ Não → Existe um gargalo de desempenho?
│        │
│        ├─ Sim → Use Host (considere os riscos de segurança)
│        └─ Não → Use Bridge (mais seguro)
│
└─ Sim → Os contêineres precisam se comunicar pelo nome?
         │
         ├─ Sim → Rede Bridge personalizada
         └─ Não → Rede Bridge padrão

Casos especiais:

• Não precisa de nenhuma rede → modo None
• Contêineres dentro de um Pod do Kubernetes → modo Container

Tabela rápida de recomendações

Três equívocos comuns

Equívoco 1: “O modo host é sempre o melhor”

Não é. Host sacrifica isolamento e flexibilidade em troca de um ganho de desempenho que pode ser irrelevante em muitos cenários.

Já vi gente executar todos os contêineres em host e acabar com uma pilha de conflitos de porta e problemas de segurança. O desempenho realmente melhorou um pouco, mas o custo de manutenção ficou dez vezes maior.

A realidade: bridge é suficiente para 80% das aplicações. Não escolha host apenas porque ele é “mais rápido”.

Equívoco 2: “O bridge padrão é suficiente”

KiloClaw - OpenClaw gerenciado para empresas: orquestração de agentes IA e roteamento inteligente

Começar →Anúncio

Ele não é recomendado para ambientes de produção. A rede bridge padrão não resolve nomes de contêineres. Quando vários serviços precisam se comunicar, você acaba fixando IPs ou passando-os por variáveis de ambiente, uma solução muito frágil.

Criar uma rede bridge personalizada é simples:

docker network create mynet
especifique network no docker-compose.yml

A realidade: dois minutos configurando uma rede personalizada podem economizar horas de diagnóstico.

Equívoco 3: “Todo problema de rede em contêiner acontece porque o modo está errado”

Não necessariamente. Muitas vezes, a causa é o firewall, a configuração do iptables ou o DNS.

Siga estes passos para diagnosticar:

1. Dentro do contêiner, teste se o gateway, o IP da docker0, responde a ping
2. Depois, teste se o IP externo do host responde a ping
3. Verifique se há regras DROP no iptables
4. Confira a configuração do Docker daemon em /etc/docker/daemon.json

A realidade: o modo é apenas o primeiro ponto; o diagnóstico de rede precisa ser sistemático.

Técnicas avançadas

Técnica 1: conectar um contêiner a várias redes

Às vezes, um contêiner precisa se conectar a duas redes ao mesmo tempo, como uma rede de frontend e outra de backend. Faça assim:

docker network create frontend
docker network create backend

docker run -d --name web --network frontend nginx
docker network connect backend web

Agora o contêiner web participa das redes frontend e backend.

Técnica 2: controlar a atribuição de IP com precisão

Ao criar uma rede personalizada, você pode definir a sub-rede e o gateway:

docker network create \
  --driver bridge \
  --subnet 192.168.10.0/24 \
  --gateway 192.168.10.1 \
  mynet

docker run -d --network mynet --ip 192.168.10.100 nginx

Isso é útil quando você precisa de um IP fixo, por exemplo, para uma lista de permissões do firewall.

Técnica 3: ferramentas úteis para diagnosticar problemas de rede

Estes comandos ajudam a investigar a rede dentro de um contêiner:

# Instalar ferramentas de rede
docker exec -it <container> apk add curl netcat-openbsd

# Testar conectividade
docker exec <container> nc -zv <host> <port>

# Ver a tabela de rotas
docker exec <container> ip route

# Capturar pacotes para análise (exige permissão no host)
docker exec <container> tcpdump -i eth0

Conclusão

Depois de tudo isso, vamos recapitular rapidamente os quatro modos de rede:

• Modo bridge: é o padrão e serve para a maioria dos casos; em produção, prefira uma rede bridge personalizada
• Modo host: prioriza desempenho, mas sacrifica o isolamento; use apenas quando houver um gargalo real
• Modo none: deixa o contêiner totalmente sem rede e é raramente usado
• Modo container: compartilha a rede e é usado principalmente no Kubernetes

Lembre-se: não existe o melhor modo, apenas o mais adequado para cada caso.

Se você está começando com Docker, use primeiro o bridge padrão. Ajuste quando surgir um problema concreto: se a descoberta de serviços estiver difícil, passe para uma rede bridge personalizada; se o desempenho realmente não for suficiente, considere host. Não comece tentando decidir qual modo é o “melhor”.

Vale a pena testar: crie uma rede personalizada, inicie alguns contêineres e veja se eles conseguem se comunicar usando os respectivos nomes. Executar o processo uma vez ensina mais do que ler dez artigos.

Se você já encontrou problemas de rede do Docker em um projeto real, compartilhe sua experiência nos comentários. Esse assunto é profundo, mas, dominando os conceitos básicos, você consegue resolver sozinho 80% dos casos.