关键在于用自定义bridge网络替代默认bridge，启用内置dns实现容器名解析；支持多网接入、host模式低延迟通信及底层接口验证，确保连得稳、查得清、扩得开。
要让业务在容器间稳定互通，关键不是“连得上”，而是“连得稳、查得清、扩得开”。Docker 网络接口本身不提供服务发现或自动重连，但它的虚拟网卡（veth pair）、网桥（docker0 或自定义 bridge）和 Network Namespace 隔离机制，构成了可预测、可复现的通信基础。实战中真正起效的，是围绕这些特性设计的网络拓扑与接入方式。
用自定义 Bridge 网络替代默认 bridge
默认的 bridge 网络不启用内置 DNS，容器名无法解析，只能靠手动记 IP——这在业务重启、扩缩容时必然出错。
- 创建带子网和网关的独立网络：
docker network create --subnet=172.30.0.0/16 --gateway=172.30.0.1 myapp-net - 所有业务容器启动时显式加入该网络：
docker run -d --name api --network myapp-net -p 8080:8080 my-api-image - 同网内的容器可直接用名称通信：
curl http://api:8080/health，无需查 IP，DNS 由 Docker 内置 daemon 自动响应
避免跨网段直连，用 network connect 拓展连接能力
当已有容器运行在不同网络（如默认 bridge 和自定义 myapp-net），不要尝试改 IP 或配静态路由——Docker 不支持容器多网卡绑定，但支持“多网络接入”。
- 让一个容器同时接入两个网络：
docker network connect bridge my-legacy-container - 此时容器会拥有两个 IP：一个在
172.17.0.x（bridge），一个在172.30.0.x（myapp-net） - 其他容器可通过任一 IP 访问它，适合灰度迁移、数据库代理、监控采集等过渡场景
用 host 网络模式解决低延迟或 UDP 类业务
某些业务对网络栈延迟敏感（如实时音视频转发、高频金融行情推送），或依赖 UDP 广播/组播（如 Consul 健康检查、Zeroconf 服务发现），bridge 模式下的 NAT 和 iptables 规则会引入不可控抖动。
- 启动容器时指定
--network host，容器直接复用宿主机网络命名空间 - 容器内
localhost就是宿主机，netstat -tuln显示的端口即真实监听端口 - 注意规避端口冲突：多个 host 模式容器不能同时监听 8080；也建议配合
--user限制权限，降低安全风险
调试时善用底层接口验证通信路径
当业务不通，别急着改应用配置。先确认网络层是否就绪：
- 进容器执行
ip a，看是否有eth0且获取到预期网段 IP（如172.30.0.5/16） - 在宿主机执行
brctl show docker0或docker network inspect myapp-net，核对容器是否真正在该网桥下 - 从容器 ping 同网另一容器名（如
ping db），失败则说明 DNS 或网络未生效；成功但 curl 失败，则问题在应用层或防火墙
不复杂但容易忽略：网络是基础设施，不是一次配置就永久有效的。每次新增容器、更换镜像、升级 Docker 版本，都可能影响 veth pair 创建逻辑或 iptables 规则加载顺序。把 docker network ls 和 docker network inspect 当成日常巡检动作，比事后抓包更高效。
