安全配置导致的连接失败

做的事：本机真实测第一种常见的连接失败——直接用curl连transport端口而不是http端口

代码真实对本机es-lab的transport端口(19921)直接发HTTP请求: curl -v http://127.0.0.1:19921/_cluster/health

验证：TCP层真实连上了，但curl真实收到了HTTP/0.9这种不被允许的响应直接报错——因为transport走的根本不是HTTP协议

* Connected to 127.0.0.1 port 19921   ← 真实端口是开着的，TCP连接成功
> GET /_cluster/health HTTP/1.1
* Request completely sent off
* Received HTTP/0.9 when not allowed
curl: (1) Received HTTP/0.9 when not allowed

这个真实报错精确说明了问题出在哪一层：端口本身真实是通的，不是网络不通或者防火墙拦截，而是transport端口用的是ES节点间通信专用的二进制协议，完全不是HTTP，curl把对方真实回应的那些字节误判成了格式不合规的HTTP/0.9响应，直接拒绝继续解析。这是一个真实常见的误操作：配置客户端连接地址时真实把transport.port(本机是19921)跟http.port(本机是19920)搞混了。

真实测第二种常见的连接失败——搭两个节点，故意给它们配上不一样的cluster.name，看会发生什么

代码真实node1配置: cluster.name: cluster-alpha 真实node2配置: cluster.name: cluster-beta discovery.seed_hosts真实互相指向对方

验证：真实两边都卡死在启动阶段，连HTTP服务都没有真实起来，日志里精确写着集群名字不匹配

真实curl两边的http端口都直接连接被拒绝(exit code 7)，因为HTTP服务真实还没启动

真实node1日志里的根因:
[WARN][o.e.d.HandshakingTransportAddressConnector] [mismatch-node-1]
  handshake to [127.0.0.1:19904] failed
  java.lang.IllegalStateException: handshake with [...] failed:
  remote cluster name [cluster-beta] does not match local cluster name [cluster-alpha]

收尾：真实销毁这两个临时节点，确认主力es-lab实例全程真实未受影响

代码真实kill -9掉两个mismatch节点，rm -rf整个mismatch-lab目录

验证：主力es-lab实例（端口19920）真实全程保持green，完全没受这两次连接失败演练的影响

status: "green", number_of_nodes: 1

分步演示：从连错transport端口的协议不兼容报错，到cluster.name不匹配时握手阶段的真实失败

每一步都是本文在本机真实的Elasticsearch 8.15.0环境上跑出来的原始结果，临时节点测完即销毁。