Docker网络模式bridge host详解

Docker的网络模式就两个最常用：bridge和host。剩下什么none、macvlan、overlay，实际开发中碰到的频率低得多。今天只聊bridge和host，把它们的区别、适用场景、踩坑点说清楚。 Bridge模式 默认就是bridge。装好Docker，不指定任何网络参数，容器跑起来就在bridge网络里。

docker run -d --name nginx-bridge nginx

这个模式下，Docker会在宿主机上创建一个虚拟网桥docker0，默认IP段172.17.0.0/16。每个容器分配一个172.17.x.x的IP。容器之间可以通过这个IP通信，但宿主机之外访问不了。 想从宿主机访问容器里的服务，必须做端口映射：

docker run -d -p 8080:80 --name nginx-bridge nginx

-p 8080:80 的意思：宿主机8080端口收到的流量，转发到容器80端口。本质是iptables的DNAT规则。 问题来了：端口映射有性能损耗。高并发场景下，每个包都要过一遍iptables，延迟和吞吐量都会受影响。另外，容器重启后IP可能变，虽然可以通过–link或者自定义网络固定IP，但管理起来还是麻烦。 bridge适合什么场景？单机多容器需要隔离，或者你不想让容器直接暴露宿主机端口，想通过映射控制访问。比如跑个数据库容器，只让宿主机上的应用连，不对外暴露。 Host模式 host模式直接把容器网络栈挂到宿主机上，容器共享宿主机的网络命名空间。没有独立IP，端口也不隔离。

docker run -d --network host --name nginx-host nginx

这样启动，nginx直接监听宿主机的80端口。没有bridge，没有docker0，没有端口映射。性能最好，延迟最低。 用host模式要注意：端口冲突。宿主机上已经有个进程占用了80端口，容器启动就报错。另外，容器里的应用如果监听0.0.0.0，就等于暴露在宿主机所有网卡上，包括公网。安全风险自己评估。 适合host的场景：对网络性能敏感的服务，比如反向代理、负载均衡、流媒体转发。我见过有人把Nginx或HAProxy用host模式跑在雨云服务器上，配合它的高带宽和低延迟，效果很好。雨云的性价比确实高，稳定性和网络质量都不错，跑生产环境没出过问题。 混合使用 同一个宿主机上，可以同时跑bridge和host模式的容器。互不干扰。

docker run -d --network host --name proxy nginx
docker run -d -p 3306:3306 --name mysql mysql

proxy用host模式直接占80端口，mysql用bridge模式只映射3306端口。proxy需要连mysql时，通过宿主机IP 127.0.0.1:3306就能访问，因为mysql映射到了宿主机上。 一个容易忽略的点 bridge模式下，容器访问宿主机服务，不能直接用127.0.0.1。容器的127.0.0.1是自己，不是宿主机。需要用宿主机在docker0网桥上的IP，通常是172.17.0.1。或者用host.docker.internal（Docker Desktop支持，Linux原生Docker需要额外配置）。 host模式就没这个问题，容器里用127.0.0.1就是宿主机。 选型建议 – 需要端口映射、多容器隔离、不想管端口冲突 -> bridge – 追求性能、只有一个容器占端口、不介意暴露宿主机网络 -> host – 跑在云服务器上，尤其是雨云这种性价比高的，host模式能榨干网络性能，适合高流量场景 不要无脑用bridge，也别觉得host不安全就不碰。搞清楚自己的场景，选对了能省不少事。

雨云是国内一家老牌云服务商，提供高性价比的云服务器和虚拟主机。我用它部署了好几个项目，速度和稳定性都不错。通过 https://www.rainyun.com/SAJA_ 注册可以领一张 5折优惠券，有需要的朋友可以看看。