Elasticsearch REST 客户端报不是 HTTP 端口：先核对协议与监听器

使用 Elasticsearch 7.3 Java REST 客户端时，出现过这样的异常：

org.apache.http.ParseException:
Not a valid protocol version: This is not an HTTP port

它说明 HTTP 解析器没有读到合法的 HTTP 响应。应该核对连接的是哪个监听器，而不是直接修改业务查询。

REST 客户端需要 HTTP(S) 接口

RestHighLevelClient 基于 REST 协议，不能连接 Elasticsearch 的节点 Transport 接口。官方 7.3 示例使用 http 和 9200：

try (RestHighLevelClient client = new RestHighLevelClient(
        RestClient.builder(
            new HttpHost("localhost", 9200, "http")
        ))) {
    // 在这里进行与项目版本匹配的 REST 调用
}

相关类分别来自 Elasticsearch REST 客户端和 Apache HTTP 库。示例只说明初始化和资源关闭，不包含认证或生产 TLS 配置。ES 7.3 REST 客户端初始化

9200 常用于 HTTP，9300 常用于 Transport，但部署可以更改端口，也可能经过容器映射或反向代理。数字不是协议本身。

怎样确认目标地址

先核对客户端种类和配置里的 scheme、主机、端口，再对照 ES 监听配置、容器映射与代理上游。仅对自己管理、已确认的本地 HTTP 监听器，可用只读请求查看响应：

curl --include --max-time 5 http://127.0.0.1:9200/

如果实际使用 HTTPS，就应匹配正确协议、信任链和认证方式，不要用关闭证书校验的办法掩盖错误。排查代理返回时也要避免把含认证信息的日志公开。

一次端口修改不足以证明根因

当年的短记写过把 9200 换成 9300 后恢复，但未保存实际监听与代理关系。不能据此推广成“REST 客户端应该连 9300”，也无法确定当时是否还改变了其他条件。

可复用的结论是：协议、目标监听器和转发关系必须一致。先确认请求到达哪里，再处理认证、查询或客户端兼容问题。