高并发下nginx cpu瓶颈主因是tls握手、进程调度与连接分发三环节失衡，需先通过top、openssl speed、ss和错误日志锁定根因，再逐层验证会话复用、密码套件、ocsp stapling及cpu亲和性等配置实效性。
高并发下 Nginx CPU 瓶颈不是“扛不住”，而是 TLS 握手、进程调度和连接分发三个环节在流量洪峰中同时失衡。排查要从现象锁定根因，再逐层验证配置与系统协同效果。
先确认是不是 SSL 导致的 CPU 飙升
别急着改配置——先看真实负载来源：
- 运行 top -c，只关注 nginx: worker process 的 CPU 占比；若 master 进程高，问题不在请求处理层
- 执行 openssl speed rsa2048，单核吞吐低于 800 ops/sec，说明 AES-NI 或 OpenSSL engine 未启用，还在纯软算
- 查活跃 TLS 连接：ss -s | grep -i tls，ESTABLISHED 超过 5000 就要警惕短连接风暴（比如 keepalive 被禁或客户端不复用）
- 翻错误日志：grep "ssl_handshake" /var/log/nginx/error.log | tail -10，大量 timeout 很可能卡在 OCSP 验证或证书链不全，而非 CPU 不够
检查 TLS 会话复用是否真正生效
每次完整握手耗时 0.5–2ms CPU，而复用能跳过密钥交换和证书校验——但很多配置只是“开了”，没“配准”：
- ssl_session_cache 必须写在 http { } 块顶层，且全局唯一声明，例如：ssl_session_cache shared:SSL:32m;（写在 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;，让客户端选它支持的最优组合，而不是服务器硬推低效算法
检查内核级分发与 CPU 绑定是否到位
worker 进程争抢 accept 锁、频繁上下文切换、跨核迁移缓存失效，都会把 CPU 拖垮：
- 启用 SO_REUSEPORT：在 listen 指令后加 reuseport，绕过 accept_mutex，消除惊群效应
- 设置 worker_processes auto;，Nginx 会智能适配 NUMA 架构，比手动设数更稳
- 开启 worker_cpu_affinity auto;，自动绑定物理核心，避免进程在不同 CPU 间迁移
- 调高调度优先级（需 root）：worker_priority -5;，减少被其他进程抢占的机会
- 用 vmstat 1 观察 cs（上下文切换）列，若持续 >10k/s，说明调度开销过大
