ssl卸载一般只设在边缘层，因多层终止会导致证书轮换运维成本激增、tls 1.3优化（如0-rtt）被截断、x-forwarded-*等关键头易伪造或覆盖，引发鉴权/限流失效。
在多层代理环境中做 SSL 卸载，核心不是“在哪一层解密”，而是“在哪一层终止 TLS 并确保后端始终可信、路径信息不丢失、安全策略不降级”。Nginx 多层架构中，SSL 卸载通常只应在最外层（边缘节点）完成，内层代理应使用明文 HTTP/TCP 转发，避免重复加解密和证书管理混乱。
为什么 SSL 卸载一般只设在边缘层
多层代理若每层都做 SSL 终止，会带来三类实际问题：证书轮换需同步更新所有层，运维成本指数上升；TLS 1.3 的 0-RTT、会话复用等优化在中间层被截断；X-Forwarded-Proto、X-Real-IP 等关键头易被伪造或覆盖，导致鉴权/限流逻辑出错。
- 边缘层（如全球 CDN 或公网入口 Nginx）负责面向公网的 TLS 握手、证书管理、HSTS/OCSP Stapling 等安全增强
- 区域层（如机房入口网关）只需信任内部网络，接收明文 HTTP 请求，专注 GEO 路由、熔断、IP 白名单
- 服务网关层（微服务前端）不再处理加密，只做 JWT 验证、路由匹配、gRPC/HTTP2 协议适配
三层架构中 SSL 卸载的具体配置要点
以电商系统为例，边缘层 Nginx 接收 443 端口 HTTPS 流量，解密后以 HTTP 明文转发给区域层；区域层再以 HTTP 转发至服务网关；全程保持 X-Forwarded-* 头链完整，且后端服务无需部署私钥。
- 边缘层 server 块：启用 ssl_certificate + proxy_pass http://region-gateway；必须设置 proxy_set_header X-Forwarded-Proto https 和 X-Forwarded-Ssl on
- 区域层 upstream：后端地址写为 http://service-gateway:8080（非 https），避免二次 TLS 开销；开启 keepalive 连接池减少握手延迟
- 服务网关层：通过 $http_x_forwarded_proto 判断原始协议，控制重定向逻辑（如强制 https 仅在边缘层生效，此处跳过）
四层代理场景下的 SSL 卸载特殊处理
当需要在 stream 块中实现多域名共用 443 端口（如 MySQL over TLS），SSL 卸载体现为“TLS 终止 + SNI 路由”，此时不走 HTTP 协议栈，但原理一致：Nginx 完成客户端 TLS 握手后，以明文 TCP 连接连向后端数据库。
- 必须启用 with-stream_ssl_preread_module 和 with-stream_ssl_module 编译选项
- server 块 listen 443 ssl + ssl_preread on，读取 $ssl_preread_server_name 实现域名分流
- proxy_pass 指向的是 upstream 的明文 TCP 地址（如 192.168.10.11:3306），不是 https://
- 证书仍由 Nginx 统一托管，后端 MySQL 实例可关闭 require_secure_transport，降低 CPU 压力
关键安全与可靠性保障措施
卸载 SSL 后，明文流量在内网传输是可接受的，但必须建立信任边界和防篡改机制，否则等于放弃传输层保护。
- 内网通信启用 mutual TLS（mTLS）或 IP 白名单，限制只有上游代理能访问下游服务端口
- 所有代理层统一校验 X-Forwarded-For 中第一个非私有 IP，拒绝伪造头请求
- 边缘层开启 ssl_session_cache shared:SSL:10m 和 ssl_session_timeout 4h，提升 TLS 复用率
- 禁用不安全协议：ssl_protocols TLSv1.2 TLSv1.3；禁用弱密码套件，如 !aNULL !MD5 !RC4
