引言
在使用 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 网络问题，欢迎在评论区分享你的解决方案。