自定义桥接网络+Docker Compose多网络编排可有效化解容器网络复杂性：默认bridge不支持服务名解析，IP易变；自定义bridge支持DNS自动解析、子网/网关定制及逻辑隔离，提升可维护性与安全性。
直接用自定义桥接网络 + Docker Compose 多网络编排，就能把多数容器网络复杂性问题化解掉。关键不是堆功能，而是让网络结构清晰、可预测、易验证。
用自定义 bridge 替代默认 docker0
默认的 bridge 网络（即 docker0）不支持容器名解析，所有通信得靠 IP，一重启就变，维护成本高。换成自定义桥接网络后，容器能通过服务名互相访问，DNS 自动生效，这才是生产可用的基础。
- 创建带子网和网关的网络：
docker network create --driver bridge --subnet 192.168.50.0/24 --gateway 192.168.50.1 app-net - 启动容器时显式指定：
docker run -d --name api --network app-net my-api - 同一网络下的容器可直接
ping api或curl http://api:3000/health
用 Docker Compose 定义分层网络拓扑
当服务角色分明（比如前端、API、数据库），别把所有容器塞进一个网里。用 Compose 的 networks 字段做逻辑隔离，既控制通信路径，又提升安全性。
- 前端只连
frontend网络，数据库只连backend网络 - API 服务同时接入两个网络，充当唯一入口点
- 这样 db 就不会被 web 直接访问，也不用开额外防火墙规则
避免 host 模式滥用，除非真需要零延迟
host 模式省去了 NAT 和虚拟网桥，性能确实好，但代价是端口冲突、容器与宿主机网络紧耦合、无法跨环境复用配置。它适合压测工具或监控代理这类“旁路型”组件，不适合主业务服务。
- 检查是否真有性能瓶颈：先用
docker stats和iftop确认网络不是瓶颈 - 若必须用，确保只在单节点、非编排场景下启用
- 永远不要在 Compose 中全局设
network_mode: host，会破坏服务发现
防火墙共存而非绕过
很多“容器连不上外网”或“容器间 ping 不通”，其实不是 Docker 配置错，而是 firewalld 重启后清空了 Docker 插入的 iptables 规则。解决思路不是关防火墙，而是让它管理 Docker 的流量边界。
- 把
docker0接口加入 trusted zone：firewall-cmd --permanent --zone=trusted --add-interface=docker0 - 放行容器子网（如
172.18.0.0/16）：firewall-cmd --permanent --zone=trusted --add-source=172.18.0.0/16 - 重载后，Docker 规则和防火墙策略就协同工作了
