Modos de red Docker en la práctica: guía para elegir entre bridge, host y overlay

Empezando con un fallo real

A las dos de la madrugada, el servicio API de producción empezó a dar timeout.

El contenedor estaba en ejecución — docker ps mostraba running —, el firewall desactivado, el mapeo de puertos bien configurado y los logs sin errores. Tras media hora de diagnóstico, casi al límite, descubrimos el problema: el modo de red Docker era incorrecto. Usábamos el bridge por defecto, pero el servicio necesitaba acceder a una base de datos en otro nodo; el bridge solo comunica dentro de un host, no entre hosts.

Este caso expone un problema bastante común: muchos desarrolladores conocen los modos bridge, host y overlay, pero no saben cuándo usar cada uno. Yo mismo caí en esa trampa al principio.

Al terminar este artículo tendrás un diagrama de decisión completo y una tabla comparativa de rendimiento para los tres modos. La próxima vez que tengas un problema de red, pregúntate primero «¿un solo host o entre hosts?» y evitarás dar vueltas como yo.

Bridge: la opción por defecto, rey de la comunicación en un solo host

Bridge es el modo de red por defecto de Docker.

Cuando ejecutas docker run sin especificar --network, el contenedor se conecta automáticamente a este modo. El principio es sencillo: Docker crea en el host un puente virtual llamado docker0; cada contenedor recibe una IP independiente (normalmente 172.17.x.x) y se conecta al puente mediante un par veth (cable de red virtual).

¿Suena abstracto? En la práctica, tratas el contenedor como una máquina virtual con IP privada y usas NAT (mapeo de puertos) para comunicarte con el exterior.

Casos de uso

Despliegue de varios contenedores en un solo host: Bridge es la primera opción.

Entornos de desarrollo, pruebas e incluso algunos escenarios de producción sin comunicación entre hosts. Simple, seguro y sin configuración extra.

Ejemplo de configuración

Bridge es el modo por defecto, así que no hace falta especificarlo:

# bridge por defecto, IP automática, requiere -p para mapear puertos
docker run -d -p 8080:80 nginx

Pero hay un problema: en el bridge por defecto, los contenedores solo pueden comunicarse por IP, no por nombre. Si levantas dos contenedores y quieres que se hablen, tienes que buscar la IP manualmente.

¿Cómo consultarla? Con docker inspect:

# Levantar dos contenedores
docker run -d --name web nginx
docker run -d --name db redis

# Ver la IP del contenedor web
docker inspect web | grep IPAddress
# Salida: 172.17.0.2

# Desde el contenedor db, ping a web (solo por IP)
docker exec db ping 172.17.0.2

Cada comunicación exige buscar la IP; si el contenedor se reinicia, la IP puede cambiar.

La solución recomendada es crear un bridge personalizado:

# Crear red personalizada
docker network create --subnet=192.168.100.0/24 my-net

# Levantar contenedores en la red personalizada
docker run -d --network my-net --name web nginx
docker run -d --network my-net --name db redis

# web puede hacer ping a db directamente (resolución DNS automática)
docker exec web ping db

Así el nombre del contenedor funciona como dominio. Me sorprendió gratamente: pensaba que habría que configurar DNS a mano, pero Docker lo resuelve solo.

Host: máximo rendimiento, mínimo aislamiento

El modo Host es algo «directo»: el contenedor usa la pila de red del host.

Sin IP independiente, sin NAT, sin par veth. Las interfaces de red del contenedor son las del host; el rendimiento se acerca al nativo, con costo casi nulo.

¿No será el mejor rendimiento? Sí, pero a cambio pierdes el aislamiento.

Casos de uso

Para escenarios sensibles al rendimiento de red, Host es la mejor opción.

Servidores de juegos, comunicación en tiempo real (WebSocket, streaming de vídeo), sistemas de trading de alta frecuencia: unas decenas de microsegundos de latencia importan, y Host elimina ese costo.

KiloClaw - OpenClaw gestionado para empresas: orquestación de agentes IA y enrutamiento inteligente

Empezar →Anuncio

También sirve para depuración de red: ejecutas tcpdump dentro del contenedor y capturas el tráfico del host sin configuración extra.

Ejemplo de configuración

Aún más simple: ni siquiera necesitas -p:

# modo host, el contenedor ocupa el puerto 80 del host
docker run -d --network host nginx

Tras el arranque, acceder al puerto 80 del host es acceder al nginx del contenedor.

Riesgos a tener en cuenta

Hay varias trampas.

Conflicto de puertos: si nginx ya corre en el host (puerto 80), un segundo contenedor en modo Host que quiera el 80 fallará al arrancar.

El error suele ser:

docker: Error response from daemon: driver failed programming external connectivity on endpoint xxx: Bind for 0.0.0.0:80 failed: port is already allocated.

Para diagnosticarlo, revisa qué ocupa el puerto en el host:

# Ver puertos en uso
netstat -tuln | grep :80
# o
ss -tuln | grep :80

# Ver el proceso
lsof -i :80

Si hay un proceso ocupándolo, detén el servicio o cambia el puerto. En modo Host no puedes usar -p; debes modificar la configuración de la aplicación dentro del contenedor (por ejemplo, que nginx escuche en 8080).

Seguridad: el contenedor ve todas las interfaces de red del host, incluidas red interna, externa e incluso VPN. Si el contenedor se compromete, el atacante accede a todos los recursos de red del host. En producción, piénsalo bien.

Host se usa poco; en la mayoría de casos Bridge basta. Pero ante un cuello de botella de rendimiento o necesidad real de baja latencia, Host merece considerarse — si aceptas el costo en aislamiento.

Overlay: la solución para comunicación entre hosts

Bridge solo comunica dentro de un host; Host rinde bien pero tampoco cruza hosts. ¿Cómo se comunican contenedores en varios servidores? Con Overlay.

La red Overlay se basa en túneles VXLAN: une contenedores en distintos hosts en una LAN virtual, como si estuvieran en la misma máquina.

Principio central

VXLAN es la clave de Overlay.

Encapsula el tráfico del contenedor, lo envía por un «túnel» a otro host, lo desencapsula y lo entrega al contenedor destino. Ese proceso lo gestiona el VTEP (VXLAN Tunnel Endpoint), administrado automáticamente en Docker Swarm.

Analogía: envías un paquete de Pekín a Shanghái; la mensajería lo mete en una caja grande, lo transporta por la red logística, lo abre en destino y entrega el paquete. VXLAN es la «caja grande», el tráfico del contenedor es el «paquete» y el VTEP es el empaquetado/desempaquetado.

La ventaja de VXLAN: independientemente de cómo esté conectada la red física, los contenedores ven la misma LAN virtual, con IPs unificadas y comunicación sencilla.

Requisito: Overlay necesita un clúster Swarm o un KV store externo (como Consul). Docker en un solo nodo no basta; hace falta colaboración multi-nodo.

¿Por qué Swarm? Overlay debe gestionar IPs de contenedores en varios hosts, conexiones VTEP e información de enrutamiento; hace falta un coordinador centralizado, y Swarm cumple ese papel. Sin Swarm, puedes usar Consul o Etcd como KV store, pero la configuración es más compleja.

Casos de uso

En un clúster Docker Swarm, Overlay es la única opción.

Despliegue de microservicios entre hosts: por ejemplo, el servicio web en el nodo A y la base de datos en el nodo B; Overlay los une en una red virtual y pueden comunicarse por nombre de contenedor, sin configurar IPs.

Kubernetes tiene un concepto similar (red CNI), aunque la configuración difiere. Si usas K8s, los conceptos de Overlay de este artículo también ayudan a entender su red.

Ejemplo de configuración (flujo completo)

Overlay es más complejo que Bridge o Host; primero hay que inicializar Swarm:

# 1. Inicializar Swarm en el primer host
docker swarm init --advertise-addr 192.168.1.10

# Mostrará un join token, por ejemplo:
# docker swarm join --token SWMTKN-xxx 192.168.1.10:2377

# 2. Unir otros hosts al Swarm (copia el comando anterior)
docker swarm join --token SWMTKN-xxx 192.168.1.10:2377

# 3. Crear red Overlay
docker network create --driver overlay --subnet=10.0.1.0/24 my-overlay

# 4. Levantar contenedores en distintos hosts, en la misma Overlay
# En el nodo A
docker run -d --network my-overlay --name web nginx

# En el nodo B
docker run -d --network my-overlay --name db redis

# 5. Probar comunicación (web puede hacer ping a db, ¡entre hosts!)
docker exec web ping db

La primera vez que configuré Overlay, olvidé inicializar Swarm e intenté crear la red overlay directamente; el error fue «This node is not a swarm manager». Entonces entendí que Overlay depende de Swarm.

Otro detalle: --subnet=10.0.1.0/24. Se recomienda un bloque /24 (256 IPs) para evitar conflictos con otras redes. Clústeres grandes pueden usar /16, pero planifica bien el rango de IPs.

Comparativa de rendimiento: los datos hablan

¿Cuánto difieren realmente los tres modos? Aquí tienes datos de prueba para una comparación directa.

Datos clave (prueba de estrés de 72 horas)

Según un informe de prueba en producción de CSDN, el comportamiento bajo estrés es:

Hallazgos clave

Algunos números llaman la atención:

Host es notablemente más rápido que Bridge. La latencia media baja de 128μs a 32μs — 96μs de diferencia, ≈14% de mejora. En throughput, Host se acerca al nativo y Bridge ronda el 80%. Si tu aplicación procesa miles de peticiones por segundo, la brecha se nota.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

El costo NAT de Bridge no es pequeño. El uso de CPU sube de 0.9 a 1.8 núcleos, casi el doble: cada petición externa pasa por NAT, una capa extra de procesamiento.

La encapsulación VXLAN de Overlay pesa más. La comunicación entre hosts requiere encapsular y desencapsular; la latencia supera a Bridge y el uso de CPU es mayor. Adecuado para escenarios distribuidos, no para alto rendimiento en un solo host.

Impacto real

Los números pueden parecer abstractos, pero en la práctica la diferencia importa.

En trading de alta frecuencia, cada microsegundo cuenta: 32μs en Host frente a 128μs en Bridge puede decidir si capturas una orden. En una web convencional, con latencias de ida y vuelta de cientos de milisegundos, unos microsegundos pasan desapercibidos.

No te fijes solo en los números; combínalos con tu escenario. ¿Sensibilidad al rendimiento? Prioriza Host. ¿Seguridad? Bridge por defecto. ¿Entre hosts obligatorio? Overlay, aceptando el costo de rendimiento.

Cómo probar en tu entorno

Si quieres medir la diferencia en tu propio entorno:

Prueba de latencia: con ping o iperf3

# Desde el contenedor A, ping al contenedor B (modo bridge)
docker exec container-a ping container-b

# Throughput con iperf3 (instala iperf3 antes)
docker exec container-a iperf3 -c container-b

Monitorización de CPU: con docker stats

# Ver uso de CPU del contenedor
docker stats --no-stream

Monitorización de tráfico: con tcpdump

# Capturar tráfico del host (modo host, captura directa)
docker exec -it container-host tcpdump -i eth0

# Capturar tráfico bridge (especifica el puente)
tcpdump -i docker0

Recomiendo ejecutar una prueba de estrés antes de desplegar en producción y comprobar si el modo elegido aguanta la carga. Mejor descubrirlo antes que después del go-live.

Diagrama de decisión: del escenario al modo

Después de tanto contexto, ¿cómo elegir? Aquí va una lógica sencilla.

Flujo de decisión en tres pasos

Ante una configuración de red, sigue este flujo:

Paso 1: ¿Necesitas comunicación entre hosts?

Si varios contenedores están en servidores distintos y deben comunicarse (web en el nodo A, base de datos en el nodo B), necesitas cruzar hosts.

• SÍ → Paso 2
• NO → Paso 3

Paso 2: ¿Usas Swarm?

Para comunicación entre hosts hay dos caminos: Docker Swarm (Overlay) o enrutamiento manual (Host + iptables).

• SÍ → Red Overlay (lo más simple; Swarm lo gestiona)
• NO → Considera Macvlan o Host + enrutamiento (complejo; escenarios especiales)

Paso 3: ¿Es sensible al rendimiento de red?

Si la aplicación es sensible a latencia y throughput (trading de alta frecuencia, comunicación en tiempo real, juegos), prioriza rendimiento.

• SÍ → Modo Host (pero evalúa el riesgo de seguridad)
• NO → Modo Bridge (opción segura por defecto)

Tabla de recomendaciones por escenario

Un consejo

No te obsesiones desde el inicio con «cuál es el modo óptimo».

En la mayoría de casos, Bridge basta. Ajusta cuando surjan problemas:

• Descubrimiento de servicios complicado → bridge personalizado
• Rendimiento insuficiente → considera Host, evaluando el costo de seguridad
• Necesidad entre hosts → Overlay, aceptando el costo VXLAN

He visto equipos que configuran Host desde el principio y acaban con conflictos de puertos y fallos de seguridad. Bridge resuelve el 90% de los escenarios; no hace falta sobreoptimizar.

Buenas prácticas en producción

Cada modo tiene ventajas e inconvenientes. ¿Cómo usarlos con seguridad en producción?

Bridge: red personalizada + DNS

El bridge por defecto tiene un problema grave: los contenedores solo se comunican por IP, no por nombre.

En producción, crea un bridge personalizado:

# Crear red personalizada con subred (evita conflictos)
docker network create --subnet=192.168.100.0/24 --name my-app-net

# Levantar servicios en la red personalizada
docker run -d --network my-app-net --name web-server nginx
docker run -d --network my-app-net --name redis-cache redis

# web-server puede acceder a redis-cache (resolución DNS automática)
docker exec web-server ping redis-cache

El descubrimiento de servicios no requiere IPs manuales: el nombre del contenedor funciona como dominio.

Planifica bien la subred. Evita el 172.17.x.x por defecto si puede chocar con la red interna de la empresa. Se recomienda 192.168.100.0/24 o 10.10.10.0/24; coordina el rango de IPs con el equipo de operaciones.

Host: refuerzo de seguridad imprescindible

Host rinde bien, pero la seguridad es débil: el contenedor ve todas las interfaces del host, incluidas red interna, externa y VPN.

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

Si usas Host en producción, haz al menos dos cosas:

Primero: limitar permisos del contenedor. Con --cap-drop elimina capabilities Linux innecesarias, como CAP_NET_RAW (evita capturas de paquetes arbitrarias):

docker run -d --network host --cap-drop NET_RAW nginx

Segundo: monitorizar tráfico anómalo. Vigila el comportamiento de red del contenedor: conexiones masivas hacia el exterior, acceso a interfaces internas sensibles, etc. Puedes usar Prometheus + Grafana o herramientas de seguridad de red.

Host se usa poco en producción salvo cuello de botella real de rendimiento. En la mayoría de casos, Bridge + red personalizada basta.

Overlay: tamaño de subred + estabilidad de Swarm

La clave de Overlay es la encapsulación VXLAN, con costo no despreciable.

Algunos puntos de optimización:

Controla el tamaño de la subred: se recomienda /24 (256 IPs); clústeres grandes pueden usar /16 (≈65.000 IPs), pero planifica con antelación para evitar conflictos.

# Recomendado: bloque /24
docker network create --driver overlay --subnet=10.0.1.0/24 my-overlay

Monitoriza el uso de CPU: la encapsulación VXLAN aumenta el costo de CPU, especialmente con alto tráfico. Usa docker stats o Prometheus; si la CPU se dispara, optimiza (ajusta MTU, reduce comunicación entre hosts).

Prioriza estabilidad de red entre nodos Swarm: Overlay depende de Swarm; si la red entre nodos es inestable, Overlay falla. En producción, asegura baja latencia y poca pérdida de paquetes entre nodos; una red interna dedicada es lo ideal.

Resumen: tres principios clave

En resumen, tres frases:

1. Un solo host: Bridge por defecto

El 90% de los escenarios. Seguro, simple, listo al arrancar. Si el descubrimiento de servicios es un dolor, usa un bridge personalizado: los nombres de contenedor bastan.

2. Rendimiento crítico: Host

Latencia y throughput sensibles: Host es la mejor opción. Pero recuerda: mejor rendimiento, peor aislamiento. En producción, refuerza la seguridad.

3. Entre hosts: Overlay obligatorio

Contenedores en varios servidores que deben comunicarse: Overlay es la solución. Requiere clúster Swarm; la configuración es más compleja que Bridge o Host, pero es imprescindible para cruzar hosts.

Consejo práctico

La próxima vez que tengas un problema de red Docker, pregúntate: ¿un solo host o entre hosts?

Un solo host: Bridge por defecto. ¿Rendimiento insuficiente? Considera Host, evaluando el costo de seguridad. Entre hosts: Overlay, aceptando el costo VXLAN.

No te obsesiones desde el inicio con «cuál es el modo óptimo»; empieza con Bridge y ajusta cuando haga falta. Yo lo hice al revés: configuré Overlay primero y en escenarios de un solo host no servía de nada.

Si aún no dominas los fundamentos de bridge/host/none/container, te recomiendo leer el artículo 11 de la serie, «Modos de red Docker explicados», antes de este contenido avanzado.

Referencias

"Docker ofrece varios drivers de red, incluidos bridge, host, overlay, macvlan, etc., cada uno apto para distintos escenarios. La documentación oficial detalla la configuración y los casos de uso de cada modo."

"Las redes Overlay se basan en túneles VXLAN y requieren un clúster Swarm o un KV store externo; son ideales para comunicación entre contenedores en distintos hosts. La documentación oficial incluye el flujo de configuración completo."

"Guía de gestión de red en Swarm: cómo crear redes overlay, gestionar redes de servicios y buenas prácticas de comunicación entre hosts."

"Informe de mejores prácticas de configuración de red Docker (prueba de cero pérdida en producción), con datos de prueba de estrés de 72 horas: latencia, throughput y tasa de pérdida de Host, Bridge y Overlay."

"Docker Network Tests under Host/Bridge Mode: comparación detallada del rendimiento de Host y Bridge, con métodos de prueba de latencia y datos experimentales."