如何配置Nginx中ssl_session_cache提升HTTPS握手性能-Nginx-PHP中文网

配置 ssl_session_cache 可显著减少 tls 握手开销，核心是复用 session ticket 或 session id；推荐使用 shared:ssl:10m 配合 ssl_session_timeout 4h、ssl_session_tickets on 及安全轮换的 ticket.key。

如何配置nginx中ssl_session_cache提升https握手性能

配置 ssl_session_cache 能显著减少 TLS 握手开销，尤其对高频短连接（如 API、Web 前端资源）效果明显。核心是复用会话票据（session ticket）或会话 ID（session ID），避免重复执行完整的 RSA/ECC 密钥交换。

理解两种缓存机制：shared vs builtin

Nginx 支持两种 session 缓存方式，常组合使用：

shared：进程间共享的内存区域（如 ssl_session_cache shared:SSL:10m），容量单位为 MB，推荐设置 5–20MB。1MB 约可缓存 4000 个会话（取决于证书大小和协议版本）。多 worker 进程可共用，适合生产环境。
builtin：每个 worker 进程私有缓存（如 ssl_session_cache builtin:1000），容量单位为条目数。响应快但不共享，适合低并发或调试。一般不单独使用。

推荐配置与关键参数

一个兼顾性能与内存占用的典型配置如下：

Session Handoff

创建全面的交接文档，使新AI代理能够无缝继续工作，消除歧义。解决上下文耗尽问题。时机：(1)用户请求保存交接，(2)上下文即将满，(3)主要任务完成，(4)会话结束，(5)恢复工作时。关键词：保存状态、创建交接、上下文已满、暂停、从...恢复、加载交接、保存进度、会话转移、交接

下载

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 4h;
ssl_session_tickets on;
ssl_session_ticket_key /etc/nginx/ssl/ticket.key;

ssl_session_timeout 4h：设为较长时间（默认 5m 太短），让客户端在有效期内复用缓存会话。注意：实际复用受客户端行为影响，不强制生效。
ssl_session_tickets on：启用会话票据（RFC 5077），比传统 session ID 更高效，无需服务器端存储状态。必须配合 ssl_session_ticket_key 使用。
ssl_session_ticket_key：指定加密票据的密钥文件（二进制，32+ 字节），建议定期轮换（如每月），避免长期密钥泄露导致会话被解密重放。

验证是否生效

通过 OpenSSL 检查握手是否复用：

openssl s_client -connect example.com:443 -reconnect -servername example.com 2>/dev/null | grep "Session-ID"

若多次连接输出的 Session-ID 相同，且 Reused 显示 Yes，说明缓存命中。
也可用 nginx -T | grep ssl_session 确认配置已加载；用 curl -I https://example.com 查看响应头中是否有 Strict-Transport-Security 等，间接判断 HTTPS 正常工作。

常见误区与优化提示

以下做法容易降低效果或引发问题：

缓存过小（如 1m）：高并发下频繁淘汰，复用率骤降；建议从 5m 起步，按 active_connections × 2KB 估算所需内存。
关闭 ssl_session_tickets 却依赖 shared 缓存：旧版客户端（如 Android 4.x）可能仅支持 session ID，此时需确保 shared 容量足够且 ssl_session_timeout 合理。
未设置 ssl_session_ticket_key 却开启 tickets：Nginx 会自动生成临时密钥，重启后失效，导致票据无法解密，等效禁用 tickets。
HTTPS 反向代理场景：若上游也走 HTTPS，注意 proxy_ssl_* 参数独立控制上游 TLS 行为，不影响客户端到 Nginx 的 session 缓存。