keepalive_timeout 不降低 TLS 证书校验 CPU 开销，仅控制空闲 HTTP 连接保持时长；真正减少开销需启用 ssl_session_cache、设置 ssl_session_timeout 并可选开启 OCSP Stapling。
keepalive_timeout 本身不参与证书校验，也不能直接降低 TLS 握手中的证书验证 CPU 开销。它的作用是控制 Nginx 在响应完成后、等待下一次请求的空闲连接保持时长。真正影响证书校验开销的是 TLS 层的会话复用机制（如 session ticket 或 session ID），而非 HTTP 层的 keep-alive 连接管理。
理解关键区别：keepalive_timeout ≠ TLS 会话复用
很多人误以为调长 keepalive_timeout 就能“复用证书校验结果”，这是混淆了两个层级：
- HTTP 层 keep-alive：让同一个 TCP 连接承载多个 HTTP 请求（比如首页 + 图片 + JS），避免反复建连；但它不保存或跳过任何 TLS 握手步骤
- TLS 层会话复用：在第二次握手时跳过完整证书验证、密钥交换等高开销环节，直接恢复会话——这才是降低 CPU 的核心手段
真正降低 HTTPS 证书校验 CPU 开销的配置组合
要减少重复证书验证带来的 CPU 压力，需配合以下三项启用并调优：
-
启用 TLS 会话缓存：用
ssl_session_cache shared:SSL:10m开启共享内存缓存，支持 worker 间复用 -
设置合理会话超时：用
ssl_session_timeout 4h（建议 1–8 小时），比 keepalive_timeout 更长，确保会话在连接复用期内仍有效 -
开启 OCSP Stapling（谨慎）：配置
ssl_stapling on和ssl_stapling_verify on，但必须搭配可靠的上游 OCSP 响应器；否则 stapling 延迟反而导致客户端放弃复用、新建连接
keepalive_timeout 的间接协同作用
虽然它不处理证书，但合理设置可提升 TLS 复用成功率：
- 设得太短（如
keepalive_timeout 5s）：连接很快关闭，即使 TLS 会话还有效，也无法复用——等于浪费了已缓存的会话 - 设得过长（如
keepalive_timeout 300s）：空闲连接堆积，占用文件描述符，反而挤占可用于新 TLS 握手的资源 - 推荐值：对 HTTPS 服务，设为
keepalive_timeout 30s左右较平衡；此时若客户端在 30 秒内发起第二个请求，TCP 连接复用成功，TLS 会话也大概率仍在有效期内，双重复用达成
验证是否真正降低了证书校验开销
不能只看响应头或连接数，应结合：
-
OpenSSL 统计：
openssl s_client -connect example.com:443 -reconnect观察 “Reused, SSL handshake” 是否频繁出现 -
Nginx 日志字段：添加
$ssl_session_reused到 log_format，统计.（未复用）与r（复用）比例 -
CPU 火焰图对比：压测前后抓取
perf record -g -p $(pgrep nginx)，重点关注ssl3_accept和ssl_get_prev_session的耗时占比变化
