docker bridge网络隔离依靠网络命名空间、veth pair和docker0网桥三者协同：命名空间提供独立网络栈，veth pair实现容器与主机间数据通路，网桥完成同网段二层转发；默认bridge仅ip互通且无dns，自定义bridge支持服务名解析与强隔离。
学 Docker Bridge 网络隔离机制，关键不是背命令，而是理清“谁隔离了谁、靠什么隔离、隔离后还能怎么通”。它本质是 Linux 网络虚拟化能力在容器场景的落地，从内核层到 Docker CLI 都有对应体现。
搞懂三个核心组件：命名空间、veth 对、网桥
这是隔离的底层支柱，缺一不可：
- 网络命名空间（Network Namespace）：每个容器启动时自动获得一个独立的网络世界——自己的 lo 和 eth0、自己的路由表、自己的 iptables 规则、自己的端口空间。容器 A 绑定 8080 端口，完全不影响容器 B 绑定 8080。
- veth pair（虚拟以太网对）：像一根虚拟网线，一端插进容器的命名空间（表现为 eth0），另一端插进宿主机（表现为类似 vethabc123 的接口），数据包靠它进出容器。
- docker0 网桥：宿主机上的一个虚拟交换机，所有默认 bridge 模式的容器都通过 veth pair 接入它。网桥负责二层转发——根据 MAC 地址学习和泛洪，让同网段容器能互相 ping 通。
区分默认 bridge 和自定义 bridge 的实际差异
很多问题源于混淆这两者。它们都用 bridge 驱动，但行为天差地别：
- 默认 bridge（docker network inspect bridge）：子网固定为 172.17.0.0/16；容器只能靠 IP 互访；不提供 DNS 解析；所有未指定网络的容器都会掉进来——容易造成意外连通。
- 自定义 bridge（docker network create mynet）：可指定子网、网关、MTU；容器自动支持名称解析（ping web1 就能通）；天然隔离——只有显式加入同一网络的容器才能通信；支持动态 attach/detach 容器。
动手验证隔离效果，比看文档更有效
用几条命令就能亲眼看到隔离是否生效：
- 启动两个容器，都不指定网络：docker run -d --name a1 nginx、docker run -d --name a2 nginx → 进入 a1 执行 ping a2 失败（无 DNS），但 ping 它的IP 成功（同属默认 bridge）。
- 创建自定义网络：docker network create app-net，再启动：docker run -d --name b1 --network app-net nginx、docker run -d --name b2 --network app-net nginx → 进入 b1 执行 ping b2 直接成功。
- 再启动第三个容器：docker run -it --rm --network bridge alpine ping b1 → 必定失败，证明跨网络默认不通。
理解 NAT 和端口映射如何影响“对外可见性”
Bridge 模式下，容器出向访问外网靠宿主机开启 IP 转发 + iptables SNAT；而外部访问容器，则必须依赖 -p 或 -P 做 DNAT 映射。这不是网络模式本身的能力，而是 Docker 在宿主机上配置的 iptables 规则。不映射端口，容器服务对外就是不可见的——这是隔离的自然结果，不是缺陷。
