Contenedores Docker en un VPS sin conexión a la red (2026): resolución DNS, redes bridge y diagnóstico de 127.0.0.11

Entra al contenedor:

docker exec -it app sh

Si el contenedor no tiene sh, usa en su lugar:

docker exec -it app bash

Primero prueba una IP pública:

ping -c 3 1.1.1.1

Luego prueba un nombre de dominio:

ping -c 3 google.com

Si las IP funcionan pero los nombres de dominio no, revisa primero el DNS.

Si las IP tampoco funcionan, revisa primero la red de Docker, NAT, el reenvío y el firewall.

Si internet funciona pero los contenedores no pueden accederse entre sí por nombre de servicio, céntrate en el tipo de red de Docker: puede que sigas usando el bridge predeterminado en lugar de un bridge definido por el usuario o la red predeterminada de Compose.

Ejecuta dentro del contenedor:

cat /etc/resolv.conf

Si el contenedor está en un bridge definido por el usuario o en una red de Docker Compose, el resultado habitual es:

nameserver 127.0.0.11
options ndots:0

127.0.0.11 es el DNS interno de Docker. Se encarga de dos cosas:

1. Reenviar las consultas DNS externas del contenedor.
2. Resolver nombres de contenedor y de servicio en redes definidas por el usuario.

Si lo que ves no es 127.0.0.11 sino alguna dirección local del host, como 127.0.0.53, cuidado con los problemas relacionados con systemd-resolved. Dentro del contenedor, 127.0.0.53 apunta al propio contenedor, no al servicio resolved del host, y normalmente fallará la resolución.

Este es el punto más fácil de pasar por alto en la red de Docker.

Un contenedor iniciado directamente así:

docker run -d --name app nginx

entra por defecto en la red bridge predeterminada de Docker. En el bridge predeterminado, los contenedores normalmente no pueden resolverse automáticamente por nombre de contenedor.

Es mejor crear una red personalizada:

docker network create app-net

Luego inicia el contenedor:

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

En la misma red bridge personalizada, los contenedores pueden accederse por nombre:

redis:6379

Docker Compose también crea por defecto una red personalizada para el proyecto, así que los nombres de servicio en Compose normalmente se resuelven entre sí. Por ejemplo:

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

Para acceder a Redis desde app, escribe:

redis:6379

No 127.0.0.1:6379. Dentro de un contenedor, 127.0.0.1 se refiere al propio contenedor, no al host ni a otro contenedor.

No mires solo docker ps. Los problemas de red requieren network inspect.

Lista las redes:

docker network ls

Inspecciona una red:

docker network inspect app-net

Céntrate en:

• Si los contenedores están realmente en la misma red.
• Si existen los nombres y alias de los contenedores.
• Si la Subnet / Gateway entra en conflicto con la red del host.
• Si se usó por accidente host, none o un antiguo bridge predeterminado.

Si un contenedor no está conectado a la red correcta, puedes conectarlo temporalmente:

docker network connect app-net app

La configuración a largo plazo debe volver al archivo Compose, no mantenerse con connect manual.

Primero instala una herramienta de diagnóstico dentro del contenedor. Contenedores Debian/Ubuntu:

apt update
apt install -y dnsutils iputils-ping curl

Contenedores Alpine:

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

Si apt update no puede ejecutarse por un fallo de DNS, puedes iniciar temporalmente un contenedor de prueba:

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

Prueba la resolución:

nslookup debian.org
nslookup debian.org 1.1.1.1

Si la resolución funciona al especificar 1.1.1.1 pero falla por defecto, la ruta DNS predeterminada de Docker tiene un problema.

Puedes especificar DNS en /etc/docker/daemon.json:

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

Luego reinicia Docker:

sudo systemctl restart docker

Nota: reiniciar Docker afecta a los contenedores en ejecución. En máquinas de producción, evalúa primero el impacto y programa una ventana de mantenimiento si es necesario.

Común en Ubuntu: el /etc/resolv.conf del host apunta a:

nameserver 127.0.0.53

Este es el stub resolver local de systemd-resolved del host. Docker normalmente maneja esta situación, pero con ciertas imágenes, versiones antiguas de Docker, resolv.conf modificado a mano o configuración del daemon, los contenedores pueden recibir ajustes DNS que no les corresponden.

Primero revisa en el host:

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

Si antes modificaste /etc/resolv.conf a mano para arreglar el DNS, primero confirma que no has roto el DNS del host. Si la resolución DNS del propio host tiene problemas, resuélvelo primero: Qué hacer cuando falla la resolución DNS en un VPS.

Si los contenedores no pueden acceder ni a IP públicas, comprueba si el host tiene habilitado el reenvío IPv4:

sysctl net.ipv4.ip_forward

Normalmente debería ser:

net.ipv4.ip_forward = 1

Docker suele configurarlo automáticamente. Si es 0, puedes habilitarlo temporalmente:

sudo sysctl -w net.ipv4.ip_forward=1

Luego comprueba si Docker creó reglas NAT. En sistemas iptables:

sudo iptables -t nat -S | grep DOCKER

En sistemas nftables:

sudo nft list ruleset | grep -i docker

Si has instalado UFW, firewalld, scripts de reglas nftables o has limpiado iptables manualmente, puede que hayas roto las reglas de reenvío y NAT de Docker.

Los síntomas habituales de esta situación:

• Los contenedores arrancan.
• Las asignaciones de puertos parecen existir.
• Los contenedores no acceden a internet.
• Tras reiniciar Docker se recupera brevemente y luego los scripts de firewall lo sobrescriben de nuevo.

Mucha gente en VPS Ubuntu usa UFW para gestionar puertos, pero Docker opera directamente sobre iptables/nftables. El resultado: crees que UFW bloqueó un puerto, pero los puertos mapeados por Docker siguen abiertos al exterior; o cambiaste la política de reenvío predeterminada de UFW y la salida de los contenedores falla.

Primero revisa el estado de UFW:

sudo ufw status verbose

Luego revisa la política de reenvío predeterminada:

grep DEFAULT_FORWARD_POLICY /etc/default/ufw

Si es:

DEFAULT_FORWARD_POLICY="DROP"

puede afectar al reenvío de los contenedores. Muchos tutoriales te dicen que lo cambies a ACCEPT, pero eso amplía la superficie de reenvío, así que evalúalo según tus reglas reales en producción.

Un enfoque más estable:

• No hagas flush a la ligera de las reglas creadas por Docker.
• Comprueba la salida de los contenedores tras recargar los scripts de firewall.
• Expón puertos mediante un punto de entrada unificado de proxy inverso en lugar de -p 0.0.0.0:xxxx:xxxx por todas partes.

Si tu problema es "el servicio arrancó pero no se puede acceder desde internet", consulta: Servicio en VPS arrancado pero inaccesible desde internet: puertos, firewall, grupos de seguridad, direcciones de escucha.

Cuando falla la resolución de nombres de servicio en Compose, normalmente no es un servidor DNS roto sino una configuración incorrecta.

Error común uno: escribir localhost.

REDIS_HOST=localhost

Dentro de un contenedor, localhost es el contenedor actual. Escribe el nombre del servicio:

REDIS_HOST=redis

Error común dos: dos servicios no están en la misma red.

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

Así, app no puede resolver redis por defecto. Deben compartir una red o planificar explícitamente los límites de red.

Error común tres: tratar container_name como una capacidad de extensión.

container_name no es obligatorio y a menudo complica las múltiples réplicas, el aislamiento de proyectos y los conflictos de nombres. Los nombres de servicio predeterminados de Compose ya son suficientes como nombres DNS internos.

Cuando los contenedores no acceden a la red o no resuelven nombres de dominio, revisa en este orden:

1. Prueba primero IP dentro del contenedor: ping 1.1.1.1.
2. Luego prueba nombres de dominio: ping debian.org o nslookup debian.org.
3. Revisa el /etc/resolv.conf del contenedor para confirmar si usa 127.0.0.11.
4. Usa docker network ls y docker network inspect para ver si el contenedor está en la red correcta.
5. Si los contenedores no se acceden entre sí, cambia primero a un bridge personalizado o a una red Compose.
6. Si falla el DNS, usa temporalmente --dns 1.1.1.1 para verificar si es un problema de la ruta DNS.
7. Si es necesario, configura dns en /etc/docker/daemon.json.
8. Revisa resolvectl status y /etc/resolv.conf del host.
9. Si las IP también fallan, revisa net.ipv4.ip_forward y las reglas NAT de Docker.
10. Comprueba si UFW/firewalld/nftables está rompiendo el reenvío de Docker.

Cuando los contenedores Docker en un VPS no tienen conexión a la red, no te fijes en un solo error. Primero distingue si fallan las IP públicas, si falla el DNS o si falla la resolución de nombres de servicio entre contenedores.

Si es acceso entre contenedores, confirma primero si están en el mismo bridge personalizado o red Compose; si es resolución de dominios externos, céntrate en 127.0.0.11, el DNS del host y daemon.json; si las IP también fallan, revisa entonces el reenvío, NAT y el firewall. Una vez separadas estas capas, los problemas de red de Docker dejarán de parecer una caja negra.