各位老哥，今天想跟大伙聊聊 Docker 网络这块儿。我最早接触 Docker 的时候，以为容器网络就是"跑起来就能访问"，结果第一次部署应用就被上了一课：容器起来了，MySQL 本机连不上，两个容器之间互相 ping 不通，宿主机防火墙一开整个服务直接瘫痪。后来花了整整一个下午，从docker inspect一路查到 iptables 规则，才把整条链路摸清楚。这篇文章我就把这段时间折腾出来的经验做个梳理，重点讲讲 Docker 的几种网络模式、端口映射背后的原理，以及网络不通时怎么一步步定位问题。不管你是刚把 Docker 装好、正被"docker网络不通"折腾的新手，还是准备从单机容器走向多机部署的开发者，这篇内容应该都能给你一些参考。
1. 容器网络为什么总让人摸不着头脑：从一次常见故障说起
很多教程只告诉你docker run -p 3306:3306 mysql这样一条命令，用完就完事儿了。但真正出问题的时候，你会发现"端口映射看起来没问题，为啥就是不通"。这一章我们先不急着敲命令，先把 Docker 网络最基本的工作原理讲清楚。
1.1 bridge网桥与veth pair：容器的"虚拟网线"
Docker 默认使用 bridge 模式，也就是通过一个虚拟网桥docker0把宿主机和容器连接起来。你可以把docker0想象成一台虚拟交换机，宿主机是连在这台交换机上的一个端口，每个容器则是交换机下的另一台设备。为了让容器能接入这台"交换机"，Docker 会为每个容器创建一对 veth pair——这是 Linux 内核提供的一种虚拟网线，一头连着容器内部的eth0，另一头挂在宿主机的网桥上，名字通常是vethxxxxxx这种随机后缀。
创建一对 veth 接口，就是把一根网线的两头分别插到两个namespace里，数据进去一边，另一边就能收到，中间不需要真实物理链路参与。
# 查看宿主机上的 veth 接口 ip link show type veth # 查看网桥上的接口列表 bridge link show docker0你执行完上面两条命令，会看到一堆veth开头的接口。这就是每个容器在宿主机侧的"网线插头"。理解了这层关系，你也就明白为什么两个容器默认能互通——它们本来就挂在同一个虚拟交换机上。容器之间的数据包从 A 的eth0发出，经 A 的 veth 到达网桥，网桥根据目的 MAC 地址转发到 B 的 veth，最后进入 B 的eth0。
这里有一个很容易被忽略的点：docker0网桥的默认网段是172.17.0.0/16，但如果你在服务器上部署了多个 Docker 项目，并且每个项目都用了默认 bridge 网络，它们之间是可以互相访问的。这在某些安全要求比较高的场景下是个隐患。后续我们会讲到自定义 bridge 网络，那才是隔离的正确姿势。
1.2 端口映射背后的隐藏机制：docker-proxy与iptables DNAT
当你执行docker run -p 8080:80时，Docker 实际做了两件事：
第一，启动一个docker-proxy用户态进程，它监听宿主机的8080端口，并把流量转发到容器的80端口。这个进程存在的历史原因是为了解决某些场景下内核转发不可用的问题，在 Linux 上它更像一个兜底方案。
第二，在 iptables 的nat表中添加一条DNAT规则，把所有发往宿主机8080端口的包，目的地址改写为容器的 IP 和80端口。因为目标地址被改了，这些包会直接通过网桥转发给容器，根本不经过 docker-proxy 进程。
这也是为什么你用ss -tlnp有时候能看到docker-proxy进程在监听，但实际流量却没走它——真正的转发路径是 iptables 那条快速通道。反过来，如果你在宿主机上开了防火墙，但又没放行对应端口，那条 DNAT 规则可能被防火墙策略拦截，外面的流量根本进不来。这就引出了最经典的一个坑：
注意：
-p映射成功不代表外部一定可以访问。宿主机防火墙如果拦住了对应端口，DNAT 规则再完美也没有用。
我遇到过不只一次这种情况：服务在本地 curl 完全正常，换一台机器访问就是不通。排查到最后发现是云厂商安全组没放行端口，跟 Docker 本身没有任何关系。所以遇到"映射了但无法访问"的问题，第一件事先看宿主机防火墙和安全组，不要急着怀疑 Docker。
1.3 同一主机上容器间的三条互通路径
同一台宿主机上的多个容器，有几种互相访问的方式：
第一种，直接通过 IP 访问。如果你在docker run时没有指定网络模式，所有容器默认都在同一个docker0网桥的网段内，通过docker inspect <容器名> | grep IPAddress查到 IP 后，容器之间可以直接用这个 IP 通信。但这种方式有个问题：容器重建后 IP 可能变化，写死 IP 很容易翻车。
第二种，使用自定义网络和 Docker DNS 解析。创建一个自定义 bridge 网络后，加入该网络的容器会自动启用内嵌 DNS 解析。只要网络内部有多个容器，Docker 会自动根据容器名生成 DNS 记录，容器之间可以直接用名字互访。比如你的应用容器里写jdbc:mysql://mysql:3306，因为mysql这个容器名会被 DNS 解析成对应的容器 IP 地址，而这个 IP 在容器重建后会自动更新。这也解释了为什么我强烈推荐用容器名而不是 IP 通信。
第三种，host 网络模式下的直通。当容器使用--network host时，它共享宿主机的网络命名空间，直接通过localhost就能访问同主机上的其他服务。这种方式性能损失最小，但也失去了网络隔离，端口冲突的风险也同步变高。
2. 五种网络模式该如何选：一张表讲清适用范围
Docker 官方提供五种网络模式：bridge、host、none、macvlan 和 overlay。很多人学完 Docker 只知道 bridge 和 host，剩下三种听过名字但不知道怎么用。我把它们放在一起对比，顺便补充每种模式适合什么场景。
| 网络模式 | 配置方式 | 隔离性 | 性能 | 适合场景 | 典型注意点 |
|---|---|---|---|---|---|
| bridge | --network bridge | 容器间隔离，共享网桥 | 有少量NAT开销 | 单机多容器、开发环境 | IP不固定，需用服务名通信 |
| host | --network host | 无隔离，共享宿主机网络栈 | 近乎物理机性能 | 性能敏感、端口多且动态 | 端口冲突，无独立IP |
| none | --network none | 完全隔离 | 无网络能力 | 安全性极高的离线任务 | 无法联网，需手动配置 |
| macvlan | --network macvlan | 每个容器独立MAC/IP | 接近物理机性能 | 希望容器像局域网设备一样工作 | 依赖交换机，不支持VLAN间通信 |
| overlay | --network overlay | 跨主机虚拟二层网络 | 有封装开销 | 多机集群、Docker Swarm | 需初始化Swarm集群 |
2.1 bridge模式：单机默认方案的正确使用姿势
bridge 模式是 Docker 的默认选项，但这不意味着你什么都不用管。在实际项目中，直接使用默认的docker0网桥并不是最优解。我推荐你在项目启动前先创建自定义 bridge 网络：
docker network create --driver bridge my-net为什么强调"自定义"？原因有两点：一是同一个自定义网络内的容器才能通过容器名互通，默认网桥不支持自动 DNS 解析（老版本 Docker 支持--link，但那是历史遗留方案，不建议新项目使用）；二是自定义网络可以独立配置网段、子网掩码和网关，当你的公司内网网段恰好是172.17.0.0/16时，默认网桥会产生路由冲突。
比如你在服务器上同时跑着 OpenStack 相关服务，内部管理网段是172.17.x.x，这时候 Docker 默认网桥就跟它撞网段了，路由表会变得非常混乱。遇到这种场景，直接在创建网络时指定一个不冲突的网段：
docker network create --driver bridge --subnet=192.168.100.0/24 --gateway=192.168.100.1 my-bridge不过这种固定网段的方式也有代价：Docker 不会自动管理 IP 分配，如果你手动指定了静态 IP，就要确保 IP 没有被别的容器占用，否则网络会冲突。我见过不少人在 Docker Compose 里给每个容器固定 IP，结果后面再加容器时忘了检查网段余量，IP 冲突导致服务间歇性不可用，排查起来非常痛苦。
2.2 host模式：性能优先的取舍与代价
host 模式的原理是不为容器创建独立的网络命名空间，容器直接使用宿主机的网络协议栈。这意味着容器的localhost和宿主机的localhost是同一个，端口号直接落在宿主机上。
这个模式的优点很明确：网络性能几乎无损，因为没有 NAT 和网桥转发；同时也避免了端口映射这层"代理"，容器内监听的端口在宿主机上直接可见。缺点同样明显：一是端口冲突风险高，你启动的容器如果监听 8080，宿主机上任何进程都不能再用 8080；二是容器没有独立 IP，无法按容器维度做网络隔离。
哪些场景适合 host？我的经验是：对网络性能要求极高的中间件容器（比如一些日志采集 Agent，需要高速上报数据）、需要大量动态端口暴露的服务，以及某些对时延极其敏感的实时通信程序。在这些场景下，host 模式能让你少折腾不少映射配置。
但有一点很多人没意识到：host 模式下，Docker 的-p参数会被直接忽略，因为网络栈已经是宿主机的了，再做端口映射就没有意义。如果你执行docker run --network host -p 8080:80 nginx，运行时不会报错，但 8080 映射不会生效，你访问宿主机的 80 端口才能到 nginx。这个坑我踩过一次。
2.3 none模式与macvlan模式：特殊场景的定位
none模式适合那些完全不需要网络功能的容器，比如一些定期执行离线计算任务的批处理脚本容器、安全审计类容器，或者你希望从外部桥接一个手工配置的网络给容器使用。启动后容器内只有lo回环接口，没有 eth0，连网关都没有，任何出网操作都会失败。
macvlan模式则非常有特色：它允许你给容器分配一个宿主机所在局域网的真实 IP，容器看起来就像网络上的一台独立物理设备。从交换机的视角看，这个容器有自己独立的 MAC 地址和 IP 地址。这样做的好处是：局域网内其他设备可以直接访问容器，不需要经过端口映射；容器之间的通信也不走网桥，性能接近物理机。
部署 macvlan 时，宿主机网卡需要开启混杂模式，因为实际上它会收到本来发给容器 MAC 地址的帧，需要把这些帧交给容器的 veth 接口。这带来一个明显的限制：大多数家用路由器/交换机不支持同一个物理端口下 MAC 地址在不同的 VLAN 间通信，所以使用 macvlan 时容器默认不能和宿主机直接通信，除非额外为宿主机创建一个 macvlan 网卡并配置同网段 IP。
2.4 overlay模式：跨主机网络的入口
overlay 网络打通多台宿主机之间的容器通信，它通过 VXLAN 隧道技术把分布在多台机器上的容器连接成一个虚拟的二层网络。Docker 的 overlay 模式通常配合 Docker Swarm 使用——你需要先初始化一个 Swarm 集群，才能创建 overlay 网络。
我用 overlay 的体会是：它是 Kubernetes 和 Docker Swarm 这类容器编排平台的基础设施，单机环境下用不上，但一旦需要把服务跨机器部署，它就成了刚需。VXLAN 的封装有一定性能损耗（大约 10% 左右），这在物理机网络带宽充裕的机房环境里通常可以接受。不过如果你跑的是高频交易或者物联网消息转发这类高吞吐低时延的服务，还是优先考虑 host 模式或者直接部署在物理机上更稳妥。
3. 从"docker网络不通"到定位根因：一套可复用的排查链路
我一直认为，排查网络问题的能力比构建网络配置的能力更重要。你配置好网络之后几乎一劳永逸，但一旦出问题，如果没有清晰的排查思路，很容易被困在"看起来全对，就是不通"的死胡同里。下面这套流程是我自己反复用过的，基本能覆盖大部分"docker网络不通"的排查场景。
3.1 先摸清脑海里那张"地图"：docker network系列命令
排查第一件事是搞清楚当前容器挂在哪个网络上、IP 是什么、端口映射是什么。三个命令就够了：
# 查看所有网络 docker network ls # 查看指定网络的详细配置，包括已连接的容器 docker network inspect my-net # 查看容器端口映射情况 docker port my-containerdocker network inspect输出里有两个信息特别有用：一个是Containers段，列出所有连到这个网络的容器以及它们的 IP；另一个是IPAM段，显示当前网络的子网范围和网关。子网范围决定 IP 分配池，网关就是容器默认路由的下一跳。
提示：如果容器没出现在预期的网络里，检查一下你的容器启动参数是不是多个容器加入了不同的网络。有时候你以为它们都在同一个网络栈里，实际一个是 bridge，另一个是 host，自然互相访问不了。
这一步做完，你应该能回答三个问题：容器在哪个网络？IP 是什么？端口怎么映射的？如果这三个问题答不上来，后面的排查都是盲人摸象。
3.2 进入容器内部查看真实网络状态
宿主机上的网络状态正常不代表容器内部网络正常。进入容器看看eth0是否分配了地址、路由表是否完整、DNS 配置是否正确：
# 进入容器并查看网络接口 docker exec -it my-container sh ip addr ip route cat /etc/resolv.conf一个常见故障是容器内的resolv.conf是空的或者指向了一个不可达的 DNS 服务器。Docker 默认把宿主机的 DNS 配置复制到容器里，但如果你用了自定义 bridge 网络，Docker 内嵌 DNS（127.0.0.11）会作为一个选项写入容器配置。如果这个内嵌 DNS 失效了，容器之间通过名字互访就会失败，表现为"明明同一个网络，但 ping 容器名不通"。
另外，很多基础镜像是精简版，里面连ping、ip这些工具都没有。遇到这种情况你可以用docker exec my-container cat /etc/hosts先看 hosts 文件，或者临时装一个iproute2、iputils-ping再排查。我个人习惯在排查前先确认镜像内有哪些命令可用，避免跑到一半发现没有工具干瞪眼。
3.3 容器网络不通的常见根因清单
这一步我按概率从高到低列一下可能导致网络不通的因素：
- 端口映射遗漏：创建容器时忘了加
-p，外部访问自然不通。检查docker port是不是空的。 - 宿主机防火墙：cloud 平台安全组、
firewalld、ufw或 iptables 规则拦截了对应端口。关闭防火墙测试一下就知道是不是这个原因。 - 容器内进程监听地址错误：容器里的应用只监听了
127.0.0.1，而没有监听0.0.0.0。这是最隐蔽的坑，网络配置、端口映射全对，但应用只听本机回环，外部流量进来直接被内核拒绝。查一下容器内ss -tlnp看监听地址是0.0.0.0还是127.0.0.1。 - 自定义网络和外部网络路由冲突：比如容器内到某个目的网段的路由被 Docker 默认路由覆盖了，导致包发不出去。这种情况
ip route能看到异常。 - iptables 规则被第三方工具清空重写：比如你装了一些安全软件或手动执行了
iptables -F，把 Docker 创建的链清掉了。Docker 的转发链通常叫DOCKER和DOCKER-USER，如果这两个链不存在，基本就是这个原因。
3.4 一个完整的排查案例复盘
这里我写一个真实的排查过程，读者可以感受一下上面这套方法怎么串起来用：
有一次我在服务器上部署一个前端容器 A 和后端容器 B，前端通过http://backend:8080访问后端 API。结果启动后浏览器一直报 502。我按上面三步走了一遍：
先用docker network inspect查看，两个容器都在my-net网络上，IP 也正常，没有端口映射问题。然后进入容器 A 执行ping backend，结果返回bad address 'backend'——这说明 DNS 解析失败了。继续检查/etc/resolv.conf，发现 nameserver 指向了127.0.0.11，看起来正常。但我再仔细查看，发现容器 A 实际没有加入自定义网络，它用的是默认 network。
原来容器 A 启动时是第一次写项目时创建的，启动命令里漏掉了--network my-net参数。默认 bridge 网络不支持 Docker 内置 DNS 解析，所以它自然无法解析backend这个容器名。解决方案很简单：把容器 A 停掉，用docker network connect my-net <容器A>把它加入自定义网络，再启动，问题就解了。
这个案例我想强调的点是：很多时候不是你配置了错误，而是某个容器漏了配置，所以整个链路就断了。用docker inspect去逐个确认每个容器到底在网络里还是不在网络里，比盯着一个可疑容器反复测试要高效得多。
4. Docker Compose 与多容器项目的网络规划
如果你用一个一个docker run来管理多个容器，你会发现网络配置很快就失控了。Docker Compose 提供了更规范的多容器编排方式，也把网络问题前置到了配置文件中，让你可以在启动前就把整个网络拓扑设计好。
4.1 compose 里网络到底该怎么配
Docker Compose 默认会为每个项目创建一个独立的网络，前缀通常是项目名，比如myproject_default。所有服务默认加入这个网络，服务之间可以通过服务名互访。如果你需要多个项目之间共享网络，或者要建立一个更复杂的网络拓扑，就得在docker-compose.yml里显式声明网络：
version: "3.8" services: nginx: image: nginx:latest ports: - "8080:80" networks: - frontend - backend app: build: . networks: - backend mysql: image: mysql:8.0 networks: - backend networks: frontend: driver: bridge backend: driver: bridge在这个例子里，nginx同时挂在frontend和backend两个网络上，app和mysql挂在backend网络上。这样设计的好处是：nginx可以通过frontend网络暴露给外部，同时通过backend网络访问app；但mysql不会暴露给外部，只有app能访问它。这在安全隔离上比所有服务混在同一个网络里要好得多。
端口映射在 Compose 里默认是宿主机端口在前、容器端口在后。如果你漏写了ports，容器就只能服务内部访问，外部完全不可达。这个和docker run的行为一致，但 Compose 里漏写的情况更容易被忽略。
4.2 固定容器 IP 与依赖启动顺序的坑
很多人喜欢在 Compose 里手动给每个服务指定 IP：
services: mysql: networks: backend: ipv4_address: 192.168.100.10这样确实能让 IP 固定下来，但随之而来的问题是：你必须保证backend网络的子网覆盖这个 IP，否则 Docker 会直接报错。其次，如果你后续往同一个网络里加容器，容器的自动分配 IP 可能会和你的静态 IP 重复，到时候网络冲突排查起来真的要怀疑人生。我目前的做法是：用服务名作为唯一的寻址方式，不固定任何容器 IP。毕竟容器本身就是短暂的，把 IP 写死等于给自己埋雷。
另一个常见的坑是启动顺序的问题。比如你先启动 app 容器，再启动 mysql 容器。app 容器在启动时会尝试连接mysql:3306，但此时 mysql 还没起来，连接失败，整个应用直接崩溃退出。这不是网络配置的错，而是应用缺少重试机制。正确的做法是在应用侧加入重试逻辑，或者在 Compose 配置里添加depends_on，再配合健康检查：
services: app: depends_on: mysql: condition: service_healthy mysql: healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost"] interval: 5s timeout: 5s retries: 104.3 healthcheck 是分布式应用的"网络缓冲"
上面这个healthcheck配置很关键。它让依赖方等待被依赖方处于健康状态再启动，避免了"网络已通但服务未就绪"的尴尬。我见过太多人用depends_on却从头到尾不配置健康检查，结果 MySQL 已经启动但还没完成初始化，app 连过去直接报Access denied，然后整个编排直接失败。
健康检查本身也会消耗一定资源，interval 不宜设置太短，5 秒是相对合理的经验值。对于重负载的数据库，建议把 interval 放宽到 10 秒左右，避免频繁探测影响正常业务。
5. 一套能扛住跨主机部署的网络设计思路
单机 Docker 学到一定程度，你必然会遇到"多台服务器怎么组网"的问题。这一章我把跨主机的常用方案和选型经验做个总结，属于进阶一点的内容，但也没有那么高深。
5.1 为什么 Swarm 的 overlay 不一定是首选
Docker Swarm 提供了开箱即用的 overlay 网络，确实很方便。你只需要在 manager 节点上执行：
docker swarm init docker network create --driver overlay --attachable my-overlay之后任何加入 Swarm 集群的节点，都能把容器挂到这个 overlay 网络上，跨主机的容器就像在同一台机器上一样互访。--attachable参数很关键，它允许非 Swarm 服务（比如通过docker run启动的容器）接入 overlay 网络，否则路会堵死。
但 Swarm 本身在持久化存储、跨主机卷复制方面比较薄弱，很多团队最终会转向 Kubernetes 或者裸机上直接用更轻量的网络方案。如果你只是个人实验或者小团队几十个容器，Swarm 足够用；如果集群规模到几百个节点，Kubernetes 生态的 CNI（容器网络接口）更成熟，比如 Calico 和 Flannel，它们底层用的也是 VXLAN/BGP 之类的技术，但管理面丰富得多。
5.2 从"网络互通"到"流量治理"：更实际的中间层思路
在跨主机网络里，很多人只盯着二层互通，忽略了更重要的流量治理需求。比如你要限制某个容器只能被特定的服务访问，或者要对多个副本做负载均衡，单靠 overlay 网络的自愈能力是不够的。
一种折中方案是：容器统一走 host 网络，由宿主机上的 Nginx 或者 HAProxy 来做反向代理和负载均衡。在这种架构里，容器没有独立 IP，每个容器监听一个宿主机端口，Nginx 通过 upstream 把请求分发到不同端口。这个方案牺牲了容器粒度的网络隔离，但性能好、排障方便，网络问题直接退化成普通的端口和负载均衡问题。很多生产环境的中间件集群就是这么跑的。
5.3 网络策略与安全隔离：很多 DBA 和运维会忽略的事
最后提一个容易被忽略的点：Docker 本身的网络隔离只做到二层和三层，不提供四层以上访问控制。限制特定容器访问另一个容器的某个端口，光靠 Docker network 是做不到的，必须依赖 iptables 或者 CNI 网络策略。比如你不能因为 container A 和 container B 都在同一个 bridge 网络上，就默认 A 可以访问 B——实际上确实可以访问，因为 Docker bridge 网络默认没有 ACL 能力。
如果你在 Kubernetes 环境里，要善用 NetworkPolicy 资源来定义哪些 Pod 可以访问哪些服务。在纯 Docker 环境里，你需要写 iptables 规则或者用weave、calico这类工具来补上网络策略能力。这块内容很深，我目前实战经验也还在积累中，但至少有一点是明确的：网络规划和业务安全是强绑定的，不要等事故出了再回头补网络策略。
给新手的最后建议
Docker 网络说难不难，说简单也不简单。我自己是一路踩坑过来的，从端口映射失效到容器间 DNS 解析失败，再到跨主机路由冲突，几乎每个问题都让我多长了一个心眼。如果你现在正准备搭建 Docker 环境，我建议你把网络配置当成项目的一部分来设计，而不是事后补救。多花十分钟想清楚容器之间怎么互访、哪些容器需要暴露给外部、要不要设固定 IP，很可能帮你省下一整天的排查时间。
最后分享一个实用的小技巧：启动容器后，立刻执行docker network inspect和docker exec验证一遍网络链路是否和预期一致，花不了两分钟，但能在出问题之前发现问题。网络这块永远值得多花点心思，祝大家都能少踩几个"网络不通"的坑。
