1. Docker 网络背后的核心概念
在深入之前，先建立三个基础认知，后面所有模式都围绕它们展开：
- Network Namespace —— 每个容器拥有独立的网络栈（网卡、路由、iptables 规则）。
- veth pair —— 一对虚拟网线，一端插在容器里，另一端插在宿主机的网桥上。
- 端口映射 ——
-p 8080:80通过宿主机 iptables DNAT 规则，把宿主机流量转发进容器。
2. bridge 网络：默认的隔离模式
这是 docker run 默认使用的网络，也是单机部署最常用的选择。
$ docker network ls
NETWORK ID NAME DRIVER SCOPE
b7a1c2e4f0a1 bridge bridge local
$ docker run -d --name web -p 8080:80 nginx
$ docker inspect web --format '{{.NetworkSettings.Networks.bridge.IPAddress}}'
172.17.0.2工作原理与特点：
- 所有挂在同一个 bridge 上的容器共享一个 docker0 网桥，可以互相通过容器 IP 通信。
- 容器默认只能通过端口映射对外暴露，网络隔离性好。
- 同网桥容器之间可直接通信，但生产环境建议拆成自定义 bridge，并显式指定网络名，而不是用默认的
docker0。
最佳实践
docker network create --driver bridge mynet 创建自定义网络，
使用自定义网络时容器间可用容器名直接解析（内置 DNS），比记住 IP 更可靠。
3. host 网络：共享宿主机网络栈
容器不再拥有自己的网络命名空间，直接复用宿主机的网络栈。
$ docker run -d --name nginx-host --network host nginx
# 此时无需 -p 映射，nginx 直接监听宿主机的 80 端口- 性能最高 —— 跳过网桥与 NAT，延迟最低，适合对性能敏感、端口敏感的中间件（如部分高性能代理、监控 agent）。
- 牺牲隔离 —— 容器与宿主机共享端口空间，端口冲突风险上升。
- 不建议默认使用 —— 会破坏「容器可移植」的核心价值。
4. overlay 网络：跨主机的魔法
在 Swarm 或 Kubernetes 多节点场景下，容器分布在不同宿主机上，需要一个跨主机的虚拟网络。
$ docker network create -d overlay --attachable prod-net
# 使用 VXLAN 封装，节点间通过 4789/UDP 隧道通信
$ docker run -d --network prod-net --name app-a nginx
$ docker run -d --network prod-net --name app-b nginx
$ docker exec app-a ping app-b
PING app-b (10.0.0.6) 56(84) bytes of data.- overlay 网络内置 DNS 服务发现，容器可以用服务名跨主机互相访问。
- 底层用 VXLAN 隧道封装，天然具备跨网段能力。
- 单机场景下不要使用 overlay，会带来不必要的封装开销。
注意
真实生产环境（Kubernetes）通常使用 CNI 插件（Calico、Flannel、Cilium）实现 overlay 网络，
不再直接依赖 Docker 内置网络。理解概念即可，选型交给编排平台。
5. 选型建议
把常见需求映射到网络模式，直接对号入座：
| 场景 | 推荐模式 | 理由 |
| 单机常规业务容器 | 自定义 bridge | 隔离 + DNS 服务发现 |
| 端口敏感/极致性能 | host | 无 NAT 开销，低延迟 |
| 跨主机服务发现 | overlay / K8s CNI | 隧道 + 内置 DNS |
| 临时测试容器 | 默认 bridge | 开箱即用 |
网络问题排查时，先用 docker network inspect 看拓扑，再用
docker exec 进容器用 ip addr / traceroute 验证连通性，
90% 的「网络不通」都能通过这两步解决。
