Contêineres Docker em VPS sem acesso à rede (2026): resolução DNS, redes bridge e diagnóstico do 127.0.0.11

Entre no contêiner:

docker exec -it app sh

Se o contêiner não tiver sh, use em vez disso:

docker exec -it app bash

Primeiro teste um IP público:

ping -c 3 1.1.1.1

Depois teste um nome de domínio:

ping -c 3 google.com

Se os IPs funcionam mas os nomes de domínio não, verifique o DNS primeiro.

Se os IPs também falham, verifique primeiro a rede do Docker, o NAT, o encaminhamento e o firewall.

Se a internet funciona mas os contêineres não conseguem se acessar entre si pelo nome de serviço, concentre-se no tipo de rede do Docker: você pode ainda estar usando o bridge padrão em vez de um bridge definido pelo usuário ou da rede padrão do Compose.

Execute dentro do contêiner:

cat /etc/resolv.conf

Se o contêiner estiver em um bridge definido pelo usuário ou em uma rede do Docker Compose, o resultado comum é:

nameserver 127.0.0.11
options ndots:0

127.0.0.11 é o DNS interno do Docker. Ele cuida de duas coisas:

1. Encaminhar as consultas DNS externas do contêiner.
2. Resolver nomes de contêiner e nomes de serviço em redes definidas pelo usuário.

Se o que você vê não é 127.0.0.11, mas algum endereço local do host, como 127.0.0.53, cuidado com problemas relacionados ao systemd-resolved. Dentro do contêiner, 127.0.0.53 aponta para o próprio contêiner, não para o serviço resolved do host, e normalmente falhará na resolução.

Este é o ponto mais fácil de passar despercebido na rede do Docker.

Um contêiner iniciado diretamente assim:

docker run -d --name app nginx

entra por padrão na rede bridge padrão do Docker. No bridge padrão, os contêineres normalmente não conseguem se resolver automaticamente pelo nome do contêiner.

É melhor criar uma rede personalizada:

docker network create app-net

Depois inicie o contêiner:

docker run -d --name redis --network app-net redis:7
docker run -d --name app --network app-net nginx

Na mesma rede bridge personalizada, os contêineres podem se acessar pelo nome:

redis:6379

O Docker Compose também cria por padrão uma rede personalizada para o projeto, então os nomes de serviço no Compose normalmente se resolvem entre si. Por exemplo:

services:
  app:
    image: my-app
    depends_on:
      - redis
  redis:
    image: redis:7

Para acessar o Redis a partir de app, escreva:

redis:6379

Não 127.0.0.1:6379. Dentro de um contêiner, 127.0.0.1 se refere ao próprio contêiner, não ao host nem a outro contêiner.

Não olhe apenas docker ps. Problemas de rede exigem network inspect.

Liste as redes:

docker network ls

Inspecione uma rede:

docker network inspect app-net

Concentre-se em:

• Se os contêineres estão realmente na mesma rede.
• Se os nomes e aliases dos contêineres existem.
• Se a Subnet / Gateway entra em conflito com a rede do host.
• Se foi usado por acidente host, none ou um antigo bridge padrão.

Se um contêiner não estiver conectado à rede correta, você pode conectá-lo temporariamente:

docker network connect app-net app

A configuração de longo prazo deve voltar para o arquivo Compose, em vez de ser mantida com connect manual.

Primeiro instale uma ferramenta de diagnóstico dentro do contêiner. Contêineres Debian/Ubuntu:

apt update
apt install -y dnsutils iputils-ping curl

Contêineres Alpine:

apk add --no-cache bind-tools iputils curl

Se o apt update não consegue rodar por falha de DNS, você pode iniciar temporariamente um contêiner de teste:

docker run --rm -it --dns 1.1.1.1 debian:12 bash

Teste a resolução:

nslookup debian.org
nslookup debian.org 1.1.1.1

Se a resolução funciona ao especificar 1.1.1.1 mas falha por padrão, o caminho DNS padrão do Docker tem um problema.

Você pode especificar o DNS em /etc/docker/daemon.json:

{
  "dns": ["1.1.1.1", "8.8.8.8"]
}

Depois reinicie o Docker:

sudo systemctl restart docker

Atenção: reiniciar o Docker afeta os contêineres em execução. Em máquinas de produção, avalie primeiro o impacto e agende uma janela de manutenção se necessário.

Comum no Ubuntu: o /etc/resolv.conf do host aponta para:

nameserver 127.0.0.53

Este é o stub resolver local do systemd-resolved do host. O Docker normalmente lida com essa situação, mas com certas imagens, versões antigas do Docker, resolv.conf modificado manualmente ou configuração do daemon, os contêineres podem receber configurações de DNS que não lhes servem.

Primeiro verifique no host:

resolvectl status
ls -l /etc/resolv.conf
cat /etc/resolv.conf

Se você modificou /etc/resolv.conf manualmente antes para corrigir o DNS, primeiro confirme que não quebrou o DNS do host. Se a resolução DNS do próprio host tem problemas, resolva isso primeiro: O que fazer quando a resolução DNS da VPS falha.

Se os contêineres não conseguem acessar nem IPs públicos, verifique se o host tem o encaminhamento IPv4 habilitado:

sysctl net.ipv4.ip_forward

Normalmente deveria ser:

net.ipv4.ip_forward = 1

O Docker geralmente configura isso automaticamente. Se estiver 0, você pode habilitá-lo temporariamente:

sudo sysctl -w net.ipv4.ip_forward=1

Depois verifique se o Docker criou regras NAT. Em sistemas iptables:

sudo iptables -t nat -S | grep DOCKER

Em sistemas nftables:

sudo nft list ruleset | grep -i docker

Se você instalou UFW, firewalld, scripts de regras nftables ou limpou o iptables manualmente, pode ter quebrado as regras de encaminhamento e NAT do Docker.

Os sintomas comuns dessa situação:

• Os contêineres iniciam.
• Os mapeamentos de porta parecem existir.
• Os contêineres não acessam a internet.
• Após reiniciar o Docker, recupera-se brevemente e depois é sobrescrito novamente pelos scripts de firewall.

Muitas pessoas em VPS Ubuntu usam o UFW para gerenciar portas, mas o Docker opera diretamente no iptables/nftables. O resultado: você acha que o UFW bloqueou uma porta, mas as portas mapeadas pelo Docker continuam abertas para fora; ou você alterou a política de encaminhamento padrão do UFW e a saída dos contêineres falha.

Primeiro verifique o status do UFW:

sudo ufw status verbose

Depois verifique a política de encaminhamento padrão:

grep DEFAULT_FORWARD_POLICY /etc/default/ufw

Se for:

DEFAULT_FORWARD_POLICY="DROP"

pode afetar o encaminhamento dos contêineres. Muitos tutoriais dizem para mudar para ACCEPT, mas isso amplia a superfície de encaminhamento, então avalie conforme as regras reais em produção.

Uma abordagem mais estável:

• Não faça flush levianamente das regras criadas pelo Docker.
• Verifique a saída dos contêineres após recarregar os scripts de firewall.
• Exponha portas por meio de um ponto de entrada unificado de proxy reverso em vez de -p 0.0.0.0:xxxx:xxxx em todo lugar.

Se o seu problema é "o serviço iniciou mas não pode ser acessado pela internet", consulte: Serviço na VPS iniciado mas inacessível pela internet: portas, firewall, grupos de segurança, endereços de escuta.

Quando a resolução de nomes de serviço falha no Compose, geralmente não é um servidor DNS quebrado, mas uma configuração incorreta.

Erro comum um: escrever localhost.

REDIS_HOST=localhost

Dentro de um contêiner, localhost é o contêiner atual. Escreva o nome do serviço:

REDIS_HOST=redis

Erro comum dois: dois serviços não estão na mesma rede.

services:
  app:
    networks:
      - frontend
  redis:
    networks:
      - backend

Assim, app não consegue resolver redis por padrão. Eles precisam compartilhar uma rede ou você precisa planejar explicitamente os limites de rede.

Erro comum três: tratar container_name como um recurso de extensão.

container_name não é obrigatório e muitas vezes torna as múltiplas réplicas, o isolamento de projetos e os conflitos de nomes mais problemáticos. Os nomes de serviço padrão do Compose já são suficientes como nomes DNS internos.

Quando os contêineres não acessam a rede ou não resolvem nomes de domínio, verifique nesta ordem:

1. Teste primeiro IPs dentro do contêiner: ping 1.1.1.1.
2. Depois teste nomes de domínio: ping debian.org ou nslookup debian.org.
3. Verifique o /etc/resolv.conf do contêiner para confirmar se ele usa 127.0.0.11.
4. Use docker network ls e docker network inspect para ver se o contêiner está na rede correta.
5. Se os contêineres não se acessam entre si, mude primeiro para um bridge personalizado ou uma rede Compose.
6. Se o DNS falhar, use temporariamente --dns 1.1.1.1 para verificar se é um problema do caminho DNS.
7. Se necessário, configure dns em /etc/docker/daemon.json.
8. Verifique resolvectl status e /etc/resolv.conf do host.
9. Se os IPs também falharem, verifique net.ipv4.ip_forward e as regras NAT do Docker.
10. Verifique se UFW/firewalld/nftables está quebrando o encaminhamento do Docker.

Quando os contêineres Docker em uma VPS não têm acesso à rede, não fique olhando para um único erro. Primeiro distinga se os IPs públicos falham, se o DNS falha ou se a resolução de nomes de serviço entre contêineres falha.

Se for acesso entre contêineres, confirme primeiro se estão no mesmo bridge personalizado ou rede Compose; se for resolução de domínios externos, concentre-se em 127.0.0.11, no DNS do host e em daemon.json; se os IPs também falharem, verifique então o encaminhamento, o NAT e o firewall. Depois de separar essas camadas, os problemas de rede do Docker não parecerão mais uma caixa preta.