ssl卸载本质是将https加解密与tls握手交由nginx处理，后端仅接收明文http请求，从而降低后端cpu负载、统一证书管理并提升安全策略集中度。
SSL 卸载在 Nginx 负载均衡架构中，本质是把 HTTPS 的加解密、握手协商等高开销操作全部交给 Nginx 层完成，后端服务器只处理明文 HTTP 请求。这能显著降低后端 CPU 占用，尤其对 Java、Python 或 Node.js 等语言编写的业务服务效果明显——它们本身不擅长密集型密码运算。
为什么要在负载均衡层做 SSL 卸载
后端服务器每处理一个 HTTPS 请求，都要执行 TLS 握手、密钥交换、对称加解密，这些操作消耗大量 CPU 周期。当 QPS 达到数千甚至上万时，CPU 往往成为瓶颈，而非业务逻辑或数据库。
- 单台 Nginx 实例可轻松支撑数万并发 TLS 连接（依赖合理调优），而同等配置的 Spring Boot 应用可能在 2000 并发时 CPU 就接近 100%
- 证书统一由 Nginx 管理，避免在每台后端机器上重复部署、轮换和校验私钥，降低运维复杂度和安全风险
- 配合 HSTS、OCSP Stapling、TLS 1.3 等特性，Nginx 层还能集中提升全站 HTTPS 安全等级
Nginx 配置 SSL 卸载的关键项
核心在于：前端用 listen 443 ssl 接收加密流量，后端用 proxy_pass http://... 转发明文请求，并透传原始协议信息。
-
必须设置
X-Forwarded-Proto: https，否则后端生成跳转链接或判断是否为安全上下文时会出错 -
启用 SSL 会话复用（
ssl_session_cache shared:SSL:10m; ssl_session_timeout 4h;），大幅减少重复握手开销 -
禁用老旧协议与弱密钥套件，例如明确写
ssl_protocols TLSv1.2 TLSv1.3;和ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256; - 若后端需识别真实客户端 IP，
proxy_set_header X-Real-IP $remote_addr;和X-Forwarded-For缺一不可
与负载均衡协同工作的注意事项
SSL 卸载不是孤立配置，它必须嵌入完整的反向代理与负载均衡流程中。
- upstream 块中定义的后端地址应为
http://协议，且端口对应后端服务的实际监听端口（如 8080、3000） - 如果启用了健康检查（
health_check），检查请求也应走 HTTP，避免因 TLS 配置不一致导致误判下线 - 使用
proxy_next_upstream error timeout http_502;可在某台后端崩溃或超时时自动切到其他节点，保障卸载后的链路可靠性 - 日志中建议记录
$scheme和$http_x_forwarded_proto，便于排查“为什么后端收到的是 http 却以为自己该跳 https”这类典型问题
进阶：卸载后如何保障内网通信安全
有人担心“Nginx 到后端走 HTTP，中间被窃听怎么办”。实际中，只要满足以下任一条件，风险极低：
- 后端服务器与 Nginx 部署在同一内网 VPC 或物理机房，网络路径受基础设施保护
- 使用 Service Mesh（如 Istio）或 mTLS 对内部东西向流量加密，与边缘 SSL 卸载分层解耦
- 对极敏感场景，可在 Nginx 和后端之间启用自签名证书 + 双向认证，但会增加运维负担，通常不必要
