Docker容器之所以能被广泛用于R语言数据科学环境以及各类微服务部署，很大程度得益于它灵活的网络体系。很多初学者在部署Shiny应用、Plumber API服务时，经常遇到容器之间ping不通、宿主机访问不到容器端口、跨机器容器无法互联的问题，其根源都在于没有理解Docker的网络模型。本文围绕最常用的两种网络模式展开：单机场景下的bridge网桥，以及跨主机场景下的overlay网络，把配置过程和背后的原理一次性讲清楚。
一、bridge模式的工作原理与默认行为
Docker安装完成之后会自动创建三个网络：bridge、host和none。其中bridge是容器默认加入的网络，它依赖Linux内核的网桥设备docker0来实现。每当有新容器启动，Docker会从172.17.0.0/16这个地址段中分配一个空闲IP给容器的虚拟网卡，宿主机上则会出现一个对应的veth接口，一头挂在容器内部的eth0上，另一头插进docker0网桥，相当于给容器接了一根虚拟网线到宿主机内部的虚拟交换机上。
理解这个拓扑之后，很多现象就解释得通了。两个容器都在bridge网络里，它们可以直接通过IP互访，因为流量走的是同一个二层网桥；容器访问外网时，数据包经过docker0后由宿主机做NAT转发出去；宿主机访问容器则需要通过端口映射，因为容器IP属于内部地址段，外部网络默认不可路由。可以通过下面的命令观察当前的网络状态：
# 查看Docker内置网络列表 docker network ls # 查看bridge网络的详细配置，包括子网和网关 docker network inspect bridge # 在宿主机上查看docker0网桥 ip addr show docker0
默认bridge网络有个明显短板：容器之间只能靠IP通信，不支持通过容器名做DNS解析。也就是说，容器重启后IP一变，依赖这个IP的其他服务立刻失效。这在R应用场景里很常见，比如一个Plumber API容器需要连接数据库容器，写死IP显然不可维护，所以生产环境几乎都会用自定义bridge网络来替代默认网络。
二、自定义bridge网络的创建与容器互联
自定义bridge网络相比默认bridge多了两个关键能力：一是内置DNS服务，容器名可以直接当主机名用；二是网络隔离，不同自定义网络之间的容器默认互相不可见，安全性更好。创建过程非常简单：
# 创建一个自定义bridge网络，指定子网便于规划 docker network create --driver bridge \ --subnet 172.20.0.0/16 \ --gateway 172.20.0.1 \ rnet # 启动R环境容器并加入该网络 docker run -d --name r-server --network rnet \ rocker/r-base:latest sleep infinity # 再启动一个容器作为客户端 docker run -d --name r-client --network rnet \ rocker/r-base:latest sleep infinity # 测试容器名解析与连通性 docker exec r-client ping -c 3 r-server
上面两个容器都加入了rnet网络，r-client执行ping r-server能够正常解析到IP并收到响应，这就是内置DNS在起作用。如果希望容器同时加入多个网络，可以先用docker run挂一个网络，再用docker network connect追加，例如让一个R容器同时接入业务网络和数据网络，实现按需隔离。
端口映射是bridge模式绕不开的话题。宿主机访问容器内的服务，必须在启动时用-p参数建立映射。以Shiny应用为例，容器内Shiny Server监听3838端口，映射命令如下：
# 将宿主机8080端口映射到容器的3838端口 docker run -d --name shiny-app --network rnet \ -p 8080:3838 \ rocker/shiny-verse:latest # 查看端口映射关系 docker port shiny-app
需要注意-p 8080:3838和-p 127.0.0.1:8080:3838的区别：前者对所有网卡开放，公网IP也能访问到；后者只绑定本机回环地址，仅限宿主机内部访问，适合前面有Nginx反向代理的场景。生产环境暴露端口时尽量用后者，减少直接暴露面。
三、overlay网络：跨主机容器的通信方案
bridge网络再怎么配置，作用范围也仅限单台宿主机。当R计算服务分布在多台机器上，或者微服务集群跨节点部署时，就需要overlay网络了。overlay网络基于VXLAN隧道技术，在底层物理网络之上构建一个虚拟二层网络，让不同宿主机上的容器看起来像插在同一个交换机上。
overlay网络的正式使用依赖Docker Swarm集群。首先初始化集群，然后创建overlay网络，所有加入该网络的服务即可跨主机互通：
# 在管理节点初始化swarm集群 docker swarm init --advertise-addr 192.168.0.10 # 工作节点加入集群（命令由init输出提示） docker swarm join --token SWMTKN-1-xxxx 192.168.0.10:2377 # 创建加密的overlay网络 docker network create \ --driver overlay \ --attachable \ --subnet 10.0.1.0/24 \ --opt encrypted \ roverlay # 部署一个跨节点的R服务 docker service create --name r-api \ --network roverlay \ --replicas 2 \ -p 8080:8000 \ rocker/r-ver:latest Rscript -e "plumber::pr_run(plumber::Plumber\$new(), port=8000)"
这里有几个参数值得展开。--attachable允许普通的docker run容器（而不仅是service）接入该网络，调试阶段特别有用；--opt encrypted对VXLAN数据包加密，代价是约10%左右的性能损耗，涉及敏感数据传输时建议开启；--subnet指定overlay网段，注意不要与宿主机现有网段冲突。服务部署后，swarm自带的DNS会在r-api这个服务名下做负载均衡，两个副本分摊请求，这正是overlay网络配合service发现的价值所在。
验证跨主机连通性可以在任意节点上起一个临时容器接入网络测试：
# 在节点二上启动调试容器接入overlay网络 docker run -it --rm --network roverlay rocker/r-base:latest bash # 容器内测试服务名解析 ping r-api
如果解析正常且能收到响应，说明VXLAN隧道工作正常。排查不通时，先检查各节点2377、7946和4789端口的防火墙放行情况，这三个端口分别承担集群管理、节点发现和VXLAN数据传输，任何一个被拦截都会导致overlay异常。
四、两种网络的选型建议与常见问题
选型其实并不复杂：单机部署、本地开发，用自定义bridge就够；多机集群、需要服务发现和负载均衡，上overlay加swarm；追求极致网络性能且不需要隔离时，可以考虑host模式，但要清楚host模式下容器与宿主机共享网络栈，端口冲突风险由自己承担。
几个高频踩坑点也值得记录。第一，容器间通信用容器名或服务名，别依赖IP，重启后IP会变。第二，默认bridge网络里的容器没有DNS，容器名解析只在自定义网络中生效，这是新手最容易混淆的点。第三，overlay网络的ingress网络是swarm路由网格专用的，不要把业务服务直接挂上去。第四，Windows或macOS上的Docker Desktop实际运行在虚拟机里，bridge的iptables规则和真实Linux宿主机表现不同，排查问题时务必进入虚拟机层面去看。
掌握bridge和overlay这两套网络模型，容器化部署中绝大多数网络问题都能定位到具体层面。建议在自己的测试环境里把文中命令完整跑一遍，观察docker network inspect输出的网段、网关和容器列表，对Docker网络的理解会比只看文档深刻得多。
Docker bridge模式overlay网络容器网络配置修改时间：2026-09-16 21:54:57