Kafka报错“No security protocol defined for listener PLAINTEXT://:TCP”求助

这个报错完全是监听器格式配置错误导致的——你说得没错，PLAINTEXT已经指定了安全协议，后面不该再加:TCP，正确的监听器格式应该是类似PLAINTEXT://0.0.0.0:9092（绑定所有网卡+端口）或者PLAINTEXT://localhost:9092这种。针对wurstmeister/kafka镜像，咱们一步步找配置来源：

1. 先查Docker环境变量（最核心的配置入口） #

wurstmeister/kafka主要靠环境变量生成最终的server.properties，所以先看你的启动配置（比如docker-compose.yml或者docker run命令）里的这两个关键变量：

• KAFKA_LISTENERS：Kafka监听的地址
• KAFKA_ADVERTISED_LISTENERS：对外公告的地址
  检查这两个变量的值是不是写成了PLAINTEXT://:TCP这种错误格式，比如有没有手滑多写了:TCP，或者端口号被误写成了TCP。

2. 排查是否挂载了自定义的server.properties #

如果你在启动时通过Docker卷挂载了本地的server.properties到容器内的/opt/kafka/config/server.properties，那直接打开本地的这个配置文件，搜索listeners和advertised.listeners配置项，看是不是里面的格式写错了。这种情况下，环境变量的配置会被挂载的文件覆盖，所以得优先检查这个。

3. 清理Docker缓存，排除旧配置残留 #

你提到之前正常运行，后来因为Docker版本和缓存管理出问题不确定配置何时变更，那可以彻底清理相关缓存和容器：

• 先停止并删除容器和关联卷：docker-compose down -v（如果用docker-compose）或者docker rm -v <kafka-container-id>
• 重新拉取最新的wurstmeister/kafka镜像：docker pull wurstmeister/kafka
• 再重新启动容器，看是不是缓存的旧配置导致的问题。

4. 查看容器内最终生效的server.properties #

如果容器能临时启动（哪怕报错），可以进入容器查看实际生效的配置文件：

docker exec -it <kafka-container-name> cat /opt/kafka/config/server.properties

搜索listeners字段，看看实际生成的配置是什么样的——这能帮你确定是环境变量生成的错误配置，还是挂载的文件有问题。

5. 检查环境变量拼写错误 #

有时候可能是变量名拼写错了，比如把KAFKA_LISTENERS写成了KAFKA_LISTENER（少了个s），或者KAFKA_ADVERTISED_LISTENERS拼错，导致Kafka用了默认的错误配置。仔细核对变量名的拼写。

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