Docker bridge 网络是多数开发者第一次接触容器网络时遇到的默认模型。它看起来只是让容器拥有一个 IP，但背后实际包含 Linux 网络命名空间、veth 虚拟网卡对、Linux bridge、iptables 或 nftables NAT 规则，以及 Docker 内置 DNS。理解这些组件，才能在“容器能访问外网但外部访问不了容器”“两个容器 IP 能通但服务名不通”等问题中快速定位原因。
如果你正在系统学习容器网络，可把本文与容器网络、Docker容器探索结合阅读，先掌握单机 bridge，再理解 Kubernetes 的跨节点网络。
bridge 网络由哪些组件组成
Docker 启动后通常会创建一个默认网桥 docker0。每启动一个接入 bridge 网络的容器，Docker 会创建一对 veth 设备：一端放进容器网络命名空间，表现为容器里的 eth0；另一端留在宿主机，并连接到 docker0 或自定义 bridge。容器发送数据包时，数据从 eth0 出来，经 veth 到宿主机网桥，再根据目标地址转发。
docker network ls
docker network inspect bridge
ip link show type bridge默认 bridge 能满足简单实验，但生产或多服务开发更建议创建自定义 bridge 网络。原因是自定义网络提供内置 DNS 服务名解析、隔离边界更清晰，也便于按项目拆分通信域。
docker network create app-net
docker run -d --name api --network app-net my-api:latest
docker run -d --name redis --network app-net redis:7容器到容器通信：同网桥内直接转发
在同一个自定义 bridge 网络中，容器之间可以通过容器名访问。比如 api 访问 redis 时，Docker 内置 DNS 会把 redis 解析为对应容器 IP，数据包随后通过 veth 和 bridge 在宿主机内完成二层转发。这个路径不需要经过宿主机端口映射，也不需要把 Redis 暴露给外部。
需要注意的是，容器名解析通常只在自定义 bridge 网络中表现更稳定。默认 bridge 下历史行为和配置差异较多，不应把它作为复杂多服务应用的长期方案。使用 Compose 时，每个项目默认会创建独立网络，服务名会自动成为 DNS 名称，这也是本地开发环境中“用服务名访问数据库”的基础。
容器访问外部网络：源地址转换
当容器访问互联网或宿主机外部网络时，容器私有 IP 通常无法被上游网络直接识别。Docker 会在宿主机上配置 NAT，让容器流量以宿主机地址发出。返回包再由连接跟踪规则送回对应容器。
这个机制解释了一个常见现象：容器里 curl 外部站点能成功，但外部机器不能直接访问容器 IP。容器 IP 属于宿主机内部网络，外部网络没有到该网段的路由。若希望外部访问容器，应使用端口映射、反向代理或上层编排平台提供的 Service/Ingress。
外部访问容器：端口映射改变入口
bridge 模式默认不会把容器端口暴露到宿主机。只有执行 -p 后，Docker 才会把宿主机端口与容器端口建立映射。例如：
docker run -d --name web --network app-net -p 8080:80 nginx
curl http://127.0.0.1:8080此时客户端访问宿主机 8080，流量会被转发到容器的 80。排障时不要只看容器内应用是否监听 80，还要确认宿主机端口是否映射、是否被其他进程占用、防火墙是否允许访问。
常见问题与定位方法
| 现象 | 可能原因 | 检查命令 |
|---|---|---|
| — | — | — |
| 容器名无法解析 | 不在同一自定义 bridge 网络 | docker network inspect app-net |
| IP 能通但端口不通 | 应用未监听目标端口或监听 127.0.0.1 | docker exec app ss -lntp |
| 外部访问失败 | 未发布端口或宿主机防火墙阻断 | docker ps、docker port |
| 容器无法访问外网 | NAT、DNS 或宿主机出口异常 | docker exec app ip route |
一个实用排障顺序是：先在容器内确认应用监听，再确认容器 IP 和路由，然后检查同网络容器互通，最后检查宿主机端口映射和外部访问。不要一开始就修改镜像或重装 Docker，网络问题通常可以沿路径逐层缩小范围。
docker exec api ip addr
docker exec api getent hosts redis
docker exec api nc -vz redis 6379
docker port webbridge 与 Kubernetes 网络的关系
Docker bridge 是单机容器网络模型，Kubernetes 则要求 Pod 在集群内具备更一致的互通语义，并通过 CNI 插件实现跨节点转发、网络策略和服务抽象。学习 bridge 的价值在于理解网络命名空间、veth、NAT 和服务发现的底层概念，但不能把 Docker bridge 直接等同于 Kubernetes Service。若后续进入集群网络，可继续阅读Kubernetes实践与Kubernetes容器专题。
小结：把 bridge 看作一条可拆解的链路
Docker bridge 网络并不神秘，它是由容器网络命名空间、veth、Linux bridge、NAT 和 DNS 组合出的单机通信方案。掌握它的关键不是背命令，而是能把一次访问拆成“名称解析、路由选择、网桥转发、端口映射、应用监听”几个环节。只要链路清楚，大多数容器通信问题都能被稳定复现和定位。
转载请注明出处：https://www.cloudnative-tech.com/p/7337/
