必须把SSL从单机“搬出来”，因TLS加解密强占30%~50% CPU，导致延迟陡增、并发受限且运维 reload 影响全局；实测8000+并发时性能断崖下降。
单机 Nginx 直接处理 SSL 加解密，随着流量增长会迅速成为性能瓶颈——CPU 被大量消耗在 TLS 握手和加解密上，导致后端应用响应变慢、并发能力受限。真正的转型不是“要不要卸载”，而是“在哪卸、怎么卸、如何平滑过渡”。
为什么必须把 SSL 从单机里“搬出来”
单机模式下，Nginx 同时承担反向代理、负载均衡、静态服务和 SSL 终止四项任务。当 HTTPS 请求量上升，TLS 协商开销会吃掉 30%~50% 的 CPU 资源，尤其在小包高频请求（如 API 调用、WebSocket 连接）场景下更明显。此时即使升级服务器硬件，提升也有限，因为 SSL 处理是强 CPU 密集型操作，无法靠简单扩容解决。
- SSL 握手耗时随并发线性增长，单机 Nginx 实测在 8000+ 并发时延迟陡增
- 证书更新、协议切换（如停用 TLSv1.1）、OCSP Stapling 等运维动作需 reload 全局配置，影响所有业务
- 后端服务（如 PHP-FPM、Tomcat）无需再处理加密逻辑，可专注业务计算，部署更轻量
SSL 卸载的三级演进路径
不是一步跳到 LVS 或专用 WAF，而是按实际流量与团队能力分阶段推进：
- 阶段一：单机内部分离 —— 在同一台服务器上，用独立 Nginx 实例专做 SSL 终止（监听 443），再 proxy_pass 到另一个不启用 SSL 的 Nginx 实例（监听 8080），后者只管路由、缓存和转发。好处是零拓扑变更，仅改配置，适合验证卸载收益
- 阶段二：集群前置卸载 —— 部署多台 Nginx 作为 SSL 卸载层（可配合 Keepalived 做高可用 VIP），后端 Web 集群统一走 HTTP 内网通信。此时 SSL 层可横向扩展，Web 层也可独立伸缩
- 阶段三：四层卸载 + 七层协同 —— 在最前端引入 LVS（DR 模式）或云厂商的四层 SLB，只做 TCP 转发；SSL 终止由后端 Nginx 集群完成。这种组合兼顾了 LVS 的百万级连接能力和 Nginx 的灵活策略控制
关键配置与避坑要点
SSL 卸载不是加几行配置就完事，几个实操中高频出错的点必须提前对齐：
- 后端服务必须信任 X-Forwarded-Proto 和 X-Real-IP 头，否则登录跳转可能变成 http://，或用户 IP 显示为 127.0.0.1
- session 保持不能依赖客户端 IP（因所有请求经 Nginx 转发后源 IP 统一），应改用 cookie 或 $request_id 透传，配合 ip_hash 或 sticky 模块
- 证书私钥权限必须严格限制（600），且 Nginx 主进程需有读取权限；若用 systemd 管理，注意 PrivateTmp=yes 可能导致证书路径不可见
- 启用 ssl_session_cache shared:SSL:10m 和 ssl_session_timeout 4h，复用会话减少握手次数，实测可降低 40%+ TLS CPU 占用
如何验证卸载是否真正生效
别只看浏览器锁图标，要抓本质指标：
- 对比前后端 CPU 使用率：卸载后，原 Nginx 实例的 %sys（系统态）应显著下降，后端应用的 %usr（用户态）应更稳定
- 用 openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 检查 Server Name Indication（SNI）是否正确返回证书
- 访问 /nginx_status（需开启 stub_status）观察 Active connections 中 SSL 握手相关计数变化趋势
- 后端日志中检查 $http_x_forwarded_proto 是否恒为 https，$remote_addr 是否为真实客户端 IP（而非 Nginx 内网地址）
