Elasticsearch默认使用9200端口提供HTTP接口，很多团队在测试或内部环境会直接开放该端口。一旦将9200端口直接暴露到办公网甚至公网，任何人都可以读取索引、删除数据或修改映射。即便只在内网，如果没有细粒度权限控制，误操作风险也很高。Nginx作为成熟的反向代理和负载均衡器，可以放在Elasticsearch前面统一接收客户端请求，再转发到后端的ES节点。这样做不仅能隐藏集群拓扑、限制允许的HTTP方法，还可以完成TLS终止、基础认证和跨域响应头处理。
一、直接暴露9200端口的风险与反向代理的价值
Elasticsearch默认监听在所有网卡的9200端口上，绑定地址通常是0.0.0.0。较早版本甚至没有默认启用安全认证，任何能访问该端口的客户端都可以执行创建索引、写入文档、删除数据等操作。即便启用了X-Pack安全模块，节点自身的TLS和账号体系仍然无法完全替代网络边界防护。内网中如果有一台主机被攻破，攻击者可以很轻易地利用ES的REST API遍历索引名称、导出敏感数据或直接关闭集群。
引入Nginx之后，访问链路变为客户端到Nginx，再由Nginx转发到Elasticsearch节点。Nginx成为唯一入口，后端节点的真实IP地址和端口可以完全从客户端视野中隐藏。与此同时，代理层还能完成统一的TLS终止，避免在每个ES节点上重复配置证书。对于集群规模较大的场景，这种方式能显著降低证书更新和多节点配置漂移带来的运维成本。
反向代理对集群本身也有实际收益。Nginx的upstream健康检查可以把暂时不可用的节点自动摘除，客户端请求不会继续打到故障节点上。长连接复用减少了Elasticsearch节点频繁建立HTTP连接的开销，在高并发查询场景下尤其明显。配合限流和请求日志，还能对异常访问进行追踪和拦截，提升整体可控性。
二、HTTP反向代理配置与关键参数解析
下面是最基础的HTTP反向代理配置，先定义一个upstream组，包含三个Elasticsearch数据节点，并使用least_conn策略。Elasticsearch本身具备协调节点机制，客户端的查询请求无论落到哪个节点，该节点都会自动路由到相关分片。因此Nginx层不必关心分片分布，只需要保证请求被均匀地分配到可用节点即可。
upstream elasticsearch {
zone elasticsearch 64k;
least_conn;
server 192.168.10.11:9200 max_fails=3 fail_timeout=30s;
server 192.168.10.12:9200 max_fails=3 fail_timeout=30s;
server 192.168.10.13:9200 max_fails=3 fail_timeout=30s;
keepalive 16;
}
server {
listen 80;
server_name es.internal.ipipp.com;
location / {
proxy_pass http://elasticsearch;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_buffering off;
proxy_request_buffering off;
}
}这里有两个参数需要特别说明。proxy_http_version 1.1和proxy_set_header Connection ""通常一起出现。Nginx默认使用HTTP/1.0与上游通信，而Elasticsearch的HTTP接口基于HTTP/1.1，长连接复用能够减少每次请求的TCP握手和慢启动开销。如果不设置这两行，Nginx与ES之间会退化为短连接，高并发时容易出现端口耗尽或响应延迟增加。
请求头中的Host字段默认会被Nginx改成upstream名称，这可能导致Elasticsearch返回的某些URL出现异常，因此需要手动设置proxy_set_header Host $host。同理，X-Real-IP和X-Forwarded-For用于把真实客户端IP传给Elasticsearch，便于审计日志记录来源。X-Forwarded-Proto则告诉ES原始请求是HTTP还是HTTPS，在Kibana生成绝对路径链接时会用到。关闭proxy_buffering可以让大结果集以流式方式及时返回，避免Nginx先缓存完整响应再发送造成的首字节延迟。
如果后端只有一个节点，也可以不使用upstream，直接在proxy_pass后写死地址。但生产环境通常至少两个节点，使用upstream可以达到故障转移和基础负载均衡的目的。建议在upstream中显式设置max_fails和fail_timeout，避免某个节点抖动时频繁被摘除恢复。
三、启用TLS终止与认证加固
生产环境不建议继续使用明文HTTP。Nginx可以监听443端口并配置TLS证书，外部客户端通过HTTPS访问，内部Nginx到Elasticsearch仍走HTTP，只要内网网络可信即可。这样既简化了ES节点的证书管理，又保证了外部传输安全。对应的配置如下所示。
server {
listen 443 ssl;
server_name es.internal.ipipp.com;
ssl_certificate /etc/nginx/certs/es.crt;
ssl_certificate_key /etc/nginx/certs/es.key;
ssl_protocols TLSv1.2 TLSv1.3;
location / {
proxy_pass http://elasticsearch;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Authorization $http_authorization;
proxy_buffering off;
proxy_request_buffering off;
}
}如果Elasticsearch已经启用了原生安全功能，客户端会携带Basic或者Bearer Token形式的Authorization请求头。默认情况下Nginx会转发大多数请求头，但显式写上proxy_set_header Authorization $http_authorization可以防止某些编译版本或自定义配置意外丢弃该头。否则用户即使输入了正确的账号密码，ES仍会返回401未认证错误。
如果Elasticsearch没有启用安全模块，可以在Nginx层使用auth_basic和auth_basic_user_file做临时的基础认证。不过需要注意，基础认证的用户名密码只是Base64编码，并非加密，必须配合TLS使用，否则很容易被网络嗅探获取。更稳妥的做法是升级ES并启用原生安全，通过角色和API密钥进行细粒度授权。
还可以在Nginx中限制HTTP方法，比如只允许GET、POST、PUT、HEAD，直接拒绝DELETE请求，降低误删索引的风险。配合allow和deny指令可以实现IP白名单，只允许指定的办公网段或服务器访问。对于写入频繁的场景，使用limit_req_zone限制请求速率，可以防止单个客户端打满ES资源。访问日志建议开启，记录请求方法、路径、状态码和来源IP，方便出现问题时回溯审计。
ElasticsearchNginx反向代理集群负载均衡修改时间：2026-09-20 20:51:51