Docker 容器连接（详细教程）

Docker 容器连接：让服务“对话”的底层逻辑

你有没有遇到过这样的场景？本地开发一个前端项目，用 Vue 3.0 搭建，然后另一个后端服务用 Node.js 写的，两个服务运行在不同的端口上，彼此“看不见”对方。这时候，你可能想：“能不能让它们像邻居一样，通过一条小路直接通电话？”——这正是 Docker 容器连接要解决的核心问题。

在容器化时代，每个服务被封装成一个独立的容器，就像一个个小房子。但房子建好了，如果没通水、没通电、没通网，那也只是空壳。Docker 容器连接，就是为这些“小房子”之间搭建通信桥梁，让它们能互相调用、共享数据、协同工作。

本文将带你从零开始，理解 Docker 容器连接的本质，掌握常用方式，并通过真实项目案例，让你真正“打通”容器之间的通信路径。

什么是 Docker 容器连接？

简单来说，Docker 容器连接（Container Networking）就是让两个或多个容器之间能够相互通信的技术。它不只限于“同一个宿主机”，还支持跨主机、跨网络环境的通信，是构建微服务架构的基石。

你可以把容器比作城市里的独立办公室。每个办公室里有员工（服务），但彼此之间没有直接电话线。Docker 容器连接，就是为你拉一条内网专线，让这些办公室可以互相拨打、传输文件、共享会议室资源。

Docker 默认使用 bridge 网络模式，这是最常见、最基础的网络方式。在这个模式下，容器通过 Docker 引擎自动分配 IP 地址，并通过内部网桥与宿主机通信。但默认情况下，容器之间是“互不相识”的，必须显式配置连接。

使用默认 bridge 网络连接容器

我们先来一个最简单的例子：启动两个容器，一个运行 Nginx，另一个运行 Alpine Linux，然后让它们互相 ping 通。

docker run -d --name nginx-container nginx:latest

docker run -it --name test-container alpine:latest sh

现在，你有两个容器：nginx-container 和 test-container。但它们默认不在同一个网络中，无法直接通信。

这时，你需要手动将它们加入同一个网络。先创建一个自定义 bridge 网络：

docker network create my-network

然后把两个容器都加入这个网络：

docker network connect my-network nginx-container

docker network connect my-network test-container

此时，两个容器已经“住”在同一个小区里了。你可以进入 test-container，尝试 ping nginx-container：

docker exec -it test-container sh

ping nginx-container

如果看到返回的 ICMP 包，说明通信成功！这说明，通过自定义网络，Docker 容器连接已经建立。

注意：Docker 默认 bridge 网络不支持容器间自动解析主机名，必须通过自定义网络才能实现。这就是为什么我们特意创建了 my-network。

通过自定义网络实现服务发现

在实际项目中，你不可能手动 ping 一个服务。真正有用的是，让容器能通过服务名访问对方。

举个真实场景：你有一个前端 Vue 3.0 项目，运行在容器 A；一个后端 Node.js API 服务运行在容器 B。前端需要访问 http://localhost:3000/api，但这个 localhost 只在容器 A 内有效。如果容器 B 没有被正确连接，前端就“找不到路”。

我们来模拟这个场景。

第一步：创建自定义网络

docker network create app-network

第二步：启动后端服务容器

docker run -d \
  --name api-server \
  --network app-network \
  -p 3000:3000 \
  node:18-alpine \
  sh -c "echo 'Hello from API' > /app/index.html && http-server /app -p 3000"

这个命令做了几件事：

使用 node:18-alpine 镜像，轻量且适合生产
启动时执行 http-server 服务，监听 3000 端口
通过 --network app-network 加入自定义网络
将容器的 3000 端口映射到宿主机 3000 端口，方便测试

第三步：启动前端容器

docker run -d \
  --name vue-client \
  --network app-network \
  -p 8080:8080 \
  nginx:alpine \
  sh -c "echo '<h1>Fetching API...</h1><script>fetch(\"http://api-server:3000\").then(r=>r.text()).then(t=>document.body.innerHTML=t)</script>' > /usr/share/nginx/html/index.html && nginx -g 'daemon off;'"

这个容器做了：

使用 Nginx 作为静态服务器
写入一段 HTML + JavaScript，尝试访问 http://api-server:3000
api-server 是我们在自定义网络中定义的容器名，Docker 会自动解析为 IP

第四步：访问前端页面

打开浏览器，访问 http://localhost:8080，你应该能看到 “Hello from API”。

这说明：前端容器通过服务名 api-server 成功访问了后端容器，Docker 容器连接在这里发挥了关键作用。

✅ 关键点：在自定义网络中，容器名自动成为 DNS 解析名，无需 IP，无需手动配置 hosts。

使用 `--link` 参数（已弃用，仅作了解）

曾经，Docker 提供 --link 参数来连接容器，语法如下：

docker run -d --name web --link db:db mysql:5.7

这会把 db 容器链接到 web 容器，并在 web 容器的 /etc/hosts 中添加一条记录，将 db 映射为 IP。

但 --link 有明显缺点：

只支持单向连接
不支持多网络环境
容器名必须唯一
Docker 官方已明确推荐弃用，建议使用自定义网络

所以，除非你维护老旧项目，否则不建议使用 --link。它就像老式电话线，只能一对一，而现代 Docker 容器连接是高速局域网。

网络模式对比：bridge、host、none 详解

网络模式	是否支持容器连接	适用场景	优点	缺点
bridge（默认）	✅ 支持（需自定义网络）	多容器协作、微服务	隔离性好，支持 DNS 解析	需手动配置网络
host	❌ 不支持（容器共享宿主机网络）	性能要求极高，如数据库	无网络开销，性能最优	无法隔离端口，易冲突
none	❌ 不支持	安全要求极高，完全断网	最安全，无外部通信	无法与其他容器通信

💡 建议：绝大多数项目使用 自定义 bridge 网络，它是平衡隔离、性能与通信能力的最佳选择。

实用技巧：查看容器网络信息

当你遇到连接失败时，可以通过以下命令排查：

docker network ls

docker network inspect my-network

docker inspect nginx-container

docker network inspect 的输出中，你会看到 Containers 字段列出所有连接的容器，以及它们的 IP 地址、网关等信息。这是排查连接问题的“终极武器”。

常见问题与解决方案

1. 容器间无法 ping 通？

检查是否加入同一个网络
确保容器内有 ping 命令（Alpine 默认无 ping，需 apk add iputils）
检查防火墙或安全组是否拦截

2. 服务名无法解析？

确保使用的是自定义网络（非默认 bridge）
容器名不能有特殊字符
重启容器后可能需要重新解析，可尝试 docker restart container-name

3. 端口映射失败？

检查宿主机端口是否被占用
使用 lsof -i :3000 查看端口占用
确保 -p 3000:3000 语法正确

总结：让容器真正“活”起来

Docker 容器连接不是“高级功能”，而是构建可运行应用的基础能力。没有它，容器就是一个个“孤岛”。通过自定义 bridge 网络，你不仅能实现容器间通信，还能享受服务发现、自动 DNS 解析、网络隔离等强大特性。

本文通过真实项目案例，带你从零搭建前后端容器通信，理解了：

为什么默认 bridge 不够用
如何创建自定义网络
如何通过服务名访问容器
如何排查连接问题

记住：Docker 容器连接的核心思想，是为服务提供“可信赖的通信路径”。当你能熟练掌握它，你就真正迈入了容器化应用开发的大门。

别再让服务“失联”了。从今天起，给你的容器们拉一条专属网络专线吧。