用Docker这么久网络模式算是避不开的一道坎。很多新手能把镜像、容器、Compose玩得飞起一遇到docker network就卡住为什么两个容器互相ping不通为什么宿主机访问不到容器端口为什么Swarm服务之间可以自动互访这些问题归根结底都是没吃透Docker网络模式。这篇文章不打算复读官方文档而是把实战经验摊开来讲常见的bridge、host、none、container、overlay、macvlan每种模式适合什么场景、怎么配置、有哪些隐藏坑。无论你是做后端开发、运维还是自己在机器上折腾自建服务读完应该能对Docker网络形成完整的判断力遇到问题也知道从哪下手。1. 整体认知先搞懂Docker网络到底在解决什么问题1.1 为什么网络配置是绕不开的门槛你执行docker run启动一个容器本质上是启动了一个进程只不过这个进程被装进了独立的文件系统、独立的进程空间和独立的网络命名空间。网络命名空间意味着容器有自己的一套网卡、IP、路由表和防火墙规则。Docker不会让这些资源裸奔出来而是设计了一套网络模型把隔离和连通性做了分层处理。Docker网络模式的选择本质上是在隔离程度和连通性需求之间做权衡。跑一个数据库你希望它只被内部业务容器访问跑一个Web服务你希望外部流量能直接进到容器跑一个监控agent你希望它能看到宿主机的网络接口。没有一种模式适合所有场景所以Docker才提供了这么多选择。选错网络模式的代价很直接轻则业务间访问不通重则端口冲突、路由混乱、安全边界出问题。我见过有人把所有容器都放在默认bridge下服务一多DNS解析和端口映射全乱套也见过有人图省事全用host模式结果两个服务抢同一个端口排查了半天才发现是网络模式的问题。所以第一步就是建立整体认知知道每种模式在解决什么问题以及它付出了什么代价。1.2 常用网络模式速览先给一张对照表后面再逐个展开讲。模式/驱动隔离方式外部访问方式典型场景bridge容器有独立IP通过NAT出网端口映射 -p单机多容器默认首选host无隔离共享宿主机网络栈直接用宿主机端口性能敏感、端口强绑定、本地调试none只有loopback无外部网络无法访问离线计算、高安全隔离container复用指定容器的网络栈跟随共享容器sidecar模式、代理、日志采集overlayVXLAN隧道跨主机组网服务发现/IngressSwarm集群、跨主机通信macvlan独立MAC直连物理网络直接分配局域网IP容器融入存量物理网络严格来说macvlan是独立的网络驱动但使用频率很高值得和前面的内置模式放在一起看。你在docker network ls里看到的bridge、host、none是内置network同时你还可以创建自定义bridge、自定义overlay。内置network和自定义network在DNS解析、配置灵活性上差别很大后面会详细说。2. 最绕不开的bridge模式原理与配置实操2.1 bridge模式的底层链路不指定网络时容器会连到名为bridge的默认网桥这个网桥在宿主机上显示为docker0默认网段是172.17.0.0/16。整个链路可以这么看容器内eth0通过veth虚拟网卡对连到宿主机的docker0网桥docker0再对接宿主机的物理网卡。容器像是一台内网设备宿主机更像是一台路由器。容器访问外网时Docker会给iptables加一条MASQUERADE规则把容器IP改成宿主机的IP再出去外网访问容器时-p参数生成的DNAT规则把宿主机端口的流量转给容器IP。这也是bridge模式天然支持NAT式对外访问的原因。但默认bridge有两个明显的短板。第一它不支持容器名字自动DNS解析容器之间想互相访问要么把IP写死在配置里要么用已经被废弃的--link。第二默认网段人人都在用一台宿主机上跑多个Docker服务时很容易出现IP冲突或者防火墙规则互相干扰的情况。所以我的建议很明确别用默认bridge干正式业务自定义bridge网络才是日常主力。2.2 自定义bridge网络的搭建创建自定义bridge网络很简单但关键参数值得认真对待docker network create -d bridge --subnet172.25.0.0/24 --gateway172.25.0.1 mynet这条命令把网络的IP段、网关都明确划定了。后面所有连入mynet的容器都会在172.25.0.0/24内自动分配IP并且彼此可以通过容器名直接解析。基于这个网络启动两个容器docker run -d --name mysql8 --network mynet -e MYSQL_ROOT_PASSWORDyourpass mysql:8.0 docker run -d --name app --network mynet -p 8080:80 myapp:latest此时在app容器里可以直接mysql -h mysql8 -P 3306去连数据库不用查IP。自定义bridge内置了一套内嵌DNS容器名就是域名。这个特性在生产里价值极高IP会随容器重建而变化但容器名相对稳定服务之间只依赖名字重构和扩缩容都省心。如果想给容器固定IP可以加--ip参数docker run -d --network mynet --ip 172.25.0.10 --name app myapp:latest注意自定义bridge网络创建后网段和网关就不能改了。想调整网段只能重新建网络再把容器切过去。所以规划网段时要留足余地多个业务最好用不同网段避免日后冲突。另一个实用命令是docker network connect它能让容器动态加入网络不用重建docker network connect mynet mysql8这样mysql8同时连了默认bridge和mynet两个网络。多network常用于流量隔离和双网络互通。但要注意容器内默认路由一般属于第一个网络跨网络访问必须依赖明确路由或中间设备别指望一个容器在两个网络里能自由漂移。2.3 端口映射的细节与常见坑端口映射的格式是-p 宿主机端口:容器端口。宿主机端口默认绑定0.0.0.0即所有网卡都监听。如果宿主机有多个IP只想让内网IP访问可以这样写docker run -d --name web -p 192.168.1.100:8080:80 nginx:latest这种写法在安全加固时很实用具体业务网卡分别监听不同端口避免对外暴露。批量映射也可以写docker run -d --name web -p 8080-8085:80-85 nginx:latest不建议一次性映射太多端口排查问题会让你很头疼。-P参数会把Dockerfile里EXPOSE的端口全部随机映射到宿主机高位端口适合临时冒烟测试。这里有三个我踩过的坑容器内进程如果只监听127.0.0.1宿主机映射了端口也访问不到。很多应用默认拒绝非本机访问比如某些Web中间件只监听localhost你要先把容器内服务改成监听0.0.0.0否则端口映射等于白做。修改端口映射需要重建容器没有在线改的办法。所以写Compose或部署清单时端口规划要提前想清楚。宿主机开了防火墙时DNAT规则和防火墙规则可能打架。常见表现是宿主机内curl localhost:8080通但外部机器访问不通。这多半是firewalld或ufw的问题不是Docker本身的问题要看系统防火墙是否放行了对应端口。另外host模式下-p会被完全忽略。很多人配置host模式时还习惯写-p发现不生效其实这时候容器直接用宿主机端口不需要也不允许再做端口映射。3. 单机场景的三种特殊选择host、none、container3.1 host模式性能优先代价是彻底共享host模式通过--network host启用容器不会创建独立的网络命名空间直接使用宿主机的网络栈。相当于容器里的进程就是宿主机上的普通进程直接绑定物理网卡的IP和端口。最大的好处是性能和兼容性。一些网络性能敏感的应用比如高性能网关、监控采集agent、依赖固定IP做白名单的软件跑在host模式下省掉了NAT和veth转发延迟更低抓包也方便。容器里需要绑定特定网卡时host模式可以直接访问宿主机所有网卡不用再纠结端口映射。但代价同样明显端口完全没有隔离两个容器都监听8080就直接冲突容器里跑的服务如果异常占用端口还可能影响宿主机上其他进程。还有一个容易被忽略的风险host模式下容器内路由表和宿主机一样如果在容器里改路由、配iptables等于直接改宿主机的网络配置操作风险很高。我的经验是host模式适合把容器当普通进程管理的场景比如daemon类工具、监控客户端或者对网络性能有硬指标的服务。业务应用、数据库、多服务堆叠尽量不要用host否则迟早为端口冲突买单。3.2 none模式彻底断网也是一种能力--network none会给容器创建独立的网络命名空间但空间里只有loopback接口没有网卡、没有IP、没有路由。这个模式下容器是彻底的网络孤岛外部无法访问它它也访问不了外部。听起来很鸡肋但实际很有用。运营离线计算任务、跑涉及敏感数据的批处理脚本、或者做完全不需要网络的安全沙箱时none模式能最大程度减少攻击面。比如一个用于本地文件签名、加密的容器完全可以丢在none网络里不依赖任何网络设施反而更安全。如果想单独给none模式的容器手搓网络也可以通过nsenter进入容器的网络命名空间手动建veth、配IP基本等于手工实现一遍bridge。这个操作比较进阶非必要不建议在生产环境手动搞容易把网络命名空间搞乱。3.3 container模式和某个容器共享网络栈container模式比较有意思新容器不创建自己的网络栈而是直接复用指定容器的网络栈。启动方式docker run -d --name app --network container:mysql8 myapp:latest这样app容器和mysql8容器共享同一个IP、同一组端口它们之间用localhost就能互访。这个模式天然适合sidecar架构主容器跑业务另一个容器跑日志采集日志采集容器用container模式挂到主容器的网络里就能拿到全部回环流量。但共享网络栈意味着端口必须错开。两个容器都要监听8080就冲突。我在做流量代理转发时经常这么用业务容器只监听127.0.0.1代理容器共享它的网络栈代为监听公网端口业务完全不感知外部网络安全和可维护性都很好。要注意container模式依赖的目标容器必须先启动而且目标容器重启共享网络的容器也会受影响。生产环境用这种拓扑时要谨慎设计重启策略。4. 跨主机与物理网卡overlay和macvlan模式4.1 overlay模式Swarm集群的基础网络单机场景bridge够用但当你把多台物理机组成Docker Swarm集群就需要overlay网络。overlay网络通过VXLAN封装在底层物理网络之上再叠加一层虚拟网络。每个容器能拿到跨主机唯一的虚拟IP不同主机上的容器可以像在同一局域网内一样直接通信。初始化Swarm后创建overlay网络docker swarm init docker network create -d overlay --attachable my-overlay--attachable参数很重要它允许不是Swarm Service的普通容器也连入这个overlay网络。不加这个参数只有Swarm部署的服务才能使用。启动跨主机服务docker service create --network my-overlay --name web --replicas 3 nginx:latest三个副本可能分布在三台主机上但通过服务名web任意节点上的容器都能互相解析和访问。核心机制是Swarm自带DNS和服务发现配合VXLAN隧道转发数据包从节点A的容器出发在物理网络里封装成UDP包到节点B再解封还原整个过程对容器不透明。配置overlay网络时注意几个端口7946/tcp、7946/udp用于节点发现和状态同步4789/udp用于VXLAN数据通道。云厂商安全组或本机防火墙必须放行这些端口否则overlay网络建立起来但数据不通表现为服务能正常注册但副本之间死活连不上。如果对链路易被监听有顾虑可以加密docker network create -d overlay --attachable --opt encrypted my-overlay-secure加密模式会额外消耗一部分CPU但对跨机房的链路来说这个成本通常值得。4.2 macvlan让容器直接成为局域网成员macvlan模式像是bridge的去NAT化变体。它为每个容器生成独立MAC地址然后把宿主机物理网卡当作交换机的上行口容器直接暴露在物理局域网中。不需要做端口映射外部设备可以直接访问容器IP。创建macvlan网络假设宿主机物理网卡是eth0局域网是192.168.1.0/24docker network create -d macvlan \ --subnet192.168.1.0/24 \ --gateway192.168.1.1 \ -o parenteth0 \ macnet启动容器时指定macvlan网络容器会拿到192.168.1.x的地址局域网内其他设备可以直接访问。在存量基础设施上很有用比如现有环境只有传统交换机、没有SDN又希望容器拥有独立身份macvlan就派上用场了。但macvlan有几个明显的坑宿主机无法直接访问macvlan网络里的容器IP。因为macvlan的父接口通常不会接收发给子接口MAC地址的数据包导致宿主机和macvlan容器之间的通信中断。想绕开可以给宿主机额外创建一个macvlan的vlan子接口再配同网段IP。Wi-Fi环境基本用不了macvlan。无线路由通常会对非自身发出的MAC地址做过滤容器能拿到IP但通信经常断。云主机上慎用macvlan。云平台对MAC地址有绑定和限制macvlan会让网卡出现多个MAC很可能直接被平台掐断网络。与macvlan类似的还有ipvlan模式它不生成新MAC而是基于IP路由实现更省MAC资源但很多网络设备对ipvlan兼容性不如macvlan。能用macvlan的场景优先用macvlan。5. 网络故障排查与实用心得5.1 端口映射失效的排查路径端口映射失效是最常见的Docker网络问题。表现形式很多宿主机本地能访问、外部不能访问容器内能访问、宿主机不能访问甚至宿主机和容器互不相通。我通常按这个顺序排查# 1. 确认容器确实在监听 docker exec web ss -tlnp # 2. 确认宿主机端口监听情况 ss -tlnp | grep 8080 # 3. 确认端口映射关系 docker port web # 4. 查看网络配置 docker network inspect bridge # 5. 查看NAT规则是否生成 iptables -t nat -L -n | grep 8080最容易漏掉的一步是看容器内进程监听地址。很多镜像默认服务监听127.0.0.1但Docker端口映射的DNAT目标是容器的eth0 IP进程不监听eth0 IP就接收不到。所以第一步一定是先进容器执行ss -tlnp确认监听地址是0.0.0.0而不是127.0.0.1。另一个真实案例某同学在Ubuntu上起了一个Nginx容器-p 8080:80也写了容器内Nginx也正常外部就是访问不了。最后查下来是ufw默认策略是denyDocker的iptables规则和ufw的交互又很魔幻。这种场景要么放行对应端口要么调整ufw对Docker网桥的信任策略。不同系统版本行为不一样建议仔细核对。5.2 容器互通异常的排查思路如果两个容器都在同一个bridge网络但还是ping不通先确认它们是不是真的在同一个网络下docker inspect app -f {{json .NetworkSettings.Networks}} docker network inspect mynet看输出里两个容器的网络名称和IP网段是否一致。一个是默认bridge一个是自定义bridge默认就是互不相通的。解决方法用docker network connect把其中一个容器连到另一个网络里。跨主机容器连不上的情况优先检查overlay所需端口是否放行再用docker service ps看任务分布在哪个节点在两端节点上用ip route和docker network inspect确认VXLAN隧道是否建立。这里不建议在容器里直接ping宿主机IP因为overlay网络的默认路由设计会让ICMP包走隧道再回来表现非常反直觉容易误判为网络故障。5.3 最实用的几个调试工具我的网络调试三板斧docker exec、nsenter、tcpdump。docker exec适合进容器看服务状态但容器镜像越小自带的网络工具越少精简版Alpine可能连ping都没有需要apk add iputils先补工具。nsenter适合进入容器的网络命名空间做观察docker inspect -f {{.State.Pid}} web nsenter -t PID -n bash进去以后看到的是容器的网络栈但用的是宿主机上的工具调试起来顺手得多。tcpdump是最后手段在宿主机上指定网卡抓包tcpdump -i docker0 host 172.25.0.10 and port 3306流量是过桥接还是过NAT、包到底有没有进容器看抓包结果一目了然。再补充一个小技巧测试容器间连通性不能只看ICMP。有些镜像默认禁了ping响应但TCP端口是通的所以最好用nc -vz 172.25.0.10 3306这类TCP探测比ping可靠得多。最后聊一点个人经验。日常单机部署我基本是自定义bridge打底多网络按需叠加业务容器放进同一个mynet里用容器名解析需要对外暴露的才加-phost模式只留给性能敏感的工具类容器跨主机统一走Swarm的overlay网络。这套组合在测试和生产环境都验证过稳定性和排障成本都优于盲目使用默认配置。如果你刚接触Docker网络别急着把六种模式都背下来。先把bridge玩熟再根据真实需求去研究overlay或者macvlan。网络这块很多问题不是配置命令的问题而是对流量到底走了哪条路没有概念。找时间用tcpdump追踪一次容器访问外网的完整路径理解会通透很多。希望对你有帮助。