Networking Docker: Bridge, Host, Overlay — Guía Práctica 2026

Microservicios Docker en producción, y nadie entendía por qué dos contenedores no se comunicaban. Mismo host, misma máquina. El problema: dos redes bridge separadas, DNS interno no configurado. 30 minutos para encontrarlo, 2 líneas para resolverlo. Este escenario, demasiado común, resalta lo crítico que es comprender las bases del networking Docker para cualquiera que gestione infraestructuras IT modernas. Una configuración de red errónea puede transformar una arquitectura robusta en una pesadilla de troubleshooting, impactando los SLA y los tiempos de reacción. Con la creciente adopción de los contenedores, la capacidad de diseñar, implementar y depurar redes Docker eficientes se ha convertido en una habilidad imprescindible para cada sysadmin y DevOps engineer. El 70% de las interrupciones de servicio en entornos contenerizados está relacionado con problemas de configuración de red o recursos (Cloud Native Computing Foundation, 2025). Esta guía te proporcionará las bases y las configuraciones prácticas para dominar los principales drivers de red Docker, garantizando que tus contenedores se comuniquen de forma segura y eficiente.

Requisitos Previos / Entorno de Prueba

Para seguir esta guía, necesitarás un entorno Linux con Docker instalado y funcionando. Se recomiendan las versiones más recientes de Docker Engine (24.x o superior). Para las secciones relativas a la red overlay, será necesario un clúster Docker Swarm mínimo de dos nodos.

Los drivers de red Docker: bridge, host, overlay, macvlan, none

Docker ofrece varios drivers de red, cada uno diseñado para casos de uso y requisitos arquitectónicos específicos. Comprender las diferencias entre estos drivers es fundamental para elegir la solución más adecuada para tu entorno. Cada driver define cómo los contenedores se conectan entre sí y con el mundo exterior.

• Bridge: El driver predeterminado. Crea una red interna privada para los contenedores en un único host.
• Host: Elimina el aislamiento de red entre el contenedor y el host, permitiendo que el contenedor utilice directamente el stack de red del host.
• Overlay: Habilita la comunicación entre contenedores que residen en diferentes hosts Docker, esencial para los clústeres Swarm.
• Macvlan: Asigna una dirección MAC e IP de la red física directamente al contenedor, haciéndolo aparecer como un dispositivo físico en la red.
• None: Deshabilita completamente el networking para el contenedor, útil para contenedores que no necesitan conectividad de red.

Para visualizar las redes disponibles en tu sistema Docker, puedes usar el comando:

docker network ls

Esto te mostrará las redes predeterminadas (bridge, host, none) y cualquier red personalizada que hayas creado.

Bridge network: el default y sus límites

Cuando inicias un contenedor sin especificar una red, Docker lo conecta automáticamente a la red bridge predeterminada. Esta red crea un puente virtual (docker0 en Linux) que permite a los contenedores en el mismo host comunicarse entre sí utilizando sus direcciones IP internas. Sin embargo, esta red tiene limitaciones significativas:

1. Aislamiento limitado: Todos los contenedores en la red bridge predeterminada pueden alcanzarse. No hay aislamiento lógico entre diferentes aplicaciones.
2. Resolución DNS: Los contenedores pueden comunicarse mediante IP, pero la resolución DNS por nombre entre contenedores no es automática en la red bridge predeterminada.
3. Configuración estática: No puedes configurar parámetros específicos como la subred o la puerta de enlace.

Para aplicaciones sencillas o pruebas rápidas, la red bridge predeterminada puede ser suficiente. Pero para entornos de producción con microservicios, es aconsejable pasar a redes bridge definidas por el usuario.

User-defined bridge: aislamiento y DNS automático

Las redes bridge definidas por el usuario ofrecen un aislamiento de red superior y funcionalidades de resolución DNS automática entre los contenedores conectados. Cada red personalizada crea un puente virtual separado, garantizando que solo los contenedores explícitamente conectados a esa red puedan comunicarse entre sí. Esto mejora la seguridad y la capacidad de gestión de la arquitectura.

Para crear una red bridge personalizada:

docker network create --driver bridge --subnet 172.20.0.0/16 mynet

Este comando crea una red llamada mynet con la subred especificada. Ahora puedes iniciar contenedores y conectarlos a esta red:

docker run -d --net mynet --name webserver nginx
docker run -d --net mynet --name appserver myapp:latest

Los contenedores webserver y appserver ahora pueden comunicarse entre sí utilizando sus nombres como hostname, gracias al DNS interno proporcionado por Docker. Para inspeccionar la red y ver los contenedores conectados:

docker network inspect mynet

También puedes asignar una IP específica a un contenedor, aunque es una práctica menos común y a menudo desaconsejada a menos que haya necesidades específicas, dado que Docker gestiona el DHCP dentro de la red:

docker run -d --net mynet --ip 172.20.0.10 --name fixedip_nginx nginx

Host network: cuándo y por qué usarla

El driver host elimina el aislamiento de red entre el contenedor y el host. El contenedor comparte el stack de red del host, lo que significa que no tiene su propia dirección IP separada. Los puertos expuestos por el contenedor se mapearán directamente a los mismos puertos en el host. Esto puede mejorar el rendimiento al eliminar la capa de NAT, pero también introduce riesgos de seguridad y colisiones de puertos.

Casos de uso:

• Aplicaciones de alto rendimiento: Si cada milisegundo cuenta y la latencia del stack de red virtual es un problema.
• Monitorización: Herramientas de monitorización que necesitan acceder a todas las interfaces de red del host.
• Servicios de red específicos: Contenedores que deben interactuar directamente con el hardware de red o protocolos de bajo nivel.

Para iniciar un contenedor en modo de red host:

docker run -d --net host --name myhostapp myapp:latest

Es fundamental ser consciente de los riesgos: el contenedor tiene acceso a todas las interfaces de red del host, incluidos los servicios que escuchan en localhost. Este driver debe usarse con precaución y solo cuando sea estrictamente necesario.

Overlay network: comunicación multi-host con Swarm

Las redes overlay son la columna vertebral de la comunicación entre contenedores distribuidos en múltiples hosts Docker. Son esenciales para las arquitecturas de microservicios que necesitan escalabilidad horizontal y orquestación, como las gestionadas por Docker Swarm. Un clúster Swarm utiliza un almacén de clave-valor interno (basado en Raft) para mantener el estado de la red y de los servicios.

Para crear una red overlay (requiere un clúster Swarm inicializado):

1. Inicializa Swarm (si no lo has hecho ya):

docker swarm init --advertise-addr <IP_MANAGER>

1. Crea la red overlay:

docker network create --driver overlay --attachable myoverlay

El flag --attachable permite a los contenedores standalone (que no forman parte de un servicio Swarm) conectarse a esta red.

1. Inicia un servicio Swarm en la red:

docker service create --replicas 3 --network myoverlay --name myweb nginx

Los contenedores del servicio myweb, aunque distribuidos en diferentes hosts del clúster Swarm, podrán comunicarse entre sí y con otros contenedores en la red myoverlay utilizando sus nombres de servicio o nombres de contenedor (si se crearon con --attachable).

Macvlan: contenedores con IP en la red física

El driver macvlan permite asignar una dirección MAC única a un contenedor, haciéndolo aparecer como un dispositivo físico en la red. Esto significa que el contenedor obtiene una dirección IP directamente de la red física, como si fuera una máquina virtual o un dispositivo hardware. Es particularmente útil en escenarios que requieren:

• Integración con redes legacy: Aplicaciones que necesitan estar en la misma subred que dispositivos físicos o VM preexistentes.
• Aislamiento IP: Cuando un contenedor debe tener una IP pública o una IP en una VLAN específica.
• IoT/Networking especializado: Contenedores que deben interactuar con dispositivos de red de bajo nivel o protocolos específicos.

Para crear una red macvlan:

docker network create -d macvlan --subnet=192.168.1.0/24 --gateway=192.168.1.1 -o parent=eth0 mymacvlan

Sustituye eth0 por la interfaz de red física de tu host. Ahora puedes iniciar un contenedor que obtiene una IP de tu red física:

docker run -d --net mymacvlan --name mymacvlan_nginx nginx

Atención: la configuración macvlan puede ser compleja y requiere un buen conocimiento de la red física. Asegúrate de que tu switch soporte el modo promiscuous o que hayas configurado las VLAN correctamente, si aplica.

Docker Compose networking: ejemplos prácticos

Docker Compose simplifica la gestión de aplicaciones multi-contenedor definiendo su configuración (incluida la red) en un archivo docker-compose.yml. Por defecto, Compose crea una red bridge definida por el usuario para todos los servicios definidos en el archivo, permitiéndoles comunicarse por nombre.

Ejemplo de docker-compose.yml:

version: '3.8'
services:
  web:
    image: nginx
    ports:
      - "80:80"
    networks:
      - app_net

  app:
    image: myapp:latest
    networks:
      - app_net

networks:
  app_net:
    driver: bridge
    ipam:
      config:
        - subnet: 172.21.0.0/24

En este ejemplo, web y app están en la misma app_net y pueden comunicarse entre sí. Si omites la sección networks a nivel de servicio, Compose los conectará a la red default creada automáticamente para el proyecto.

Lee también: Proxmox VE: Guía Completa de Instalación y Configuración (2026)

Debugging redes Docker: herramientas y comandos

La depuración de problemas de red Docker es una habilidad fundamental. Aquí tienes algunos comandos útiles:

• Inspeccionar una red: docker network inspect proporciona detalles completos sobre la red, incluidos los contenedores conectados, subred, puerta de enlace y configuraciones DNS.
• Lista de redes: docker network ls muestra todas las redes Docker presentes.
• Probar la conectividad entre contenedores: Utiliza docker exec para entrar en un contenedor y usar herramientas como ping o curl para probar la conectividad hacia otros contenedores o servicios externos.

docker exec webserver ping appserver

• Comprobar los logs: Los logs de los contenedores a menudo pueden revelar errores de conexión o timeouts.
• Firewall: Asegúrate de que los firewalls en el host (como ufw o firewalld) no estén bloqueando el tráfico entre los contenedores o hacia los puertos expuestos.

Un error común es olvidar que los contenedores en diferentes redes bridge no pueden comunicarse entre sí sin un enrutamiento explícito o el uso de redes overlay. Cuando un servicio no responde, lo primero que hay que hacer es verificar la configuración de red del contenedor y del host.

Errores Comunes y Resolución de Problemas

1. Contenedores que no se comunican: A menudo causado por contenedores en redes bridge diferentes. Verifica con docker network inspect y asegúrate de que los servicios pertinentes estén en la misma red bridge definida por el usuario, o considera una red overlay para entornos multi-host.
2. Puertos no accesibles desde el exterior: Podría ser un problema de mapeo de puertos (-p puerto_host:puerto_contenedor) o un firewall en el host que bloquea el tráfico. Asegúrate de que el puerto en el host esté abierto y no en conflicto.
3. Fallo en la resolución DNS: Si los contenedores no pueden resolverse por nombre, verifica que estén en la misma red bridge definida por el usuario o que tu servicio DNS externo esté configurado correctamente si estás usando un driver diferente. docker network inspect mostrará los servidores DNS configurados para la red.
4. Conflicto de direcciones IP: Si creas redes con subredes que se superponen a tu red física o a otras redes Docker, podrías tener problemas de enrutamiento. Elige subredes no utilizadas.

Según una investigación de 2024, el 40% de los incidentes relacionados con Docker en producción son atribuibles a configuraciones de red erróneas o insuficientes (Container Security Report, 2024).

FAQ — Preguntas Frecuentes

¿Qué es la red docker0?

docker0 es la interfaz bridge virtual creada por Docker cuando se instala, que actúa como punto de conexión para la red bridge predeterminada. Todos los contenedores que no especifican una red se conectan a docker0 y obtienen una IP de su rango. Es gestionada automáticamente por Docker y no debería ser modificada manualmente.

¿Cuándo debería usar una red bridge definida por el usuario en lugar de la predeterminada?

Deberías usar una red bridge definida por el usuario para la mayoría de tus aplicaciones en producción. Ofrece un mejor aislamiento entre los contenedores, una resolución DNS automática por nombre de contenedor y una mayor flexibilidad en la configuración de la subred. Esto crea un entorno más seguro y gestionable para tus microservicios.

¿Cuál es la diferencia entre host network y bridge network?

La bridge network crea un aislamiento de red entre el contenedor y el host, asignando al contenedor una IP interna y utilizando NAT para la comunicación externa. La host network, en cambio, elimina este aislamiento, permitiendo al contenedor utilizar directamente la interfaz y el stack de red del host. La host network es más performante pero menos segura.

¿Puedo conectar un contenedor a varias redes?

Sí, un contenedor puede conectarse a varias redes simultáneamente. Esto puede ser útil para escenarios complejos en los que un contenedor debe comunicarse con servicios en redes diferentes, como un contenedor que expone una API en una red pública y se comunica con una base de datos en una red privada y aislada. Puedes hacerlo especificando múltiples flags --net o configurando múltiples redes en Docker Compose.

Conclusiones con Puntos Clave Operativos

La comprensión y la correcta configuración del networking Docker son pilares fundamentales para la estabilidad y la seguridad de tus aplicaciones contenerizadas. Desde la simplicidad de la red bridge predeterminada hasta la complejidad estratégica del overlay para los clústeres Swarm, cada driver tiene un papel específico. Adoptar redes bridge definidas por el usuario para el aislamiento y la resolución DNS interna es una buena práctica irrenunciable para entornos de producción. Recuerda siempre inspeccionar tus redes (docker network inspect) y probar la conectividad para prevenir y resolver rápidamente los problemas. Invertir tiempo en dominar estas configuraciones te ahorrará horas de depuración y garantizará la resiliencia de tus sistemas.

Actualizado: junio de 2026

Lee también: Lynis Audit Linux: Guía Práctica de Hardening 2026

Lee también: Ansible Windows: Gestión de Servidores con WinRM y Módulos Core

Lee también: Zabbix 7 en Ubuntu: Instalación y Configuración Completa (2026)