关键在于选用自定义bridge网络、Compose统一管理、overlay跨主机、避免host模式。自定义bridge启用DNS自动解析，Compose默认创建专属网络支持服务名通信，overlay实现跨节点全局IP可达，host模式应谨慎使用。
要让容器集群内部服务访问更灵活，关键不是堆配置，而是选对网络模式、建好命名空间边界、用好 DNS 自动发现，并保留扩展余地。
优先使用自定义 bridge 网络代替默认 bridge
默认的 bridge 网络不支持容器名自动解析，只能靠 IP 通信，维护成本高。自定义 bridge 网络则启用内置 DNS 服务，容器可直接用服务名互访。
- 创建带子网和网关的自定义网络：
docker network create --subnet=192.168.50.0/24 --gateway=192.168.50.1 mynet - 启动容器时显式指定网络：
docker run -d --name api --network mynet my-api-image - 同一网络下的容器（如
web）能直接curl http://api:3000，无需硬编码 IP 或端口映射
在 Docker Compose 中统一管理服务网络拓扑
Compose 默认为每个项目创建专属 bridge 网络，所有服务自动加入并可通过服务名通信——这是提升灵活性最轻量的方式。
- 确保
docker-compose.yml中不写死 IP，依赖服务名：depends_on+http://app:8080 - 如需隔离，可用
internal: true屏蔽外部访问，但保留服务间互通 - 多个 compose 项目间需互通？可复用同一自定义网络，或通过
external: true引用已有网络
跨主机场景下启用 overlay 网络（Swarm 或 Kubernetes）
单机 bridge 不解决多节点问题。overlay 是 Docker 原生支持的跨主机通信方案，基于 VXLAN 封装，容器 IP 在整个集群内全局可达。
- 初始化 Swarm：
docker swarm init，再创建 attachable overlay 网络：docker network create -d overlay --attachable my-overlay - 服务部署时指定该网络：
docker service create --network my-overlay --name redis redis - 任意节点上的容器只要连入该网络，就能用
redis名称访问，无需关心物理位置
避免滥用 host 模式，谨慎处理容器访问宿主机
host 模式虽性能高，但破坏网络隔离、引发端口冲突，不适合常规服务编排。真正需要访问宿主机服务时，应选择更可控的方式：
- Linux 宿主机：用
host.docker.internal（Docker Desktop 自动注入）或ip route | awk '/default/ {print $3}'动态获取网关 IP - 生产环境（尤其 Linux 服务器）：推荐通过
--add-host=host.docker.internal:host-gateway显式注入 DNS 别名 - 敏感服务（如数据库）建议从宿主机移出，改用独立容器+自定义网络，统一走容器间通信路径
