本文系统讲解 Docker 容器间通信的核心原理与最佳实践，重点澄清“容器内访问 localhost 即可连通其他容器”这一常见误解，详解 Bridge 网络、自定义网络、DNS 解析机制，并提供可直接运行的 docker-compose 配置与 Node.js 应用适配方案。
本文系统讲解 docker 容器间通信的核心原理与最佳实践，重点澄清“容器内访问 `localhost` 即可连通其他容器”这一常见误解，详解 bridge 网络、自定义网络、dns 解析机制，并提供可直接运行的 `docker-compose` 配置与 node.js 应用适配方案。
在 Docker 中，localhost 是一个极具迷惑性的概念——它永远指向容器自身，而非宿主机或其他容器。你遇到的问题（app1 中 fetch("http://localhost:3002") 失败）正是这一根本特性导致的典型错误：app1 容器内的 localhost:3002 指向的是它自己监听的 3002 端口（实际未监听），而非 app2 容器。extra_hosts: host.docker.internal:host-gateway 仅解决容器访问宿主机服务的问题，对容器间通信无效。
✅ 正确解法是：让容器通过对方的服务名（即容器名或服务名）进行通信，这依赖于 Docker 内置的用户自定义网络（User-Defined Bridge Network）及其 DNS 服务。
✅ 推荐方案：使用自定义 Bridge 网络 + 服务名解析（生产就绪）
这是 Docker 官方推荐、最简洁可靠的方式，无需修改应用代码逻辑（仅需配置环境变量解耦）：
1. 创建自定义网络（关键！）
docker network create app-network
2. 更新 docker-compose.yaml
version: '3.8'
services:
app1:
build: ./app1
container_name: app1_c
ports:
- "3000:3000"
environment:
- CONNECTION_URL=http://app2:3002 # ✅ 使用服务名 app2，非 localhost
networks:
- app-network # ✅ 加入同一自定义网络
app2:
build: ./app2
container_name: app2_c
ports:
- "3002:3002"
networks:
- app-network # ✅ 同一网络，自动 DNS 解析
⚠️ 注意：必须移除 extra_hosts 配置。它在此场景下不仅无用，还可能干扰 DNS 解析。
3. 应用代码保持环境变量驱动（最佳实践）
app1/index.js（无需改动，复用你已优化的版本）：
import fetch from 'node-fetch';
import express from 'express';
import 'dotenv/config';
const app = express();
const port = 3000;
app.get('/', async (req, res) => {
try {
const resp = await fetch(process.env.CONNECTION_URL, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ msg: 'hello app2' }),
});
const data = await resp.json();
res.json(data);
} catch (err) {
res.status(500).json({ error: 'app2 unreachable', details: err.message });
}
});
app.listen(port, () => console.log(`app1 listening on port ${port}`));
.env（开发环境）：
CONNECTION_URL=http://localhost:3002
docker-compose.yaml（生产/测试环境）：
environment: - CONNECTION_URL=http://app2:3002 # ✅ 自动解析为 app2 容器 IP
❌ 为什么其他方式不推荐？
- 默认 bridge 网络：不支持服务名解析（app2 无法被识别），只能靠 IP（不稳定）或 --link（已废弃）。
- host 网络模式：容器共享宿主机网络栈，端口易冲突，丧失网络隔离性，禁止用于生产。
- extra_hosts + host.docker.internal：仅映射宿主机 IP，app2 在另一容器中，其端口并未暴露在宿主机 localhost:3002（除非显式 ports 映射且 app1 主动访问 host.docker.internal:3002，但此方式绕过 Docker DNS，缺乏弹性）。
? 验证通信是否成功
# 进入 app1 容器，直接 ping app2 服务名（验证 DNS）
docker exec -it app1_c ping -c 2 app2
# 从 app1 容器 curl app2（模拟 fetch 行为）
docker exec -it app1_c curl -X POST http://app2:3002 -H "Content-Type: application/json" -d '{"msg":"test"}'
? 关键总结
| 场景 | 正确做法 | 错误做法 |
|---|---|---|
| 同主机容器通信 | 创建自定义 bridge 网络 + 用服务名（如 app2）访问 | 用 localhost、127.0.0.1 或宿主机 IP |
| 跨主机通信 | 使用 overlay 网络（Swarm/K8s）或 Flannel/Calico 等 CNI 插件 | 尝试手动配置路由或暴露所有端口 |
| 应用配置解耦 | 通过 environment 注入 URL，代码读取环境变量 | 硬编码 localhost 或 IP 地址 |
遵循此方案，你的 app1 与 app2 将在 Docker 网络层实现零配置、高可靠、可扩展的通信，同时完美兼容本地开发（.env）与容器化部署（docker-compose）。
