Docker Bridge网络在高并发下易现NAT开销、DNS不稳定等问题，应弃用默认docker0，改用自定义bridge+静态IP、host模式混合部署，并调优conntrack等内核参数。
Docker Bridge 网络在高并发系统中不是首选方案，但若受限于架构或需兼容单机多服务场景，仍可优化配置——关键不是“怎么配”，而是“怎么避坑+怎么补强”。默认 bridge（docker0）在高并发下容易暴露 NAT 开销、DNS 不稳定、IP 漂移和连接跟踪瓶颈，直接套用会拖慢吞吐、增加超时概率。
避开默认 docker0 网桥
默认 bridge 不支持服务名解析、IP 动态分配不可控、iptables 规则随容器增减频繁刷新，高并发下易引发 conntrack 表溢出或 DNAT 延迟。生产环境必须弃用。
- 禁用默认网络：启动容器时显式指定 --network none 或使用自定义网络，避免意外接入 docker0
- 不依赖
docker run -d nginx这类无网络声明的命令，所有容器必须绑定明确网络 - 检查现有容器是否误连 docker0：
docker network inspect bridge | grep -A 10 Containers，及时迁移
用自定义 bridge + 固定子网与静态 IP
自定义 bridge 可控性强，配合固定子网和预留 IP 能规避 DNS 解析延迟与连接中断，尤其适合 Java/Go 微服务间高频调用。
- 创建带子网和网关的网络：
docker network create --driver bridge --subnet 172.25.0.0/16 --gateway 172.25.0.1 highload-net - 为关键服务分配静态 IP（如 API 网关、Redis、DB）：
docker run -d --name api-gw --network highload-net --ip 172.25.0.10 -p 80:80 nginx - Java 应用连接 MySQL 示例：
jdbc:mysql://172.25.0.20:3306/app?useSSL=false&connectTimeout=2000（直连 IP，绕过 DNS 查询）
补充 host 模式关键组件
Bridge 模式无法消除内核态 NAT 开销，而高并发 IO 密集型组件（如 Nginx 入口、Kafka Broker、Envoy 边车）建议改用 host 网络，复用宿主机协议栈。
- 入口层用 host：
docker run -d --network host --name nginx-lb nginx，省去端口映射和 iptables 转发 - 后端服务保留在自定义 bridge 中，仅将流量敏感组件剥离——实现“host + bridge”混合部署
- 注意：host 模式下容器共享宿主机端口，需协调好端口占用，避免冲突
调优底层网络参数
Bridge 网络依赖 Linux 内核 netfilter 和 conntrack，高并发下必须调整相关阈值：
- 增大连接跟踪表：
sysctl -w net.netfilter.nf_conntrack_max=655360（写入 /etc/sysctl.conf 持久化） - 缩短连接超时：
sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=300 - 启用 TCP BBR（提升长连接吞吐）：
echo 'net.core.default_qdisc=fq' >> /etc/sysctl.conf && echo 'net.ipv4.tcp_congestion_control=bbr' >> /etc/sysctl.conf
