Redes en Docker: guía práctica

Redes en Docker es el mecanismo que permite que los contenedores se comuniquen entre sí, con el host o con otros servicios externos. Sin una red bien entendida, es fácil publicar puertos sin necesidad, mezclar entornos o no saber por qué dos contenedores no se ven entre ellos.

Docker crea redes virtuales para aislar servicios y controlar cómo circula el tráfico. En un entorno real esto afecta a aplicaciones web, bases de datos, APIs internas, colas, proxies inversos y cualquier stack levantado con contenedores.

En esta guía vas a ver qué tipos de red existen, cuándo usar una red bridge personalizada, cómo listar e inspeccionar redes y qué errores conviene evitar al conectar contenedores. La idea es que puedas trabajar con redes en Docker de forma práctica y segura.

👉 Y recuerda, si quieres aprender más de Linux, pincha en este curso de Linux gratis.

🐳 Si quieres aprender más de Docker, pincha en este curso de Docker gratis.

Qué son las redes en Docker

Una red de Docker es una capa de comunicación que conecta contenedores. Cuando arrancas un contenedor, Docker lo coloca en una red y le asigna conectividad según el driver utilizado. Esto permite separar servicios por proyecto, evitar exposición innecesaria y resolver nombres de contenedor dentro de una misma red.

El caso más común en desarrollo es una red bridge definida por el usuario. En ese escenario, varios contenedores del mismo proyecto pueden comunicarse usando sus nombres, sin publicar todos los puertos hacia el host. Por ejemplo, una aplicación web puede hablar con una base de datos por su nombre interno, mientras solo publicas hacia fuera el puerto del frontend o del proxy.

Es importante distinguir dos conceptos: comunicación interna entre contenedores y publicación de puertos hacia el host. Que dos servicios se comuniquen dentro de una red no significa que estén accesibles desde Internet. Para exponer un puerto al host se usa el mapeo de puertos al crear o ejecutar el contenedor.

Tipos de redes en Docker

Docker incluye varios drivers de red. No todos se usan en el mismo contexto, y elegir el adecuado evita configuraciones innecesarias o inseguras.

Tipo de red	Uso principal	Cuándo usarla
bridge	Red local para contenedores en un mismo host.	Desarrollo, stacks pequeños y comunicación interna entre servicios.
host	El contenedor comparte la red del host.	Casos muy concretos donde se necesita evitar NAT o simplificar rendimiento/red.
none	Contenedor sin conectividad de red.	Procesos aislados que no deben comunicarse por red.
overlay	Red entre varios nodos Docker.	Swarm o escenarios distribuidos con varios hosts.
macvlan	El contenedor aparece como un equipo más en la red física.	Laboratorios o integraciones donde se necesita IP propia en la LAN.

Para la mayoría de usuarios, la opción recomendada es crear una red bridge personalizada por proyecto. Es más clara que reutilizar la red bridge por defecto y permite resolución DNS interna entre contenedores conectados a la misma red.

La red overlay no es la opción normal para un entorno local simple. Se usa sobre todo en clústeres Docker Swarm o cuando necesitas comunicación entre contenedores distribuidos en diferentes hosts.

Comandos básicos para redes en Docker

Los comandos de red se agrupan bajo docker network. Antes de crear o eliminar nada, conviene listar e inspeccionar las redes existentes para entender el estado actual.

Listar e inspeccionar redes

docker network ls
docker network inspect bridge
docker network inspect mi_red

docker network ls
docker network inspect bridge
docker network inspect mi_red

El primer comando lista las redes disponibles. Los comandos de inspección muestran detalles como driver, subred, gateway, contenedores conectados y opciones de configuración. No hace falta inventar salidas: lo importante es revisar esos campos en tu propio entorno.

Crear una red bridge personalizada

docker network create mi_red
docker network create --driver bridge red_app

docker network create mi_red
docker network create --driver bridge red_app

Al crear una red personalizada, puedes separar los servicios de una aplicación del resto de contenedores. Esto mejora el orden y reduce errores cuando tienes varios proyectos funcionando en la misma máquina.

Conectar y desconectar contenedores

docker network connect mi_red mi_contenedor
docker network disconnect mi_red mi_contenedor

docker network connect mi_red mi_contenedor
docker network disconnect mi_red mi_contenedor

Estos comandos conectan o desconectan un contenedor existente de una red. Son útiles para pruebas, depuración o cambios puntuales, aunque en proyectos reproducibles suele ser mejor declarar la red en Docker Compose.

Eliminar redes que ya no usas

docker network rm mi_red
docker network prune

docker network rm mi_red
docker network prune

Precaución: elimina solo redes que tengas claro que no están en uso. Docker no permite borrar una red con contenedores conectados, pero docker network prune elimina redes no utilizadas y puede afectar a proyectos detenidos si dependían de una red creada previamente.

Ejemplo práctico de comunicación entre contenedores

Una de las ventajas de usar una red personalizada es que los contenedores pueden comunicarse por nombre. Esto evita depender de IPs internas, que pueden cambiar al recrear contenedores.

docker network create red_demo
docker run -d --name web --network red_demo nginx:stable
docker run --rm --network red_demo curlimages/curl:8.10.1 http://web

docker network create red_demo
docker run -d --name web --network red_demo nginx:stable
docker run --rm --network red_demo curlimages/curl:8.10.1 http://web

En este ejemplo se crea una red llamada red_demo, se arranca un contenedor Nginx conectado a esa red y después se lanza un contenedor temporal para hacer una petición HTTP al servicio web usando el nombre web.

Fíjate en un detalle importante: no se publica ningún puerto hacia el host. La comunicación ocurre dentro de la red de Docker. Si quisieras acceder al servicio desde tu navegador usando el host, entonces tendrías que publicar un puerto al arrancar el contenedor.

docker run -d --name web_publico --network red_demo -p 8080:80 nginx:stable

docker run -d --name web_publico --network red_demo -p 8080:80 nginx:stable

Con este segundo ejemplo, el puerto 80 del contenedor queda publicado como 8080 en el host. Esta diferencia es clave: una cosa es conectar contenedores entre sí y otra exponer servicios fuera del entorno Docker.

Redes en Docker Compose

En Docker Compose, normalmente no necesitas crear la red a mano. Compose crea una red por proyecto y conecta los servicios definidos en el archivo. Además, los servicios pueden resolverse por su nombre dentro de esa red.

services:
  web:
    image: nginx:stable
    ports:
      - "8080:80"
    networks:
      - app_net

  api:
    image: nginx:stable
    networks:
      - app_net

networks:
  app_net:
    driver: bridge

services:
  web:
    image: nginx:stable
    ports:
      - "8080:80"
    networks:
      - app_net

  api:
    image: nginx:stable
    networks:
      - app_net

networks:
  app_net:
    driver: bridge

Este ejemplo declara una red app_net y conecta dos servicios a ella. El servicio web publica el puerto 8080 hacia el host, mientras api solo queda disponible dentro de la red interna del proyecto.

En entornos reales puedes usar este patrón para separar frontend, backend y base de datos. Publica únicamente los servicios que deben recibir tráfico externo y deja el resto accesible solo para los contenedores que lo necesitan.

Errores comunes con redes en Docker

Confundir red interna con puerto publicado: que un contenedor escuche en un puerto no significa que el host pueda acceder si no existe un mapeo de puertos.
Usar siempre la red por defecto: funciona para pruebas simples, pero en proyectos reales es más claro crear una red por aplicación o dejar que Compose lo haga.
Depender de IPs internas: es mejor usar nombres de servicio o de contenedor dentro de la red, porque las IPs pueden cambiar.
Eliminar redes sin revisar: antes de usar prune, comprueba qué proyectos pueden depender de redes no utilizadas en ese momento.
Usar overlay sin necesitarlo: para un solo host normalmente basta con bridge; overlay tiene sentido en entornos distribuidos o Swarm.

También conviene revisar reglas de firewall, proxies inversos y puertos publicados cuando un servicio no responde desde fuera. Muchas incidencias no están en Docker, sino en la diferencia entre comunicación interna, publicación de puertos y acceso desde la red externa.

Buenas prácticas para redes en Docker

La recomendación principal es trabajar con redes por proyecto. Si usas Docker Compose, deja que el archivo declare las redes necesarias y evita mezclar contenedores de aplicaciones distintas sin una razón clara.

Publica solo los puertos imprescindibles. Una base de datos, una cola o un servicio interno normalmente no necesitan estar expuestos al host ni a la red externa. Mantenerlos dentro de la red de Docker reduce superficie de ataque y simplifica el diseño.

Cuando algo falle, empieza por lo básico: lista redes, inspecciona la red concreta, revisa qué contenedores están conectados y comprueba si el problema está dentro de Docker o en el mapeo de puertos hacia el host. Este método evita cambiar configuraciones al azar.

En resumen, dominar redes en Docker te ayuda a diseñar stacks más ordenados, seguros y fáciles de depurar. No se trata de memorizar todos los drivers, sino de entender cuándo usar bridge, cuándo publicar puertos y cuándo necesitas una red más avanzada.

Lecciones relacionadas del curso Docker

Documentación oficial y recursos

Con estos conceptos ya puedes organizar la conectividad de tus contenedores con más criterio: redes separadas por proyecto, puertos publicados solo cuando haga falta y comandos de inspección para diagnosticar problemas reales.