同一Docker Compose栈内Kafka JS客户端无法连接Kafka容器报ENOTFOUND问题

getaddrinfo ENOTFOUND kafka本质是运行KafkaJS消费者的环境，无法通过kafka这个域名解析到Kafka容器的网络地址，结合现有配置，问题来自两个明确的配置缺陷：

• 自定义网络未实际生效：你虽然在compose文件末尾定义了桥接网络kafkanet，但没有在各服务的配置块中通过networks字段显式将服务挂载到该网络下。Docker Compose不会自动将服务接入用户手动定义的非默认网络，跨网络的容器无法通过服务名完成DNS解析。这也是你手动给Kafka加hostname: kafka也没用的原因——hostname仅用于容器内部的主机名识别，不会注册到Docker的内部DNS，Docker DNS仅对同一网络内的服务名、容器名提供解析能力。
• 连接地址和运行环境不匹配：你用外部客户端通过localhost:29092能正常连接Kafka，是因为该端口做了宿主机映射，走的是宿主机网络栈；而kafka这个服务名仅在Docker容器网络内部可被解析，宿主机本身的DNS无法识别该域名。如果此前你直接在宿主机上运行消费者脚本，哪怕网络配置正确，也会触发ENOTFOUND报错。

1. 完成自定义网络的全量挂载
   保留compose文件末尾的自定义网络定义：

   networks:
     kafkanet:
       driver: bridge
   

   对所有需要互相通信的服务，在其配置块下新增networks字段，将服务挂载到kafkanet网络下，涉及的服务包括：zookeeper、kafka、kafka-rest-proxy、kafka-manager、logstash、visual-app。
   示例（kafka服务的修改片段）：

   kafka:
     image: confluentinc/cp-kafka:5.4.1
     container_name: kafka
     # 原有配置（端口映射、环境变量、健康检查）全部保留
     networks:  # 新增挂载配置
       - kafkanet
   

2. 匹配消费者的连接地址和运行环境
   • 若消费者运行在visual-app容器内部：所有服务接入kafkanet后，保持现有连接配置host = 'kafka:9092'即可，该地址对应Kafka的内部监听器，仅同网络容器可访问。
   • 若消费者直接运行在宿主机上：需将broker地址替换为宿主机映射地址localhost:29092，和外部客户端的连接逻辑保持一致，不能使用容器内部的服务名。
3. 优化启动依赖避免偶发故障
   现有visual-app的depends_on配置仅等待Kafka容器进程启动，不会等待Kafka服务完全就绪。可以结合已配置的Kafka健康检查，将依赖条件调整为服务健康状态后再启动消费者，避免因启动顺序过早导致的解析失败：

   visual-app:
     container_name: visual-app
     # 原有配置（构建路径、卷挂载、端口映射）全部保留
     depends_on:
       kafka:
         condition: service_healthy
     networks:
       - kafkanet
   

修改完成后，先执行docker-compose down清理旧容器和关联的网络资源，再重新启动所有服务。启动完成后，进入visual-app容器执行ping kafka，若能正常返回Kafka容器的IP地址，说明DNS解析已正常，再运行消费者脚本即可连接成功。

内容的提问来源于stack exchange，提问作者Morgy