Docker 网络故障排查记：当 bridge 模式失效时，host 模式如何救场

引言

在使用 Docker 容器的过程中，网络问题大概是最令人头疼的故障之一。最近我就遇到了这样一个场景：启动了一个标准的 Ubuntu 精简镜像容器，执行 apt update 时却卡在连接阶段，没有任何错误提示，只是无限等待。

作为开发者，我们都知道容器网络不通意味着什么------无法安装软件包，无法拉取代码，几乎什么都做不了。这篇文章记录了我从发现问题到解决的全过程，希望能给遇到类似问题的朋友一些参考。

问题重现

环境很简单：Docker 最新稳定版，拉取 ubuntu:latest 镜像，使用默认的 bridge 网络模式运行容器。

bash 复制代码

docker run -it ubuntu bash

进入容器后执行更新：

bash 复制代码

root@24780be2eae0:/# apt update
Ign:1 http://archive.ubuntu.com/ubuntu resolute InRelease                
Ign:2 http://security.ubuntu.com/ubuntu resolute-security InRelease      
0% [Connecting to archive.ubuntu.com] [Connecting to security.ubuntu.com]^C

光标停在 0%，没有任何进展，只能强制中断。

起初我以为是镜像源的问题，尝试配置阿里云镜像源，但问题依旧。由于容器内连 ip、ping 等基础网络工具都没有，无法进行常规的网络诊断，这让排查变得格外困难。我意识到这不是源配置的问题，而是容器网络本身出了故障。

快速解决：使用 host 网络模式

修复 bridge 网络需要排查 Docker 服务、网桥配置、iptables 规则等多个环节，过程比较耗时。而我当时的需求是尽快让容器能够联网，因此决定先使用 --network host 模式作为临时解决方案。

host 模式会让容器直接使用宿主机的网络栈，跳过 Docker 的网桥隔离，通常能绕过大多数网络配置问题。

bash 复制代码

# 删除有问题的容器
docker rm -f b098e62563a5

# 使用 host 网络模式重新运行容器
docker run -it --network host --name ubuntu-net ubuntu bash

这次，apt update 顺利执行完成，不再卡住。

bash 复制代码

root@localhost:/# apt update
Get:1 http://archive.ubuntu.com/ubuntu jammy InRelease [270 KB]
Get:2 http://archive.ubuntu.com/ubuntu jammy-security InRelease [110 KB]
...
Reading package lists... Done

网络通了！接下来趁着容器可用的机会，一次性安装好常用的网络工具：

bash 复制代码

apt install -y iputils-ping curl wget vim net-tools

这些工具在后续的调试和维护中非常有用。

保存成果：提交镜像

由于当前容器已经有了网络工具和配置，我不希望下次使用时重复操作，于是将容器提交为一个新镜像，方便后续复用：

bash 复制代码

# 退出容器
exit

# 提交容器为新镜像
docker commit ubuntu-net ubuntu-with-tools:latest

这样，我就有了一个预装了网络工具的基础镜像。

回归 bridge 模式并验证

有了 ubuntu-with-tools 镜像后，我尝试切换回标准的 bridge 网络模式，看看是否恢复正常：

bash 复制代码

# 使用 bridge 网络运行新镜像
docker run -it --network bridge ubuntu-with-tools bash

进入容器后测试网络：

bash 复制代码

root@936ab62db60d:/# ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3053ms

遗憾的是，bridge 模式仍然无法联网，所有数据包全部丢失。这说明问题并非临时故障，而是 Docker 的 bridge 网络配置存在根本性问题。

解决方案

既然 bridge 模式无法正常工作，我决定继续使用 --network host 模式作为长期解决方案。

方案一：直接使用 host 模式运行容器

bash 复制代码

# 运行新容器时直接指定 host 网络
docker run -it --network host --name myapp ubuntu-with-tools bash

方案二：检查并修复 Docker bridge 网络（可选）

如果确实需要使用 bridge 模式，可以尝试以下步骤修复：

在宿主机执行：

bash 复制代码

# 1. 检查 IP 转发
cat /proc/sys/net/ipv4/ip_forward
# 如果输出 0，启用 IP 转发
sudo sysctl -w net.ipv4.ip_forward=1

# 2. 检查 docker0 网桥
ip addr show docker0

# 3. 检查 iptables 规则
sudo iptables -L FORWARD -n -v

# 4. 重启 Docker 网络
docker network prune -f
sudo systemctl restart docker

# 5. 重新测试
docker run --rm ubuntu ping -c 3 8.8.8.8

总结与思考

这次经历让我总结出几个要点：

1. bridge 模式问题可能更严重

当 ping 8.8.8.8 显示 100% 丢包时，说明 Docker 的 bridge 网络配置存在根本性问题。此时继续尝试 --network host 是更务实的选择。

2. `--network host` 是有效的替代方案

在 bridge 模式无法修复的情况下，host 模式提供了可靠的工作方式。虽然 host 模式会降低网络隔离性，但在开发和测试环境中是完全可接受的。

3. 精简镜像的双刃剑

Ubuntu 精简镜像为了减小体积，去掉了 ip、ping、curl 等基础网络工具，这让网络故障的诊断变得困难。预装一套基础工具的基础镜像，能有效避免这种"网络不通→无法安装诊断工具→无法排查网络"的尴尬循环。

4. 保存中间状态很有价值

将配置好的容器提交为镜像是个好习惯。docker commit 虽然不如 Dockerfile 那样可追溯，但在快速迭代和调试场景下非常实用。

希望这篇文章对你有帮助。如果你也遇到过类似的 Docker 网络问题，欢迎在评论区分享你的解决方案。

Docker 网络故障排查记：当 bridge 模式失效时，host 模式如何救场

引言

问题重现

快速解决：使用 host 网络模式

保存成果：提交镜像

回归 bridge 模式并验证

解决方案

方案一：直接使用 host 模式运行容器

方案二：检查并修复 Docker bridge 网络（可选）

总结与思考

1. bridge 模式问题可能更严重

2. --network host 是有效的替代方案

3. 精简镜像的双刃剑

4. 保存中间状态很有价值

2. `--network host` 是有效的替代方案