最近在排查一个跨容器通信的问题，重新梳理了一遍 Docker 的网络模型。很多人用 Docker 只关心 -p 端口映射，但理解底层的网络模式对排查问题和做架构设计都很关键。

Bridge 模式：默认但不万能

Bridge 是 Docker 的默认网络模式。每个容器都连接到一个虚拟网桥 docker0，容器之间通过这个网桥通信。每个容器有自己的网络命名空间和独立 IP（通常是 172.17.0.x 段）。

# 查看默认 bridge 网络
docker network inspect bridge

# 创建自定义 bridge
docker network create --driver bridge my-app-net

Bridge 模式的核心特点：

• 容器之间通过 IP 互通（同一 bridge 内）
• 容器到宿主机需要通过 NAT（-p 端口映射）
• 自定义 bridge 支持 DNS 解析——容器可以用容器名互访，而默认 bridge 不行

最常见的坑：用默认 bridge 时，容器之间只能用 IP 互访，不能用容器名。一旦容器重建 IP 变了就断了。生产环境永远用自定义 bridge。

Host 模式：性能优先的选择

Host 模式让容器直接使用宿主机的网络栈——没有独立 IP，没有 NAT，没有端口映射。容器里监听的端口就是宿主机的端口。

docker run --network host nginx
# nginx 直接监听宿主机的 80 端口

Host 模式的适用场景：

• 高性能网络应用：跳过了 veth pair 和 iptables NAT，网络延迟降低约 10-20%
• 需要大量端口的应用：比如 FTP 服务器的被动模式需要大范围端口
• 网络调试：容器内的 tcpdump 能直接抓宿主机流量

代价是失去了网络隔离——容器能看到宿主机的所有网络接口和端口。在多租户环境下这是安全隐患。

Overlay 模式：跨主机通信的正解

当你的应用部署在多台物理机上时，Bridge 模式就不够用了——不同主机上的容器无法直接通信。Overlay 网络通过 VXLAN 隧道在多台主机之间建立一个虚拟的二层网络。

# 初始化 Swarm（overlay 需要 swarm 或外部 KV store）
docker swarm init

# 创建 overlay 网络
docker network create --driver overlay --attachable my-overlay

# 在不同主机上的容器都能加入这个网络
docker run --network my-overlay my-service

Overlay 的工作原理：每个数据包会被封装一层 VXLAN 头，通过宿主机之间的 UDP 4789 端口传输，到达目标主机后解封装。对容器来说，它们像在同一个二层网络里一样直接用 IP 通信。

性能开销约 5-10%（VXLAN 封装/解封装），对大多数应用可以接受。如果对延迟极度敏感，考虑 macvlan 或 SR-IOV。

选型建议

• 单机开发/测试：自定义 bridge，简单够用
• 单机高性能：host 模式，省掉 NAT 开销
• 多机集群：overlay，Swarm 或 Kubernetes 自动管理
• 需要容器有真实 IP：macvlan，容器直接出现在物理网络中

大部分场景用自定义 bridge 就够了。只有当你遇到跨主机通信或性能瓶颈时，才需要考虑 overlay 或 host。