Docker网络核心原理与实战：从Bridge到Overlay，彻底吃透容器网络-开发者社区

理解Docker容器的网络？很多人刚开始接触Docker时，往往是在“容器跑起来、端口映射好”这一步停下来，觉得网络不过就是docker run -p那点事。可真到了要部署多容器应用、跨主机通信、排查莫名其妙的连不上时，才发现自己在Docker网络这一块全是盲区。这篇文章不打算做成官方文档的翻译，而是从实际使用场景出发，把Docker网络的底细翻出来讲清楚，既有原理也有实操，带你把它真正吃透。适合刚入门不久、想系统搞懂Docker网络的新手，也适合已经在用Docker但经常踩网络坑的开发者，看完全篇你会发现自己排查网络问题的思路会清晰很多。

1. 先搞明白：Docker网络到底解决什么问题

Docker网络的核心，是给一个个“进程级隔离”的容器，提供一套独立可控的网络环境。平时我们熟悉的虚拟机，每个系统自带一块网卡、一个IP，天然就是“一台电脑”；但容器在操作系统层面只是进程，默认并不能直接拥有网络设施。如果不做任何配置，容器启动后就像是待在一个没有网卡、没有IP的黑屋子里，谁也找不到它，它也出不去。

所以Docker网络要做的事情，通俗点讲就是：给每个容器“登记”一张身份证（IP地址），配一根网线（虚拟网卡接口），再把它连到一个可以互通的世界里（网络驱动）。这个世界的形态可以不同，但目的都一样——让容器之间能通信，让外界能访问到容器，同时保证该隔离的时候隔离得住。

1.1 网络命名空间：容器网络的基石

理解Docker网络，绕不开Linux的网络命名空间（Network Namespace）。命名空间是Linux内核提供的一种隔离机制，它可以把网络栈整体“复制”成独立的一份，包括网卡、IP地址、路由表、iptables规则，全都在自己的命名空间内各玩各的。

打个比方：宿主机是一栋大楼，大楼有一整套门牌号系统和内部电话网络。每个容器就是楼里的一个房间，Docker给每个房间装了一套独立的内部电话线和小门牌号系统，房间之间互相看不见对方的电话簿，除非管理员把它们拉到同一条总线上。

Docker每启动一个容器，都会自动创建一个新的网络命名空间，并给这个空间准备：

loopback接口（lo），用来容器自己跟自己通信；
eth0接口，由一对veth虚拟网线设备拉出来，一头插在容器里，另一头挂在宿主机的虚拟交换机上；
默认路由，一般指向官方默认网关，也就是docker网桥的地址；
一套独立的iptables规则，防止容器间的防火墙规则相互干扰。

这套机制的好处是隔离性很强，坏处是如果不懂它，出现问题时会觉得毫无头绪。比如你在容器里执行ifconfig只看到 lo 和 eth0，看不到宿主机的eth0/eth1，这就是命名空间隔离在起作用。

1.2 veth pair和Linux Bridge是怎么配合的

光有网络命名空间还不够，容器要真正具备网络能力，需要用“网线”把命名空间和宿主机连起来。Docker默认用的网线，就是Linux的veth pair（虚拟以太网对）。

veth pair可以理解成一根“虚拟网线”，它永远成对出现，一头连着容器内的eth0，另一头连着宿主机命名为vethxxx的接口。数据包从容器这头进去，会原封不动地从另一头出来，像电话线两头各插一台话机。

宿主机那一端，Docker会把它挂到一个Linux Bridge上，也就是一个工作在二层的“虚拟交换机”。以默认的bridge网络为例，Linux会创建一个名为docker0的网桥，默认网段是172.17.0.0/16，所有连到docker0上的容器，都能在同一个网段里互相直接用IP通信，就像所有电脑插在同一个交换机上一样。

数据流向大概是：容器内进程 -> 容器eth0 -> veth对 -> docker0网桥 -> 宿主机路由/iptables逻辑 -> 外部网络。出方向靠NAT（网络地址转换）把容器内私有IP翻译成宿主机IP，入方向靠端口映射把宿主机的端口请求转发给容器。整个过程对容器来说是透明的，它觉得自己就是一台拥有独立IP的机器。

1.3 为什么要理解默认的“三层链路”

很多人在排查问题时，脑子里缺的就是“数据到底走哪条路”的图景。比如容器A访问容器B，通常情况下是：

A的域名解析，找到B的IP；
A把包发给自己的默认网关（即网桥IP）；
网桥根据MAC地址表转发到B的veth接口；
B的eth0收到包，交给B的协议栈。

之所以强调这条链路，是因为只要中间任何一环出问题（网桥损坏、iptables拦截、路由缺失），表现就会是“能ping通网关，但ping不通对方”，或者“直接抛连接超时”。如果你脑子里有这条链路，排查手段就会从“胡乱重启”变成“按链路一段一段测”。

2. 五种网络驱动怎么选：很多坑都出在选错模式上

Docker内置了五种网络驱动，分别对应不同的使用场景，它们的隔离级别、性能、跨主机能力截然不同。我见过太多人不管三七二十一全部用默认bridge，或者为了图方便全局用host，结果各种问题接踵而来。这里把五种模式挨个讲透。

2.1 Bridge：最常用的默认选择

bridge模式是Docker的默认网络，也是大多数单机场景下的首选。它靠Linux Bridge + veth pair + iptables实现容器互联和端口映射，属于“NAT型”网络。

关键特性是：

默认分配私有网段（docker0）；
容器间可以通过IP互相访问；
出外网走NAT，入站走端口映射；
隔离性好，容器默认不暴露给外部。

用bridge时最常见的问题是“同网段容器能互相ping通，但跨网桥的容器完全不通”，以及“容器重启后IP变了，之前写死IP的配置全部失效”。前者是因为不同网桥就是“不同交换机”，没有路由三层互通；后者是因为Docker的IP分配是随机的。

使用建议：单机多容器互联，优先用自定义bridge网络，而不是默认bridge。自定义bridge额外提供了内置DNS服务发现，这一点对微服务部署是天大的帮助，后面实操部分会细说。

2.2 Host：性能优先，隔离靠边

host模式直接取消网络命名空间隔离，让容器和宿主机共用同一个网络栈。容器里的eth0就是宿主机的eth0，容器监听端口等于直接在宿主机上监听端口，不再需要-p映射，因为根本没有NAT这一层。

host模式最大的优点是性能极高，几乎没有网络转换开销，延迟极低。适合对网络性能极其敏感的服务，比如一些实时数据采集、高性能网关类容器。

但它的代价也很明显：

端口冲突问题突出，容器里绑定的端口占用的本质上是宿主机端口；
失去了网络隔离，容器能直接看到宿主机网络接口；
在容器里执行ifconfig看到的是宿主机全部网卡，这对一些依赖自己拥有独立网络设施的软件来说很别扭。

我记得有次给一个日志采集容器配host模式，本想图性能，结果它默认监听514端口，宿主机上的系统日志服务也占用514，两边直接冲突，折腾了大半天才定位。如果不需要极致的性能，我通常不推荐host。

2.3 None：完全隔离，用在哪

none模式下的容器只有一个loopback接口，没有eth0，没有IP，没有网络连接，彻底跟外界隔绝。这种模式下容器跑起来只能自己访问自己，连外网都出不去。

看起来有点像“自断经脉”，但确实有适用场景：

运行安全要求极高的任务，比如密码哈希计算、密钥生成，不希望在网络上留下痕迹；
做离线类型的任务，容器只依赖本地文件，不涉及任何通信；
测试自己在自定义网络环境下的能力，比如你要手动给容器配复杂的网卡链路时。

另外，当你用--network none创建容器后，还能通过docker network connect把它连到某个已有网络，达到一种“一开始隔离，需要的时候再接入”的效果。就类似一台电脑先不插网线，装好系统后再按需插线，灵活度很高。

2.4 Overlay：跨主机通信的正确打开方式

overlay驱动解决的是多台宿主机上容器的互相通信问题。它不依赖宿主机之间物理网络的二三层互通，而是把所有参与节点的容器网络“叠加”到一个统一的虚拟子网上，底层通过VXLAN技术封装隧道传输数据。

使用overlay网络时，每台宿主机上的容器无论物理分布如何，只要接入同一个overlay网络，都像在同一个局域网里一样，直接用私有IP互访。

搭建overlay网络的典型方式：

# 先初始化Docker Swarm集群，overlay天然配合Swarm docker swarm init # 在manager节点创建overlay网络 docker network create -d overlay --subnet=10.99.0.0/24 --gateway=10.99.0.1 my-overlay # 启动服务时加入该网络 docker service create --name web --network my-overlay --replicas 3 nginx

overlay的关键点在于：它不仅是网络虚拟化，还自带跨主机的服务发现和负载均衡。服务名在集群内可以被任意解析到多个副本IP，Docker内置的VIP（虚拟IP）机制会做流量分担。

踩坑提醒：overlay网络创建后，如果你发现docker service ps能看到服务正常，但容器之间Ping不通，优先检查VXLAN端口（默认UDP 4789）是否被宿主机防火墙拦截，以及所有节点的时钟是否同步。VXLAN隧道对时间同步要求比较高，时间漂移会导致隧道建不起来。

2.5 Macvlan：让容器直接拥有真实网络身份

macvlan驱动比bridge更进一步，它给每个容器分配一个物理局域网内的真实IP地址，并附带一个独立的MAC地址，让容器看起来就是直接插在局域网交换机上的一台物理设备。

应用场景很典型：家里或者公司内网里，希望每个容器直接获得网段内IP，能被其他非Docker设备直接访问；又或者需要一个低延迟、无NAT开销的环境。比如我在搭一个家庭媒体中心时，就曾用macvlan让所有容器直接获得192.168.1.x的局域网IP，这样手机、电视、电脑访问每个服务都非常顺畅，不需要记各种映射端口。

但macvlan的坑也很深：

宿主机与macvlan容器之间默认不能通信，因为macvlan默认不允许父接口与子接口直接互通，数据包会被交换机“回收”，要么加一个同网段的macvlan子接口，要么老老实实走外部访问；
无线网卡（Wi-Fi）上没法用macvlan，很多路由器会过滤掉多MAC地址帧；
分配IP时需要自己仔细规划，避免和局域网内已有设备冲突。

如果你需要跨主机通信，macvlan依赖的是底层物理网络的连通性，要求所有宿主机在同一个二层网络里。这跟overlay不一样，overlay对底层网络拓扑要求低很多。

3. 实操拆解：从创建网络到实现容器互联

讲了这么多理论，现在来点实际的。这一节我带你完整走一遍多容器应用的网络搭建过程。

3.1 创建自定义Bridge网络的关键参数

默认的bridge网络虽然能用，但功能有限。我强烈建议在实际项目中创建自定义bridge网络，核心原因是它能提供内置DNS服务发现。所谓服务发现，就是你直接用容器名或network别名就能访问对方，而不是去背那一长串随机IP。

创建自定义网络命令：

# 创建自定义bridge网络，指定网段 docker network create \ --driver bridge \ --subnet 192.168.88.0/24 \ --gateway 192.168.88.1 \ --ip-range 192.168.88.128/25 \ my-app-net # 查看网络列表 docker network ls # 查看网络详细信息 docker network inspect my-app-net

几个参数的解释：

--subnet：指定网络的IP地址段，方便后续固定IP、安全检查、路由规划；
--gateway：指定网关地址，一般取网段内首个可用IP，但如果你的物理网络有特殊约定，也可以自定义；
--ip-range：限制Docker自动分配IP的范围，避免IP被无关容器抢走。比如网段是192.168.88.0/24，但你希望低段地址留给特殊容器用，那么可以指定自动分配范围，避免冲突。

创建好网络后，你会发现宿主机上多了一张名为br-xxxxxxxx的网桥网卡，IP就是上面配置的网关地址。这张网卡就是自定义网桥在宿主机上的“门口”。

3.2 把容器接进网络的两种姿势

第一种是启动时直接指定：

docker run -d --name web-app \ --network my-app-net \ -p 8080:80 \ nginx:alpine

这种方式最简单，容器启动即入网，自动获得一个均匀分布的随机IP。

第二种是容器已经跑起来了，需要补挂网络：

# 给运行中的容器加一个网络接口 docker network connect my-app-net mysql-db # 给容器固定IP docker network connect --ip 192.168.88.10 my-app-net mysql-db

这种“先跑后挂”的场景很常见，比如你初始部署时忘了规划，后来发现两个服务必须在同一个自定义网络里才能走快速互访，就可以动态加网络而不用重启整个容器。

需要提醒的是，一个容器可以同时连接多个网络，它会有多个eth接口，每个接口对应不同网段的IP，路由策略由内核自动决定。这在做“双网络隔离”时非常好用，比如一个容器同时接入内网管理网络和外网服务网络，只在特定网卡上暴露服务。

3.3 内置DNS与容器名互通

自定义bridge网络内置了一个简版DNS服务，监听地址是127.0.0.11。这个DNS会把容器名解析成容器的IP地址，所以你在web-app容器里ping数据库时，直接用容器名就行：

# 在web-app容器里访问mysql-db docker exec web-app ping mysql-db docker exec web-app curl http://nginx-service:80

这等于说，你部署微服务时，不需要硬编码对方IP，只要把互相要访问的服务用“容器名”彼此引用，Docker网络层自己会搞定解析。容器的IP变了，名称解析的结果会自动更新，这比维护一堆静态配置文件可靠多了。

需要注意的是，默认bridge网络并不支持这种容器名DNS解析，你必须使用自定义网络（或compCompose默认创建的网络）。因此，如果你还在用--link这类老办法，建议尽快切换到自定义网络来，--link只是往/etc/hosts里塞条目，一旦IP变化就没用了，属于历史遗留方案。

3.4 Compose场景下的网络自动管理

很多项目现在直接用Compose定义多服务，这里顺手提一下网络相关行为。执行docker compose up时，Compose会自动创建一个默认网络，服务名天然可解析。

services: web-app: image: nginx:alpine networks: - app-net mysql-db: image: mysql:8 networks: - app-net networks: app-net: driver: bridge

服务名web-app和mysql-db在同一个app-net里可直接互通。这比手动创建网络再每个容器去指定方便得多。而且Compose网络支持健康检查联动，服务不可用时会自动从DNS里摘除，这个能力在手动网络里要自己实现。

4. 端口映射：容器对外暴露时发生了什么

端口映射是另一个高频网络课题。很多人只知道-p 8080:80，但不知道背后发生了什么，更不知道为什么有时候映射后外部还是连不上。

4.1 从一次curl看端口映射的数据路径

假设你在宿主机执行：

docker run -d --name nginx-app -p 8080:80 nginx:alpine

端口映射的真实链路是：

宿主机进程docker-proxy先监听在0.0.0.0:8080，负责替容器接收连接；
iptables的DOCKER链里会生成一条DNAT规则，把发往8080的数据包目标地址改写成容器IP的80端口；
数据包进入docker0网桥，最终被转发到容器eth0。
容器里的nginx监听到80端口，正常处理请求并响应。

所以，-p 8080:80的本质是“宿主机8080端口的流量，被DNAT转发到容器80端口”。这里有个很多新手忽略的点：iptables的DNAT规则优先级高于传统iptables自定义规则，如果你在宿主机自定义了放行或拦截逻辑，很容易被Docker自己插入的规则影响。

4.2 几个必踩的坑：防火墙、端口冲突、绑定地址

第一坑是firewalld或ufw拦截。Docker在操作iptables时会插入自己的规则链，但如果你用的是firewalld，经常会出现“端口已经映射给容器了，外部还是连不上”的诡异情况。原因往往出在firewalld策略优先级和docker规则冲突，特别是重启firewalld服务以后，会把docker写入的规则清掉。

第二坑是端口被宿主机的其他进程占用。有时候没注意，8080端口被某个开发服务器占着，结果Docker映射上去后，curl访问到的还是宿主机进程，而不是容器。用ss -tulpn | grep 8080先看一眼端口属于谁，比瞎猜省时间。

第三坑是绑定的IP地址。-p默认绑定0.0.0.0，也就是宿主机所有网卡上的8080都会转发到容器。但有些时候你有多个网卡，只想让内网网卡访问则更保险，这时就用-p 192.168.1.100:8080:80，只在指定IP上做映射，能够减少直接把容器暴露到公网的风险。

4.3 端口映射后的安全建议

如果容器要对外提供服务，务必明确一点：端口映射等于把容器的端口对宿主机全量开放，甚至可能暴露到公网。对一个不信任的镜像，尽量只映射最小范围，同时尽量不要使用host模式，否则容器里一个进程监听0.0.0.0就相当于宿主机直接开端口，出问题很难溯源。

还有一个小细节：如果从外部访问宿主机IP老是失败，试试先在本机用curl 127.0.0.1:8080验证Docker-proxy是否正常。本机能通、外部不能，基本就是防火墙或者云厂商安全组的问题，和Docker网络本身无关。

5. 高频问题与排查思路实录

这部分整理了我在实际使用中反复遇到的高频网络问题，按照“症状->排查思路->解决办法”的方式来写，希望能给你一条可复用的排查路径。

5.1 症状一：容器A访问容器B的IP不通

先别急着重启容器，按下面几步来：

确认两个容器在同一个网络里：
```
docker network inspect my-app-net | grep -A5 "Containers"
```
如果A和B不在同一个网络，默认就是不通的。解决方法是把容器连接到同一网络，或者让A、B通过网关绕路，但后者比较绕。
确认B容器进程真的在监听人所指的端口，而不是容器起来了但应用崩了：
```
docker exec -it container-B sh netstat -tulpn | grep 端口
```
确认真实IP，用docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' container-B取出来，再去A容器里ping这个IP。如果IP能通但端口不行，就是应用问题，不是网络问题。
如果IP通不了，考虑iptables规则影响。有些镜像会把自己命名空间的iptables搞得复杂，尤其是一些自建防火墙的容器，可能会丢包。可以先用--network host临时跑一个调试容器，排除网络模式的因素。

5.2 症状二：宿主机外部访问映射端口一直失败

优先顺序：

宿主机本地curl测试：curl http://127.0.0.1:8080。通了说明Docker映射本身正常，问题在外部路径；
检查宿主机防火墙是否拦了端口：sudo iptables -L -n看有没有相关的DROP规则，firewalld的用firewall-cmd --list-all；
看云服务器安全组是否放行端口。很多云厂商在Docker层面没问题，但安全组没放行8080，结果外部也访问不了；
确认映射范围：docker ps --format '{{.Ports}}'看是0.0.0.0:8080还是绑定在了某个特定网卡上。

有一个很隐蔽的坑：Docker服务重启后，有时会因为iptables规则丢失而导致端口映射失效。客户端验证不充分就重启docker服务，反而把规则清没了。如果排查到这里，重启容器或重启docker，一般能恢复。

5.3 症状三：容器里访问不了外网

容器能通局域网，但ping 8.8.8.8不通，核心排查思路是：

看内核IP转发是否开启：
```
sysctl net.ipv4.ip_forward
```
如果输出0，要改成1：
```
echo 1 > /proc/sys/net/ipv4/ip_forward
```
另外要保持这个配置持久化，写入/etc/sysctl.conf。
查看容器内默认路由是否存在：
```
docker exec container-A route -n
```
如果没有默认路由，多半是网络没配好，需要重新连接网络。
检查NAT规则是否生效：
```
sudo iptables -t nat -L -n | grep MASQUERADE
```
如果找不到对应的MASQUERADE规则，说明docker的网络规则被破坏了，可以用sudo systemctl restart docker恢复。
DNS问题也会表现成“外网不通”，其实只是域名解析不了。在容器里cat /etc/resolv.conf，正常情况下应看到nameserver 127.0.0.11；如果看到宿主机残留配置，可以先重启容器再排查。

5.4 常用排查命令速查表

场景	推荐命令
查看网络列表	`docker network ls`
查看网络详情、成员IP	`docker network inspect <网络名>`
查看容器IP	`docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' <容器名>`
查看端口映射	`docker ps --format '{{.Names}} {{.Ports}}'`
进入容器测试	`docker exec -it <容器名> sh`
查宿主机监听端口	`ss -tulpn`
查iptables NAT规则	`sudo iptables -t nat -L -n`
查路由表	`route -n`或`ip route`
动态连接网络	`docker network connect <网络名> <容器名>`
断开网络	`docker network disconnect <网络名> <容器名>`

这套组合拳用熟，大部分网络问题半小时内能定位。

6. 一些实战中沉淀下来的个人经验

讲完这些原理和命令，最后分享几条我踩了多次坑后才总结出来的建议。

第一，不要在生产环境依赖容器IP。容器IP是动态的，只要重启、迁移、扩缩容，IP就可能变化。每一次服务间的访问都应该通过服务名/网络别名，配合自定义网络的内置DNS来解耦。如果你现在项目里用了一堆写死IP的配置，迟早要还债。

第二，能用Compose就用Compose。Compose默认帮你把网络规划好，服务名自动解析，还带健康检查联动。我见过不少团队，手动创建三五个网络，又在每个docker run里指定不同的--network，结果拓扑乱成蜘蛛网。Compose管理的网络方案不仅清晰，而且docker compose down之后自动清理，比手动一个一个删干净得多。

第三，跨主机场景优先考虑overlay，别急着搞macvlan。macvlan看着“高大上”，真到生产会发现二层网络要求、无线不支持、宿主机访问麻烦，坑很多。而overlay虽然性能稍逊，但在多机编排、服务发现、负载均衡这些能力上更全。除非你有明确低延迟需求且底层网络拓扑很简单，否则overlay是更稳妥的起点。

第四，有一个排查利器很多人不知道：docker run --rm --network <目标网络> curlimages/curl可以直接临时拉一个调试容器，用它来测试目标网络里的连接问题。比如：

docker run --rm --network my-app-net curlimages/curl curl http://mysql-db:3306

这样不污染现有容器，也能快速验证网络层面的连通性，非常方便。

最后一次经历供参考：有一次一个服务起不来，系统里翻来覆去查日志都指向网络超时。我用这个临时容器进目标网络一测，发现是目标容器的健康检查一直不过，服务名解析到了废弃IP。后来只要看到“互访不通”，我都会先看一眼容器实际IP和健康状态，而不是第一直觉就去调防火墙。Docker网络虽然复杂，但本质上就是命名空间、网桥、iptables这几个要素的组合，理解了它们，遇到任何网络怪问题时，都能从底层逻辑推导出排查方向。希望这篇内容能帮你真正把这层窗户纸捅破。