Redes de Docker para el Homelab: Bridge, Macvlan y Proxy Inverso

Si auto-alojas servicios con Docker Compose, la red es donde la mayoría de las configuraciones se enredan. Los contenedores necesitan comunicarse entre sí, con internet y con tu red local, pero el puente predeterminado de Docker no siempre lo hace sencillo.

Esta guía cubre los cuatro modos de red de Docker que realmente usarás en un homelab, cuándo elegir cada uno y cómo integrar todo detrás de un proxy inverso.

Los Cuatro Modos de Red

Docker proporciona cuatro controladores de red integrados relevantes para configuraciones de homelab:

Controlador	Caso de Uso	Aislamiento
bridge	Predeterminado. Los contenedores en el mismo puente se comunican libremente.	Interno al host
host	El contenedor comparte la pila de red del host.	Ninguno
macvlan	El contenedor obtiene su propia MAC e IP en la LAN física.	Por contenedor
none	Sin red. Para cargas de trabajo aisladas sin conexión.	Completo

1. Redes Bridge (Predeterminado)

Cada stack de Compose obtiene su propia red bridge por defecto. Los contenedores dentro de ese stack se resuelven entre sí por el nombre del servicio:

# docker-compose.yml
services:
  app:
    image: nginx
    networks:
      - frontend
  db:
    image: postgres:16
    networks:
      - backend

networks:
  frontend:
  backend:

Esto funciona bien para el aislamiento de un solo stack, pero crea un problema: dos stacks separados en diferentes bridges no pueden comunicarse directamente. Ahí es donde una red externa compartida por múltiples stacks ayuda.

Patrón de Red Externa Compartida

# stack-a/docker-compose.yml
services:
  service-a:
    image: my-app
    networks:
      - shared-net

networks:
  shared-net:
    external: true
    name: shared-net

Crea la red compartida una vez:

docker network create shared-net

Ahora cualquier stack que se conecte a shared-net puede alcanzar service-a por su nombre de contenedor o servicio. Esta es la base del patrón de proxy inverso.

2. Modo Host

El modo host vincula el contenedor directamente a la pila de red del host — sin mapeo de puertos, sin NAT. El rendimiento es idéntico al de un proceso nativo:

services:
  adguard:
    image: adguard/adguardhome
    network_mode: host
    restart: unless-stopped

Cuándo usarlo:

• Servidores DNS (AdGuard Home, Pi-hole) que necesitan el puerto 53
• Servicios que necesitan ver la IP real del cliente sin protocolo proxy
• Herramientas de red como netdata o snmp-exporter

Cuándo evitarlo:

• Cualquier servicio detrás de un proxy inverso (pierdes el enrutamiento a nivel de puerto)
• Servicios con múltiples instancias (no puedes ejecutar dos contenedores en el mismo puerto)

3. Macvlan

Macvlan le da a cada contenedor su propia IP y MAC en tu LAN física, haciéndolo aparecer como un dispositivo separado para tu router:

services:
  nginx-proxy:
    image: nginx
    networks:
      macvlan-net:
        ipv4_address: 192.168.1.100

networks:
  macvlan-net:
    driver: macvlan
    driver_opts:
      parent: eth0
    ipam:
      config:
        - subnet: 192.168.1.0/24
          gateway: 192.168.1.1
          ip_range: 192.168.1.100/28

Pros:

• El contenedor obtiene acceso directo a la LAN, ideal para servicios que exponen puertos
• Sin conflictos de puertos entre contenedores en diferentes IPs

Contras:

• ⚠️ El host no puede alcanzar los contenedores macvlan desde sí mismo (por defecto). Esto es una limitación del kernel. Existen soluciones (macvlan en una subinterfaz), pero son complicadas.
• Cada contenedor consume una IP de la LAN — bien en un homelab, derrochador a escala.
• Se necesitan reservas DHCP por contenedor si quieres IPs persistentes.

Mejor para: Servicios que necesitan transmitir en la red local (DLNA, mDNS, Home Assistant con integraciones locales).

4. El Patrón de Proxy Inverso (Recomendado)

Para la mayoría de los homelabs, la arquitectura más limpia es un solo proxy inverso (Traefik o Nginx Proxy Manager) en una red compartida, con todos los servicios web conectados a esa misma red:

# traefik/docker-compose.yml
services:
  traefik:
    image: traefik:v3
    container_name: traefik
    restart: unless-stopped
    command:
      - --providers.docker=true
      - --providers.docker.exposedbydefault=false
      - --entrypoints.web.address=:80
      - --entrypoints.websecure.address=:443
    ports:
      - 80:80
      - 443:443
    networks:
      - proxy
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./acme.json:/acme.json
      - ./traefik.yml:/traefik.yml

networks:
  proxy:
    name: proxy
    external: false  # El primer stack lo crea

# whoami/docker-compose.yml (ejemplo de backend)
services:
  whoami:
    image: traefik/whoami
    labels:
      - traefik.enable=true
      - traefik.http.routers.whoami.rule=Host(`whoami.example.com`)
      - traefik.http.routers.whoami.entrypoints=websecure
      - traefik.http.routers.whoami.tls.certresolver=letsencrypt

networks:
  default:
    external: true
    name: proxy

Por qué funciona este patrón

• Cada servicio se conecta a la red proxy
• Solo Traefik expone los puertos 80 y 443 al mundo
• El tráfico fluye: Internet → Host:443 → Traefik → Contenedor backend
• La terminación TLS ocurre en un solo lugar
• Agregar un nuevo servicio son solo etiquetas y conectarse a la red

Elegir el Enfoque Correcto

Escenario	Recomendación
Servicios web detrás de un dominio	Proxy inverso en una red compartida
Servicios DNS / DHCP / de red	Modo host
Servidores multimedia que necesitan transmisión LAN	Macvlan o modo host
Bases de datos internas	Bridge (solo interno del stack)
Trabajos por lotes aislados	Bridge o none

Errores Comunes

Conflictos de puertos — Dos contenedores no pueden vincular el mismo puerto del host. Usa un proxy inverso para que ningún servicio web necesite exponer puertos sin procesar.

Resolución DNS — En redes bridge, los contenedores se resuelven entre sí por el nombre del servicio, no por el nombre del contenedor. Usa el nombre del servicio de Compose.

Bucles de reinicio con dependencias de red — Usa depends_on con moderación. Diseña servicios para reintentar conexiones en lugar de depender del orden de inicio.

Redes no utilizadas se acumulan — Limpia periódicamente:

docker network prune

Resumen

• Las redes bridge predeterminadas están bien para stacks aislados
• Usa macvlan solo cuando los contenedores necesiten aparecer como dispositivos LAN independientes
• Usa modo host solo para servicios críticos de red (DNS, agentes de monitoreo)
• Construye todo lo demás detrás de un proxy inverso en una red compartida

Esta arquitectura mantiene tu homelab manejable, seguro y extensible. Una vez que la red está bien configurada, agregar nuevos servicios toma minutos en lugar de sesiones de depuración.

---

¿Tienes preguntas sobre un escenario específico de redes Docker? Ponte en contacto — estaremos encantados de ayudarte.