1. 先搞懂Docker网络到底在解决什么问题我接触Docker这几年最深的感受是很多人能把容器跑起来但一涉及到容器之间怎么通信、宿主机怎么访问容器、容器怎么上网就各种抓瞎。这其实很正常因为网络这块本身就是Docker体系里最抽象的环节不像run一个容器那么简单直观。先给新手把概念捋一遍。Docker的网络配置本质上是在解决这么几个问题容器和容器之间怎么找到对方、怎么互相通信宿主机就是你装Docker那台机器怎么访问容器里跑的服务容器怎么访问外网以及外网怎么访问到容器里暴露出来的服务。这四个问题要是没理清楚后面部署任何多容器项目都会踩坑。以我自己带团队的经验来说绝大多数Docker环境里的“连不上”“不通”“超时”八成以上都是网络模式选错了、或者端口映射没搞对、再就是自定义网络没接上而不是容器本身有问题。所以把网络这块吃透是Docker从入门到能独立部署项目的分水岭。这篇文章面向的读者是那种已经会docker run和docker-compose但一碰到网络就懵的同学。我会把Docker的几种核心网络模式讲明白再带你实际动手配置端口映射、自定义网络、跨主机通信这些高频操作最后把我这几年踩过的坑和排查思路整理成一份速查清单方便你直接对号入座。2. Docker内置的四种网络模式分别该在什么场景用2.1 bridge模式默认选项也是单机部署的主力你执行docker run不带任何网络参数默认就走bridge模式。这个模式做的事情是Docker守护进程会在宿主机上创建一个名为docker0的虚拟网桥但凡新建的容器都会通过一对虚拟网卡veth pair挂到这个网桥上然后自动分到一个172.17.0.0/16网段内的IP。打个生活化的比方docker0就像一个楼内的交换机每个容器就是插在这台交换机上的电脑它们之间可以直接用IP互相访问但要注意这个楼内的局域网和楼外宿主机外网是隔离的。容器想上外网需要通过宿主机的NAT转发也就是说Linux内核里的IP转发功能在做地址转换把容器内部IP映射成宿主机的IP再出去。bridge模式的好处是开箱即用、隔离性好适合单机上的多容器部署场景。缺点是每次容器重建IP都会变所以生产环境里不建议直接用IP通信而是用后面要讲的自定义网络加容器名。有个细节常被忽略bridge模式下的容器和宿主机虽然能互通但宿主机访问容器必须通过映射出来的端口不能直接拿容器IP去访问。这一点和host模式完全不同后面会对照着解释。2.2 host模式性能极致但隔离性妥协host模式一句话概括容器直接共享宿主机的网络命名空间不创建自己的网络栈。也就是说容器里看到的网卡、IP、端口就是宿主机本身的。举个例子你用host模式跑一个监听8080端口的Nginx容器那这个8080就等同于宿主机本机的8080直接curl localhost:8080就能通。这个模式最大的优势是性能好、延迟低因为少了一层NAT转换。适合那种对网络性能要求极高、但又不怎么需要网络隔离的场景比如一些压测工具容器、高性能缓存中间件之类的。但代价也很明显第一容器之间没法用端口区分服务了比如两个容器都监听8080就一定会冲突第二容器失去了自己的网络隔离边界安全性不如bridge。我在生产里只会在明确追求性能、且是单容器跑单一服务的场景才用host其他情况一律不碰。顺便说一句Windows和macOS上的Docker Desktop对host模式支持是有限的因为那俩场景本质是跑在虚拟机里的所以如果你用的是Docker Desktop别指望host模式有完整的Linux行为。2.3 none模式完全隔离通常用于特殊工具none模式就是不给容器配置任何网络接口容器里只有一个lo回环地址连外网、连其他容器都不行。听起来好像很鸡肋但实际上在某些场景非常有用比如跑一些离线计算任务、做网络调试的隔离环境、或者你希望容器完完全全与外界断开联系以保证数据安全。我用none模式最多的场景是跑那种需要临时挂载进去做排查的工具容器以及某些安全要求极严格的批处理任务。不过对绝大多数读者来说none模式了解即可真正日常开发中用到的机会很少。2.4 overlay模式跨主机的解决方案当你从单机走向集群比如用Docker Swarm或者Kubernetes编排多台机器时overlay模式就是主角。它做的事情是在多个宿主机之间建立一层虚拟网络让容器可以跨物理机直接通过虚拟IP通信底层数据包的转发和加密对容器是透明的。overlay模式的理解可以类比成你家在A楼、朋友家在B楼你们之间没有连着的网线但通过运营商的路由器宿主机网络建立了一条隧道让两家的电脑看起来就像在同一个局域网里。Docker的overlay网络默认会做VXLAN封装把这层“隧道”的细节屏蔽掉。实际应用的时候你通常不是手动建overlay网络而是通过docker swarm init或者部署到k8s之后由编排系统自动管理。但理解它的存在很重要这样你在看集群架构图时就不会对“容器IP跨主机还能互通”感到困惑。3. 网络配置的核心实操端口映射、自定义网络和容器互联3.1 端口映射-p 参数背后到底发生了什么最基础也最高频的操作就是端口映射。你写docker run -p 8080:80 nginx意思是把宿主机上的8080端口转发到容器的80端口上。这里有个初学者常犯的误区-p参数前面的端口是宿主机端口后面的才是容器端口别写反了。实际通信链路是这样的外部请求到达宿主机的8080端口iptables的DNAT规则Docker会自动维护这套规则会把流量目标改写成容器IP的80端口然后通过docker0网桥送到容器里。这里面Docker做了一层非常聪明的转发你自己完全不用去碰iptables除非遇到特别复杂的需求才需要手工干预。多端口映射也很简单想暴露几个就写几个-p参数比如-p 8080:80 -p 443:443。还有个细节值得注意如果只写-p 80:80而不指定宿主机IP默认会绑定到0.0.0.0也就是所有网卡接口都会监听这个端口。假如你有多块网卡、或者服务器是公网暴露的这会带来安全隐患。想只让内网访问就写成-p 127.0.0.1:8080:80这样只有本机或通过本机代理的请求才能访问到。3.2 自定义网络是生产级实践的基石前面提到bridge模式下容器IP不稳那怎么保证服务发现呢答案是用自定义bridge网络。你执行docker network create mynet创建一个自定义网络然后run容器时加--network mynet这个网络里的容器不仅自动分配稳定的网段IP更重要的是Docker内置的DNS解析能让你直接用容器名互相访问。举个例子你启动了一个MySQL容器容器名是mysql8网络是mynet再启动一个应用容器连到同一个mynet那应用容器里配置数据库地址直接写mysql8:3306就能连通完全不用关心MySQL容器的IP是多少。这个特性在生产部署里救了我无数次因为容器每次重建IP都可能变但容器名是稳定不变的。自定义网络还提供更好的隔离性。默认的bridge模式下所有容器都在同一个docker0网段里互相之间默认能互通但如果你创建了多个自定义网络容器之间默认是不通的只有显式连接到同一个网络才能通信。这意味着你可以把前后端容器放在一个网络把数据库放在另一个隔离网络再只把必要端口映射出来攻击面一下就缩小了。具体操作上你可以让一个容器同时接入多个网络docker network connect mynet2 容器名就能追加一块网卡进去。这在微服务架构里很实用比如一个网关容器既要在前端网络里接收流量又要连到后端服务网络里去转发请求。3.3 容器互联的几个常见形态和选择容器互联首先要区分几种场景一种是同机容器互联用自定义网络加容器名就搞定了另一种是跨机容器互联单机bridge肯定不行要么用overlay要么就用最朴素的办法——把依赖的端口映射到宿主机然后让对方从宿主机IP加端口访问。这里我想特别点名一个热搜里出现的“docker容器内的mysql怎么访问”。实际操作时如果你的应用容器和MySQL容器在同一个自定义网络里直接mysql:3306就行如果应用容器在外面的宿主机上那就需要把MySQL的3306映射出来比如-p 3306:3306然后用localhost或宿主机IP连。但请务必注意生产环境别把数据库端口直接暴露公网要加访问控制或者至少绑到内网IP上。还有一种形态是用docker-compose编排。Compose文件里默认会为整个项目自动创建一个自定义网络所以你在docker-compose.yml里定义的每个服务天然可以用服务名互相访问。很多人不知道这一点明明容器都启动成功了却还在费劲查IP其实直接用服务名就行了。4. 实际场景拆解从部署一个Nginx到多服务微服务为了让你把这些配置串起来我拿一个实实在在的场景带你走一遍。4.1 场景一单容器部署Nginx并暴露端口这是最经典的入门案例。假设你拉取了nginx:latest镜像要把它跑起来并让宿主机用8080访问docker run -d --name webapp -p 8080:80 nginx这条命令一执行完你可以直接在宿主机浏览器访问http://localhost:8080看到Nginx的欢迎页。这里的链路是浏览器 - 宿主机8080端口 - docker-proxy进程接收并转发 - 容器80端口。Docker在Linux上是靠iptables的DNAT规则来做转发的Docker Desktop在macOS/Windows上是靠一个轻量级的虚拟机加端口代理实现的。如果你想要更精细的绑定比如只允许127.0.0.1访问docker run -d --name webapp -p 127.0.0.1:8080:80 nginx这样外部设备就访问不到这个服务了只有宿主机本机能访问。4.2 场景二多服务部署——Web应用加MySQL现在升级一下我们部署一个简单的Web应用容器和一个MySQL容器要求应用能连上MySQL。推荐步骤是这样的先创建自定义网络docker network create myapp-net再启动MySQL并把它接入这个网络docker run -d --name mysql8 \ --network myapp-net \ -e MYSQL_ROOT_PASSWORDyourpass \ -e MYSQL_DATABASEmyapp \ mysql:8.0然后启动你的应用容器同样接入myapp-netdocker run -d --name backend \ --network myapp-net \ -p 8080:8080 \ your-app-image在这个配置下backend容器里配置数据库连接只需要用mysql8:3306作为地址Docker内置的DNS会把mysql8解析到对应容器的IP。你根本不用去查MySQL容器的IP是多少这比什么link参数都省心。如果这时候你还想从宿主机连MySQL做管理那就给MySQL也加个端口映射但我会建议只在调试时加而且绑内网docker run -d --name mysql8 \ --network myapp-net \ -p 127.0.0.1:3306:3306 \ -e MYSQL_ROOT_PASSWORDyourpass \ -e MYSQL_DATABASEmyapp \ mysql:8.04.3 场景三docker-compose里的网络自动管理如果你用docker-compose整个网络配置会更轻松。下面是一个包含web服务和redis的compose配置version: 3.8 services: web: image: your-web-app ports: - 8080:8080 networks: - app-net redis: image: redis:7-alpine networks: - app-net networks: app-net: driver: bridge你没显式配置任何网络之前compose已经默认给这个项目创建了一个前缀是项目名的网络所有服务都在这个默认网络里。但如果你有需要也可以像我上面那样显式定义网络这样服务名的解析仍然可用而且你可以把数据库这类服务放到另一个更隔离的网络里。这是我特别推荐的做法业务服务之间走一个网络数据层走另一个网络只在需要时把端口暴露出来。5. 常见网络故障排查与速查表5.1 容器之间ping不通先别急着怀疑命令我见过太多人一上来就写ping然后发现容器里根本没有ping命令就开始慌。在容器里做网络连通性测试先确认镜像里有没有装iputils-ping没有就先用docker exec -it 容器名 sh然后直接测端口或者用bash里内置的/dev/tcp来测比ping靠谱得多。实际排查思路应该是先看两边容器是不是在同一个网络里docker inspect 容器名可以看到Networks再确认目标服务监听的端口再去测连通性。5.2 permission denied while trying to connect to the docker daemon socket这个错误太经典了热搜词里也出现了。核心原因是你当前的用户没有权限访问Docker守护进程的Unix socket默认路径是/var/run/docker.sock。解决方案有两条路要么把当前用户加到docker组里sudo usermod -aG docker $USER然后重新登录要么用sudo执行每条docker命令。我个人推荐前者但一定要意识到加入docker组就等同于拿到root级别的权限因为Docker允许挂载宿主机的任意目录。所以在团队环境里给用户docker组权限之前要慎重。5.3 容器能上网但宿主机访问不了容器IP如果你发现容器里可以正常访问外网但宿主机访问容器IP不通基本都是因为你用了bridge模式而容器没有端口映射。bridge网段172.17.0.x的IP是内部地址宿主机虽然在同一张docker0网桥上但默认的路由规则并不会把对这个网段的访问直接导进容器。解决办法就是加-p端口映射或者干脆用host模式。当然你可以在宿主机上添加静态路由来做宿主机到容器IP的直连但这在生产里既笨拙又容易引起混乱不推荐。5.4 镜像下载慢、容器启动失败怎么办热搜里很多“docker安装mysql失败”“docker镜像下载慢”之类的词其实都是网络源的问题。说到底就是默认的Docker Hub镜像源在国内访问不稳定解决办法是配置镜像加速器。你可以在/etc/docker/daemon.json里写registry-mirrors改成你所在的云厂商提供的镜像加速地址然后重启dockerd生效。注意这个操作只对你重新拉取的镜像有效已经拉过的镜像不受影响。如果你用的Docker Desktop直接在Settings的Docker Engine选项里改JSON配置也一样。下面把高频故障和对应的排查命令整理成一张表格方便你直接照着做疑似问题第一步排查命令可能的解决办法容器间无法通信docker inspect 容器A | grep -A 10 Networks确认是否在同一自定义网络不在则docker network connect宿主机无法访问容器docker ps 查看端口映射补充-p映射或用host模式容器无外网宿主机执行sysctl net.ipv4.ip_forward 看是否为1开启IP转发重启docker服务宿主机端口被占用lsof -i:8080 或 netstat -tunlp换端口或停掉占用进程注意容器看不见占用情况DNS解析失败在nginx容器里执行getent hosts mysql8确认是否在同一网络检查自定义网络是否存在Docker守护进程启动失败journalctl -u docker --no-pager 或 dockerd日志常见是daemon.json写错删掉或修正后重启5.5 两条删除网络时的踩坑点最后贡献几条我从实际踩坑中总结出来的经验。第一删除自定义网络时如果网络里还有容器连接着docker network rm会报错提示网络不空这时候要么先断开所有容器要么直接删容器不要指望能强制删除。第二不要随便修改docker0网桥的默认网段除非你清楚自己在干什么。改了之后你会面临老容器IP全变化、其他服务引用了旧IP导致全面失联的问题这在生产环境里是灾难级的操作。再有一个值得反复强调的点容器网络配置是一个整体不是孤立散点。你要把“网络模式选择、自定义网络规划、端口映射范围、DNS解析机制、安全访问控制”当成一盘棋来思考。只解决眼前“通不通”的问题迟早会在下一个场景里再次踩坑。6. 我对Docker网络配置的整体心得做了这么多年的部署和运维我对Docker网络配置最大的体会是永远不要被“能跑起来”蒙蔽。很多项目在开发环境跑得很顺一到测试环境就出各种网络问题核心原因就是开发时图省事所有容器全堆在默认bridge上靠IP互相访问或者干脆把端口到处乱映射。到了稍复杂一点的环境网络冲突、安全问题就全冒出来了。所以我建议每个准备长期用Docker的人把自定义网络当成首选方案。先规划好网络拓扑哪些服务在一个网络里哪些服务要隔离哪些端口需要暴露、绑定在哪个接口上。哪怕是一个人开发的小项目也值得养成这种习惯因为一旦后期要横向扩展或者迁到集群这套规划直接就能复用。踩过几次坑之后你就会发现网络配置这件事前期多花十分钟规划后期能省几个小时排查。最后再分享一个小技巧遇到一切网络不通的问题先别慌着改配置按顺序查三件事——网络模式对不对、端口映射有没有、DNS解析通不通。八成的问题出在这三件事上剩下两成再去翻日志和查iptables规则。这套排查思路我几乎每天都在用稳定高效。
