企业官网建设流程全解析

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_PASSWORD=yourpass \ -e MYSQL_DATABASE=myapp \ mysql:8.0

然后启动你的应用容器，同样接入myapp-net：

docker 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_PASSWORD=yourpass \ -e MYSQL_DATABASE=myapp \ mysql:8.0

4.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配置也一样。

下面把高频故障和对应的排查命令整理成一张表格，方便你直接照着做：

5.5 两条删除网络时的踩坑点

最后贡献几条我从实际踩坑中总结出来的经验。第一，删除自定义网络时，如果网络里还有容器连接着，docker network rm会报错提示网络不空，这时候要么先断开所有容器，要么直接删容器，不要指望能强制删除。第二，不要随便修改docker0网桥的默认网段，除非你清楚自己在干什么。改了之后你会面临老容器IP全变化、其他服务引用了旧IP导致全面失联的问题，这在生产环境里是灾难级的操作。

再有一个值得反复强调的点：容器网络配置是一个整体，不是孤立散点。你要把“网络模式选择、自定义网络规划、端口映射范围、DNS解析机制、安全访问控制”当成一盘棋来思考。只解决眼前“通不通”的问题，迟早会在下一个场景里再次踩坑。

6. 我对Docker网络配置的整体心得

做了这么多年的部署和运维，我对Docker网络配置最大的体会是：永远不要被“能跑起来”蒙蔽。很多项目在开发环境跑得很顺，一到测试环境就出各种网络问题，核心原因就是开发时图省事，所有容器全堆在默认bridge上，靠IP互相访问，或者干脆把端口到处乱映射。到了稍复杂一点的环境，网络冲突、安全问题就全冒出来了。

所以我建议每个准备长期用Docker的人，把自定义网络当成首选方案。先规划好网络拓扑：哪些服务在一个网络里，哪些服务要隔离，哪些端口需要暴露、绑定在哪个接口上。哪怕是一个人开发的小项目，也值得养成这种习惯，因为一旦后期要横向扩展或者迁到集群，这套规划直接就能复用。踩过几次坑之后你就会发现，网络配置这件事，前期多花十分钟规划，后期能省几个小时排查。

最后再分享一个小技巧：遇到一切网络不通的问题，先别慌着改配置，按顺序查三件事——网络模式对不对、端口映射有没有、DNS解析通不通。八成的问题出在这三件事上，剩下两成再去翻日志和查iptables规则。这套排查思路我几乎每天都在用，稳定高效。