Docker Compose容器通信故障排查与最佳实践

1. 问题现场还原

凌晨2:47分，服务器告警短信第6次响起。Nginx日志里满是502错误，而docker-compose logs显示两个服务明明都在运行。这种"薛定谔的容器通信"问题，相信每个用过Docker Compose的人都遇到过。上个月我们生产环境就因此损失了3小时服务可用性，今天就把这些血泪教训整理成避坑指南。

2. 容器通信基础架构解析

2.1 默认网络模型

Docker Compose默认创建的bridge网络，实际上是个带DNS服务的虚拟子网。当运行docker-compose up时：

1. 自动创建名为{project}_default的bridge网络
2. 为每个service分配主机名(hostname)和容器名(container_name)
3. 内置DNS解析器将服务名(service name)映射到容器IP

2.2 典型通信场景

mermaid复制graph LR
    A[ServiceA] -->|通过服务名访问| B(ServiceB)
    A -->|通过容器名访问| C[ServiceB_Container1]
    B -->|通过别名访问| D[ServiceC]

（注：实际使用时请用文字描述替代图表）

3. 六大经典故障模式

3.1 DNS解析抖动

症状：间歇性连接失败，日志出现"Name or service not known"

根本原因：

• Docker内置DNS服务器响应超时(默认2秒)
• 容器启动顺序导致的服务注册延迟

验证方法：

bash复制docker exec -it container_name ping service_name
docker exec -it container_name cat /etc/resolv.conf

3.2 端口映射冲突

症状：服务能ping通但无法建立TCP连接

常见陷阱：

• 容器内服务监听127.0.0.1而非0.0.0.0
• compose文件ports定义错误：

yaml复制# 错误写法（主机端口:容器端口）
ports:
  - "8080:127.0.0.1:8080" 

# 正确写法
ports:
  - "8080:80