Docker 网络配置：从容器隔离到服务互通的底层机制与实战

一、当容器间无法通信：Docker 网络的常见陷阱

Docker 容器的网络配置看似简单——docker run 默认就能联网，但一旦涉及多容器通信、跨主机访问、网络隔离等需求，就会遇到各种问题：容器间通过 IP 互访但 IP 每次重建都会变化、容器无法访问宿主机的服务、DNS 解析在自定义网络中失效、端口映射与防火墙规则冲突。这些问题的根源是对 Docker 网络模型的底层机制理解不足。

Docker 网络的核心抽象是 Network Namespace——每个容器拥有独立的网络栈（网卡、路由表、iptables 规则），容器间的通信必须通过 Docker 创建的虚拟网络设备进行。理解这个底层模型，是解决网络问题的前提。

二、Docker 网络模型：从 Bridge 到 Overlay 的演进

Docker 提供了多种网络驱动，每种驱动对应不同的隔离级别和通信范围。

flowchart TB
    subgraph Bridge网络
        A[容器A: 172.17.0.2] --> B[docker0 网桥: 172.17.0.1]
        C[容器B: 172.17.0.3] --> B
        B --> D[NAT: 宿主机网卡]
        D --> E[外部网络]
    end

    subgraph 自定义Bridge
        F[容器C: 172.20.0.2] --> G[app-network: 172.20.0.1]
        H[容器D: 172.20.0.3] --> G
        G --> I[DNS 自动解析]
        F -.->|通过容器名通信| H
    end

    subgraph Overlay网络
        J[主机1: 容器E] --> K[VXLAN 隧道]
        L[主机2: 容器F] --> K
        K --> M[跨主机通信]
    end

    style B fill:#4dabf7,color:#fff
    style G fill:#51cf66,color:#fff
    style K fill:#ff6b6b,color:#fff

三、生产级 Docker 网络配置方案

3.1 自定义 Bridge 网络

# docker-compose.yml: 多服务网络配置
version: '3.8'

services:
  # API 网关
  gateway:
    image: nginx:1.25
    networks:
      - frontend
      - backend
    ports:
      - "80:80"
      - "443:443"
    depends_on:
      - user-service
      - order-service

  # 用户服务
  user-service:
    image: user-service:latest
    networks:
      - backend
      - db-network
    environment:
      - DB_HOST=user-db
      - DB_PORT=5432
    deploy:
      resources:
        limits:
          memory: 512M

  # 订单服务
  order-service:
    image: order-service:latest
    networks:
      - backend
      - db-network
      - cache-network
    environment:
      - DB_HOST=order-db
      - CACHE_HOST=redis
    deploy:
      resources:
        limits:
          memory: 1G

  # 数据库
  user-db:
    image: postgres:16
    networks:
      - db-network
    volumes:
      - user-db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=${DB_PASSWORD}

  order-db:
    image: postgres:16
    networks:
      - db-network
    volumes:
      - order-db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD=${DB_PASSWORD}

  # 缓存
  redis:
    image: redis:7-alpine
    networks:
      - cache-network
    command: redis-server --requirepass ${REDIS_PASSWORD}

networks:
  # 前端网络：网关与外部通信
  frontend:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.1.0/24

  # 后端网络：服务间通信
  backend:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.2.0/24

  # 数据库网络：服务与数据库通信
  db-network:
    driver: bridge
    internal: true  # 内部网络，无法访问外网
    ipam:
      config:
        - subnet: 172.20.3.0/24

  # 缓存网络
  cache-network:
    driver: bridge
    internal: true
    ipam:
      config:
        - subnet: 172.20.4.0/24

volumes:
  user-db-data:
  order-db-data:

3.2 容器与宿主机通信

# 方案一：使用 host.docker.internal 访问宿主机服务
# Docker Desktop (macOS/Windows) 内置支持
docker run --rm -it \
  --add-host=host.docker.internal:host-gateway \
  alpine ping host.docker.internal

# 方案二：在 Linux 上手动配置
# 获取 docker0 网桥 IP 作为宿主机地址
DOCKER_BRIDGE_IP=$(ip addr show docker0 | grep 'inet ' | awk '{print $2}' | cut -d/ -f1)
echo "宿主机在容器中的地址: $DOCKER_BRIDGE_IP"

# 方案三：使用 host 网络模式（容器直接使用宿主机网络栈）
# 注意：失去了网络隔离，仅用于调试或特殊场景
docker run --rm -it --network host alpine curl http://localhost:8080

3.3 网络性能调优

# Docker 网络性能调优参数

# 1. 调整 MTU（最大传输单元）
# 默认 1500，在 VXLAN/Overlay 网络中建议降低以避免分片
docker network create \
  --driver bridge \
  --opt com.docker.network.driver.mtu=1400 \
  optimized-network

# 2. 调整 net.core.somaxconn（TCP 连接队列大小）
sysctl -w net.core.somaxconn=65535

# 3. 调整 net.ipv4.tcp_max_syn_backlog（SYN 队列大小）
sysctl -w net.ipv4.tcp_max_syn_backlog=65535

# 4. 开启 TCP Fast Open
sysctl -w net.ipv4.tcp_fastopen=3

# 5. 容器内网络参数调优
docker run --rm -it \
  --sysctl net.core.somaxconn=65535 \
  --sysctl net.ipv4.tcp_max_syn_backlog=65535 \
  --ulimit nofile=65535:65535 \
  nginx:1.25

# 6. 使用 IPvlan 网络驱动（绕过网桥，直接使用宿主机网卡）
# 性能优于 Bridge，但需要 Linux 内核 4.2+
docker network create -d ipvlan \
  --subnet=192.168.1.0/24 \
  --gateway=192.168.1.1 \
  -o parent=eth0 \
  ipvlan-network

3.4 网络故障排查工具

# Docker 网络故障排查命令集

# 1. 查看容器网络信息
docker inspect <container_id> --format '{{json .NetworkSettings}}'

# 2. 查看网络详情
docker network inspect <network_name>

# 3. 进入容器网络命名空间排查
# 获取容器 PID
PID=$(docker inspect -f '{{.State.Pid}}' <container_id>)
# 使用 nsenter 进入网络命名空间
nsenter -t $PID -n ip addr
nsenter -t $PID -n netstat -tlnp
nsenter -t $PID -n tcpdump -i eth0 -nn port 80

# 4. 检查 iptables 规则（Docker 通过 iptables 实现 NAT）
iptables -t nat -L -n -v
iptables -L DOCKER -n -v

# 5. 检查 DNS 解析
docker run --rm -it --network <network_name> alpine nslookup <service_name>

# 6. 测试容器间连通性
docker run --rm -it --network <network_name> alpine ping -c 3 <target_container>
docker run --rm -it --network <network_name> alpine curl -v http://<service_name>:8080/health

# 7. 抓包分析
# 在宿主机上抓取容器流量
tcpdump -i docker0 -nn -w /tmp/docker-capture.pcap
# 在容器内抓包
docker exec <container_id> tcpdump -i eth0 -nn -c 100

四、Docker 网络配置的代价与架构权衡

Docker 网络方案的代价需要审慎评估：

Bridge 网络的 NAT 性能开销：默认 Bridge 网络通过 iptables NAT 实现容器与外部通信，每个数据包都需要经过 NAT 转换，在高吞吐场景下（如微服务间高频 RPC 调用），NAT 规则的匹配和地址转换会消耗 CPU 资源。实测中，Bridge 网络的吞吐量比 Host 网络低约 10%-20%。

Overlay 网络的延迟开销：Overlay 网络通过 VXLAN 隧道实现跨主机通信，VXLAN 封装增加了约 50 字节的头部开销，同时引入了额外的封包/解包处理。跨主机通信的延迟比同主机通信高约 0.5-1ms，在延迟敏感的场景中不可忽视。

internal 网络的安全局限：internal: true 标记阻止了容器访问外网，但无法阻止同一网络内的容器互相攻击。如果某个容器被攻陷，同一网络内的其他容器仍然暴露。需要配合网络策略（Network Policy）实现更细粒度的隔离，但 Docker 原生不支持 Network Policy，需要借助 Kubernetes 或 Cilium 等方案。

适用边界：自定义 Bridge 网络适合单主机多容器场景；Overlay 网络适合多主机集群场景；Host 网络适合对网络性能要求极高的场景。

禁用场景：当容器需要处理大量 UDP 流量（如视频流、游戏服务器）时，Bridge 网络的 NAT 转换可能成为瓶颈，应考虑 Host 网络或 IPvlan/Macvlan 驱动。

五、总结

Docker 网络配置的核心是在"隔离性"与"通信效率"之间找到平衡。自定义 Bridge 网络通过 DNS 自动解析简化了容器间通信，internal 网络通过禁止外网访问提升了安全性，Overlay 网络通过 VXLAN 隧道实现了跨主机通信。在实际落地中，建议按服务角色划分网络：前端网络暴露对外端口，后端网络承载服务间通信，数据库网络设为 internal 防止数据泄露。网络故障排查时，优先使用 nsenter 进入容器命名空间，结合 tcpdump 和 iptables 定位问题。核心原则是：网络配置不是一次性决策，而是随服务拓扑演进而持续调整的架构决策。