一、集群里的 HTTPS 不只是“单机搬过去”¶

原笔记在完成单机 HTTPS 之后，继续讲了“网站集群 HTTPS 配置”，并明确给出了两类思路：

全部进行加密
部分进行加密

这说明集群环境下的 HTTPS，不只是把单机 443 配置复制一遍，而是要先想清楚：

用户到 LB 是否加密
LB 到 Web 是否也继续加密

这两种选择会直接影响：

配置复杂度
性能开销
抓包时看到的是明文还是 TLS

二、什么是“全部加密”¶

原笔记对全链路加密的理解是：

用户 -> LB：HTTPS
LB -> Web：也是 HTTPS

也就是说，从客户端一直到后端 Web，请求始终保持加密状态。

这种方案的优点在于：

链路更完整
LB 后面的网络流量也不会以明文形式传输

但它也意味着：

Web 节点也必须部署证书
LB 与 Web 间的代理地址也要走 https://

三、全链路加密时 Web 端怎么配置¶

原笔记先在 Web 主机上准备证书目录：

mkdir -p /etc/nginx/ssl_keys/
unzip 11654958_www.harbor-local.cn_nginx.zip -d /etc/nginx/ssl_keys/

然后配置 HTTPS 站点：

server {
  listen 443 ssl;
  server_name ssl.harbor-local.cn;
  root /app/code/ssl;

  ssl_certificate /etc/nginx/ssl_keys/www.harbor-local.cn.pem;
  ssl_certificate_key /etc/nginx/ssl_keys/www.harbor-local.cn.key;

  error_log /var/log/nginx/ssl-error.log notice;
  access_log /var/log/nginx/ssl-access.log main;

  location / {
    index index.html;
  }
}

这一步和单机 HTTPS 基本一致，只不过现在它是作为后端 Web 节点存在。

四、全链路加密时 LB 端怎么配置¶

原笔记接着把证书也同步到了 LB 主机：

scp -r ssl_keys/ 192.168.1.21:`pwd`

LB 配置的关键部分如下：

upstream ssl_pools {
  server 192.168.1.20:443;
}

server {
  listen 80;
  server_name ssl.oldboylinux.cn;
  rewrite ^(.*)$ https://ssl.harbor-local.cn$1 permanent;
}

server {
  listen 443 ssl;
  server_name ssl.oldboylinux.cn;
  ssl_certificate /etc/nginx/ssl_keys/www.harbor-local.cn.pem;
  ssl_certificate_key /etc/nginx/ssl_keys/www.harbor-local.cn.key;

  location / {
    proxy_pass https://ssl_pools;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

这份配置最关键的地方在于：

upstream 指向的是后端 443
proxy_pass 用的是 https://ssl_pools

也就是说，LB 到 Web 继续走加密通道。

五、什么是“部分加密”¶

原笔记的第二种思路是“部分加密”，可以理解为：

用户到 LB：HTTPS
LB 到 Web：HTTP

这意味着：

对外访问仍然是安全的
但 LB 和后端 Web 内部链路不一定再加密

这种方案通常更省资源，配置也更简单，但前提是：

LB 与 Web 之间的网络环境本身可信

六、部分加密时 Web 和 LB 的区别在哪里¶

原笔记中，部分加密的 Web 配置就回到了普通 HTTP 站点：

server {
  listen 80;
  server_name ssl.harbor-local.cn;
  root /app/code/ssl;

  error_log /var/log/nginx/ssl-error.log notice;
  access_log /var/log/nginx/ssl-access.log main;

  location / {
    index index.html;
  }
}

而 LB 上依然负责对外提供 HTTPS：

listen 443 ssl
证书仍在 LB 上
对外用户访问仍是 HTTPS

从架构上看，区别就在于：

全链路加密：LB 到 Web 用 https
部分加密：LB 到 Web 用普通 http

原笔记在这一节里虽然示例配置复用了前面的结构，但核心思路就是这个分层差异。

七、如何在 LB 上启用 HTTP/2¶

原笔记还补充了一个很实用的点：

默认情况下，前端访问通常是 HTTP/1.1
如果希望启用 HTTP/2，需要在 LB 的 HTTPS 监听中增加对应标记

示例写法：

listen 443 ssl https;

原笔记说明：

不加相关标记时默认还是 1.1
开启后可以让前端访问具备 HTTP/2 能力

对实际部署来说，这一步通常仍然发生在最前端 LB 上，因为：

客户端是直接连 LB 的
HTTP/2 协议协商也首先发生在这里

八、抓包能帮助区分哪种架构¶

原笔记在全加密和部分加密两节都建议做访问测试并抓包。
其意义就在于：

可以看到流量是否经过 LB
也可以进一步区分 LB 后面的链路是 HTTPS 还是 HTTP

因此，抓包不仅是排障手段，也是理解“全链路加密”和“部分加密”差别的非常直观的方法。

九、小结¶

集群 HTTPS 部署最重要的不是背配置，而是先决定加密边界放在哪里：

如果追求端到端加密，可选全链路加密
如果更强调内部网络效率，可选部分加密

而前端 LB 通常承担三件事：

对外提供证书
统一把 HTTP 跳到 HTTPS
在需要时开启 HTTP/2

把这三层关系理顺，集群 HTTPS 的配置思路就会清晰很多。

Nginx集群HTTPS部署：全链路加密、部分加密与HTTP2配置