Docker Compose 网络原理与实战：同一 Compose 服务间如何稳定通信

在使用 Docker Compose 编排多个服务时，一个最常见的问题就是：

同一个 compose 文件里的多个 services，到底怎么互相通信？一共有多少种方案？

如果只说结论，其实很简单：

最常用、最推荐的方式 ：把服务放到同一个网络里，直接用服务名访问
如果按工程实践细分，常见可分为 4 类主流方案
如果再扩展到跨项目、兼容旧配置等场景，可以理解为 6～8 种变体

这篇文章会从原理、配置、示例和避坑四个层面，把 Docker Compose 服务通信一次讲清楚。

一、先说结论：最推荐的方式是什么？

在同一个 Docker Compose 项目里，服务间通信的标准做法是：

让服务加入同一个网络
通过 service 名称 直接访问目标服务
不依赖固定 IP
通常不需要把内部服务端口暴露给宿主机

例如：

yaml 复制代码

services:
  app:
    image: myapp

  redis:
    image: redis:7

启动后，app 容器里就可以直接访问：

bash 复制代码

redis:6379

这里的 redis，就是 Compose 里的 service 名。

二、Docker Compose 为什么能通过服务名通信？

Docker Compose 启动项目时，会自动创建一个默认网络。

同一个 Compose 项目中的服务，默认都会加入这个网络。

Docker 内置了 DNS 服务发现能力，因此在同一网络中的容器可以通过：

service 名
network alias

来解析到对应容器的地址。

也就是说，Compose 中最常见的服务发现方式不是 IP，而是：

db
redis
api

这样的逻辑名称。

这也是为什么在生产或开发环境中，不建议手写容器 IP 。

容器重建后 IP 可能会变化，但服务名通常不会变。

三、同一个 Compose 下 services 通信，有多少种方案？

如果从现代 Docker Compose 实践来分，可以归纳为 4 类主流方案：

默认网络 + 服务名访问
自定义 network
network alias（网络别名）
host 网络模式

如果再扩展场景，还可以加上：

多网络组合
external network（外部网络，跨 Compose 项目通信）
通过宿主机端口转发访问
links（历史方案，不推荐）

严格说，"有多少方案"没有唯一标准答案。

但在实际工程里，重点掌握前 2～4 种 就够了。

四、方案一：默认网络 + 服务名访问

这是最简单、最常见、也是最推荐的方式。

示例

yaml 复制代码

version: "3.8"

services:
  app:
    image: curlimages/curl:8.8.0
    command: ["sleep", "infinity"]

  api:
    image: hashicorp/http-echo
    command: ["-text=hello-compose", "-listen=:5678"]

启动：

bash 复制代码

docker compose up -d

进入 app 容器：

bash 复制代码

docker compose exec app sh

测试访问：

bash 复制代码

curl http://api:5678

如果一切正常，会返回：

text 复制代码

hello-compose

特点

配置最少
Compose 自动创建默认网络
可以直接通过 service 名 通信
不需要关心容器 IP

适用场景

本地开发
单项目微服务编排
Web + API + DB 的典型三层结构

五、方案二：自定义 network

当项目稍微复杂一点时，通常会手动定义网络，而不是完全依赖默认网络。

这样做的好处是：

更清晰
更安全
更容易隔离前后端、数据库等不同层次的服务

示例：前端、后端、数据库隔离

yaml 复制代码

version: "3.8"

services:
  frontend:
    image: nginx:alpine
    networks:
      - web

  backend:
    image: nginx:alpine
    networks:
      - web
      - dbnet

  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: 123456
    networks:
      - dbnet

networks:
  web:
  dbnet:

通信关系分析

frontend 和 backend 都在 web 网络中，因此能互通
backend 和 db 都在 dbnet 网络中，因此能互通
frontend 不在 dbnet，所以不能直接访问 db

适用场景

前后端分层
网关与内部服务隔离
数据库只暴露给后端
更符合最小权限原则

六、方案三：使用网络别名 alias

有时你希望一个服务除了 service 名之外，还能用其他域名访问。

这时可以给它配置 network alias。

示例

yaml 复制代码

version: "3.8"

services:
  app:
    image: curlimages/curl:8.8.0
    command: ["sleep", "infinity"]
    networks:
      - appnet

  redis:
    image: redis:7
    networks:
      appnet:
        aliases:
          - cache
          - redis-master

networks:
  appnet:

此时在 app 中，下面几个主机名都可以访问到 redis：

redis
cache
redis-master

例如：

bash 复制代码

redis-cli -h cache

适用场景

兼容旧系统中的主机名配置
服务迁移时保持地址不变
同一个服务暴露多个逻辑名称

七、方案四：host 网络模式

这是另一类通信方式，但它并不是 Compose 内部服务发现的主流方案。

示例

yaml 复制代码

services:
  app:
    image: nginx:alpine
    network_mode: host

它的含义

host 模式下，容器直接使用宿主机网络栈，而不是 Docker 的桥接网络。

也就是说：

容器没有独立的容器网络隔离
服务直接监听在宿主机网络上
一般不再需要 ports 映射

优点

网络路径更直接
某些场景下配置简单
对某些需要宿主机网络能力的服务有帮助

缺点

隔离性差
不适合作为普通服务间通信的首选
在不同平台上的行为差异需要特别注意

适用建议

除非你明确知道自己为什么要用 host，否则在 Compose 内部服务互联场景下，优先使用 bridge 网络 + 服务名访问。

八、扩展方案一：多网络组合通信

一个服务可以加入多个网络，这在复杂系统中非常常见。

示例

yaml 复制代码

version: "3.8"

services:
  gateway:
    image: nginx:alpine
    networks:
      - public
      - internal

  user-service:
    image: nginx:alpine
    networks:
      - internal

  order-service:
    image: nginx:alpine
    networks:
      - internal

networks:
  public:
  internal:

说明

gateway 同时加入 public 和 internal
user-service、order-service 只在 internal
这样网关既能接入外部流量，又能访问内部服务

这是很多微服务架构里非常常见的设计。

九、扩展方案二：external network 跨 Compose 项目通信

如果不是同一个 Compose 项目，而是多个 Compose 项目之间想互通，可以把它们接入同一个外部网络。

先创建网络

bash 复制代码

docker network create shared-net

Compose 配置

yaml 复制代码

services:
  app:
    image: nginx:alpine
    networks:
      - shared-net

networks:
  shared-net:
    external: true

另一个 Compose 项目也加入同一个 shared-net，就可以通过服务名或别名进行通信。

适用场景

多个 Compose 项目协作
公共网关、日志、监控等基础设施共享
分仓库部署但需要互联

十、扩展方案三：通过宿主机端口访问

严格说，这不是 Compose 内部服务通信的最佳方式，但确实也是一种"能连通"的方式。

例如：

yaml 复制代码

services:
  db:
    image: mysql:8
    ports:
      - "3306:3306"

此时其他容器理论上可以绕一圈，通过宿主机地址访问这个端口。

但这种方式存在几个问题：

增加了绕路和复杂度
依赖宿主机网络环境
不利于移植
不符合 Compose 内部服务发现的最佳实践

因此：

同一个 Compose 项目内部，优先用服务名，不要优先用宿主机端口。

十一、历史方案：links，不建议再用

Docker 早期支持 links 用于容器间连接，但现在已经不再是推荐做法。

原因很简单：

同网络下的 DNS 服务发现已经足够好用
links 可读性和可维护性更差
官方更推荐使用用户自定义网络

如果你看到老项目里有 links，通常可以考虑逐步迁移到标准网络方案。

十二、Compose 内部通信最容易踩的坑

1. 把 `localhost` 当成别的服务

这是最常见错误。

在容器里：

localhost
127.0.0.1

指向的是当前容器自己，不是其他 service，也不是宿主机。

例如在 app 容器里：

bash 复制代码

curl http://localhost:6379

访问的是 app 自己，而不是 redis。

正确方式应当是：

bash 复制代码

curl http://redis:6379

2. 误以为 services 通信必须写 `ports`

不是。

`ports` 的作用

用于把容器端口映射到宿主机，给宿主机或外部访问。

容器间通信

只要在同一网络里，并且目标服务在容器内监听了对应端口，通常就可以直接访问。

例如：

yaml 复制代码

services:
  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: 123456

即使不写 ports，同网络中的其他服务仍然可以访问：

text 复制代码

db:3306

3. 误以为 `depends_on` 就代表服务可用

depends_on 只能保证启动顺序，不能保证服务已经准备就绪。

例如数据库容器虽然启动了，但数据库初始化可能还没完成。

这时应用去连接，仍然可能失败。

更稳妥的方式包括：

应用内做重试
增加 healthcheck
使用等待脚本

4. 过度依赖 `container_name`

Compose 支持手动指定容器名：

yaml 复制代码

container_name: my-db

但在 Compose 的日常使用中，通常更推荐使用 service 名 来做服务发现。

原因包括：

service 名更符合 Compose 设计
更利于维护
更适合后续扩展和自动化管理

十三、一个完整示例：Web + API + MySQL

下面给一个更接近真实项目的例子。

yaml 复制代码

version: "3.8"

services:
  web:
    image: nginx:alpine
    depends_on:
      - api
    networks:
      - appnet
    ports:
      - "8080:80"

  api:
    image: node:18-alpine
    working_dir: /app
    command: ["sh", "-c", "node server.js"]
    volumes:
      - ./api:/app
    depends_on:
      - db
    networks:
      - appnet

  db:
    image: mysql:8
    environment:
      MYSQL_ROOT_PASSWORD: 123456
      MYSQL_DATABASE: demo
    networks:
      - appnet

networks:
  appnet:

通信路径

浏览器访问宿主机 localhost:8080，进入 web
web 通过 http://api:3000 调用 API
api 通过 db:3306 连接 MySQL

这里的重点

web -> api 用服务名 api
api -> db 用服务名 db
只有 web 对外暴露了 ports
api 和 db 的内部通信不需要暴露端口给宿主机

十四、到底该怎么选？

如果你只是想知道"Compose 下服务怎么互相通信"，可以按这个选择：

场景一：普通项目

直接使用 默认网络 + 服务名访问

这是首选。

场景二：希望隔离不同层

使用 自定义网络

例如：

web
app
db

分别接入不同网络，后端做桥梁。

场景三：需要兼容旧域名或逻辑名

使用 alias

场景四：需要跨 Compose 项目通信

使用 external network

场景五：明确需要宿主机网络能力

才考虑 host 模式

十五、最佳实践总结

把这篇文章压缩成几条可执行建议，就是：

优先使用同一网络 + 服务名访问
不要写死容器 IP
容器内不要把 localhost 当成其他服务
内部服务通信通常不需要 ports
复杂项目建议显式定义 networks
数据库等核心服务建议放在独立内部网络
depends_on 不等于服务已就绪
除特殊需求外，不优先使用 host 模式
老项目中的 links 可以逐步淘汰

十六、结语

Docker Compose 的服务间通信并不复杂，关键是理解两个核心点：

网络隔离由 network 决定
服务发现通常靠 service 名，而不是 IP

所以如果你问：

同一个 Compose 下的 services 如何互相通信？

最标准、最实用的答案就是：

让它们处于同一个网络中，然后直接通过服务名访问。

如果你再进一步问：

一共有多少方案？

那可以回答：

主流看 4 类
扩展看 6～8 种
真正常用且推荐的，核心还是 默认网络 / 自定义网络 + 服务名通信

参考资料

以下为可核实的官方与权威文档方向，建议发布时保留：

Docker Docs - Compose networking
docs.docker.com/compose/how...
Docker Docs - Networking in Compose
docs.docker.com/compose/
Docker Docs - Bridge network driver
docs.docker.com/network/dri...
Docker Docs - Use host networking
docs.docker.com/network/hos...

注：不同 Docker / Compose 版本在文档入口路径上可能有调整，但上述主题均可在 Docker 官方文档中查证。

Docker Compose 网络原理与实战：同一 Compose 服务间如何稳定通信

一、先说结论：最推荐的方式是什么？

二、Docker Compose 为什么能通过服务名通信？

三、同一个 Compose 下 services 通信，有多少种方案？

四、方案一：默认网络 + 服务名访问

示例

特点

适用场景

五、方案二：自定义 network

示例：前端、后端、数据库隔离

通信关系分析

适用场景

六、方案三：使用网络别名 alias

示例

适用场景

七、方案四：host 网络模式

示例

它的含义

优点

缺点

适用建议

八、扩展方案一：多网络组合通信

示例

说明

九、扩展方案二：external network 跨 Compose 项目通信

先创建网络

Compose 配置

适用场景

十、扩展方案三：通过宿主机端口访问

十一、历史方案：links，不建议再用

十二、Compose 内部通信最容易踩的坑

1. 把 localhost 当成别的服务

2. 误以为 services 通信必须写 ports

ports 的作用

容器间通信

3. 误以为 depends_on 就代表服务可用

4. 过度依赖 container_name

十三、一个完整示例：Web + API + MySQL

通信路径

这里的重点

十四、到底该怎么选？

场景一：普通项目

场景二：希望隔离不同层

场景三：需要兼容旧域名或逻辑名

场景四：需要跨 Compose 项目通信

场景五：明确需要宿主机网络能力

十五、最佳实践总结

十六、结语

参考资料

1. 把 `localhost` 当成别的服务

2. 误以为 services 通信必须写 `ports`

`ports` 的作用

3. 误以为 `depends_on` 就代表服务可用

4. 过度依赖 `container_name`