企业官网建设流程全解析

1. 为什么我不建议直接用默认的bridge网络：Docker网络管理的入门真相

很多刚接触Docker的人，可能都经历过这样一个阶段：装好Docker，跑起容器，docker ps能看到进程，应用也能访问，就觉得"网络这块搞定了"。直到某天要部署一个前后端分离项目，或者让多个容器互相通信，才发现明明容器都在同一台机器上，却怎么都连不通。这时候才意识到，Docker网络管理不是"不用管"，而是"不会管就容易掉链子"。

我从第一次部署Nginx反向代理到自建私有仓库那阵子，被各种网络问题折磨过不少次，最后硬着头皮把Docker的几种网络模式、端口转发原理、跨主机通信方案系统过了一遍，才算真正把这个环节打通。这篇内容就围绕Docker网络管理的完整体系展开，从单机上的默认网络讲起，到自定义桥接网络、跨主机组网，再到日常最能救命的排障思路，适合刚学会docker run、正准备搭建多容器项目的小伙伴，也适合部署完总遇到网络不通、想系统梳理一遍的开发者。

先说一个最重要的底层认识：Docker网络管理的核心，是让容器之间、容器与宿主机之间、容器与外部世界之间，按你的预期去转发流量。这不只是"网络通不通"的问题，还涉及IP分配、DNS解析、端口冲突、安全隔离，以及跨多台服务器时怎么把容器连接成一个虚拟局域网。如果你跳过了网络这一环，后面所有基于Docker的微服务部署都会埋下隐患。

1.1 Docker网络管理的本质：三层隔离与三类流量

要理解Docker网络管理，先别急着记命令参数，你得先清楚它到底在管什么。按我自己的总结，本质上是在处理三类流量：容器与容器之间的互访、宿主机与容器之间的访问、外部设备或浏览器与容器之间的访问。形形色色的"网络不通"问题，几乎都能归到这三类流量的某一环上。

为了管理这三类流量，Docker抽象出了几种"隔离域"，也就是网络模式。大多数人的第一反应是bridge、host、none、container、overlay这五种，但换个角度，我更倾向于把它们分成两组：单机网络方案和跨主机网络方案。bridge、host、none、container都在单台宿主机内解决问题；overlay则是为多台服务器组成的Swarm集群准备的。理解了这层关系，你就能明白为什么有时候在单机Docker上讨论overlay会显得"用不上"，也就能理解为什么官方文档反复强调：生产环境里的多容器项目，强烈建议自定义bridge网络，而不是默认的docker0。

这里还涉及一个容易被忽略的底层组件：docker0虚拟网桥。默认情况下，所有未指定网络的容器都会挂在这个网桥上，Docker会为它分配一个私有网段，比如172.17.0.0/16。容器启动后从这个网段里拿IP，彼此之间通过网桥转发数据。这个方案跑单容器、测试环境一点问题没有，但一旦你同时跑好几个项目，就会遇到IP分配混乱、DNS解析目标不明确、容器重启后IP变化导致配置失联等情况。所以，真正做项目的时候，第一步往往是创建自己独立的bridge网络，让不同项目之间互相隔离，并且同项目的容器共享同一个网络命名空间下的DNS规则。

1.2 前面说的"端口映射"到底发生了什么

再深入一层，很多新手搞不清楚"为什么我把容器的端口映射到了宿主机端口，从外面访问却失败了"。实际上这不完全是网络模式的问题，而是Linux的iptables规则在起作用。当你运行docker run -p 8080:80时，Docker daemon会在宿主机上添加一条DNAT规则，把发往宿主机8080端口的TCP流量，重定向到对应容器的80端口。这条规则插入在DOCKER链中，通常是iptables -t nat -A DOCKER ...这样的形式。

这意味着两件事：

第一，端口映射依赖宿主机的防火墙（iptables）正常工作。如果Docker daemon启动时用了--iptables=false，端口映射很可能不生效。类似地，如果你改了宿主机的firewalld或ufw规则，也可能影响到 Docker 动态插入的链。

第二，-p映射是对单个容器生效的。如果两个容器都想映射宿主机的8080端口，那么只有后启动的那个能成功，前一个会因为端口冲突而启动失败，或者处于异常状态。我见过不少人把端口冲突误判为"网络不通"，本质上是没搞清这两件事的分工。

所以，在正式进入自定义网络配置之前，务必确认你的Docker daemon是默认开启iptables管理的。多数发行版上没问题，但如果你用的是云服务器，还要额外检查安全组规则是否放行了对应端口——很多人排查半天容器网络，最后发现是云平台的安全组挡住了外部流量。

2. 从docker0到自定义bridge：容器互联的正确姿势

这一节我会直接演示：为什么默认的docker0不适合正式项目，以及如何创建并使用自定义bridge网络。如果你之后要跑MySQL主从、搭建Redis集群，或者把后端服务和数据库放在不同容器里，这套操作基本是绕不开的。

2.1 为什么默认bridge满足不了"项目隔离"

先看一个典型场景。你用docker run启动了MySQL容器和Spring Boot应用容器，两个容器都挂到默认docker0网桥上。此时MySQL容器的IP可能是172.17.0.2，应用容器需要通过172.17.0.2:3306来访问数据库。这套配置在短期内没问题，但你一定会碰到两个痛点：

一是IP的不确定性。容器每次重建，IP都可能变化；docker0网段里扩容容器时，目标IP也会变动。你不可能把数据库地址写死成某个容器IP。二是多项目的冲突。假如你在同一台宿主机上跑A项目（Redis+Web）和B项目（PostgreSQL+Web），两个项目的Web容器都想连"自己的"数据库。如果大家挤在同一个docker0上，IP是自己分配的，很容易出现A项目的Web连到B项目的PostgreSQL上，造成混乱。

自定义bridge网络就是来解决这个问题的：每个项目创建自己的网络，网络内容器通过容器名直接通信。Docker内嵌的DNS服务会负责把容器名解析成对应IP，所以你在配置文件名、连接字符串里只需要写容器名，比如jdbc:mysql://mysql-container:3306/db，然后让两个容器加入同一个自定义网络，剩下的IP解析交给Docker处理。

2.2 自定义网络的具体操作步骤

这一套我实测过很多次，步骤非常稳定。先创建网络：

docker network create --driver bridge --subnet 172.28.0.0/16 --gateway 172.28.0.1 app-network

这里有两个容易踩的坑：--subnet不要和别人已有的网络网段冲突，否则路由会变得诡异；--gateway需要落在你指定的子网内。如果你只写docker network create app-network，Docker会从默认地址池里自动选网段，也可以正常用，但是手动指定子网的好处是方便后期排障——看到IP就能知道属于哪个项目。

然后分别启动容器，并加入网络：

docker run -d --name mysql-container --network app-network -e MYSQL_ROOT_PASSWORD=123456 -p 3306:3306 mysql:8.0 docker run -d --name webapp --network app-network -p 8080:8080 my-webapp:latest

两个容器都在app-network里，webapp容器内直接mysql-container:3306就能连上库。这个过程中我特别留意过的点是：--network参数是在docker run时指定的，如果容器已启动再要加入网络，得用docker network connect app-network 容器名，两者效果一样，后者适合在线操作。

值得补充的是，自定义bridge还支持跨容器通过别名访问。比如你不想暴露"mysql-container"这个名字，可以给容器加网络别名：

docker network connect --alias db app-network mysql-container

之后同一网络内的其他容器访问db:3306也可以。这在做灰度迁移、A/B测试时非常实用，旧应用指向老数据库，新应用指向新数据库，只改网络别名就够了，应用代码一行不动。

2.3 自定义bridge带来的安全性提升

很多人只把自定义bridge当成"方便互联"的手段，忽略了它的隔离价值。默认docker0网络对同一宿主机上所有容器开放，任意容器访问另一个容器的IP和端口通常没有拦截。而自定义bridge默认就带有一定程度的隔离性，不在同一网络内的容器无法直接通过IP互通。这意味着，如果你有一个面向公网的Nginx容器和一个只允许内网访问的数据库容器，把它们放到不同的网络中，数据库就不会被Nginx容器意外访问到。

实战中我还会再加一道：数据库容器不映射任何宿主机端口，只在自定义网络内部开放。这样宿主机和外部设备完全无法直接连数据库，只有加入同一网络的业务容器能连。这个习惯对于多租户、多项目共存的服务器尤其重要。你可以边用docker network inspect app-network查看当前网络的容器清单和IP分配情况，边审视"是否有不必要的容器暴露在这个网络里"。

3. 端口映射与外部访问：宿主机防火墙、安全组和容器网络的三方协作

在单机场景下，最常被问到的问题就是"为什么端口映射了，外面还是访问不了"。这一节专门拆解外部访问链路，从-p参数到底层iptables规则，再到云平台安全组，把整条链路讲透。

3.1 -p参数背后的完整数据流

假设你在云服务器上运行了一个容器：

docker run -d -p 80:80 nginx

外部浏览器访问服务器公网IP的80端口时，数据路径是什么？第一步，数据包到达服务器网卡；第二步，进入PREROUTING链，命中Docker添加的DNAT规则，目的地址被改成容器IP；第三步，经过路由决策后，进入FORWARD链，在DOCKER链中完成端口转换并决定是否放行；第四步，数据包通过docker0或自定义网桥进入容器网卡，最终被Nginx进程接收。

也就是说，这段链路里至少有四个环节可能出问题。我遇到过的情况包括：宿主机防火墙拦截了FORWARD链、Docker daemon的iptables规则被自定义防火墙脚本清掉了、云平台安全组没有放行端口、容器内部进程绑定了127.0.0.1而不是0.0.0.0。每个环节的症状都表现为"网络不通"，但排查方向完全不同。

所以当你确认"容器在跑、应用正常"之后，切记不要只盯着防火墙或只盯着容器，而是按链路依次验证：先docker exec 容器名 curl localhost:端口判断容器内部进程是否正常监听；再在宿主机上curl localhost:映射端口验证iptables转发是否生效；最后关闭宿主机的firewalld或用安全组规则放行，分别测试。

3.2 常见外部访问故障对照表

这里我整理了一份高频故障对照表，参考价值比较大：

这个表格不是让你背下来，而是在排查时有一份对照清单，避免靠感觉定位。

3.3 什么时候该用host网络模式

既然提到外部访问，就绕不开host网络模式。--network host的意思是：容器不拥有自己的虚拟网卡和IP，直接共享宿主机的网络命名空间。容器内的进程监听端口时，等价于在宿主机上监听；也就是说-p参数会被忽略，因为端口本来就直接暴露在宿主机上。

host模式的优势非常明显：性能好，网络栈少了一跳NAT转发；延迟低，适合对网络性能敏感的场景，比如压测工具、消息队列客户端、一些需要和宿主机共享大量UDP端口的应用。但劣势也很明显：失去了端口隔离能力，一个容器占用的端口，宿主机上就不能再作为其他用途；而且容器之间的隔离依赖进程层面的隔离，安全隐患更大。

我的建议是，常规Web应用、前后端项目，优先用自定义bridge加端口映射；只有当你明确知道"我不想经历一层NAT转发"或者"这个组件必须拿到宿主机真实IP"时才用host模式，比如某些日志采集Agent、性能监控Agent。

4. 跨主机通信实战：overlay网络与路由模式的选型逻辑

到这里，单机方案已经覆盖了大部分场景。但如果你开始管理两台以上的服务器，比如用Docker Swarm编排一个稍大规模的服务集群，容器分布在不同机器上，容器之间如何通信就成了新问题。这一节讲两种常见方案，重点是overlay网络。

4.1 为什么单机bridge解决不了跨主机通信

两台服务器A和B上分别运行了容器，即使都使用自定义bridge，它们也处于各自独立的IP段中。A上的容器知道172.28.0.2是自己网络里的MySQL，但B上也有一个172.28.0.2，两边互不感知。如果不做特殊处理，A容器就无法通过IP直接访问B容器。你看到的现象，就是"跨服务器，应用连不上"，被误以为是防火墙问题。

跨主机通信方案的核心，是在两台服务器之间建立一条"虚拟隧道"或路由规则，让不同宿主机上的容器IP段互相可达，并且保证每个容器的IP在整个集群范围内唯一。Docker官方主推的方式就是overlay网络。

4.2 overlay网络的核心原理与配置过程

overlay网络基于VXLAN技术实现。简单来说，每台参与overlay网络的宿主机上，Docker会创建一个虚拟隧道端点，也就是VTEP。容器发出的数据包先封装成VXLAN报文，通过宿主机的物理网络发送到对端宿主机；对端VTEP解封装后，把原始数据包交给目标容器。对用户来说，A容器访问B容器，就像访问同一台机器上的另一个容器一样，IP地址直接可达。

在日常使用中，你不需要手动管理VXLAN的细节，只需要在Docker Swarm环境下创建overlay网络：

docker swarm init docker network create --driver overlay --attachable cluster-network

--attachable这个参数容易被忽略，但它很关键。默认创建的overlay网络只允许Swarm服务使用，普通容器无法接入。加上--attachable之后，才可以用docker run启动的常规容器加入这个overlay网络。

然后以服务方式部署到集群中：

docker service create --name webapp --network cluster-network --replicas 2 my-webapp:latest docker service create --name db --network cluster-network mysql:8.0

Swarm会负责在两个副本之间做负载均衡，并且内置DNS会把webapp这个名字解析到某个副本的虚拟IP上。你只管通过服务名互通，不需要关心副本落在哪台宿主机。

4.3 路由模式作为备选：不带Swarm的跨主机方案

如果你没有在用Swarm，只是想简单让两台宿主机上的自定义bridge网络互相可达，也可以借助路由模式手动打通。思路是：让宿主机A和B上都配置容器网络的路由规则，同时关闭Docker的iptables改动，用系统层面的路由来转发。

这个方案不适合新手，因为你要手动维护IP分配、路由表、防火墙规则。我只提醒一点：在配置之前，先确认容器使用的子网地址段在A、B两侧都做了规划，不能重叠；然后设置宿主机的IP转发功能，sysctl -w net.ipv4.ip_forward=1写进/etc/sysctl.conf；最后分别在两台宿主机上添加路由，指向对方的容器网段。

我个人对路由模式的评价是：适用于临时打通、或者不想引入Swarm的大集群场景，但它不是Docker网络管理的主流路线，长期维护成本偏高。真正生产环境里的跨主机组网，用overlay网络会让生活轻松很多，毕竟Docker daemon已经替你处理了VXLAN封装、控制面同步、VIP负载均衡这些复杂工作。

5. 排障实录：一次"docker网络不通"的完整排查链路

我来分享一次真实的排查过程。这是一个"docker网络不通"的典型现场，很多细节都是实际工作中踩过的坑，把排查链路完整复现出来，比直接给你十条命令更有价值。

5.1 从"Redis连不上"开始的现象描述

有个任务是把Redis主从部署到两台容器中，从库起来后，主库日志一直报错：

[ERROR] Error accepting a client connection: Cannot accept a client connection, error in accept: Connection reset by peer.

从库侧则显示主库连接失败。我一开始以为是主从配置问题，重新检查了replicaof参数，发现配置内容没写错，然后再去看网络，发现主从两个容器虽然都在同一台机器上，但我启动时图省事，一个用了自定义网络，另一个忘了指定网络，直接跑在了默认bridge上。结果就是：两个容器不在同一个网络内，从库通过容器名解析不到主库。

这种"一个容器在自定义网络，另一个在默认网络"的错位，是单机多容器项目里最常见的配置失误之一。解决了这个问题后，主从库通了，但又出现了第二个现象：从宿主机访问主从Redis的映射端口没问题，外部服务器却连不上。

5.2 逐链路排查：容器内部、宿主机、安全组

我的排查顺序是这样的：

第一步，在容器内部验证。用docker exec -it redis-master redis-cli -h 127.0.0.1 -p 6379 ping，返回PONG，说明Redis进程正常，监听端口没问题。

第二步，验证宿主机映射。在宿主机上执行redis-cli -h 127.0.0.1 -p 6379 ping，同样PONG，说明iptables的DNAT规则生效，端口映射也正常。

第三步，检查云平台安全组。登录云控制台，发现6379端口没有添加到安全组放行规则里，外部访问自然被挡在了云平台这一层。这个问题和Docker本身无关，但如果你不了解整个链路，很容易以为是容器网络配置出问题，实际上"网络不通"只是表象。

这个案例给我的价值不在于"解决问题"，而在于固化了一个三层验证思路：第一层容器内，第二层宿主机，第三层外部。每层都能用一条命令快速验证，从里到外逐层排除，基本能在五分钟内定位绝大多数"网络不通"的故障点。

5.3 容器重启后IP变化引发的"玄学故障"

还有一个让我印象深刻的坑：容器重启后IP变化。某个业务服务里配了数据库IP，比如172.28.0.5，当时能连，结果宿主机重启或者容器重建后，IP变成了172.28.0.8，业务瞬间连不上。排查时发现完全不是代码问题，而是配置里用了动态IP而不是容器名。

这也解释了为什么我前面强调，在自定义bridge网络里，通信用容器名而不是IP。Docker内置DNS会在容器加入到网络时自动注册，容器重启后即使IP变了，名字依然有效。整个排查链路里，只要应用配置里出现的是容器名或服务名，这类"玄学故障"就能从根上避免。

6. Docker compose下的网络管理实践与几个高频坑

前面讲的都是docker run命令行操作，但实际项目中，越来越多的人用Docker Compose管理多容器部署。Compose在底层用的是同一套Docker网络机制，只不过在编排层面做了封装。这一节讲我常用的Compose网络实践细节。

6.1 默认网络足够了吗：Compose项目下的网络隔离

当你使用docker-compose.yml时，Compose会自动为每个项目创建一个独立的bridge网络。也就是说，只要你在项目目录下执行docker compose up -d，服务之间天然就可以通过服务名互相访问。比如这个常见的配置：

services: web: image: nginx:latest ports: - "80:80" app: image: my-webapp:latest redis: image: redis:7-alpine

Web容器和App容器、Redis容器都在同一个默认网络中，容器内通过app、redis这类服务名就能互相解析。这是Compose最方便的地方，不用手写网络配置，服务名已经替代了IP。

但如果你在同一个宿主机上跑多个Compose项目，而项目之间存在跨项目互访需求，默认隔离反而成了阻碍。我通常会显式声明外部网络：

services: app: networks: - shared-network networks: shared-network: external: true

对应地，先手动创建好shared-network，再让不同Compose项目都把这个外部网络加入进来。这样做的好处是，项目间互通范围完全可控，不会因为项目名不同而出现互访困难。

6.2 端口映射冲突：Compose deploy遇到的真实问题

多项目共用宿主机时，最常见的问题是端口映射冲突。比如A项目的web映射了宿主机的80端口，B项目的web也想映射80端口，后启动的项目会报"port is already allocated"。

这个问题的解决方案通常是：不用固定端口映射，而是设计网关。也就是说，只让最外层的Nginx网关容器映射80、443端口，后端服务全部走内部网络，不映射宿主端口。这样既能避免端口冲突，也能加强安全隔离。我在部署微服务项目时几乎都是这套路由：Nginx容器对外暴露，内部服务通过服务名互访，数据库和后端不暴露公网。

6.3 Compose环境变量与网络名的联动

还有一个小细节：Compose网络中，服务名解析依赖Docker内置DNS，但不是所有基础镜像都自带DNS工具。比如你在容器里测试连通性时，ping命令可能不存在，或者需要额外安装iputils-ping。如果直接说"网络不通"，很可能只是因为容器里没有ping这个二进制，但业务进程通过TCP连接是正常的。此时建议直接用nc -zv 服务名 端口或curl 服务名:端口来测试，比ping更可靠。

我在排障时也常用docker compose exec 服务名 sh进到容器里，再用getent hosts 服务名查看解析结果。这个命令不依赖ping工具，直接查询DNS解析，能快速判断"解析失败"还是"连接失败"。

7. Docker网络管理里那些"值得再做一次"的收尾习惯

如果你能看到这里，说明你至少已经跑通过最基础的多容器通信，也对端口映射、跨主机方案有了概念。最后的这几条，都是我在实际项目里反复使用、也确实帮我少踩坑的小习惯，算是给这篇内容收个尾。

第一，所有项目的通信地址，尽量用服务名和容器名，而不是IP。一开始会觉得IP直观，但容器重建一次就要改一次配置，长期下来代价很大。Docker网络管理的目的就是让你不要操心IP变化，你偏要把IP写进配置，那相当于主动放弃了这套机制的价值。

第二，创建自定义网络时，习惯性地给子网做一个规划。比如统一用172.28.0.0/16范围给项目A，172.29.0.0/16给项目B。ip段之间留出明显间隔，排查网络表时一眼能看出归属，效率会高很多。

第三，保持iptables规则的整洁。尽量避免手动清空Docker链。很多"网络突然不通"的案例，根源就是有人跑了一条iptables -F，把Docker动态生成的规则清掉了。如果你必须管理防火墙，请基于具体规则操作，而不是用-F这种粗暴方式。

第四，遇到网络故障时，用三层验证法：容器内、宿主机、外部。每次只验证一层，能极大缩短排查时间。别一上来就觉得是"Docker的问题"，云安全组、宿主机防火墙、容器进程监听地址，都有可能是问题源头。

Docker网络管理这套体系，看似命令不多，但背后每个细节都牵一发动全身。我梳理这些内容时，也是把自己踩过的坑重新走了一遍。希望这篇内容能帮你把网络这层基础打牢，之后无论是部署单机项目还是集群服务，都能少一些"玄学"，多一点掌控感。