Modos de red Docker: bridge, host, none y container — rendimiento y cuándo usar cada uno

En la terminal aparece en verde «Container started», el servicio está en marcha, pero curl sigue dando timeout. Revisé docker logs tres veces sin errores, el mapeo -p 8080:80 está configurado, la ruta está bien, el firewall apagado. ¿Dónde está el problema?

Al final descubrí que el modo de red era incorrecto. Pensaba que con docker run -p bastaba, sin saber que Docker tiene cuatro modos de red: bridge, host, none y container.

Si tú también has vivido el «el contenedor arranca pero no puedo acceder», o si la configuración de red de Docker te suena a chino, este artículo explica con lenguaje directo las diferencias, los principios y los escenarios de uso de esos cuatro modos. Sin teoría compleja de espacios de nombres de Linux: solo lo que de verdad necesitas en la práctica.

Primero, la base de la red Docker: el puente docker0

¿Qué es docker0? La puerta de enlace de tus contenedores

Al instalar Docker, el sistema crea automáticamente una interfaz virtual llamada docker0. Puedes imaginarla como la puerta de enlace de un edificio: todos los contenedores (los «inquilinos») que quieran salir a internet pasan por ella.

Abre la terminal y prueba este comando:

ip addr show docker0

Verás una salida similar a esta:

docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

¿Ves ese 172.17.0.1? Es la dirección IP de docker0. Docker asigna a cada contenedor nuevo una IP del rango 172.17.0.0/16, por ejemplo 172.17.0.2, 172.17.0.3, y así sucesivamente.

Mira también la lista de redes de Docker:

docker network ls

NETWORK ID     NAME      DRIVER    SCOPE
7f8a2b3c9d4e   bridge    bridge    local

Esta red bridge predeterminada usa internamente el puente docker0.

veth pair: el «walkie-talkie» que conecta contenedores

Solo con docker0 no basta. Los contenedores están en su «habitación independiente» (espacio de nombres de red) — ¿cómo se comunican con docker0?

La respuesta es veth pair. Es como un par de walkie-talkies: un extremo dentro del contenedor se llama eth0, el otro en el host se llama vethXXX (por ejemplo veth9a7b4c), y hablan entre sí.

Prueba a iniciar un contenedor:

docker run -d --name test-nginx nginx

En el host, mira las interfaces:

ip addr | grep veth

Verás un dispositivo nuevo que empieza por veth. Entra al contenedor:

docker exec test-nginx ip addr

Dentro hay una interfaz eth0 con IP 172.17.0.2. Ese eth0 y el vethXXX del host forman un par: los paquetes salen de eth0, llegan al instante a vethXXX, pasan por docker0 y salen a internet por la interfaz del host (por ejemplo eth0 o ens33).

La cadena completa es así:

Interior del contenedor (172.17.0.2)
  ↓ eth0
  ↓ (veth pair)
  ↓ vethXXX
  ↓
Puente docker0 (172.17.0.1)
  ↓ reenvío NAT
  ↓
Interfaz del host (por ejemplo 192.168.1.100)
  ↓
Internet

Parece enrevesado, pero funciona muy rápido. Si haces ping a la IP del contenedor, la latencia suele ser de fracciones de milisegundo.

La verdad es que la primera vez que vi veth pair también me costó entenderlo. Luego lo vi claro: es un cable virtual, un extremo en el contenedor y otro en docker0, nada más.

Modo Bridge: la opción predeterminada de Docker

¿Por qué bridge es el predeterminado?

Si no especificas un modo de red, Docker usa bridge automáticamente. La razón es simple: equilibrio entre aislamiento y facilidad de uso.

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

Empezar ahora →Anuncio

El modo bridge da a cada contenedor una IP independiente, evita conflictos de puertos y permite exponer servicios al host con el parámetro -p. Para la mayoría de escenarios, es suficiente.

Por ejemplo, levanta dos contenedores Nginx:

docker run -d -p 8080:80 --name web1 nginx
docker run -d -p 8081:80 --name web2 nginx

Ambos escuchan en el puerto 80, pero al estar en espacios de red independientes no hay conflicto. En el host accedes por 8080 y 8081; Docker hace el reenvío NAT de puertos.

Con docker inspect web1 mira la configuración de red:

"Networks": {
    "bridge": {
        "IPAddress": "172.17.0.2",
        "Gateway": "172.17.0.1"
    }
}

El contenedor obtiene la IP privada 172.17.0.2 y la puerta de enlace es docker0 en 172.17.0.1.

Bridge predeterminado vs bridge personalizado: una diferencia clave

Aquí hay una trampa. En la red bridge predeterminada (docker0), los contenedores solo pueden comunicarse por IP, no hay resolución por nombre de contenedor.

Prueba esto:

docker run -d --name db mysql
docker run -it --name app alpine ping db

Verás que el ping falla. Hay que usar ping 172.17.0.2 con la IP explícita.

Pero si creas una red bridge personalizada:

docker network create mynet
docker run -d --name db --network mynet mysql
docker run -it --name app --network mynet alpine ping db

Esta vez funciona. Las redes bridge personalizadas incluyen DNS: el nombre del contenedor sirve como hostname.

Por eso en producción se recomienda red personalizada en lugar del docker0 predeterminado: el descubrimiento de servicios es mucho más cómodo, sin IPs fijas en el código.

El secreto del parámetro -p: reenvío NAT

Cuando usas -p 8080:80, Docker añade una regla NAT en iptables del host:

iptables -t nat -L -n | grep 8080

Verás algo como:

DNAT  tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:8080 to:172.17.0.2:80

Significa: todo el tráfico al puerto 8080 del host se reenvía al 172.17.0.2:80 del contenedor.

Por eso acceder desde fuera a http://IP-del-host:8080 llega al servicio del contenedor: Docker hace la traducción de direcciones.

Escenarios donde encaja el modo bridge

En resumen, bridge encaja en:

• Arquitectura de microservicios: varios contenedores que colaboran, con aislamiento y comunicación entre sí (red bridge personalizada)
• Entorno de desarrollo: levantar servicios rápido para probar; el bridge predeterminado suele bastar
• Aplicaciones web con mapeo de puertos: blog, API, etc.

En rendimiento, bridge tiene cierto overhead de NAT y veth pair, pero en la práctica, para la mayoría de aplicaciones esa pérdida es despreciable. Pocos escenarios llegan de verdad al cuello de botella de red; no te preocupes por eso desde el primer día.

Modo Host: cuando el rendimiento manda

¿Qué es el modo host? Red «a pelo»

El modo host es lo más directo: el contenedor no tiene red independiente, comparte la pila de red del host.

Al iniciar el contenedor añade --net=host:

docker run -d --net=host --name web nginx

El contenedor no tiene IP propia ni eth0 separado; comparte las interfaces del host. Lo que ves dentro del contenedor con ip addr es igual que en el host.

Lo más importante: ya no hace falta -p para mapear puertos. Si el servicio escucha en el 80, desde fuera accedes con IP-del-host:80 directamente.

¿Dónde está la ventaja de rendimiento?

El modo host evita docker0, veth pair y NAT. Los paquetes entran y salen por la interfaz del host, casi como un proceso nativo.

En pruebas, bajo alta concurrencia host suele ser un 5-10% más rápido que bridge. No suena a mucho, pero para aplicaciones muy sensibles a la latencia (trading de alta frecuencia, servidores de juegos en tiempo real) esa diferencia importa.

Tuve un caso: Nginx como reverse proxy con decenas de miles de peticiones por segundo. Al pasar a host, la latencia P99 bajó de 12 ms a 9 ms. Solo 3 milisegundos, pero para ese proyecto valían mucho dinero.

Trampas y costes del modo host

Mejor rendimiento, pero también más problemas:

Trampa 1: conflictos de puertos

Al usar los puertos del host directamente, dos contenedores en el mismo puerto fallan al arrancar:

docker run -d --net=host nginx  # escucha en 80
docker run -d --net=host nginx  # otro en 80, error: Address already in use

Es como levantar dos Nginx en el host. ¿Varias instancias? Cambia el puerto dentro del contenedor o no uses host.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Trampa 2: el servicio debe escuchar en 0.0.0.0

Si el servicio solo escucha en 127.0.0.1, desde fuera no llegas. Tiene que ser 0.0.0.0 para acceso externo.

Una vez puse un servicio Node.js en host con app.listen(3000, 'localhost') en el código; desde fuera no conectaba. Cambié a app.listen(3000, '0.0.0.0') y listo.

Trampa 3: pierdes aislamiento de red

El contenedor accede a todos los recursos de red del host; el riesgo de seguridad sube. Si ejecutas código de terceros no confiable, host es pedir problemas.

¿Cuándo usar host?

En la práctica, solo cuando tengas un cuello de botella real de rendimiento. En la mayoría de casos, el overhead de bridge no es el problema.

Host encaja en:

• Herramientas de monitorización: Prometheus, Grafana, ELK, que necesitan acceso directo a la red del host
• Proxies de alto rendimiento: Nginx, HAProxy como balanceadores, buscando latencia mínima
• Bases de datos: MySQL, Redis sensibles a red (con cuidado en seguridad)

Si tu aplicación está en miles de peticiones por segundo o menos, no te compliques con host; bridge alcanza.

Modos None y Container: escenarios especiales

Modo none: sandbox sin red

None es literal: el contenedor no tiene red.

docker run -it --net=none alpine sh

Dentro, ip addr solo muestra loopback (lo): sin internet ni acceso desde otros contenedores.

¿Cuándo usar none?

Sinceramente, casi nunca lo he usado en producción. Los casos son muy estrechos:

• Pruebas de seguridad: ejecutar código no confiable, aislado para evitar fugas de datos
• Procesamiento offline: solo cálculo local, sin comunicación de red
• Configuración manual de red: casos raros con herramientas como pipework para configurar veth a mano

Si no haces investigación de seguridad o redes muy custom, none casi no te hará falta.

Modo container: dos contenedores «comparten red»

Container hace que un contenedor use el espacio de nombres de red de otro. Suena raro; un ejemplo lo aclara:

# Primero un contenedor
docker run -d --name web nginx

# El segundo comparte la red de web
docker run -it --net=container:web alpine sh

Ambos comparten la misma configuración de red: misma IP, mismos puertos, mismas interfaces. En el segundo contenedor, localhost:80 llega al nginx.

Caso típico: el Pod de Kubernetes

Los Pods de Kubernetes usan en esencia el modo container. Varios contenedores en un Pod comparten la red de un contenedor «pause».

Por ejemplo, aplicación y sidecar de logs en el mismo Pod se hablan por localhost sin exponer puertos fuera.

Con Docker solo (sin Kubernetes), container se usa poco: bridge + red personalizada también permite comunicación entre contenedores, con más flexibilidad.

Posicionamiento de estos dos modos

None y container son más «capacidades de bajo nivel» que soluciones del día a día. Dan flexibilidad en casos raros, pero el 80% del tiempo no los necesitas.

Recuerda:

• None: aislamiento total de red (muy poco frecuente)
• Container: común en Kubernetes y orquestadores; raro en Docker puro

Decisión práctica: cómo elegir el modo de red

Un diagrama de decisión simple

¿Qué modo usar en tu proyecto? Resumo un flujo sencillo:

¿Necesitas aislamiento de red?
│
├─ No → ¿Hay cuello de botella de rendimiento?
│       │
│       ├─ Sí → Modo host (cuidado con seguridad)
│       └─ No → Modo bridge (más seguro)
│
└─ Sí → ¿Comunicación entre contenedores por nombre?
        │
        ├─ Sí → Red bridge personalizada
        └─ No → Red bridge predeterminada

Escenarios especiales:

• Sin red en absoluto → Modo none
• Contenedores en un Pod de Kubernetes → Modo container

Tabla rápida por escenario

Tres errores comunes

Error 1: «Host siempre es lo mejor»

Falso. Host sacrifica aislamiento y flexibilidad; en muchos casos la mejora de rendimiento es irrelevante.

He visto a gente poner todo en host: conflictos de puertos y problemas de seguridad por montones. Sí, iba un poco más rápido, pero el costo de mantenimiento se multiplicó.

La realidad: el 80% de las apps van bien con bridge; no te dejes engañar por «mejor rendimiento».

Error 2: «El bridge predeterminado basta»

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

Empezar →Anuncio

En producción, no es lo ideal. El bridge predeterminado no resuelve nombres; varios servicios acaban con IPs fijas o variables de entorno frágiles.

Crear red bridge personalizada es trivial:

docker network create mynet
# Indica la red en docker-compose.yml

La realidad: dos minutos de configuración ahorran horas de depuración.

Error 3: «Todos los problemas de red son por el modo equivocado»

No siempre. A menudo es firewall, iptables o DNS.

Pasos de diagnóstico:

1. Desde el contenedor, ¿ping a la puerta de enlace (IP de docker0)?
2. ¿Ping a la IP externa del host?
3. ¿Reglas iptables con DROP?
4. ¿Configuración del daemon Docker (/etc/docker/daemon.json)?

La realidad: el modo es solo el primer paso; hay que diagnosticar de forma sistemática.

Trucos avanzados

Truco 1: un contenedor en varias redes

A veces un contenedor debe estar en dos redes (frontend y backend):

docker network create frontend
docker network create backend

docker run -d --name web --network frontend nginx
docker network connect backend web

Ahora web está en frontend y backend a la vez.

Truco 2: control preciso de IPs

En red personalizada puedes fijar subred y puerta de enlace:

docker network create \
  --driver bridge \
  --subnet 192.168.10.0/24 \
  --gateway 192.168.10.1 \
  mynet

docker run -d --network mynet --ip 192.168.10.100 nginx

Útil cuando necesitas IP fija (listas blancas de firewall, por ejemplo).

Truco 3: herramientas para diagnosticar red

Dentro del contenedor, estas ayudan:

# Instalar herramientas de red
docker exec -it <container> apk add curl netcat-openbsd

# Probar conectividad
docker exec <container> nc -zv <host> <port>

# Ver tabla de rutas
docker exec <container> ip route

# Captura de paquetes (requiere permisos en el host)
docker exec <container> tcpdump -i eth0

Conclusión

Repaso rápido de los cuatro modos:

• Bridge: predeterminado, apto para la mayoría; en producción, bridge personalizado
• Host: rendimiento primero, menos aislamiento; solo con cuello de botella real
• None: sin red; uso muy raro
• Container: red compartida; sobre todo en Kubernetes

Recuerda: no hay un modo «mejor», solo el más adecuado.

Si acabas de empezar con Docker, usa bridge predeterminado. Cuando surja un problema concreto, ajusta: descubrimiento de servicios incómodo → bridge personalizado; rendimiento insuficiente → valora host. No te obsesiones al inicio con cuál es «óptimo».

Te recomiendo probar en mano: crea una red personalizada, levanta varios contenedores y comprueba si se alcanzan por nombre. Hacerlo una vez vale más que leer diez artículos.

Si en un proyecto real te atascas con la red de Docker, comenta y lo vemos. El tema es profundo, pero con estos conceptos resuelves el 80% de los problemas por tu cuenta.