这是 Kafka 客户端连接机制的一个典型陷阱，你遇到的现象可以通过 Kafka bootstrap server 的连接策略和 broker 的 advertised.listeners 配置来精确解释。
🎯 问题描述简化
✅ 使用顺序为：
192.168.22.22:9092,192.168.22.23:9092,172.21.16.147:9092 ✅ 可连接❌ 使用顺序为：
172.21.16.147:9092,192.168.22.22:9092,192.168.22.23:9092 ❌ 连接失败
📌 Kafka 客户端连接机制核心逻辑
Kafka 的 bootstrap.servers 是用来初始化连接的地址列表，连接流程如下：
客户端尝试按顺序连接
bootstrap.servers中的地址；一旦连接上某个 broker，它会通过
Metadata请求获取集群中其他 broker 的地址（这些地址由advertised.listeners决定）；客户端将使用这些地址与集群中其他 broker 通信。
✅ 为什么第一种地址顺序可以连接成功？
情况：
bootstrap.servers=192.168.22.22,192.168.22.23,172.21.16.147
前两个地址虽然无效，但 Kafka 客户端最终尝试到了
172.21.16.147:9092，成功连接；这个 broker 返回的元数据中的其他 broker 地址是：
192.168.22.22:9092, 192.168.22.23:9092, 172.21.16.147:9092即使前两个地址在逻辑上不存在，AdminClient 没有立即使用它们，测试连接未失败；
或者 AdminClient 的某些测试操作并不强制访问所有节点，只要元数据能正常返回就视为成功。
❌ 为什么地址顺序变了就连接失败？
bootstrap.servers=172.21.16.147,192.168.22.22,192.168.22.23
客户端首次连接的是
172.21.16.147（通的）；然而该 broker 的
advertised.listeners是192.168.22.22:9092或192.168.22.23:9092；客户端在获取到集群元数据后，尝试连接这些地址；
连接失败（因为这些地址根本无 broker）；
某些 API（特别是
AdminClient.describeCluster()）要求能访问至少一个 controller 节点；如果该 controller 地址解析为
192.168.22.22:9092，连接不上 → 抛出TimeoutException。
🔍 结论总结
| 顺序 | 是否成功 | 原因 |
|---|---|---|
192.168.22.22,...,172.21.16.147 |
✅ | 尽管前两个失败，但最后一个能连接，且不会触发必须访问其他节点的逻辑 |
172.21.16.147,...,192.168.22.23 |
❌ | 虽然连上第一个节点，但返回的元数据中 broker 地址不可访问，测试逻辑失败 |
✅ 正确配置方式建议
1. 修改每个 Kafka broker 的 server.properties 配置文件：
advertised.listeners=PLAINTEXT://172.21.16.147:9092
不要写成虚假的 IP（如 192.168.22.22），否则客户端通过元数据拿到的地址就是无效的。
2. 优化 bootstrap.servers：
确保只有能访问的实际地址：
bootstrap.servers=172.21.16.147:9092
如你提供 server.properties 配置，我可以帮你检查并建议修改。是否需要？