docker bridge模式下，容器间通信走纯二层转发：容器a发包→经veth pair抵达docker0网桥→网桥查mac表直转至容器b对应veth端口，全程不触发路由、iptables或nat。
要真正看清 Docker Bridge 模式的数据包转发流程，关键不是罗列命令，而是还原一个真实请求从容器发出、经过哪些内核组件、如何被决策和送达的全过程。整个路径干净、轻量，且严格分层——二层转发归网桥管，跨网才触发三层动作。
docker0 是真实运行的“虚拟交换机”
它不是配置项，而是宿主机上一个实实在在的 Linux 网桥设备（ip link show docker0 可见）。所有默认 bridge 容器的 eth0，都通过一对 veth 接口插在这台“交换机”的不同端口上。
- 容器 A 发包，目标 IP 是容器 B 的 172.17.0.3，源 MAC 是自己的 veth 接口 MAC
- 数据帧经 veth pair 进入宿主机命名空间，抵达 docker0
- docker0 查 MAC 地址表，匹配到容器 B 对应的 veth 端口，直接二层转发
- 全程不查路由表、不走 iptables FILTER/NAT 链、不修改 IP 或端口
veth pair 是穿透命名空间的“硬连线”
每启一个容器，Docker 就创建一对 veth：一端在容器内叫 eth0，另一端在宿主机上挂进 docker0，名字类似 vethabc123。这根“线”由内核直接调度，零代理、无协议栈开销。
- 容器内 ip route 显示默认网关是 172.17.0.1（即 docker0 的 IP），说明所有非本子网流量都会先送到网桥
- 宿主机上用 ethtool -S vethabc123 能看到 rx_packets / tx_packets 实时增长，证明流量真实流经该接口
- 用 tcpdump -i docker0 port 8080 可抓到请求与响应帧进出，直观验证纯二层路径
NAT 只在出向跨网时生效，与容器互访无关
当 Java 服务调用外部 HTTPS 接口（如 api.pay.example），数据包离开 172.17.0.0/16 子网时，才会命中宿主机的 iptables SNAT 规则，把源 IP 替换为宿主机真实地址，再发往物理网卡。
- 容器 A → 容器 B 的通信始终在子网内，永远不触发 NAT
- 这意味着延迟极低，接近本地进程间 socket 通信
- 若连接失败，大概率是容器 B 应用未监听、绑定在 127.0.0.1、或端口防火墙未放行——不是网络不通，而是应用层没准备好
ARP 和 MAC 表是转发决策的核心依据
docker0 作为二层设备，靠 ARP 请求学习容器 IP 与 veth MAC 的映射，并维护动态 MAC 地址表。广播只发生在首次通信或表项老化时。
- 容器首次访问另一容器，会先发 ARP 请求：“谁有 172.17.0.3？”
- 目标容器响应后，docker0 记录 IP-MAC 绑定，后续帧直接单播转发
- 可用 bridge fdb show 查看当前网桥的 MAC 表项
- 表项超时默认 5 分钟，可通过 sysctl net.bridge.bridge_forward_delay 调整
