Docker网络配置实战：驱动选型、容器互通与故障排查

1. Docker 网络配置的整体设计思路与驱动选型

1.1 为什么网络是新手崩的第一个点

刷完 docker 安装教程、把镜像拉下来、容器也run起来了，然后打开浏览器输入localhost:8080，页面转圈转到超时——这大概是每个学 Docker 的人都会经历的第一次破防。我当年也是，明明docker ps里容器状态写着 Up，日志也打印了"启动成功，监听 8080"，可宿主机就是连不上。折腾两个小时之后才发现，容器里的 8080 和宿主机的 8080 是两套完全独立的网络栈，中间那根线要我自己手动搭。

这就是 Docker 网络配置最容易被忽略的地方：安装 docker desktop、装 ubuntu 安装 docker、装 centos7 配置网络，这些步骤本身都很顺，教程也不会出错，真正卡人的是后面——容器跑起来了，但它和外面这个世界没有任何默认的通道。容器的 IP 是私有的、容器之间的名字默认不互通、容器的端口默认不外露，这三点叠加在一起，新手必然懵。

这篇笔记不打算把网卡、网桥、命名空间的理论从头讲一遍，网上那些东西够多了。我想做的是把"我实际配置 docker 网络时踩过什么、怎么排查、最后形成什么习惯"写清楚。无论你是在 Windows 上用 Docker Desktop，还是在 ubuntu 20.04 / ubuntu 22.04 / centos7 / rocky9 上装 docker，网络这一层的逻辑是一样的，只是宿主机侧的差异需要注意。看完之后你至少能做到三件事：知道几种网络模式该在什么时候用、能独立排查"容器连不上"这类问题、能写出一个不会在生产环境翻车的 compose 网络配置。

1.2 一句大白话：Docker 到底给容器装了几张网卡

把 Docker 的网络想成一栋公寓楼，会好理解很多。宿主机是整个小区的物业，docker0这个网桥就是小区中间的那条主干道，每起一个容器，Docker 就给它拉一根"虚拟网线"（veth pair）接到这条主干道上，容器内部看到的那张网卡就是这根网线的这一头，另一头插在docker0上。容器拿到的 IP（默认从 172.17.0.0/16 里分）相当于这栋楼的门牌号，只在小区内部有效，外面的人想找它，必须经过物业登记（端口映射）。

再往下一层，每根网线两头其实运行在不同的网络命名空间（network namespace）里。命名空间的意思是：容器有自己独立的一张路由表、一份/etc/resolv.conf、一套 iptables 规则，和宿主机完全隔离。所以你在宿主机上ping 127.0.0.1和容器里ping 127.0.0.1，命中的是两个不同的东西。理解了这一点，"容器访问宿主机服务该填什么地址"这个经典问题就自然有答案了——填 127.0.0.1 是找不到宿主机的，那指的是容器自己。

Docker 起的每一张网卡、每一个网桥、每一条 iptables 规则，都是守护进程在后台自动完成的。你可以用ip link show在宿主机上看到一堆vethxxxx开头的接口，那些就是容器的网线头。看到它们，说明网络这套机制正在正常工作。

1.3 六种网络驱动，别再用默认的那一个

docker network ls一敲，通常能看到 bridge、host、none 三个。这三个是默认存在的，但真正干活的驱动远不止这些。我整理了一张选型表，这张表比我第一次看官方文档时那几大段描述有用得多：

选型逻辑其实只有三句话。第一，单机上的多个容器要互相调用，一律用自定义 bridge，不用默认的那个；第二，只有当容器需要独占宿主机端口、或者你对网络延迟极度敏感时，才考虑 host 模式；第三，容器之间不需要网络（比如纯做数据处理的批处理任务），直接--network none最安全，少暴露一个攻击面。

提示：在 Linux 上使用 host 模式时，-p参数会被忽略并打印一条警告，因为容器已经没有独立的网络栈了。很多人第一次遇到这个警告会以为是报错，其实不是。

Overlay 和 macvlan 属于进阶内容。macvlan 的用途是给容器发一个和宿主机同网段的真实 IP，让它直接出现在公司局域网里，适合跑一些需要被交换机层面识别的服务，但它有个硬伤：宿主机和 macvlan 容器之间默认不能直接通信，得再补一张网卡。Overlay 则依赖 Swarm 集群，单机环境用不上。小白阶段先把自定义 bridge 玩透，比什么都强。

2. 默认 bridge 的三个大坑与自定义网络的正确姿势

2.1 坑一：容器名互相 ping 不通

新手最常干的事是这样的：起了两个容器，一个叫 web，一个叫 db，然后在 web 里试图ping db，结果提示ping: db: Name or service not known。但换成ping 172.17.0.3就通了。这不是网络断了，而是默认的 bridge 网络根本没有内置 DNS 解析服务。

Docker 只在自定义网络里部署了一个内嵌的 DNS 服务器（容器里/etc/resolv.conf会指向 127.0.0.11），它负责把容器名、容器别名、服务名解析成对应的 IP。默认 bridge 是 Docker 早期留下的历史包袱，那时还没这套机制，所以只保留了通过--link写死 hosts 的老办法。

解决方式很简单，一行命令：

docker network create app-net docker run -d --name db --network app-net mysql:8.0 docker run -d --name web --network app-net nginx docker exec -it web ping db

你会发现ping db直接通了。这个差异背后的逻辑是：自定义网络里的每个容器，都会被 DNS 服务登记一次，容器名即域名。这也解释了为什么很多 compose 项目里服务名可以直接当主机名用——compose 默认会给你创建一个独立的 bridge 网络，所有服务都挂在上面。

2.2 坑二：默认网段和公司内网撞车

默认 bridge 用的 172.17.0.0/16，如果你公司内网恰好也用 172.17 或者 172.16 段，那么宿主机上的路由表就乱了套：访问某个内网机器时，包可能会被送进 docker0 网桥。表现是宿主机访问公司某个服务突然不通，或者容器访问内网数据库超时。

这个问题不会报错，只会"莫名其妙不通"，排查起来非常耗时间。所以我的习惯是：任何正式一点的环境，都不使用默认网段，创建网络时显式指定一个不容易冲突的私有段。

docker network create \ --driver bridge \ --subnet 10.88.0.0/16 \ --gateway 10.88.0.1 \ --opt com.docker.network.bridge.name=br-app \ app-net

这里--opt com.docker.network.bridge.name是给宿主机上那张网桥起个可读的名字，默认会生成br-加一串随机字符。环境多了以后，br-app、br-web这种名字比一堆乱码好认太多。另外还可以用--ip-range限制容器的地址分配范围，比如网段是 /16 但只想用里面的一小段给容器，剩下的留给别的东西。

如果宿主机上跑了几十个网络，光靠每次手动指定太累，可以在/etc/docker/daemon.json里配置默认地址池：

{ "default-address-pools": [ { "base": "10.200.0.0/16", "size": 24 } ] }

改完之后systemctl restart docker。注意这一步会重启守护进程，所有容器都会停，做之前先确认能接受停机。这也是为什么很多人问"docker 权限错误怎么解决""failed to connect to the docker api"这类问题——如果 daemon.json 写错了缩进或者语法，守护进程起不来，客户端就会连不上那个 socket。

2.3 坑三：--link 已经是历史遗留

江湖上还流传着--link的写法，网上有些老教程还在用。我的建议是：新项目一律不要用。它做的是单向的 hosts 注入，A 链接 B，A 能解析 B，B 反过来解析不了 A，还得再加一次。而且容器重启后 IP 变化会让 link 关系失效，跨网络更是完全不支持。

自定义网络从设计上就把这事解决了：双向解析、动态更新、支持别名。想给某个容器加多个名字，用--network-alias：

docker run -d --name db --network app-net \ --network-alias mysql --network-alias primary-db \ mysql:8.0

这样 web 容器里ping mysql、ping primary-db、ping db都能通。这个技巧在做数据库主从切换的时候特别有用——应用里写死连primary-db，切换时只需要改指向，不用动应用配置。我在做 redis 主从、mysql 主从这类部署时都会加上别名，后面维护省不少事。

2.4 自定义网络的落地写法与可回收性

创建网络还有一个容易被忽视的点：清理。项目做多了，docker network ls会冒出一大堆<none>或者没用到的网络。删除之前要确认没有容器还在用：

docker network inspect app-net --format '{{range .Containers}}{{.Name}} {{end}}' docker network rm app-net docker network prune

inspect那一行的格式化输出是我常用的一个小技巧，直接列出该网络下所有容器名，比翻一长串 JSON 快得多。prune会删除所有没被容器引用的网络，跑之前最好先docker network ls看一眼，避免删掉正在准备用的。

另外一个实战习惯：网络名带上项目前缀，比如shop-web-net、shop-db-net，而不是简单叫web-net。一台机器上同时跑三四个项目是常态，命名不带前缀，半年后自己都认不出来哪个是哪个。

3. 从零实操：搭一套可复现的容器网络环境

3.1 第一步永远是先看清楚现状

在动手改任何东西之前，先做一次现状盘点，这是我吃了亏之后养成的习惯。有一次我调了半天端口不通，最后发现是前一个测试留下的容器占了同样的端口，Docker 又没报错，因为人家的容器还在跑。

# 看看有哪些网络 docker network ls # 看某个网络的详细配置，包括网关、已连接的容器 docker network inspect bridge # 看宿主机上的网桥接口和地址 ip addr show docker0 # 看当前生效的转发和 NAT 规则 sudo iptables -t nat -L DOCKER -n | head -20

docker network inspect输出是 JSON，信息量很大，重点看三个字段：Subnet（网段）、Gateway（网关）、Containers（已接入的容器）。如果发现某个网段的容器数量异常多，就要留意是不是测试残留。

在 Windows 上用 Docker Desktop 的朋友，宿主机侧看不到docker0，因为实际的 Linux 环境跑在 WSL2 的一个轻量虚拟机里。这种情况下排查方式不一样：wsl --shutdown重启一下子系统往往能解决大部分网络抽风。顺便提一句，Docker Desktop 启动时报"virtualisation support not detected"这类提示，通常是 BIOS 里的虚拟化开关没打开，或者 Windows 的 Hyper-V / WSL2 后端没有启用，这跟网络配置无关，但很多人会混在一起找不到北。

3.2 创建一个带自定义网段的网络

把前面说的要点合起来，一个完整可用的网络创建命令应该长这样：

docker network create \ --driver bridge \ --subnet 10.88.0.0/16 \ --gateway 10.88.0.1 \ --ip-range 10.88.10.0/24 \ --opt com.docker.network.bridge.name=br-app \ app-net docker network inspect app-net

参数为什么这么选：--subnet用 10.88 是因为它在 RFC1918 私有地址里，同时 10.88 这个段被企业内部使用的概率相对低，冲突风险小。--ip-range限定在 /24，意思是这个网络虽然号称 /16 大，但容器只从 10.88.10.0/24 里分配地址，剩下的空间留白，将来需要扩展时再调整。--gateway不指定的话 Docker 会自动取网段第一个可用地址，显式写出来是为了让配置文件自解释。

这行命令跑完之后，ip addr show br-app应该能看到一张新网桥，地址是 10.88.0.1。如果用的不是 Linux 宿主机，这一步看不到也没关系，容器之间照样能通。

3.3 端口映射 -p 的参数细节，比你想的讲究

-p是新手用得最多也最容易迷糊的参数。它的完整格式其实是四段：ip:hostPort:containerPort/protocol。绝大多数教程只写-p 8080:80，把中间的门道全省了。

# 最简写法，绑定到所有网卡的 8080 docker run -d -p 8080:80 nginx # 只绑定到本机回环，外部机器访问不到 docker run -d -p 127.0.0.1:8080:80 nginx # 只绑定到指定网卡（比如只有内网能访问） docker run -d -p 10.88.0.1:8080:80 nginx # 随机分配宿主机端口，用 docker port 查看 docker run -d -P nginx

绑定地址这一项在服务器上非常重要。像数据库、管理后台这类不该对外暴露的服务，用127.0.0.1:3306:3306只允许本机访问，是最省事的安全隔离方式。如果你在公司服务器上直接-p 3306:3306，而宿主机防火墙又刚好放行了，那这个数据库实际上就暴露在办公网里了——这种事我在真实环境里见过不止一次。

还有两个细节值得记住。第一，-p可以写多次，一个容器可以映射多个端口。第二，协议默认 TCP，需要 UDP 时显式写-p 53:53/udp，DNS 类服务经常两者都要。

注意：端口映射是靠宿主机 iptables 的 DNAT 规则实现的，它可能绕过部分应用层防火墙的端口限制。也就是说，即使系统防火墙看起来没放行 8080，Docker 发布的端口仍然可能从外部访问到。发布端口前先想清楚"这个服务真的需要被外面看到吗"。

3.4 compose 里怎么描述网络，别全塞进 default

用 docker compose 的人越来越多，但很多 compose 文件里一个networks都没写，所有服务默认挤在同一个网络里。这在开发环境没感觉，一旦服务多起来，数据库能被前端直接访问到，隔离性为零。一个我常用的结构是这样：

services: gateway: image: nginx:1.25-alpine ports: - "80:80" networks: - frontend app: image: myapp:latest networks: - frontend - backend db: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: change-me networks: - backend networks: frontend: driver: bridge backend: driver: bridge internal: true

这里的关键在于internal: true。它表示这张网络没有对外的出口，接入的容器不能访问外网，也拿不到被映射到宿主机的公网入口。数据库放在这张网里，即使配置写错了，外面也摸不到它。这个参数我强烈建议所有涉及数据库、缓存、消息队列的 compose 项目都加上。

gateway只挂在 frontend，db只挂在 backend，app两边都挂，承担桥梁。这样前端服务即使被攻击，也够不着数据库。网络分层的思路和微服务项目里划分内外网是同一回事，只是 Docker 把这个成本降到了几行 YAML。

3.5 验证连通性，四个动作搞定

配完网络不要直接交付，按顺序跑四个验证：

# 1. 容器间按名字解析 docker exec -it app ping -c 2 db # 2. 容器访问外网 docker exec -it app ping -c 2 223.5.5.5 # 3. 容器访问宿主机上的服务 docker exec -it app curl -s -o /dev/null -w "%{http_code}\n" http://host.docker.internal:9000 # 4. 宿主机访问容器发布的服务 curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:80

第 2 步用 IP 而不是域名，是为了把"网络通不通"和"DNS 好不好使"分开验证，这是排查顺序的基本原则——先通网络，再通名字。第 3 步在 Linux 上需要额外做一步：host.docker.internal这个特殊域名 Docker Desktop 自带，Linux 上默认没有，要在启动时手动加：

docker run -d --add-host=host.docker.internal:host-gateway myapp

host-gateway是 Docker 的保留值，它会自动替换成宿主机在这张网桥上的地址（通常就是网关 10.88.0.1）。比起硬编码一个 IP，这种写法在网段调整后依然有效。

4. 常见问题与排查技巧实录

4.1 容器连不上外网，按这个顺序查

"容器里 ping 不通外网"是高频问题，排查必须讲顺序，乱试只会更糊涂。

第一，docker exec -it 容器名 cat /etc/resolv.conf。如果显示的是一个奇怪的 IP 或者宿主机上并不存在的 DNS，域名解析必然失败。自定义网络里应该是 127.0.0.11，宿主机上的 DNS 配置会通过它转发。想统一指定 DNS，在 daemon.json 里加"dns": ["223.5.5.5", "119.29.29.29"]。

第二，docker exec -it 容器名 ping -c 2 8.8.8.8。IP 能通但域名不通，那就是 DNS 问题；IP 也不通，往下看。

第三，在宿主机上sysctl net.ipv4.ip_forward。这个值必须是 1，Docker 守护进程启动时会自动设置，但如果之前被别的脚本改成 0，容器就出不去。临时改：sysctl -w net.ipv4.ip_forward=1，永久改写到/etc/sysctl.d/下的配置文件。

第四，检查 FORWARD 链。Docker 会往 iptables 的 FORWARD 链里插规则，如果系统上装了 firewalld 且默认策略是 DROP，Docker 的规则可能被排在后面。用sudo iptables -L FORWARD -n -v看有没有包被丢掉。这也是为什么很多人在 centos7 网络配置调好之后，Docker 网络还是不通——宿主机的防火墙和 Docker 的规则打架了。

4.2 宿主机访问不到容器端口，八成是这三个原因

如果容器日志显示服务正常，但宿主机curl 127.0.0.1:端口没反应，按可能性从高到低查：

原因一：应用只监听了容器内的 127.0.0.1。这是最隐蔽的一个。有些服务默认配置里写的是bind 127.0.0.1，那它只接受来自容器内部的连接，端口映射过去也是空的。解决办法是改配置成0.0.0.0，让服务监听所有网卡。判断方法很简单，进容器里curl 127.0.0.1:端口能通，但在宿主机上不通，基本就是这个。

原因二：端口映射绑错了地址。前面说过-p 127.0.0.1:8080:80只对本机开放，如果你从另一台机器访问当然不通。用docker port 容器名能看到实际绑定情况。

原因三：宿主机上已经有进程占了这个端口。Docker 发布端口时如果冲突会直接报错，但如果是先启动容器、后来宿主机上又起了别的服务抢端口，那表现就是时好时坏。sudo ss -lntp | grep 端口号一看便知。

4.3 容器访问宿主机上的服务，地址到底填什么

这个问题几乎每个人都会问一遍，因为直觉上"宿主机"就是127.0.0.1，但容器里那个127.0.0.1是它自己。

准确的答案是：填宿主机在这张容器网络里的地址，也就是网桥的网关地址。默认 bridge 下是172.17.0.1，自定义网络下是你创建时指定的--gateway。命令行里可以用ip addr show br-app确认。

但硬编码网关有个问题：网络重建后网关可能变。所以更推荐两种方式。一是前面提到的--add-host=host.docker.internal:host-gateway，写一次到处能用；二是在 compose 里用extra_hosts声明：

services: app: image: myapp:latest extra_hosts: - "host.docker.internal:host-gateway"

还有一个前提条件：宿主机上的那个服务本身必须监听0.0.0.0或者网桥地址，如果它只监听127.0.0.1，容器通过网桥地址也是访问不到的。这个坑和 4.2 里的原因是同一个逻辑的另一半，只是方向相反。我自己就被这个坑卡过一次：本地起了一个只监听回环的开发服务，容器里怎么都连不上，改监听地址之后立刻通了。

4.4 MTU 不一致，小包能通大包卡死

这是最像玄学的一个问题：ping能通，小请求能通，稍微大一点的响应就卡住或者超时。我第一次遇到时完全没头绪，后来才明白是 MTU 的事。

原理说一下。宿主机的网卡 MTU 一般是 1500，容器网桥默认也取 1500。但如果宿主机本身在网络环境里需要通过一条封装链路出去（比如某些云主机的内部网络），实际可行的 MTU 会小于 1500。这时候小包正常，大包被分片或者被丢弃，表现就是"有时候好用，有时候不好用"。

验证方法和解决办法：

# 在容器里测大包 docker exec -it app ping -c 2 -s 1400 8.8.8.8 docker exec -it app ip link show eth0 # 创建网络时直接指定 MTU docker network create --opt com.docker.network.driver.mtu=1400 app-net

也可以全局在 daemon.json 里加"mtu": 1400。具体填多少需要试，从 1400 开始,能通就往下加,找到临界值再留 20 左右余量。这个参数一旦调对，之前那些"偶发超时"会突然全部消失。

4.5 一份能直接照着查的速查表

5. 多容器协作的网络分层与生产约定

5.1 按职责切网络，而不是全塞一个

前面提了 compose 里分层，这里说说单机手写场景下的分层思路。我的习惯是按"谁能访问谁"来切，而不是按"什么服务"来切。通常三张网就够了：

• 入口网：只跑对外提供服务的容器，比如 nginx 这类统一入口，端口映射只在这张网上发生。
• 应用网：业务容器之间互调，比如应用服务调缓存、调消息队列。
• 数据网：数据库、存储，设成internal，无外网出口。

这样切的好处是：出问题时影响范围清晰。前端容器被打了，它够不着数据库；某个业务容器需要临时访问外网抓数据，只把它接到有出口的网里，其他容器不受影响。

代价是配置文件变长了一点，容器可能同时属于两张网。但这部分成本在排查故障时能十倍地还回来。我经历过一次数据库被前端容器里的错误配置意外清库的事，从那以后所有项目一律给数据网加internal。

5.2 只暴露必要端口，以及 DOCKER-USER 的正确用法

发布端口是攻击面，这句话在容器里尤其成立。我的判断标准很简单：这个端口是给人访问的，还是给容器访问的。给人访问的才用-p，给容器访问的一律走容器网络内部的端口，不发布。

如果确实需要在宿主机层面统一管理进出流量，Docker 提供了一条专门的链：DOCKER-USER。它的好处是 Docker 升级或者重启时不会清掉你写的规则，因为它排在 Docker 自己维护的规则之前。

# 只允许 10.88.0.0/16 访问宿主机的 3306 sudo iptables -I DOCKER-USER -p tcp --dport 3306 ! -s 10.88.0.0/16 -j DROP

这条规则的读法是：往 DOCKER-USER 链头部插入一条规则，目标是 tcp 协议的 3306 端口，源地址不是 10.88.0.0/16 的全部丢弃。注意!的位置和-I而不是-A，前者保证规则在最前面生效。改完之后一定要用外部机器实测一次，别只看规则列表。

5.3 跨主机通信，先想清楚是不是真的需要

容器跨主机通信有两个方向：一是 overlay 网络配合集群，二是让容器直接拿宿主机所在网段的 IP（macvlan）。这两个方案我都用过，也都不推荐新手一上来就碰。

原因很实在：overlay 需要集群环境，出了问题的排查链路比单机长得多，而且网络的抖动会直接影响服务发现；macvlan 虽然简单，但交换机的 MAC 地址表容量、宿主机与容器之间的通信限制，都是容易忽略的坑。

大多数中小规模的场景，正确的做法其实是让容器就待在单机网络里，跨主机的事交给上层的负载均衡入口去处理：每台机器上的入口容器监听宿主机端口，流量从上层的统一入口分发下来。这样每一层的职责都很清晰——容器网络管容器之间，宿主机网络管机器之间。稳妥，好排查，改动成本低。

顺便说一句，如果是麒麟、龙芯这类国产环境的 Docker 部署，网络层的逻辑完全一致，只是镜像来源和基础环境需要额外确认。docker network的命令、参数、行为都不变，不需要为此改变配置习惯。

我个人在配置这套东西时最重要的一条体会是：不要等到出问题才去理解网络。每次新起一个项目，先把网络拓扑想清楚——谁需要被外面访问、谁之间要通、谁绝对不能被碰——然后落成配置文件。这个习惯养成之后，你会发现自己几乎不再需要半夜爬起来查"怎么容器又连不上了"。最后再分享一个小技巧：把常用的网络创建命令写成一个init-network.sh放在项目根目录，新机器上一条命令重建整套环境，比记参数靠谱得多。