nginx https cpu飙升核心原因是tls握手与加解密集中爆发，需通过会话复用（shared缓存+4h超时）、禁用session ticket、启用tlsv1.3、精简ecdhe套件、ocsp stapling及硬件加速协同优化。
Nginx 配置 SSL 后 CPU 使用率飙升，核心原因不是“开了 HTTPS 就该这样”，而是 TLS 握手和加解密在高并发下集中爆发，把 CPU 压垮了。重点不是压指标，而是让加密更轻、复用更稳、计算更省。
确认确实是 SSL 导致的 CPU 高负载
先排除误判：
- 运行
top -c，看高 CPU 是否集中在nginx: worker process（不是 master 进程） - 执行
openssl speed rsa2048，单核吞吐若低于 800 ops/sec，说明硬件加速未生效或 CPU 硬算吃力 - 查当前 TLS 连接数：
ss -s | grep -i tls，如果 ESTABLISHED 超过 5000，需警惕短连接风暴 - 检查错误日志：
grep "ssl_handshake" /var/log/nginx/error.log | tail -10，大量 timeout 报错往往意味着握手卡在验证环节，不一定是算力不够
启用 TLS 会话复用并精准配置缓存大小
每次完整握手消耗 0.5–2ms CPU，复用能跳过密钥交换和证书校验。关键不在“开不开”，而在“配得准不准”：
- 必须在
http { }块顶层唯一声明：ssl_session_cache shared:SSL:10m;（重复写在 server 块里会被忽略） - 超时设为
ssl_session_timeout 4h;（默认 5 分钟太短，复用率极低） - 关闭服务端无状态票据：
ssl_session_tickets off;（避免额外加解密开销） - 缓存大小按真实流量算：例如每秒新建 1000 个会话 × 14400 秒 × 0.5KB ≈ 6.9MB，起步配
shared:SSL:10m即可；若启用了 OCSP Stapling 或证书链长，按 2–3KB/条估算，可能需要shared:SSL:48m
切换到高性能密码套件与 TLSv1.3
老旧算法（如 RSA 密钥交换、DHE、3DES）或高强度密钥（rsa:4096）会显著拖慢握手：
- 强制使用 ECDHE 密钥交换：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; - 禁用不安全旧协议：
ssl_protocols TLSv1.2 TLSv1.3;（TLSv1.3 握手快 30%–50%，且自动屏蔽低效套件） - 关闭服务端优先选密：
ssl_prefer_server_ciphers off;（让客户端选它支持的最优组合）
开启 OCSP Stapling 并检查硬件加速状态
OCSP 查询本身要发起外部请求+验签，不做 stapling 就等于每次握手都多一次网络往返+CPU 计算：
- 启用并验证：
ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /path/to/fullchain.pem;
- 检查内核是否加载加速模块：
lsmod | grep -E "(qat|ccp)"，有输出再确认 Nginx 编译时带 OpenSSL 引擎支持（nginx -V 2>&1 | grep -o with-openssl）
不复杂但容易忽略。
