高并发 https 性能下降主因是重复 tls 握手而非连接数过多；核心优化是确保 ssl_session_cache 置于 http 块顶层、设 shared 缓存与 4h 超时，并启用 session tickets 实现跨进程复用与无状态兜底。
高并发 HTTPS 场景下性能下降，往往不是连接数本身压垮了 Nginx，而是大量重复 TLS 握手持续消耗 CPU 和内存。真正要查的，不是“为什么慢”，而是“为什么每次都要重握手”。
看 error.log 里有没有 handshake failure 或 session reuse 相关报错
打开 /var/log/nginx/error.log，搜索关键词：
-
SSL_do_handshake() failed → 表明握手中断，需结合错误码（如
error:14094410）判断是 SNI 缺失、协议不匹配还是套件无交集 - ssl_session_cache misses 或反复出现 no session found → 说明会话复用未生效，大量连接在走完整握手
- accept() failed (24: too many open files) 或 worker process exited on signal 9 → 虽是资源耗尽现象，但根源常是握手开销过大导致 worker 响应延迟、连接堆积
验证 ssl_session_cache 是否真正跨进程共享且命中率足够
会话缓存必须放在 http 块顶层，不能只写在 server 块里：
- 确认配置含
ssl_session_cache shared:SSL:10m;（至少 10MB，支持约 5 万个会话） - 搭配
ssl_session_timeout 4h;，避免过早失效 - 用
nginx -T | grep ssl_session_cache检查是否被多处覆盖或遗漏 - 通过
curl -I https://your-domain.com并观察响应头中Set-Cookie或Strict-Transport-Security出现频率，间接判断复用是否稳定；更准的方式是用openssl s_client -connect your-domain.com:443 -reconnect -servername your-domain.com 2>&1 | grep "Session-ID"看多次连接是否复用同一 ID
检查后端是否也强制 HTTPS 导致双重握手叠加
如果 Nginx 作为反向代理还配置了 proxy_pass https://backend，就会让每个请求经历两次 TLS 握手（Nginx ←→ 客户端 + Nginx ←→ 后端），CPU 开销翻倍：
- 优先让后端走 HTTP（如
proxy_pass http://backend），把 TLS 终止在 Nginx 层 - 若后端必须 HTTPS，请确保它也启用了会话复用，并且与 Nginx 的 TLS 版本、SNI、套件严格一致
- 用
curl -w "@format.txt" -s https://backend-url测后端单独的%{time_appconnect}，确认其握手是否也慢——如果是，问题不在 Nginx 配置，而在后端 TLS 实现
确认 TLS 版本和密码套件没人为制造“无交集”
过于激进的 cipher 配置会导致客户端无法协商出共同套件，被迫降级或失败，从而绕过复用、触发新握手：
- 避免禁用所有 RSA 套件（如
!RSA），部分旧客户端或国密兼容层依赖它做密钥交换 - 推荐组合：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; - 启用 TLSv1.3（
ssl_protocols TLSv1.2 TLSv1.3;），它天然支持 0-RTT 和更强的默认复用机制 - 用
openssl s_client -connect your-domain.com:443 -tls1_2 -cipher 'ECDHE-RSA-AES128-SHA'逐个测试关键套件是否能通，尤其覆盖移动端常用组合
