设计docker容器网络架构应按场景匹配驱动：单机用自定义bridge，集群用overlay，直通用macvlan/ipvlan；服务需分层隔离；避免localhost陷阱；预留可观测性支持。
设计 Docker 容器网络架构，关键不是选最“高级”的驱动，而是根据部署规模、安全要求、性能瓶颈和运维能力做匹配。默认的 bridge 模式能跑通 80% 的本地开发和单机测试场景，但生产环境往往需要更明确的划分和控制。
按部署规模选基础网络类型
单机开发或测试环境：用自定义 bridge 网络，避免和默认 docker0 冲突，也方便清理和复用。
- 创建带子网的独立网络：
docker network create --subnet 192.168.120.0/24 --gateway 192.168.120.1 app-net - 容器启动时显式指定：
docker run --network app-net ... - 好处是 IP 可预测、DNS 自动解析（容器名即主机名）、隔离性比默认 bridge 更强
多节点集群（如 Swarm 或接入 K8s）：必须用 overlay 网络，它通过 VXLAN 封装实现跨宿主二层互通。
- 需初始化 Swarm：
docker swarm init - 创建可跨节点的服务网络：
docker network create -d overlay --attachable my-overlay - 服务或容器加入后，自动获得跨主机 DNS 解析和负载均衡
高性能或物理网络直通场景（如数据库代理、DPDK 应用）：考虑 macvlan 或 ipvlan，让容器拥有真实局域网 IP 和 MAC。
- macvlan 示例：
docker network create -d macvlan --subnet=192.168.1.0/24 --gateway=192.168.1.1 -o parent=eth0 macvlan_net - 注意：交换机需开启混杂模式或配置 MAC 学习；ipvlan 更节省 MAC 表项，适合高密度部署
服务通信要分层隔离
不要把所有容器扔进同一个网络。按访问关系划分子网：
- 前端服务（Nginx、React）→ 公共 bridge 网络，映射端口对外暴露
- 后端 API → 单独的内部 bridge 网络，不对外发布端口
- 数据库、缓存 → 更严格的内部网络（甚至用 none + host 端口绑定），只允许特定后端容器访问
这样既能利用 Docker 内置 DNS（backend 可直接访问 redis），又避免前端容器意外连上数据库端口。
外部系统连接要绕过 localhost 陷阱
容器里写 DB_HOST=localhost 是常见错误——它指向容器自身，不是宿主机。
- Linux 宿主机：用宿主机实际局域网 IP（如
192.168.1.50），可通过ip -4 route | awk '{print $9}'快速获取 - macOS / Windows（Docker Desktop）：用特殊 DNS 名
host.docker.internal - 生产环境外部 DB：建议走独立网络段，并在防火墙上限制源 IP（只放行容器所在子网）
别忽略可观测性与排障支撑
网络架构设计要留出调试入口：
- 为关键网络创建时加标签：
--label env=prod --label team=backend，便于后续过滤和审计 - 保留一个诊断容器（如
nicolaka/netshoot），随时进入网络命名空间抓包：docker run -it --network container:myapp nicolaka/netshoot tcpdump -i eth0 - 对延迟敏感服务，禁用 iptables NAT（改用 host 模式或 ipvlan），并监控 eBPF 路径（如 Cilium 提供的流日志）
