Nginx高并发HTTPS CPU飙升主因是TLS握手与加解密集中爆发，需通过顶层配置会话复用（shared:SSL:10m+4h超时）、禁用session ticket、启用TLSv1.3、精简ECDHE套件、OCSP Stapling及硬件加速协同优化。
高并发 HTTPS 场景下 Nginx CPU 飙升，不是“HTTPS 必然慢”，而是 TLS 握手与加解密在流量洪峰中集中爆发，把 worker 进程拖垮了。关键要分清：是算力真不够？还是配置没跟上？或是连接行为本身出了问题？下面按实战顺序拆解排查路径。
确认是不是 SSL 真正导致的瓶颈
别一上来就调参数——先锁定根因：
- 运行 top -c，只看
nginx: worker process的 CPU 占比；若 master 进程高，问题不在请求处理层 - 执行 openssl speed rsa2048，单核吞吐低于 800 ops/sec，说明硬件加速（如 OpenSSL engine 或 CPU AES-NI）未生效，还在硬算
- 查当前活跃 TLS 连接：ss -s | grep -i tls，ESTABLISHED 超过 5000 就得警惕短连接风暴（比如客户端没复用、keepalive 被禁用）
- 翻错误日志：grep "ssl_handshake" /var/log/nginx/error.log | tail -10，大量 timeout 不一定是 CPU 不够，更可能是 OCSP 验证卡住或证书链不全
检查 TLS 会话复用是否真正生效
每次完整握手消耗 0.5–2ms CPU，而复用能跳过密钥交换和证书校验——但很多配置只是“开了”，没“配准”：
-
ssl_session_cache 必须写在
http { }块顶层，且唯一声明：ssl_session_cache shared:SSL:10m;（写在 server 块里会被忽略） -
ssl_session_timeout 设为
4h，默认 5 分钟太短，复用率几乎为零 - ssl_session_tickets off; 关闭服务端无状态票据，避免每次新建 session 都多一次 AES 加解密
- 缓存大小按真实压力估算：每秒新建 1000 个会话 × 14400 秒 × 2KB ≈ 27MB，起步建议
shared:SSL:32m，启用了 OCSP Stapling 后需再加余量
验证密码套件与协议是否高效
老旧算法（RSA 密钥交换、DHE、3DES）或高强度密钥（rsa:4096）会让握手变慢 3–5 倍：
- 强制使用 ECDHE 密钥交换：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; - 协议只开 TLSv1.2 和 TLSv1.3：
ssl_protocols TLSv1.2 TLSv1.3;（TLSv1.3 握手快 30%–50%，且自动屏蔽低效套件） - ssl_prefer_server_ciphers off; 让客户端选它支持的最优组合，而不是服务器硬推低效算法
确认 OCSP Stapling 是否启用并验证成功
不做 stapling，等于每次握手都发起一次外部 OCSP 查询 + 本地验签，网络延迟+CPU 双重开销：
- 必须三要素齐备：
ssl_stapling on;、ssl_stapling_verify on;、ssl_trusted_certificate /path/to/fullchain.pem; - 验证是否生效：openssl s_client -connect yourdomain.com:443 -status -servername yourdomain.com 2>&1 | grep -i "OCSP response"，看到
OCSP Response Status: successful才算落地 - 如果 stapling 失败，先检查
ssl_trusted_certificate是否包含中间 CA，再确认 DNS 和防火墙允许 outbound 到 OCSP 响应方
