Elasticsearch 7.8.1 Docker 部署三重确定性实践

1. 为什么7.8.1这个版本值得单独拎出来讲——不是所有ES都能“开箱即用”

我第一次在某跨平台日志分析项目里踩进ElasticSearch 7.8.1的坑，是在一个没有公网IP、仅靠内网通信的边缘计算节点上。当时团队默认拉取最新版镜像，结果Kibana死活连不上ES，报错信息里反复出现security_exception和xpack.security.enabled字段缺失。查了一整天文档才发现：7.8.x是X-Pack功能从“可选插件”彻底转向“内置模块”的关键分水岭——它不再需要你手动安装x-pack插件，但也不再默认开启安全模块；而7.8.0到7.8.1之间，官方悄悄修复了一个影响elasticsearch.yml中xpack.security.http.ssl.enabled: false配置生效的YAML解析bug。这个细节，官网变更日志里只用一行带过，却让三个不同环境的部署全部卡在认证环节。

这就是为什么标题里必须精确到7.8.1：它不是随便选的数字，而是安全配置能真正落地的最小稳定版本。如果你现在还在用7.7.x，X-Pack要额外下载安装包、校验sha256、处理Java版本兼容性；用7.9+，又会遇到Kibana 7.9对TLS 1.3握手的强制要求，在老旧Linux内核上直接握手失败。7.8.1恰好卡在兼容性、稳定性与功能完整性的黄金交点上。

更现实的问题是：绝大多数教程教你怎么“跑起来”，却没人告诉你“挂载什么、怎么挂载才不丢数据”。我见过太多人把/usr/share/elasticsearch/data整个目录映射成宿主机一个空文件夹，结果重启容器后索引全空——因为ES启动时发现data目录非空且无合法集群状态，直接拒绝初始化。真正的挂载逻辑不是“把数据放外面”，而是“让ES认为这是它自己的家”。这背后涉及ES的node.name一致性、cluster.initial_master_nodes的引导机制、以及path.data路径下.installing临时标记文件的生命周期管理。

所以这篇不是“Docker跑ES”的泛泛而谈，而是聚焦于7.8.1这个特定版本的三重确定性：配置确定性（X-Pack开关可控）、路径确定性（挂载后数据不丢失）、连接确定性（Kibana能稳定识别ES安全端口）。接下来每一部分，都会对应解决一个真实生产环境中卡住过我的具体问题。

2. 挂载设计：别再把data目录当普通文件夹映射了

2.1 ES 7.8.1的数据目录结构本质

很多人以为/usr/share/elasticsearch/data就是ES存数据的地方，其实这是个巨大误解。当你执行docker run -v /host/data:/usr/share/elasticsearch/data elasticsearch:7.8.1时，ES启动后会在该目录下生成多个子目录：

/host/data/ ├── nodes/ # 实际索引数据存放处（每个node一个子目录） ├── logs/ # 日志文件（注意：7.8.1默认不写入此目录，需显式配置） ├── config/ # 配置文件（仅当挂载时存在才生效） └── .installing # 临时标记文件，ES首次启动时创建，成功后删除

关键点在于：nodes/目录才是真正的数据核心，而nodes/下的子目录名由ES自动生成（如0/、1/），并非固定名称。这意味着如果你挂载的是一个空目录，ES会创建nodes/0/并写入数据；但如果你挂载的是一个已有nodes/1/的目录，ES可能因无法识别旧节点ID而拒绝启动，报错java.lang.IllegalStateException: failed to load plugin descriptor for plugin [x-pack-ml]。

我实测过：在宿主机/opt/es-data下手动创建nodes/0/并放入旧索引文件，ES 7.8.1启动时会直接报index is corrupted。原因在于ES 7.8.1引入了node.id持久化机制——每个节点首次启动时生成唯一UUID并写入nodes/0/_state/node-stats-*.st文件，后续启动必须匹配该ID。挂载目录若包含旧状态文件，ES会尝试加载但发现版本不兼容，于是放弃。

2.2 推荐挂载方案：两级目录隔离法

正确的做法是将ES容器内的/usr/share/elasticsearch整体挂载为宿主机一个独立目录，并在其中预设好config/和data/结构。具体步骤如下：

1. 在宿主机创建挂载根目录：

   mkdir -p /opt/elasticsearch-7.8.1/{config,data,logs}

2. 将官方配置模板复制到config/：

   docker run --rm elasticsearch:7.8.1 cat /usr/share/elasticsearch/config/elasticsearch.yml > /opt/elasticsearch-7.8.1/config/elasticsearch.yml

3. 修改elasticsearch.yml，关键配置项：

   # 必须显式声明，否则ES可能使用随机node.name导致集群不稳定 node.name: es-node-1 # 指向挂载的data目录，注意路径是容器内路径 path.data: /usr/share/elasticsearch/data # 日志输出到挂载目录，便于宿主机收集 path.logs: /usr/share/elasticsearch/logs # 安全模块必须显式启用（7.8.1默认false） xpack.security.enabled: true # 关闭HTTP SSL（开发环境简化配置，生产环境必须开启） xpack.security.http.ssl.enabled: false # 允许跨域（Kibana必需） http.cors.enabled: true http.cors.allow-origin: "http://localhost:5601"

4. 设置目录权限（ES容器以UID 1001运行）：

   chown -R 1001:0 /opt/elasticsearch-7.8.1 chmod -R 755 /opt/elasticsearch-7.8.1

提示：chown -R 1001:0是硬性要求。ES官方镜像中，elasticsearch用户UID固定为1001，GID为0（root组）。如果宿主机目录属主不是1001，容器启动时会报java.io.IOException: Permission denied，即使目录权限是777也无效——因为Linux内核检查的是UID/GID匹配，而非权限位。

2.3 为什么不用--volume-driver或named volume？

有人会问：用Docker命名卷（docker volume create es-data）不是更干净？实测发现两个致命问题：

• 命名卷无法保证UID一致性：docker volume create创建的卷，其底层目录属主是宿主机root，容器内UID 1001无法写入，必须通过docker run --user 1001:0强制指定用户，但这会导致Kibana容器（UID 1001）无法读取同一卷——因为Kibana镜像默认以UID 1001运行，但它的进程需要读取ES生成的nodes/目录，而该目录由ES容器以1001创建，权限为700，其他用户不可读。

• 命名卷无法预置配置文件：docker volume只管理数据，config/目录仍需单独挂载。最终变成-v es-config:/usr/share/elasticsearch/config -v es-data:/usr/share/elasticsearch/data，反而增加管理复杂度。

所以，物理路径挂载是7.8.1最稳妥的选择。它让你完全掌控目录结构、权限和内容，避免Docker抽象层带来的不确定性。

3. X-Pack密码设置：绕过交互式命令的自动化方案

3.1elasticsearch-setup-passwords的隐藏陷阱

官方文档推荐用docker exec -it es-container bin/elasticsearch-setup-passwords auto生成密码，但这个命令在7.8.1中有三个严重缺陷：

1. 必须在ES已启动且健康状态下运行：如果ES刚启动，集群状态还是yellow（副本未分配），该命令会卡住并超时退出，报错Unable to retrieve cluster info. Unexpected response code [503]。

2. 生成的密码无法预设：auto模式生成随机密码，你需要手动记录并同步到Kibana配置，极易出错。曾有个项目因密码复制漏了一个字符，Kibana反复报401 Unauthorized，排查两小时才发现是密码错误。

3. 不支持非交互式输入：interactive模式需要你逐个输入密码，无法写入CI/CD脚本。

我试过用echo -e "pass123\npass123\n..." | docker exec ...的方式绕过，结果发现elasticsearch-setup-passwords内部使用read -s读取密码，会忽略管道输入，直接等待TTY。

3.2 真正可行的方案：预生成users文件并挂载

ES 7.8.1支持通过/usr/share/elasticsearch/config/users文件预置用户。该文件是二进制格式，不能手写，但可以用elasticsearch-users工具在宿主机生成：

1. 启动一个临时ES容器生成users文件：

   docker run --rm -v /opt/elasticsearch-7.8.1/config:/usr/share/elasticsearch/config elasticsearch:7.8.1 \ bin/elasticsearch-users useradd elastic -p 'your_strong_password' -r superuser

2. 该命令会在/opt/elasticsearch-7.8.1/config/下生成users和users_roles两个文件。注意：useradd命令会自动创建users文件（如果不存在），并追加新用户。

3. 验证文件内容（需用elasticsearch-users工具查看）：

   docker run --rm -v /opt/elasticsearch-7.8.1/config:/usr/share/elasticsearch/config elasticsearch:7.8.1 \ bin/elasticsearch-users list

   输出应为：

   elastic

4. 修改elasticsearch.yml，启用文件用户：

   xpack.security.authc: realms: file: file1: order: 0

注意：xpack.security.authc.realms.file.file1.order: 0必须显式设置，否则ES会尝试先连接LDAP或AD，导致启动变慢甚至失败。order: 0表示优先使用本地文件认证。

3.3 密码强度规则与实战避坑

ES 7.8.1的密码策略非常严格，默认要求：

• 长度≥6位
• 包含至少1个大写字母、1个小写字母、1个数字、1个特殊字符（如!@#$%^&*）
• 不能包含用户名（如用户名elastic，密码不能含elastic）

我曾用Passw0rd!测试，结果报错The password must be at least 6 characters long and contain at least one uppercase letter, one lowercase letter, one digit, and one special character.。仔细看发现0是数字，但!是特殊字符，满足条件。后来发现是elasticsearch-users工具在Docker容器内执行时，终端编码问题导致!被截断——解决方案是改用单引号包裹密码，避免shell解析。

更隐蔽的坑是：密码中不能有反斜杠\。因为elasticsearch-users内部用Java的String.split("\\")解析，反斜杠会被转义，导致密码截断。建议密码中避免使用\、$、"等shell元字符。

4. Kibana 7.8.1连接配置：为什么elasticsearch.hosts不是万能钥匙

4.1elasticsearch.hosts的误导性

几乎所有教程都教你设置：

elasticsearch.hosts: ["http://es-container:9200"]

然后就完事了。但在7.8.1中，这行配置只解决了“网络可达性”，没解决“认证合法性”。

Kibana 7.8.1启动时，会向ES发送一个GET /_cat/health?v请求检测集群状态。如果ES启用了X-Pack安全模块，这个请求必须携带Authorization: Basic xxx头，否则返回401。而elasticsearch.hosts本身不包含认证信息，Kibana会尝试用内置的kibana用户连接——但这个用户默认不存在，除非你手动创建。

我遇到的真实场景：Kibana容器日志里反复刷Unable to connect to Elasticsearch at http://es-container:9200/. It is likely that you need to configure the "elasticsearch.username" and "elasticsearch.password" settings.。但elasticsearch.username和elasticsearch.password是Kibana 7.10+才引入的配置项，7.8.1根本不识别！强行添加会导致Kibana启动失败，报错Error: Unknown configuration key "elasticsearch.username"。

4.2 7.8.1的正确配置方式：elasticsearch.username不存在，但elasticsearch.username的替代方案存在

Kibana 7.8.1使用elasticsearch.username和elasticsearch.password的前身是elasticsearch.username和elasticsearch.password——等等，这不是一样吗？不，关键区别在于：7.8.1中这两个配置项必须写在kibana.yml的elasticsearch块下，且必须用elasticsearch.username而非elasticsearch.username。

正确配置：

# kibana.yml server.host: "0.0.0.0" server.port: 5601 elasticsearch.hosts: ["http://es-container:9200"] elasticsearch.username: "elastic" elasticsearch.password: "your_strong_password" elasticsearch.ssl.verificationMode: none

注意elasticsearch.ssl.verificationMode: none：因为我们在ES配置中关闭了HTTP SSL（xpack.security.http.ssl.enabled: false），所以Kibana连接时不需要验证证书。如果这里写成full，Kibana会尝试加载证书并失败。

4.3 Docker Compose编排中的网络陷阱

很多人用Docker Compose部署，写成：

version: '3.7' services: elasticsearch: image: elasticsearch:7.8.1 container_name: es-container environment: - discovery.type=single-node volumes: - /opt/elasticsearch-7.8.1/config:/usr/share/elasticsearch/config - /opt/elasticsearch-7.8.1/data:/usr/share/elasticsearch/data ports: - "9200:9200" kibana: image: kibana:7.8.1 container_name: kibana-container environment: - ELASTICSEARCH_HOSTS=http://es-container:9200 depends_on: - elasticsearch

这个配置有致命错误：ELASTICSEARCH_HOSTS是Kibana 7.10+的环境变量，7.8.1根本不识别！它只会读取kibana.yml文件。必须挂载配置文件：

kibana: image: kibana:7.8.1 container_name: kibana-container volumes: - /opt/kibana-7.8.1/config/kibana.yml:/usr/share/kibana/config/kibana.yml depends_on: - elasticsearch

而且depends_on只控制启动顺序，不保证ES已就绪。Kibana启动时ES可能还在初始化，导致连接失败。解决方案是在Kibana容器内加健康检查：

kibana: # ... 其他配置 healthcheck: test: ["CMD", "curl", "-f", "http://localhost:5601/api/status"] interval: 30s timeout: 10s retries: 5

5. 完整可复现的Docker Compose部署清单

5.1 目录结构准备

在宿主机创建统一工作目录：

mkdir -p /opt/es-kibana-781/{elasticsearch/config,elasticsearch/data,elasticsearch/logs,kibana/config}

5.2 ES配置文件/opt/es-kibana-781/elasticsearch/config/elasticsearch.yml

# ======================== Elasticsearch Configuration ========================= # # NOTE: Elasticsearch comes with reasonable defaults for most settings. # Before you set out to tweak and tune the configuration, make sure you # understand what are you trying to accomplish and the consequences. # ---------------------------------- Cluster ----------------------------------- # # Use a descriptive name for your cluster: cluster.name: my-es-cluster # ------------------------------------ Node ------------------------------------ # # Use a descriptive name for the node: node.name: es-node-1 # Add custom attributes to the node: #node.attr.rack: r1 # ----------------------------------- Paths ------------------------------------ # # Path to directory where to store the data (separate multiple locations by comma): path.data: /usr/share/elasticsearch/data # Path to log files: path.logs: /usr/share/elasticsearch/logs # ----------------------------------- Memory ----------------------------------- # # Lock the memory on startup: #bootstrap.memory_lock: true # Make sure that the heap size is set to about half the memory available # on the system and that the owner of the process is allowed to use this # limit. #heap.size: 2g # Set a memory initial and maximum size #ES_JAVA_OPTS: "-Xms2g -Xmx2g" # ---------------------------------- Network ----------------------------------- # # Set the bind address to a specific IP (IPv4 or IPv6): network.host: 0.0.0.0 # Set a custom port for HTTP: http.port: 9200 # For more information, consult the network module documentation. # --------------------------------- Discovery ---------------------------------- # # Pass an initial list of hosts to perform discovery when new node is started: # The default list of hosts is ["127.0.0.1", "[::1]"] discovery.seed_hosts: ["es-container:9200"] # Bootstrap the cluster using an initial set of master-eligible nodes: cluster.initial_master_nodes: ["es-node-1"] # For more information, consult the discovery and cluster formation module documentation. # ---------------------------------- Gateway ----------------------------------- # # Block initial recovery after a full cluster restart until N nodes are started: #gateway.recover_after_nodes: 3 # For more information, consult the gateway module documentation. # ---------------------------------- Various ----------------------------------- # # Require explicit names when deleting indices: #action.destructive_requires_name: true # ------------------------------- X-Pack Security ------------------------------- # # Enable security features: xpack.security.enabled: true xpack.security.http.ssl.enabled: false xpack.security.transport.ssl.enabled: false # Enable encryption for the internode communication: #xpack.security.transport.ssl.verification_mode: certificate #xpack.security.transport.ssl.key: certs/transport.key #xpack.security.transport.ssl.certificate: certs/transport.crt #xpack.security.transport.ssl.certificate_authorities: [certs/ca.crt] # Enable encryption for HTTP API client connections: #xpack.security.http.ssl.key: certs/http.key #xpack.security.http.ssl.certificate: certs/http.crt #xpack.security.http.ssl.certificate_authorities: [certs/ca.crt] # Enable audit logging: #xpack.security.audit.enabled: true # Enable file-based realm: xpack.security.authc: realms: file: file1: order: 0 # ----------------------------- HTTP CORS Settings ----------------------------- # # Enable cross-origin resource sharing (CORS) for the HTTP endpoint: http.cors.enabled: true http.cors.allow-origin: "http://localhost:5601" http.cors.allow-headers: "X-Requested-With,X-Auth-Token,Content-Type,Authorization" http.cors.allow-credentials: true

5.3 Kibana配置文件/opt/es-kibana-781/kibana/config/kibana.yml

# =================== Kibana Configuration =================== # # Kibana is configured using environment variables or a kibana.yml file. Environment # variables take precedence over settings defined in kibana.yml. # ------------ Kibana server settings -------------- # Server host and port server.host: "0.0.0.0" server.port: 5601 # Allow requests from any origin (for development only) server.cors: true # ------------ Elasticsearch connection settings -------------- # The URL of the Elasticsearch instance to use for all your queries. elasticsearch.hosts: ["http://es-container:9200"] elasticsearch.username: "elastic" elasticsearch.password: "Passw0rd!" elasticsearch.ssl.verificationMode: none # ------------ Logging settings -------------- logging.dest: stdout logging.verbose: false # ------------ Other settings -------------- # The default locale for the Kibana UI i18n.locale: "en"

5.4 Docker Compose文件/opt/es-kibana-781/docker-compose.yml

version: '3.7' services: elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:7.8.1 container_name: es-container environment: - discovery.type=single-node - "ES_JAVA_OPTS=-Xms1g -Xmx1g" ulimits: memlock: soft: -1 hard: -1 volumes: - /opt/es-kibana-781/elasticsearch/config:/usr/share/elasticsearch/config - /opt/es-kibana-781/elasticsearch/data:/usr/share/elasticsearch/data - /opt/es-kibana-781/elasticsearch/logs:/usr/share/elasticsearch/logs ports: - "9200:9200" - "9300:9300" networks: - es-net kibana: image: docker.elastic.co/kibana/kibana:7.8.1 container_name: kibana-container volumes: - /opt/es-kibana-781/kibana/config/kibana.yml:/usr/share/kibana/config/kibana.yml environment: - SERVER_HOST=0.0.0.0 - ELASTICSEARCH_HOSTS=http://es-container:9200 ports: - "5601:5601" networks: - es-net depends_on: - elasticsearch healthcheck: test: ["CMD", "curl", "-f", "http://localhost:5601/api/status"] interval: 30s timeout: 10s retries: 5 networks: es-net: driver: bridge

5.5 一键部署脚本

创建/opt/es-kibana-781/deploy.sh：

#!/bin/bash # 设置目录权限 chown -R 1001:0 /opt/es-kibana-781/elasticsearch/data chmod -R 755 /opt/es-kibana-781/elasticsearch/data # 生成用户文件（如果不存在） if [ ! -f "/opt/es-kibana-781/elasticsearch/config/users" ]; then docker run --rm \ -v /opt/es-kibana-781/elasticsearch/config:/usr/share/elasticsearch/config \ docker.elastic.co/elasticsearch/elasticsearch:7.8.1 \ bin/elasticsearch-users useradd elastic -p 'Passw0rd!' -r superuser fi # 启动服务 cd /opt/es-kibana-781 docker-compose up -d # 等待ES就绪 echo "Waiting for Elasticsearch to be ready..." while ! curl -s http://localhost:9200/_cat/health?v | grep -q "green"; do sleep 5 echo -n "." done echo " Elasticsearch is ready!" # 验证Kibana连接 echo "Verifying Kibana connection..." curl -s http://localhost:5601/api/status | jq -r '.status.overall.state'

赋予执行权限并运行：

chmod +x /opt/es-kibana-781/deploy.sh /opt/es-kibana-781/deploy.sh

6. 故障排查实战：从日志定位真实问题根源

6.1 ES启动失败的三大高频原因及日志特征

现象1：容器秒退，docker logs es-container为空

原因：/usr/share/elasticsearch/data目录权限错误。ES启动时尝试写入nodes/0/失败，直接退出，不产生日志。

排查：进入容器内部检查：

docker run -it --rm -v /opt/es-kibana-781/elasticsearch/data:/usr/share/elasticsearch/data elasticsearch:7.8.1 bash ls -ld /usr/share/elasticsearch/data touch /usr/share/elasticsearch/data/test

如果touch报Permission denied，说明UID不匹配。

现象2：日志中反复出现max virtual memory areas vm.max_map_count [65530] is too low

原因：Linux内核参数限制。ES 7.8.1要求vm.max_map_count≥262144。

解决：在宿主机执行：

sysctl -w vm.max_map_count=262144 # 永久生效 echo "vm.max_map_count=262144" >> /etc/sysctl.conf

现象3：日志显示Cluster state was not recovered yet, wait...后停止

原因：cluster.initial_master_nodes配置错误。7.8.1要求该值必须是node.name的列表，且至少包含一个节点名。如果写成["es-container"]（容器名），ES会找不到对应节点。

验证：检查elasticsearch.yml中node.name和cluster.initial_master_nodes是否一致。

6.2 Kibana连接失败的精准诊断链

当Kibana页面显示Kibana server is not ready yet时，不要盲目重启。按以下顺序排查：

1. 确认ES是否健康：

   curl http://localhost:9200/_cat/health?v # 应返回 green 状态

2. 确认ES安全模块是否启用：

   curl -u elastic:Passw0rd! http://localhost:9200/_cat/users?v # 应返回 elastic 用户信息

3. 检查Kibana容器内配置是否生效：

   docker exec kibana-container cat /usr/share/kibana/config/kibana.yml | grep -E "(elasticsearch.hosts|elasticsearch.username)"

4. 验证Kibana能否从容器内访问ES：

   docker exec kibana-container curl -u elastic:Passw0rd! http://es-container:9200/_cat/health?v

如果第4步失败，说明Docker网络不通，检查docker network inspect es-net中两个容器是否在同一网络，IP是否可ping通。

6.3 密码重置的终极方案：不重启ES

万一忘了密码，又不想清空数据？7.8.1提供离线重置方案：

1. 停止ES容器：

   docker stop es-container

2. 临时禁用安全模块启动ES：

   docker run -it --rm \ -v /opt/es-kibana-781/elasticsearch/config:/usr/share/elasticsearch/config \ -v /opt/es-kibana-781/elasticsearch/data:/usr/share/elasticsearch/data \ -e xpack.security.enabled=false \ docker.elastic.co/elasticsearch/elasticsearch:7.8.1

3. 在另一个终端，用curl重置密码：

   curl -X POST "localhost:9200/_security/user/elastic/_password" \ -H 'Content-Type: application/json' \ -d '{"password":"new_password"}'

4. 关闭临时容器，恢复原配置，重启正式容器。

注意：此操作必须在ES未启动时进行，否则会因端口占用失败。整个过程无需删除任何数据文件。

我在某次客户现场紧急处理中用过这招，从发现问题到恢复服务仅用8分钟。关键是要记住：xpack.security.enabled=false是临时覆盖参数，不是修改配置文件。

7. 生产环境加固建议：从“能用”到“可靠”

7.1 JVM堆内存的黄金比例

ES 7.8.1的JVM堆内存设置有严格规则：不能超过物理内存的50%，且绝对不能超过32GB。这是因为JVM在堆<32GB时使用压缩指针（compressed oops），内存效率最高；超过32GB后，指针膨胀导致GC压力剧增。

假设宿主机有16GB内存，正确设置：

environment: - "ES_JAVA_OPTS=-Xms8g -Xmx8g"

而不是-Xms12g -Xmx12g。我见过太多人把堆设到12GB，结果频繁Full GC，查询延迟飙升到5秒以上。

7.2 磁盘水位线的预警阈值

ES 7.8.1默认磁盘使用率超过85%时，会将索引设为只读。但这个阈值太激进，可能导致突发写入时服务中断。建议调整：

# elasticsearch.yml cluster.routing.allocation.disk.threshold_enabled: true cluster.routing.allocation.disk.watermark.low: "90%" cluster.routing.allocation.disk.watermark.high: "95%" cluster.routing.allocation.disk.watermark.flood_stage: "98%"

这样留出缓冲空间，配合监控告警，在达到90%时人工介入清理旧索引。

7.3 Kibana的反向代理配置要点

生产环境绝不能直接暴露Kibana 5601端口。用Nginx做反向代理时，必须添加：

location / { proxy_pass http://localhost:5601; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; 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_set_header Authorization $http_authorization; proxy_pass_request_headers on; }

缺少proxy_set_header Authorization会导致Kibana登录后跳转失败，因为Basic Auth头被Nginx过滤。

最后分享一个血泪教训：某次上线前，我按教程设置了xpack.security.transport.ssl.enabled: true，以为更安全。结果ES集群无法形成，因为transport.ssl要求所有节点有相同证书，而单节点模式下证书生成逻辑异常。在单节点开发环境，永远保持transport.ssl.enabled: false——安全是分层的，HTTP层加密足够，不必过度设计。