Docker 用久了你会发现一个有意思的现象镜像构建、容器编排这些事看文档基本能搞定唯独网络这块一旦出问题就特别容易卡壳。容器之间 ping 不通、宿主机访问不到容器里的服务、自定义网络里 DNS 解析时灵时不灵这类问题排查起来往往要翻半天资料。这篇内容就把 Linux 环境下 Docker 网络这套东西从头捋一遍从底层原理到实操配置再到踩坑排查尽量讲透。Docker 网络本质上解决的是容器间通信、容器与宿主机通信、容器与外部网络通信这三件事。默认情况下 Docker 会帮你建好几个网络但真正在生产或者复杂本地环境里用得顺手的基本都得自己规划自定义网络。这篇适合刚接触 Docker 网络、被 bridge 和 host 搞混过的朋友也适合已经用过但没系统梳理过底层机制的同学看完你应该能自己设计一套清晰的容器网络方案。1. Docker 网络整体设计与底层逻辑拆解1.1 为什么 Docker 要自己造一套网络模型很多人第一次看docker network ls会疑惑宿主机明明已经有网卡和路由了Docker 为什么还要再叠一层答案在于隔离和可移植性。容器是进程级隔离的如果所有容器直接共享宿主机网络栈端口冲突、IP 冲突会立刻变成灾难。Docker 的做法是给每个容器配一个独立的网络命名空间network namespace让容器以为自己有一整套独立的网卡、路由表、iptables 规则实际上这些都由内核虚拟化出来。这套设计的核心价值在于容器内部看到的网络环境和宿主机解耦容器迁移、批量启动时不用关心宿主机网络细节。代价是多了一层虚拟化需要理解 veth pair、网桥、NAT 这些概念。我个人的经验是只要把每个容器是一个独立网络命名空间这句话刻在脑子里后面所有现象都能解释得通。1.2 五种默认网络驱动到底怎么选Docker 内置了几种网络驱动选错驱动是很多网络问题的根源。下面这张表是我实际使用中总结的对照建议先有个整体印象驱动类型适用场景隔离性性能开销典型用途bridge单机容器互联中低默认场景、本地开发host需要极致网络性能无极低高性能服务、监控代理none完全隔离最高无安全沙箱、离线计算overlay跨主机通信中较高集群、多机部署macvlan容器需要独立 MAC中低传统网络设备对接bridge是默认驱动容器启动不指定网络时就走它特点是容器有独立 IP通过 NAT 访问外网宿主机通过端口映射访问容器。host驱动直接复用宿主机网络栈容器没有独立 IP端口直接占用宿主机端口性能最好但隔离性最差。none就是给容器一个空网络栈除了 loopback 什么都没有适合做纯计算任务。overlay和macvlan属于进阶用法前者依赖额外的键值存储做跨主机网络后者让容器直接接入物理网络拿到同网段 IP。日常单机场景把 bridge 和自定义 bridge 玩明白就够用了overlay 那套等上了集群再说。1.3 自定义 bridge 网络为什么比默认 bridge 更值得用默认的docker0网桥有个明显短板它上面的容器只能通过 IP 互相访问没有自动 DNS 解析。也就是说容器 A 想访问容器 B得先查到 B 的 IP 再连容器重启 IP 变了就得改配置。这在多容器协作场景里非常难受。自定义 bridge 网络解决了这个问题。用docker network create建的网络接入的容器可以通过容器名直接解析Docker 内置了一个 DNS 服务专门处理这件事。我现在的习惯是只要项目里有两个以上容器需要互相通信一律先建一个自定义网络把所有容器挂上去用名字通信彻底告别硬编码 IP。这个习惯帮我省掉了大量容器重启后连不上的排查时间。2. 核心网络机制与关键细节解析2.1 veth pair 与网桥容器网络的物理骨架理解 Docker 网络绕不开 veth pair 这个东西。veth 是虚拟以太网设备永远成对出现一端在容器命名空间里通常叫 eth0另一端插在宿主机的网桥上。你可以把它想象成一根虚拟网线两头各插一个设备从一头进去的包会从另一头出来。容器启动时Docker 会做这么几件事创建网络命名空间、创建一对 veth、把一端放进容器改名 eth0、把另一端接到docker0或自定义网桥上、给容器 eth0 分配 IP、配置默认路由指向网桥。这一套下来容器就以为自己有一张真实网卡了。网桥本身是个二层设备负责在同一网段内转发。docker0默认网段是172.17.0.0/16自定义网络默认从172.18.0.0/16开始往后排。这里有个实操要点如果你宿主机所在的内网恰好也用 172.17 网段就会和 Docker 默认网段冲突表现为容器能起但网络不通。解决办法是在 daemon 配置里改bip参数或者干脆全用自定义网络并显式指定 subnet。2.2 端口映射背后的 iptables 转发链路docker run -p 8080:80这条命令看起来简单背后其实是一串 iptables 规则在干活。当你做端口映射时Docker 会在宿主机上添加 DNAT 规则把发往宿主机 8080 端口的流量改写到容器 IP 的 80 端口。同时还会加一条 MASQUERADE 规则让容器出网的流量做源地址转换。这条链路值得拆开看外部请求到达宿主机 8080 → PREROUTING 链命中 DNAT 规则 → 目标地址改成容器 IP:80 → 转发到 docker0 网桥 → 到达容器。容器回包时源地址是容器 IP需要经过 POSTROUTING 的 MASQUERADE 把源地址改回宿主机地址外部才认得出这个回包。排查端口映射问题时iptables -t nat -L -n能看到这些规则。我遇到过一种情况容器里服务明明在监听宿主机就是连不上最后发现是宿主机防火墙的 FORWARD 链默认策略是 DROP把转发流量拦了。所以记住一句话端口映射依赖内核转发转发链被拦了映射就失效。2.3 容器 DNS 解析的工作机制自定义网络里的容器名解析靠的是 Docker 内置的 DNS 服务监听在127.0.0.11:53。容器内的/etc/resolv.conf会被指向这个地址所有 DNS 查询先到这里Docker 再根据网络内的容器名映射表返回结果查不到才转发给上游 DNS。这里有几个细节容易踩坑。第一只有自定义网络才有这个 DNS 服务默认 bridge 网络没有所以默认网络下容器名解析不了。第二容器名解析依赖容器加入网络时的别名用--network-alias可以额外加别名做服务发现时很有用。第三如果容器自己改了/etc/resolv.conf或者用了--dns参数可能会覆盖掉 Docker 的 DNS 配置导致名字解析失效。我一般建议除非有特殊需求别动容器的 DNS 配置让 Docker 自己管。2.4 网络隔离与连通性控制Docker 网络天然带隔离不同 bridge 网络之间默认不通除非做路由或者让容器同时接入多个网络。这个特性在做环境隔离时特别好用比如把前端容器放一个网络、后端放另一个网络中间用一个网关容器桥接天然形成分层。--internal参数可以建一个完全隔离的内网容器之间能通但出不了外网适合放数据库这类不该暴露的服务。另外docker network connect可以让一个运行中的容器动态接入新网络不用重启这个在做临时调试或者灰度切换时很实用。我试过用这个特性给某个容器临时挂一个调试网络排查完再 disconnect全程不影响业务容器。3. 实操过程与核心环节落地3.1 从零搭建一套自定义网络环境先看最基础的一套操作。假设要跑一个 web 服务加一个数据库两者需要互相通信web 还要对外暴露端口。第一步建网络docker network create --driver bridge \ --subnet 172.20.0.0/16 \ --gateway 172.20.0.1 \ myapp-net这里显式指定 subnet 是有意为之。不指定的话 Docker 会自动分配但自动分配可能和你宿主机内网撞车显式指定能规避这个风险。选172.20.0.0/16是因为它离常见的家用网段192.168.x和企业内网10.x都比较远冲突概率低。建好之后启动容器docker run -d --name db --network myapp-net \ -e MYSQL_ROOT_PASSWORDexample \ mysql:8.0 docker run -d --name web --network myapp-net \ -p 8080:80 myapp-web:latest注意 web 容器连接数据库时主机名直接写db就行Docker DNS 会解析到 db 容器的 IP。这就是自定义网络最大的便利。验证一下docker exec web ping -c 2 db docker exec web getent hosts db如果 ping 得通、getent 能解析出 IP说明网络和 DNS 都正常。这一步是后续所有配置的基础务必先确认。3.2 端口映射的参数选择与验证方法端口映射的写法有几种选哪种取决于你的需求。-p 8080:80是把宿主机 8080 映射到容器 80绑定所有网卡。-p 127.0.0.1:8080:80只绑定本地回环外部访问不到适合只给本机调试用的服务。-p 8080:80/udp指定 UDP 协议。参数选择上有个经验生产环境尽量绑定具体网卡 IP 而不是 0.0.0.0避免服务意外暴露到不该暴露的网段。另外端口范围映射-p 8000-8010:8000-8010在批量场景下能省不少事但要注意宿主机端口别和已有服务冲突。验证映射是否生效别只看docker ps里的 PORTS 列那个只说明规则加了不代表通。实际验证要分两步先在宿主机上curl 127.0.0.1:8080确认本地通再从另一台机器访问宿主机 IP 确认外部通。两步都过才算真的没问题。我踩过一次坑本地 curl 通但外部不通最后查出来是云主机安全组没放行和 Docker 本身没关系。3.3 多网络接入与容器间通信实战复杂一点的场景一个容器需要同时接入多个网络。比如一个网关容器一面接前端网络一面接后端网络做流量中转。操作上先建两个网络docker network create frontend-net docker network create backend-net启动网关容器时先接一个再动态接另一个docker run -d --name gateway --network frontend-net gateway:latest docker network connect backend-net gateway接上之后gateway 容器里会有两块网卡分别对应两个网络的 IP。它就能同时和前端、后端容器通信了。用docker exec gateway ip addr能看到两个 eth 接口用docker network inspect能确认容器在两个网络里的 IP。这种多网络接入的模式在做服务分层时很清晰前端网络里的容器看不到后端网络只有网关能跨。安全边界天然形成比靠应用层鉴权来得更彻底。不过要注意多网络接入后容器的默认路由只会指向其中一个网络出网流量走哪个网关需要留意必要时手动调路由。3.4 用 host 网络跑高性能服务的配置要点有些服务对网络性能敏感比如高频采集的监控代理、需要处理大量连接的代理服务这时候 bridge 的 NAT 开销就成了瓶颈。切到 host 网络能省掉这层转换docker run -d --name agent --network host agent:latesthost 网络下容器没有独立 IP直接复用宿主机网络栈容器里监听 9090 就是宿主机监听 9090不需要端口映射。性能提升是实打实的但代价是端口冲突风险陡增两个 host 网络容器不能监听同一端口。用 host 网络有个前提容器里的服务要能接受端口不可配置或者配置成宿主机端口。有些镜像默认监听固定端口切 host 网络后如果宿主机该端口被占容器直接起不来。所以切之前先用ss -tlnp查一下宿主机端口占用情况。我一般只在明确需要性能、且端口可控的场景才用 host普通业务还是 bridge 更省心。4. 常见网络故障排查与避坑实录4.1 容器间 ping 不通的分层排查法容器间不通是最常见的问题排查要分层来别一上来就瞎试。我的排查顺序是这样的排查层级检查命令判断依据网络归属docker inspect 容器名两容器是否在同一网络IP 连通docker exec A ping B的IP排除 DNS 因素DNS 解析docker exec A getent hosts B名字能否解析端口监听docker exec B ss -tlnp服务是否真在监听防火墙iptables -L FORWARD -n转发链是否放行先确认两个容器在不在同一个网络这是最容易被忽略的。不在同一网络除非有路由否则永远不通。确认同网络后先用 IP ping通了说明是 DNS 问题不通说明是链路问题。链路问题再往下查网桥、veth、iptables。我遇到过一个典型案例两个容器都在自定义网络里IP 能 ping 通但用容器名解析失败。最后发现是其中一个容器启动时用了--dns参数覆盖了 DNS 配置把 Docker 内置的127.0.0.11冲掉了。去掉那个参数就好了。所以再次强调别轻易动容器的 DNS 配置。4.2 宿主机访问不到容器服务的几种原因宿主机访问容器服务失败原因通常集中在几个点。第一是端口映射没做或者写错了docker port 容器名能确认映射关系。第二是容器内服务只监听了127.0.0.1而不是0.0.0.0这种情况下即使映射了端口外部也访问不到因为服务根本没在容器网卡上监听。这个坑特别隐蔽容器内curl 127.0.0.1通宿主机就是不通查半天才发现是监听地址问题。第三是宿主机防火墙拦了转发前面提过 FORWARD 链默认 DROP 的情况。第四是云环境的安全组或网络 ACL 没放行。排查时按容器内监听 → 端口映射规则 → 宿主机转发 → 外部网络策略这个顺序走一层层排除基本不会漏。4.3 网段冲突导致网络异常的识别与处理网段冲突的表现很迷惑容器能启动docker network inspect看着也正常但容器就是上不了网或者连不上某些地址。根源是 Docker 分配的网段和宿主机实际所在网段重叠了路由表分不清该走哪。识别方法先ip route看宿主机路由再docker network inspect看各网络 subnet对比有没有重叠。如果宿主机内网是172.17.x.x而docker0默认也是172.17.0.0/16那就是冲突了。处理方式有两种改 Docker 默认网段在/etc/docker/daemon.json里加bip: 172.31.0.1/24然后重启 Docker或者干脆不用默认网络全走自定义网络并显式指定不冲突的 subnet。改 daemon 配置重启 Docker 会重启所有容器生产环境要挑时间窗口。所以更好的做法是从一开始就规划好网段把 Docker 用的网段和宿主机内网错开比如统一用172.20到172.30这一段避开常见的172.17和10.x。4.4 网络清理与残留资源处理Docker 网络用久了会积累一堆没用的自定义网络尤其是频繁创建删除容器的环境。docker network prune能清理没有被任何容器使用的网络加-f跳过确认。但要注意正在运行容器接入的网络不会被清理这是安全的。有时候删网络会报network has active endpoints说明还有容器连着哪怕容器已经停了。这时候先docker network disconnect断开或者直接删掉那个停止的容器。我习惯在项目收尾时跑一遍docker network ls加docker network prune保持环境干净避免下次建网络时网段被占。还有一个隐蔽的残留容器删了但 veth 设备没清理干净表现为宿主机上有一堆vethxxxx接口。正常情况下 Docker 会清理异常退出时可能残留。用ip link能看到确认没有对应容器后可以手动ip link delete删掉。不过这种情况现在很少见了新版 Docker 的清理机制比较可靠。5. 网络方案选型与生产环境规划建议5.1 单机多容器项目的网络规划模板单机上跑一个多容器项目我一般按这个模板规划建一个项目专属的自定义 bridge 网络所有业务容器接入用容器名通信需要对外暴露的容器做端口映射且只映射必要的端口数据库、缓存这类不该暴露的服务不映射端口只在内网通信如果项目分前后端可以再拆一个网络做隔离用网关容器桥接。这个模板的好处是边界清晰、排查简单。所有容器在一个网络里DNS 解析统一由 Docker 管不用维护额外的服务发现。项目结束后整个网络连同容器一起清理不留残留。对于绝大多数单机场景这套方案足够用没必要上 overlay 那套复杂的东西。5.2 什么时候该考虑 overlay 或 macvlanoverlay 和 macvlan 属于有明确触发条件才用的方案。overlay 的触发条件是跨主机通信单机永远用不上。上了多机集群容器需要跨主机互相访问才需要 overlay 配合键值存储做网络。macvlan 的触发条件是容器需要接入物理网络、拿到和宿主机同网段的 IP典型场景是对接传统网络设备、或者需要容器在二层网络上可见。这两个方案都有额外复杂度overlay 要维护键值存储网络故障排查链路更长macvlan 需要物理网卡支持混杂模式且容器 IP 要和物理网络统一规划。我的建议是除非业务明确要求否则优先用 bridge 加端口映射解决简单可靠。真到了必须用的时候再单独研究别为了用而用。5.3 网络配置的版本化管理思路网络配置散落在各种docker run命令里时间一长就没人记得清当初为什么这么配。我的做法是把网络定义写进 compose 文件用声明式的方式管理。compose 里可以显式定义网络、subnet、别名容器接入哪个网络一目了然改配置也有版本记录可查。即使不用 compose我也会把建网络和起容器的命令整理成一个脚本放进项目仓库注释写清楚每个网络的用途和网段选择理由。这样换台机器或者换个人接手照着脚本跑一遍就能复现环境不用靠记忆。网络这东西配置对了平时没存在感一旦出问题就是大问题前期多花十分钟做记录后期能省几小时排查。6. 几个容易被忽略的实操细节6.1 容器内查看网络状态的正确姿势排查网络问题时容器里往往没装ping、curl、ss这些工具尤其是精简镜像。这时候别急着往镜像里装工具可以用nsenter从宿主机进入容器的网络命名空间用宿主机的工具排查PID$(docker inspect -f {{.State.Pid}} 容器名) nsenter -t $PID -n ip addr nsenter -t $PID -n ss -tlnp这样不用改镜像就能看到容器内的网卡、路由、监听端口排查效率高很多。这个技巧我在排查精简镜像的网络问题时用得最多强烈建议记住。6.2 网络别名在服务发现中的妙用--network-alias可以给容器在某个网络里加额外别名多个容器可以用同一个别名DNS 查询时会轮询返回。这个特性在做简单的负载均衡时很好用起三个后端容器都加别名backend前端容器连backend就能自动轮询到三个实例不需要额外的负载均衡器。不过要注意这种轮询是 DNS 层面的没有健康检查某个后端挂了 DNS 还是会返回它的 IP。所以它适合做简单的流量分摊不适合对可用性要求极高的场景。真要做高可用还是得上正经的负载均衡方案。6.3 修改网络配置后的生效验证清单改完网络配置别急着收工按清单验证一遍容器间用名字能解析、用 IP 能 ping 通、宿主机端口映射本地能访问、外部网络能访问、容器能正常出网。这五项都过才算配置真正生效。我见过太多次改完看着没问题上线才发现某个方向不通的情况。网络是双向的入向通了不代表出向通容器间通了不代表宿主机通。养成按清单逐项验证的习惯能避免大部分上线后的意外。7. 个人实操体会Docker 网络这块我最大的体会是大部分问题都源于对隔离和连通这两个概念的模糊。容器有独立网络命名空间所以默认隔离要连通就得显式建网络、接网络、做映射。把这条主线抓住遇到问题先问这两个东西在不在同一个网络里、有没有路由、有没有被拦排查方向就不会跑偏。另一个体会是网段规划要趁早。我早期图省事全用默认网络后来宿主机内网一调整就撞车改起来牵一发动全身。现在不管项目大小第一步先把网段规划好自定义网络显式指定 subnet后面省心太多。网络配置这种基础设施前期多花点心思规划比后期救火划算得多。
Docker 用久了你会发现一个有意思的现象镜像构建、容器编排这些事看文档基本能搞定唯独网络这块一旦出问题就特别容易卡壳。容器之间 ping 不通、宿主机访问不到容器里的服务、自定义网络里 DNS 解析时灵时不灵这类问题排查起来往往要翻半天资料。这篇内容就把 Linux 环境下 Docker 网络这套东西从头捋一遍从底层原理到实操配置再到踩坑排查尽量讲透。Docker 网络本质上解决的是容器间通信、容器与宿主机通信、容器与外部网络通信这三件事。默认情况下 Docker 会帮你建好几个网络但真正在生产或者复杂本地环境里用得顺手的基本都得自己规划自定义网络。这篇适合刚接触 Docker 网络、被 bridge 和 host 搞混过的朋友也适合已经用过但没系统梳理过底层机制的同学看完你应该能自己设计一套清晰的容器网络方案。1. Docker 网络整体设计与底层逻辑拆解1.1 为什么 Docker 要自己造一套网络模型很多人第一次看docker network ls会疑惑宿主机明明已经有网卡和路由了Docker 为什么还要再叠一层答案在于隔离和可移植性。容器是进程级隔离的如果所有容器直接共享宿主机网络栈端口冲突、IP 冲突会立刻变成灾难。Docker 的做法是给每个容器配一个独立的网络命名空间network namespace让容器以为自己有一整套独立的网卡、路由表、iptables 规则实际上这些都由内核虚拟化出来。这套设计的核心价值在于容器内部看到的网络环境和宿主机解耦容器迁移、批量启动时不用关心宿主机网络细节。代价是多了一层虚拟化需要理解 veth pair、网桥、NAT 这些概念。我个人的经验是只要把每个容器是一个独立网络命名空间这句话刻在脑子里后面所有现象都能解释得通。1.2 五种默认网络驱动到底怎么选Docker 内置了几种网络驱动选错驱动是很多网络问题的根源。下面这张表是我实际使用中总结的对照建议先有个整体印象驱动类型适用场景隔离性性能开销典型用途bridge单机容器互联中低默认场景、本地开发host需要极致网络性能无极低高性能服务、监控代理none完全隔离最高无安全沙箱、离线计算overlay跨主机通信中较高集群、多机部署macvlan容器需要独立 MAC中低传统网络设备对接bridge是默认驱动容器启动不指定网络时就走它特点是容器有独立 IP通过 NAT 访问外网宿主机通过端口映射访问容器。host驱动直接复用宿主机网络栈容器没有独立 IP端口直接占用宿主机端口性能最好但隔离性最差。none就是给容器一个空网络栈除了 loopback 什么都没有适合做纯计算任务。overlay和macvlan属于进阶用法前者依赖额外的键值存储做跨主机网络后者让容器直接接入物理网络拿到同网段 IP。日常单机场景把 bridge 和自定义 bridge 玩明白就够用了overlay 那套等上了集群再说。1.3 自定义 bridge 网络为什么比默认 bridge 更值得用默认的docker0网桥有个明显短板它上面的容器只能通过 IP 互相访问没有自动 DNS 解析。也就是说容器 A 想访问容器 B得先查到 B 的 IP 再连容器重启 IP 变了就得改配置。这在多容器协作场景里非常难受。自定义 bridge 网络解决了这个问题。用docker network create建的网络接入的容器可以通过容器名直接解析Docker 内置了一个 DNS 服务专门处理这件事。我现在的习惯是只要项目里有两个以上容器需要互相通信一律先建一个自定义网络把所有容器挂上去用名字通信彻底告别硬编码 IP。这个习惯帮我省掉了大量容器重启后连不上的排查时间。2. 核心网络机制与关键细节解析2.1 veth pair 与网桥容器网络的物理骨架理解 Docker 网络绕不开 veth pair 这个东西。veth 是虚拟以太网设备永远成对出现一端在容器命名空间里通常叫 eth0另一端插在宿主机的网桥上。你可以把它想象成一根虚拟网线两头各插一个设备从一头进去的包会从另一头出来。容器启动时Docker 会做这么几件事创建网络命名空间、创建一对 veth、把一端放进容器改名 eth0、把另一端接到docker0或自定义网桥上、给容器 eth0 分配 IP、配置默认路由指向网桥。这一套下来容器就以为自己有一张真实网卡了。网桥本身是个二层设备负责在同一网段内转发。docker0默认网段是172.17.0.0/16自定义网络默认从172.18.0.0/16开始往后排。这里有个实操要点如果你宿主机所在的内网恰好也用 172.17 网段就会和 Docker 默认网段冲突表现为容器能起但网络不通。解决办法是在 daemon 配置里改bip参数或者干脆全用自定义网络并显式指定 subnet。2.2 端口映射背后的 iptables 转发链路docker run -p 8080:80这条命令看起来简单背后其实是一串 iptables 规则在干活。当你做端口映射时Docker 会在宿主机上添加 DNAT 规则把发往宿主机 8080 端口的流量改写到容器 IP 的 80 端口。同时还会加一条 MASQUERADE 规则让容器出网的流量做源地址转换。这条链路值得拆开看外部请求到达宿主机 8080 → PREROUTING 链命中 DNAT 规则 → 目标地址改成容器 IP:80 → 转发到 docker0 网桥 → 到达容器。容器回包时源地址是容器 IP需要经过 POSTROUTING 的 MASQUERADE 把源地址改回宿主机地址外部才认得出这个回包。排查端口映射问题时iptables -t nat -L -n能看到这些规则。我遇到过一种情况容器里服务明明在监听宿主机就是连不上最后发现是宿主机防火墙的 FORWARD 链默认策略是 DROP把转发流量拦了。所以记住一句话端口映射依赖内核转发转发链被拦了映射就失效。2.3 容器 DNS 解析的工作机制自定义网络里的容器名解析靠的是 Docker 内置的 DNS 服务监听在127.0.0.11:53。容器内的/etc/resolv.conf会被指向这个地址所有 DNS 查询先到这里Docker 再根据网络内的容器名映射表返回结果查不到才转发给上游 DNS。这里有几个细节容易踩坑。第一只有自定义网络才有这个 DNS 服务默认 bridge 网络没有所以默认网络下容器名解析不了。第二容器名解析依赖容器加入网络时的别名用--network-alias可以额外加别名做服务发现时很有用。第三如果容器自己改了/etc/resolv.conf或者用了--dns参数可能会覆盖掉 Docker 的 DNS 配置导致名字解析失效。我一般建议除非有特殊需求别动容器的 DNS 配置让 Docker 自己管。2.4 网络隔离与连通性控制Docker 网络天然带隔离不同 bridge 网络之间默认不通除非做路由或者让容器同时接入多个网络。这个特性在做环境隔离时特别好用比如把前端容器放一个网络、后端放另一个网络中间用一个网关容器桥接天然形成分层。--internal参数可以建一个完全隔离的内网容器之间能通但出不了外网适合放数据库这类不该暴露的服务。另外docker network connect可以让一个运行中的容器动态接入新网络不用重启这个在做临时调试或者灰度切换时很实用。我试过用这个特性给某个容器临时挂一个调试网络排查完再 disconnect全程不影响业务容器。3. 实操过程与核心环节落地3.1 从零搭建一套自定义网络环境先看最基础的一套操作。假设要跑一个 web 服务加一个数据库两者需要互相通信web 还要对外暴露端口。第一步建网络docker network create --driver bridge \ --subnet 172.20.0.0/16 \ --gateway 172.20.0.1 \ myapp-net这里显式指定 subnet 是有意为之。不指定的话 Docker 会自动分配但自动分配可能和你宿主机内网撞车显式指定能规避这个风险。选172.20.0.0/16是因为它离常见的家用网段192.168.x和企业内网10.x都比较远冲突概率低。建好之后启动容器docker run -d --name db --network myapp-net \ -e MYSQL_ROOT_PASSWORDexample \ mysql:8.0 docker run -d --name web --network myapp-net \ -p 8080:80 myapp-web:latest注意 web 容器连接数据库时主机名直接写db就行Docker DNS 会解析到 db 容器的 IP。这就是自定义网络最大的便利。验证一下docker exec web ping -c 2 db docker exec web getent hosts db如果 ping 得通、getent 能解析出 IP说明网络和 DNS 都正常。这一步是后续所有配置的基础务必先确认。3.2 端口映射的参数选择与验证方法端口映射的写法有几种选哪种取决于你的需求。-p 8080:80是把宿主机 8080 映射到容器 80绑定所有网卡。-p 127.0.0.1:8080:80只绑定本地回环外部访问不到适合只给本机调试用的服务。-p 8080:80/udp指定 UDP 协议。参数选择上有个经验生产环境尽量绑定具体网卡 IP 而不是 0.0.0.0避免服务意外暴露到不该暴露的网段。另外端口范围映射-p 8000-8010:8000-8010在批量场景下能省不少事但要注意宿主机端口别和已有服务冲突。验证映射是否生效别只看docker ps里的 PORTS 列那个只说明规则加了不代表通。实际验证要分两步先在宿主机上curl 127.0.0.1:8080确认本地通再从另一台机器访问宿主机 IP 确认外部通。两步都过才算真的没问题。我踩过一次坑本地 curl 通但外部不通最后查出来是云主机安全组没放行和 Docker 本身没关系。3.3 多网络接入与容器间通信实战复杂一点的场景一个容器需要同时接入多个网络。比如一个网关容器一面接前端网络一面接后端网络做流量中转。操作上先建两个网络docker network create frontend-net docker network create backend-net启动网关容器时先接一个再动态接另一个docker run -d --name gateway --network frontend-net gateway:latest docker network connect backend-net gateway接上之后gateway 容器里会有两块网卡分别对应两个网络的 IP。它就能同时和前端、后端容器通信了。用docker exec gateway ip addr能看到两个 eth 接口用docker network inspect能确认容器在两个网络里的 IP。这种多网络接入的模式在做服务分层时很清晰前端网络里的容器看不到后端网络只有网关能跨。安全边界天然形成比靠应用层鉴权来得更彻底。不过要注意多网络接入后容器的默认路由只会指向其中一个网络出网流量走哪个网关需要留意必要时手动调路由。3.4 用 host 网络跑高性能服务的配置要点有些服务对网络性能敏感比如高频采集的监控代理、需要处理大量连接的代理服务这时候 bridge 的 NAT 开销就成了瓶颈。切到 host 网络能省掉这层转换docker run -d --name agent --network host agent:latesthost 网络下容器没有独立 IP直接复用宿主机网络栈容器里监听 9090 就是宿主机监听 9090不需要端口映射。性能提升是实打实的但代价是端口冲突风险陡增两个 host 网络容器不能监听同一端口。用 host 网络有个前提容器里的服务要能接受端口不可配置或者配置成宿主机端口。有些镜像默认监听固定端口切 host 网络后如果宿主机该端口被占容器直接起不来。所以切之前先用ss -tlnp查一下宿主机端口占用情况。我一般只在明确需要性能、且端口可控的场景才用 host普通业务还是 bridge 更省心。4. 常见网络故障排查与避坑实录4.1 容器间 ping 不通的分层排查法容器间不通是最常见的问题排查要分层来别一上来就瞎试。我的排查顺序是这样的排查层级检查命令判断依据网络归属docker inspect 容器名两容器是否在同一网络IP 连通docker exec A ping B的IP排除 DNS 因素DNS 解析docker exec A getent hosts B名字能否解析端口监听docker exec B ss -tlnp服务是否真在监听防火墙iptables -L FORWARD -n转发链是否放行先确认两个容器在不在同一个网络这是最容易被忽略的。不在同一网络除非有路由否则永远不通。确认同网络后先用 IP ping通了说明是 DNS 问题不通说明是链路问题。链路问题再往下查网桥、veth、iptables。我遇到过一个典型案例两个容器都在自定义网络里IP 能 ping 通但用容器名解析失败。最后发现是其中一个容器启动时用了--dns参数覆盖了 DNS 配置把 Docker 内置的127.0.0.11冲掉了。去掉那个参数就好了。所以再次强调别轻易动容器的 DNS 配置。4.2 宿主机访问不到容器服务的几种原因宿主机访问容器服务失败原因通常集中在几个点。第一是端口映射没做或者写错了docker port 容器名能确认映射关系。第二是容器内服务只监听了127.0.0.1而不是0.0.0.0这种情况下即使映射了端口外部也访问不到因为服务根本没在容器网卡上监听。这个坑特别隐蔽容器内curl 127.0.0.1通宿主机就是不通查半天才发现是监听地址问题。第三是宿主机防火墙拦了转发前面提过 FORWARD 链默认 DROP 的情况。第四是云环境的安全组或网络 ACL 没放行。排查时按容器内监听 → 端口映射规则 → 宿主机转发 → 外部网络策略这个顺序走一层层排除基本不会漏。4.3 网段冲突导致网络异常的识别与处理网段冲突的表现很迷惑容器能启动docker network inspect看着也正常但容器就是上不了网或者连不上某些地址。根源是 Docker 分配的网段和宿主机实际所在网段重叠了路由表分不清该走哪。识别方法先ip route看宿主机路由再docker network inspect看各网络 subnet对比有没有重叠。如果宿主机内网是172.17.x.x而docker0默认也是172.17.0.0/16那就是冲突了。处理方式有两种改 Docker 默认网段在/etc/docker/daemon.json里加bip: 172.31.0.1/24然后重启 Docker或者干脆不用默认网络全走自定义网络并显式指定不冲突的 subnet。改 daemon 配置重启 Docker 会重启所有容器生产环境要挑时间窗口。所以更好的做法是从一开始就规划好网段把 Docker 用的网段和宿主机内网错开比如统一用172.20到172.30这一段避开常见的172.17和10.x。4.4 网络清理与残留资源处理Docker 网络用久了会积累一堆没用的自定义网络尤其是频繁创建删除容器的环境。docker network prune能清理没有被任何容器使用的网络加-f跳过确认。但要注意正在运行容器接入的网络不会被清理这是安全的。有时候删网络会报network has active endpoints说明还有容器连着哪怕容器已经停了。这时候先docker network disconnect断开或者直接删掉那个停止的容器。我习惯在项目收尾时跑一遍docker network ls加docker network prune保持环境干净避免下次建网络时网段被占。还有一个隐蔽的残留容器删了但 veth 设备没清理干净表现为宿主机上有一堆vethxxxx接口。正常情况下 Docker 会清理异常退出时可能残留。用ip link能看到确认没有对应容器后可以手动ip link delete删掉。不过这种情况现在很少见了新版 Docker 的清理机制比较可靠。5. 网络方案选型与生产环境规划建议5.1 单机多容器项目的网络规划模板单机上跑一个多容器项目我一般按这个模板规划建一个项目专属的自定义 bridge 网络所有业务容器接入用容器名通信需要对外暴露的容器做端口映射且只映射必要的端口数据库、缓存这类不该暴露的服务不映射端口只在内网通信如果项目分前后端可以再拆一个网络做隔离用网关容器桥接。这个模板的好处是边界清晰、排查简单。所有容器在一个网络里DNS 解析统一由 Docker 管不用维护额外的服务发现。项目结束后整个网络连同容器一起清理不留残留。对于绝大多数单机场景这套方案足够用没必要上 overlay 那套复杂的东西。5.2 什么时候该考虑 overlay 或 macvlanoverlay 和 macvlan 属于有明确触发条件才用的方案。overlay 的触发条件是跨主机通信单机永远用不上。上了多机集群容器需要跨主机互相访问才需要 overlay 配合键值存储做网络。macvlan 的触发条件是容器需要接入物理网络、拿到和宿主机同网段的 IP典型场景是对接传统网络设备、或者需要容器在二层网络上可见。这两个方案都有额外复杂度overlay 要维护键值存储网络故障排查链路更长macvlan 需要物理网卡支持混杂模式且容器 IP 要和物理网络统一规划。我的建议是除非业务明确要求否则优先用 bridge 加端口映射解决简单可靠。真到了必须用的时候再单独研究别为了用而用。5.3 网络配置的版本化管理思路网络配置散落在各种docker run命令里时间一长就没人记得清当初为什么这么配。我的做法是把网络定义写进 compose 文件用声明式的方式管理。compose 里可以显式定义网络、subnet、别名容器接入哪个网络一目了然改配置也有版本记录可查。即使不用 compose我也会把建网络和起容器的命令整理成一个脚本放进项目仓库注释写清楚每个网络的用途和网段选择理由。这样换台机器或者换个人接手照着脚本跑一遍就能复现环境不用靠记忆。网络这东西配置对了平时没存在感一旦出问题就是大问题前期多花十分钟做记录后期能省几小时排查。6. 几个容易被忽略的实操细节6.1 容器内查看网络状态的正确姿势排查网络问题时容器里往往没装ping、curl、ss这些工具尤其是精简镜像。这时候别急着往镜像里装工具可以用nsenter从宿主机进入容器的网络命名空间用宿主机的工具排查PID$(docker inspect -f {{.State.Pid}} 容器名) nsenter -t $PID -n ip addr nsenter -t $PID -n ss -tlnp这样不用改镜像就能看到容器内的网卡、路由、监听端口排查效率高很多。这个技巧我在排查精简镜像的网络问题时用得最多强烈建议记住。6.2 网络别名在服务发现中的妙用--network-alias可以给容器在某个网络里加额外别名多个容器可以用同一个别名DNS 查询时会轮询返回。这个特性在做简单的负载均衡时很好用起三个后端容器都加别名backend前端容器连backend就能自动轮询到三个实例不需要额外的负载均衡器。不过要注意这种轮询是 DNS 层面的没有健康检查某个后端挂了 DNS 还是会返回它的 IP。所以它适合做简单的流量分摊不适合对可用性要求极高的场景。真要做高可用还是得上正经的负载均衡方案。6.3 修改网络配置后的生效验证清单改完网络配置别急着收工按清单验证一遍容器间用名字能解析、用 IP 能 ping 通、宿主机端口映射本地能访问、外部网络能访问、容器能正常出网。这五项都过才算配置真正生效。我见过太多次改完看着没问题上线才发现某个方向不通的情况。网络是双向的入向通了不代表出向通容器间通了不代表宿主机通。养成按清单逐项验证的习惯能避免大部分上线后的意外。7. 个人实操体会Docker 网络这块我最大的体会是大部分问题都源于对隔离和连通这两个概念的模糊。容器有独立网络命名空间所以默认隔离要连通就得显式建网络、接网络、做映射。把这条主线抓住遇到问题先问这两个东西在不在同一个网络里、有没有路由、有没有被拦排查方向就不会跑偏。另一个体会是网段规划要趁早。我早期图省事全用默认网络后来宿主机内网一调整就撞车改起来牵一发动全身。现在不管项目大小第一步先把网段规划好自定义网络显式指定 subnet后面省心太多。网络配置这种基础设施前期多花点心思规划比后期救火划算得多。
