Docker网络：bridge与host模式差异

理解Docker网络模型与bridge、host模式定位

Docker的网络架构深度依赖Linux内核的网络命名空间（Network Namespace）与虚拟网络设备。在默认的bridge模式下，Docker会在宿主机创建一个名为docker0的虚拟网桥，并为每个容器分配独立的网络命名空间。容器通过veth pair一端连接至docker0，另一端置于容器内部，从而实现网络隔离与NAT转发。容器拥有独立的IP地址（通常位于172.17.0.0/16网段），外部访问需依赖iptables规则进行端口映射。相比之下，host模式直接让容器共享宿主机的网络命名空间，容器进程将直接使用宿主机的网卡、路由表和端口资源。这种设计彻底消除了网桥与NAT带来的性能损耗，但也意味着容器与宿主机之间不存在任何网络层面的隔离，两者在IP分配、端口监听及网络栈行为上完全等价。理解这一底层机制，是正确选择网络模式的前提。

实际创建容器并对比bridge与host网络行为

通过实际命令可直观观察两种模式的行为差异。执行docker run -d --name app-bridge -p 8080:80 nginx启动bridge容器后，Docker会自动分配一个独立IP，并通过iptables将宿主机的8080端口转发至容器的80端口。此时在宿主机执行docker inspect app-bridge可看到容器IP，且ss -tulnp显示8080端口由docker-proxy或iptables接管。若执行docker run -d --name app-host --network host nginx，容器将直接绑定宿主机的网络栈。此时-p参数会被Docker引擎忽略并打印警告，容器内的Nginx将直接监听宿主机的80端口。通过docker exec app-host ip addr查看，可见容器内网络接口与宿主机完全一致，不存在独立的eth0或veth设备。这种直接占用宿主机端口的行为，要求运维人员必须提前规划端口分配，避免服务冲突。

用连通性测试验证两种模式的差异

验证网络连通性需结合Docker内置命令与Linux原生网络工具。对于bridge容器，首先使用docker inspect app-bridge --format='{{.NetworkSettings.IPAddress}}'获取容器IP，随后在宿主机执行curl <容器IP>:80可验证内部直连；外部访问则通过curl localhost:8080验证NAT转发是否生效。若需排查连通性问题，可进入容器执行ip route查看默认网关是否指向docker0，并使用ping测试宿主机网关。对于host模式，验证更为直接：执行ss -tulnp | grep :80即可确认服务是否直接监听在宿主机网卡上，随后curl localhost:80应直接返回响应。若外部无法访问，需检查宿主机防火墙（如firewalld或ufw）是否放行对应端口，而非排查Docker端口映射规则。建立配置检查、端口监听验证、内外连通测试的标准化流程，可快速定位网络异常。

选择场景与常见避坑

在实际生产环境中，模式选择需严格匹配业务诉求。bridge模式适用于绝大多数微服务、Web应用及多容器编排场景，其提供的网络隔离、独立IP与灵活的端口映射能力，能有效避免服务间端口冲突，并便于实施细粒度的网络策略。host模式则适用于对网络延迟与吞吐量极度敏感的场景（如高频交易网关、网络监控探针、DPDK应用），或需要直接操作宿主机物理网卡、绑定特定MAC地址的特殊需求。常见避坑要点包括：host模式下-p参数完全失效，若多个容器同时使用host模式并监听相同端口，将直接引发Address already in use错误；此外，host模式会削弱容器安全边界，容器内进程可嗅探宿主机所有网络流量。建议优先使用bridge或自定义overlay网络，仅在性能瓶颈明确且安全可控时启用host模式，并配合端口规划与防火墙策略进行收敛。