使用CNAME访问Elasticsearch时Rest High Level Client返回403错误排查

开发者阿泽

2026-5-9

问题原因与解决方案

这个问题我之前帮同事排查过，核心是AWS Elasticsearch服务的签名验证机制和Java Rest High Level Client处理CNAME时的Host头行为不匹配，导致签名校验失败。

为什么会出现这个差异？

签名校验的Host头不匹配：
当你用CNAME访问时，Java Rest High Level Client默认会把CNAME域名作为HTTP请求的Host头，并且在生成AWS签名时会包含这个Host值。但AWS ES服务在验证签名时，是基于它自己的真实endpoint域名来校验的——这就导致签名计算用的Host（CNAME）和服务端期望的Host（真实域名）不一致，直接触发403签名不匹配错误。
而curl能正常工作，大概率是因为：要么你用的curl命令是通过AWS CLI转发的（它会自动处理Host头的签名适配），要么你的curl请求在底层解析CNAME后，自动把Host头替换成了真实域名，刚好满足服务端的签名校验要求。
Java客户端的签名逻辑未适配CNAME场景：
Rest High Level Client依赖的AWS SDK默认会用你配置的目标域名（也就是CNAME）生成签名，不会自动解析CNAME到真实域名再进行签名。但直接用真实域名时，签名的Host头和服务端期望的完全一致，所以验证通过。

解决办法

这里有几个可行的方案，按推荐程度排序：

1. 强制客户端使用真实域名作为Host头（最直接）

你可以自定义RestClient的配置，让请求发送到CNAME地址的同时，把Host头设置为ES的真实endpoint域名。这样签名计算时用的Host和服务端期望的一致，就能通过校验。示例代码如下：

import org.apache.http.HttpHost;
import org.apache.http.client.config.RequestConfig;
import org.apache.http.impl.nio.client.HttpAsyncClientBuilder;
import org.elasticsearch.client.RestClient;
import org.elasticsearch.client.RestHighLevelClient;

public class ESClientProvider {
    public static RestHighLevelClient getClient(String cnameEndpoint, String realEsEndpoint) {
        return new RestHighLevelClient(
            RestClient.builder(new HttpHost(cnameEndpoint, 80, "http"))
                .setHttpClientConfigCallback(httpClientBuilder -> 
                    httpClientBuilder.setDefaultRequestConfig(
                        RequestConfig.custom()
                            .setHeader("Host", realEsEndpoint)
                            .build()
                    )
                )
        );
    }
}

2. 利用新版AWS SDK自动处理CNAME解析（推荐长期方案）

如果你使用的是AWS SDK for Java v2，它提供了更智能的CNAME处理能力。你可以结合AWS Signer组件配置客户端，让它自动解析CNAME到真实域名，再基于真实域名生成签名。这种方式更适配AWS生态的各种场景，也能避免硬编码Host头的维护问题。

3. 用curl -v验证Host头（辅助排查）

你可以执行curl -v http://YOUR_CNAME_ENDPOINT/INDEX_NAME/_search，观察输出中的Host:字段。如果显示的是ES真实域名，那就能确认curl确实自动处理了Host头，这也能进一步验证我们的问题判断。

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