你的问题核心是Kafka的通告监听器配置与客户端连接地址不匹配，导致客户端拿到错误的连接目标（127.0.0.1:9092）而非Kafka容器的内部地址。我来一步步拆解问题和解决方案：

问题根源分析 #

先看你的Kafka配置：

KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:29092,PLAINTEXT_HOST://localhost:9092

这里定义了两个监听器：

• PLAINTEXT://kafka:29092：给Docker网络内部服务使用的地址，Kafka容器在这个端口监听内部请求
• PLAINTEXT_HOST://localhost:9092：给宿主机使用的地址，映射到宿主机的9092端口

而你的客户端环境变量设置的是BADDR: kafka:9092——这个端口是宿主机映射的端口，不是Kafka容器内部监听的端口。当客户端尝试连接kafka:9092时，虽然能通过Docker网络找到Kafka容器的IP，但Kafka会把自己的PLAINTEXT_HOST通告地址（localhost:9092）返回给客户端，客户端就会转而尝试连接自己容器的127.0.0.1:9092，自然连接失败。

本地运行正常是因为你直接用localhost:9092访问，对应Kafka的宿主机监听器，宿主机能直接打通这个端口。

解决方案 #

1. 修正客户端的连接地址 #

修改APP的docker-compose.yml中客户端的环境变量，把端口换成Kafka内部监听的29092：

environment:
  BADDR: kafka:29092  # 替换原9092为29092
  CGROUP: test_group
  TOPICS: my-topic

2. 验证Docker网络连通性 #

重启客户端服务后，可以进入容器测试连通性：

# 进入客户端容器
docker exec -it <你的客户端容器名称> /bin/sh
# 测试Kafka内部端口是否可达
telnet kafka 29092
# 或者验证域名解析
ping kafka

如果telnet能成功连接，说明网络和端口配置没问题。

3. 显式配置Kafka监听器（可选） #

为了配置更清晰，可以给Kafka添加显式的监听器配置（默认会继承通告监听器，但显式设置更直观）：

environment:
  # 其他原有配置保持不变
  KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:29092,PLAINTEXT_HOST://0.0.0.0:9092

这个配置让Kafka在容器的所有网卡上监听对应端口，确保Docker内部和宿主机都能访问。

4. 重启服务生效 #

先重启基础设施服务，再重启客户端服务：

# 停止并启动基础设施服务
docker-compose -f <你的基础设施compose文件名> down && docker-compose -f <你的基础设施compose文件名> up -d
# 重启客户端服务
docker-compose -f <你的APP compose文件名> restart client

额外注意点 #

• 你已经正确配置了两个compose文件使用同一kafka_network网络，这部分无需调整
• 如果客户端代码里有硬编码的连接地址，也要同步改成kafka:29092

内容的提问来源于stack exchange，提问作者rustysys-dev