先从一段真实经历说起先说我踩过的一个坑。刚入行那会儿我用 Docker 默认的 bridge 网络跑了一个微服务集群容器之间通过 IP 互相调用。某天重启了一台宿主机所有容器 IP 都变了服务全崩。当时我才意识到——默认 bridge 网络不支持容器名 DNS 解析容器之间只能靠 IP 通信。后来翻官方文档才发现Docker 的“默认网络”和“用户自定义网络”根本不是一回事。这期文档我就把 Docker 的 6 种网络模式一次性讲透帮你少走弯路。Docker 网络模式速览Docker 的网络子系统是插件化的通过不同的网络驱动driver来提供核心网络功能。Docker Engine 在 Linux 上提供了以下内置网络驱动模式一句话概括适用场景bridge默认模式容器通过虚拟网桥通信单机多容器通信host容器直接使用宿主机网络栈追求极致网络性能none完全无网络离线计算、安全隔离container共享另一个容器的网络命名空间边车sidecar模式overlay跨主机容器通信VXLAN 隧道Swarm 集群、多机分布式macvlan容器拥有独立 MAC 地址从 VM 迁移、需要容器像物理主机ipvlan容器共享宿主机 MAC独享 IP同网段大量容器、MAC 数量受限安装 Docker 后系统会自动创建三个默认网络bridge、host、none。一图看懂所有模式对比表结构调整对比表从原 Macvlan/IPvlan 章节之后移至此处先给全局骨架再逐个拆解血肉阅读负担更小。模式隔离级别独立 IP独立 MAC端口映射跨主机性能开销平台限制bridge默认中✅✅需要-p❌中无bridge自定义高✅✅需要-p❌中无host极低❌共享宿主机❌失效 ⚠️❌最低Linux 为主Docker Desktop 4.34 需手动开启none极高❌❌❌❌零无container中依赖目标❌共享目标❌共享目标共享目标不可单独设置❌低无overlay高✅✅需配置✅高VXLAN 封装开销需 Swarmmacvlan中✅✅独立不需要❌极低接近原生性能⚠️仅 Linux云厂商常阻断ipvlan中✅❌共享宿主机 MAC不需要❌极低接近原生性能Linux模式一Bridge——默认但别直接用默认它是什么Bridge 是 Docker 的默认网络驱动。在 Linux 上Docker 启动时会创建一个名为docker0的虚拟网桥默认子网 172.17.0.0/16每个容器分配一对 veth pair——一端在容器的网络命名空间eth0一端连到网桥上。容器访问外网走 NATiptables MASQUERADE外部访问容器需要做端口映射-p。⚠️ 致命问题默认 bridge ≠ 用户自定义 bridge这是90% 新手踩的第一个坑。Docker 的默认 bridge 网络和用户自定义的 bridge 网络有本质区别特性默认 bridge用户自定义 bridge容器名 DNS 解析❌ 不支持只能用 IP✅ 自动支持动态连接/断开❌ 需要停止容器重建✅ 支持docker network connect/disconnect配置灵活性❌ 所有容器共用配置✅ 每个网络独立配置隔离性❌ 所有容器都在同一个网络✅ 按需隔离生产环境铁律永远不要在 production 中使用默认 bridge 网络。原因很简单——默认 bridge 上的容器无法通过容器名互相访问只能靠 IP。在动态环境中 IP 会变而名字不会。⚠️--link参数已废弃。老版本 Docker 可以用--link让容器通过名称互相访问但官方文档已明确将其标记为legacy feature最终可能会被移除除非你绝对需要继续使用它否则强烈建议使用用户定义的网络。别教读者用--link补救——新项目千万别碰。正确用法# ❌ 错误使用默认 bridge不指定 --network docker run -d --name my-app nginx # ✅ 正确创建用户自定义 bridge 网络 docker network create --driver bridge my-app-network # 启动容器并加入自定义网络 docker run -d --name web --network my-app-network nginx docker run -d --name db --network my-app-network postgres:16 # 在 web 容器中可以直接通过 db 访问数据库 docker exec web ping db # 能通生产环境常用--internal参数如果你需要创建一个完全隔离的内部网络容器之间可以互通但不能访问外部网络可以加上--internal参数# 创建内部网络容器无法访问外网 docker network create --driver bridge --internal my-internal-network docker run -d --name internal-app --network my-internal-network nginx # 这个容器无法 ping 通 8.8.8.8但可以和同网络的其它容器通信这个模式很适合用来部署内网微服务——数据库、缓存、消息队列这些不需要直接暴露给外网的组件放在 internal 网络里更安全。特点总结维度评价隔离性高独立网络命名空间性能中NAT veth pair 有开销比 host 低约 5–10%易用性高默认即用但自定义网络需要手动创建安全性中端口可控但需要合理规划网络隔离适用场景单机多容器应用Web 服务 数据库 缓存开发/测试环境需要端口映射对外暴露服务的场景模式二Host——性能王者隔离弃子它是什么Host 模式下容器直接使用宿主机的网络命名空间没有网络隔离、没有虚拟网桥、没有 NAT。容器内的端口就是宿主机的端口——比如容器里监听 80宿主机的 80 端口就直接被占用了。性能优势从哪来省掉了三层东西NAT 转换、veth pair 遍历、userland-proxy。对于高频交易、实时数据采集这类对延迟极度敏感的场景host 模式是首选。⚠️ 两个致命限制第一端口冲突。同一台宿主机上只能有一个容器监听同一个端口。想跑两个 Nginx 容器都用 80 端口没门。第二-p参数失效。官方文档明确写了——-p、--publish、-P、--publish-all这些选项在 host 网络模式下会被忽略并产生警告$ docker run -d --network host -p 8080:80 nginx WARNING: Published ports are discarded when using host network mode平台支持Host 网络驱动只在 Linux 上原生支持。Docker Desktop 从 4.34 版本开始支持需要手动在 Settings → Resources → Network 中开启“Enable host networking”。特点总结维度评价隔离性极低完全共享宿主机网络栈性能最高无任何虚拟化开销端口管理麻烦必须手动规划避免冲突安全性较差容器可访问宿主机所有网络接口适用场景对网络性能极度敏感的应用高频交易、游戏服务器、基准测试需要处理大量端口的应用避免每个端口创建 userland-proxy单容器部署没有多容器端口冲突问题模式三None——完全离线它是什么None 模式下容器只有lo回环网卡没有外部网络连接与宿主机和其他容器完全隔离。$ docker run -it --network none alpine ip addr 1: lo: LOOPBACK,UP,LOWER_UP ... # 只有 lo没有 eth0适用场景只需要运行计算任务、不需要任何网络通信的批处理容器安全沙箱、离线审计测试隔离环境⚠️ 注意None 网络不支持 Swarm 服务。模式四Container——共享命名空间的“边车”模式它是什么Container 模式让一个新容器与一个已存在的容器共享同一个网络命名空间。这意味着两个容器共用一套 IP 地址、路由规则和端口空间Port Space。# 先启动一个容器 docker run -d --name app tomcat # 新容器共享 app 的网络命名空间 docker run -d --name nginx --network container:app nginx核心理解关键避坑点既然共享了端口空间那么这两个容器不能同时监听同一个端口。比如 App 容器监听了 8080Nginx 容器就不能再监听 8080会报端口冲突但它们可以互相通过localhost或127.0.0.1直接访问对方暴露的不同端口例如 Nginx 监听 80App 监听 8080Nginx 就能通过localhost:8080反向代理到 App。这个设计在Kubernetes Pod 模型中被大量使用——Pod 内的多个容器如主业务容器 日志采集 Sidecar共享网络命名空间通过localhost高效通信但各自监听不同的端口号。端口映射行为补充说明如果在创建“目标容器”App时使用了-p 8080:8080这个端口映射规则会被新容器继承。如果目标容器没有端口映射新容器也不允许单独添加-p参数会被 Docker Daemon 拦截或报错。 过渡句搞定了单机内的网络“合租”模式接下来的需求就升级了——如果容器需要跨宿主机进行通信那就必须请出下一章的主角Overlay 网络。特点总结维度评价隔离性中与目标容器共享 IP 及端口空间端口冲突风险较高需人工规划两个容器的监听端口灵活性依赖目标容器的生命周期典型场景边车模式如日志采集器与主应用共享网络适用场景Sidecar 代理如 Envoy 伴随主容器调试代理需要访问目标容器的网络栈多进程容器风格的部署模式五Overlay——跨主机通信的标配它是什么Overlay 网络将多个 Docker 守护进程连接在一起让运行在不同宿主机上的容器能够直接通信。它基于VXLAN 隧道技术在底层网络上构建一个覆盖网络。⚠️概念澄清Overlay 是Docker Swarm 模式的内置网络方案。其 VXLAN 封装理念也被 Kubernetes CNI 插件如 Flannel广泛采用但K8s 环境中不会使用 Docker 的 Overlay 驱动而是用独立的 CNI 实现。不要把 Docker Overlay 和 K8s CNI 混为一谈。性能代价Overlay 网络有不可忽视的性能开销。VXLAN 封装会增加约50 字节的包头开销吞吐量通常只有原生网络栈的一半左右。 生产环境关键参数MTU这是 Overlay 网络在生产环境最大的坑。如果不设置 MTUVXLAN 头部约 50 字节会导致底层网络频繁丢包或分片跨主机大包传输会直接卡死。铁律如果底层物理网卡 MTU 为 1500Overlay 网络的 MTU必须设置为 14501500 - 50。# ✅ 正确通过 --opt 指定 MTU docker network create -d overlay \ --subnet10.0.9.0/24 \ --opt com.docker.network.driver.mtu1450 \ my-overlay-net⚠️注意Dockernetwork create命令中不存在--mtu这个顶级参数。正确的写法是通过--opt com.docker.network.driver.mtu1450传递。不设置这个参数跨主机通信会出现诡异的“小包能通、大包超时”问题——排查起来极其痛苦。适用场景多主机分布式应用Docker Swarm 集群服务需要跨节点容器通信的场景模式六Macvlan vs IPvlan——直接接入物理网络的双生子这两个模式放在一起说因为它们解决的是同一类问题——让容器直接接入物理网络获得与宿主机同网段的独立 IP。MacvlanMacvlan 为每个容器分配独立的 MAC 地址让容器在网络上看起来像一台独立的物理主机。docker network create -d macvlan \ --subnet192.168.1.0/24 \ --gateway192.168.1.1 \ -o parenteth0 \ my-macvlan-net优点性能极好接近原生性能——绕过 docker0 和 NAT开销极低不需要端口映射和额外桥接完美兼容需要 MAC 地址识别的遗留应用。缺点很致命只支持 Linux 主机不支持 Docker Desktop for Mac 或 Windows官方文档明确写了“Most cloud providers block macvlan networking. You may need physical access to your networking equipment.”——因为需要物理网卡工作在混杂模式promiscuous mode云平台的虚拟交换机层面通常会阻止需要 Linux kernel 3.9推荐 4.0不支持 rootless 模式宿主机与 macvlan 容器之间默认无法直接通信这是 Linux 内核的限制我在 AWS 上试过 macvlan直接翻车。不是配置问题是底层网络压根就不允许。如果你的容器跑在云上macvlan 基本可以忽略。IPvlanIPvlan 和 macvlan 类似但不为每个容器分配独立的 MAC 地址——所有容器共享宿主机的 MAC 地址只在 IP 层做区分。docker network create -d ipvlan \ --subnet192.168.1.0/24 \ --gateway192.168.1.1 \ -o ipvlan_model2 \ -o parenteth0 \ my-ipvlan-net一句话区别macvlan 是“不同 MAC 不同 IP”ipvlan 是“相同 MAC 不同 IP”。IPvlan 的优势规避了云厂商对混杂模式的限制因为不分配新 MAC适合同一网段有大量容器的场景交换机 MAC 表不会爆支持 L2 和 L3 两种模式适用场景对比场景推荐从 VM 迁移应用依赖 MAC 地址识别Macvlan云环境、VPS大多数云厂商IPvlanmacvlan 大概率被阻断同网段需要大量容器 几百个IPvlan避免 MAC 地址耗尽物理机房、可控网络设备两者皆可生产环境选型决策树你的容器需要跨主机通信吗 ├─ 是 → 用 OverlaySwarm 集群 └─ 否 → 继续往下 你需要容器直接拥有物理网络 IP不需要端口映射吗 ├─ 是 → 你在物理机房还是云上 │ ├─ 物理机房可控网络 → Macvlan │ └─ 云上/VPS → IPvlanmacvlan 大概率被云厂商阻断 └─ 否 → 继续往下 你需要极致网络性能毫秒级延迟敏感吗 ├─ 是 → Host 模式但注意端口冲突 └─ 否 → 继续往下 你需要容器间通过名称互相访问吗 ├─ 是 → **用户自定义 bridge 网络**千万别用默认的 └─ 否 → 默认 bridge 也能用但建议还是用自定义的 你的容器完全不需要网络 └─ None 模式验证方法1. 查看当前所有网络docker network ls预期输出Linux 上NETWORK ID NAME DRIVER SCOPE def456... bridge bridge local ghi789... host host local jkl012... none null local说明SCOPE列对于 Overlay 网络会显示swarm对于 Bridge/Host/None 显示local。2. 查看容器的网络详情docker inspect container_name | jq .[0].NetworkSettings3. 测试容器间 DNS 解析自定义 bridge# 在 web 容器中 ping db 容器通过容器名 docker exec web ping db4. 验证 host 模式下端口映射被忽略docker run --rm --network host -p 8080:80 nginx 21 | grep -i warning # 应该看到: WARNING: Published ports are discarded when using host network mode常见问题真实报错Q1默认 bridge 网络下容器无法通过名称互相访问报错原文ping: bad address my-db原因默认 bridge 网络不支持自动 DNS 解析容器之间只能通过 IP 地址访问。解决方案改用用户自定义 bridge 网络。docker network create mynet docker run -d --name db --network mynet postgres docker run -d --name web --network mynet nginx # 现在 web 容器中可以直接 ping dbQ2Host 模式下使用-p端口映射不生效报错原文WARNING: Published ports are discarded when using host network mode原因host 模式下容器直接使用宿主机网络栈没有独立的网络命名空间端口映射没有意义。解决方案移除-p参数直接让容器监听端口或者改用 bridge 网络 端口映射Q3Macvlan 在云服务器上无法工作官方文档原文“Most cloud providers block macvlan networking. You may need physical access to your networking equipment.”社区反馈“多数公有云默认启用源/目的检查Source/Destination Check尤其在使用自定义网桥或 macvlan 模式时会拦截非本机发起的流量。”解决方案如果在云上改用IPvlan共享宿主机 MAC不触发云平台限制如果在物理机房且能控制交换机可以尝试 macvlanQ4Container 模式启动失败——目标容器不存在报错原文No such container: container_name原因--network container:name指定的目标容器不存在或未运行。解决方案确保目标容器已经存在且处于运行状态。Q5Overlay 网络跨主机大包通信超时现象小包如 ping能通但大包如 curl 大文件、数据库批量查询超时或卡死。根本原因VXLAN 封装增加了约 50 字节的包头开销如果 Overlay 网络的 MTU 没有相应减小数据包会在物理网络层面被分片或丢弃。解决方案创建 Overlay 网络时通过--opt com.docker.network.driver.mtu1450设置 MTU。最后说几句三个核心 takeaways永远不要在生产环境用默认 bridge——没有 DNS 解析容器间只能靠 IP一重启就崩。创建用户自定义 bridge 网络是举手之劳收益巨大。--link已经废弃别走回头路。性能、隔离、便捷三者不可兼得——host 最快但最不安全bridge 最通用但有 NAT 开销overlay 能跨主机但必须设置 MTU1450否则大包传输会卡死。选型前先想清楚你最在乎什么。macvlan 在云上大概率不可用——别在 AWS、GCP、阿里云上折腾 macvlan 了直接上 ipvlan 省心。如果觉得这篇对你有帮助欢迎分享给团队里正在踩网络坑的同事。你在生产环境里用过哪个网络模式遇到过什么奇葩问题欢迎留言交流。
