ssl_session_timeout控制TLS会话缓存有效时长，调大可提升复用率、降低握手延迟；默认5m偏短，推荐普通站点设10m–20m，内网网关可达4h，需同步保障ssl_session_cache容量充足并验证复用效果。
在Nginx中，ssl_session_timeout 控制TLS会话缓存的有效时长。合理调大该值，能显著降低客户端重连时的完整TLS握手频率，从而减少延迟、提升首屏加载速度和并发处理能力。
理解会话复用机制与timeout的关系
Nginx默认使用内存中的会话缓存（如 ssl_session_cache shared:SSL:10m），将协商好的会话ID与加密参数暂存。当客户端再次连接并携带有效会话ID时，服务端可跳过密钥交换和证书验证，直接复用会话——这就是“会话复用”。
ssl_session_timeout 决定了这个缓存条目在内存中保留多久（单位：秒）。超时后，即使缓存未满，该会话也会被清理，下次连接只能走完整握手。
常见误配与实际影响
默认值通常为 5m（300秒），对移动端或长周期交互场景偏短：
- 用户切换Wi-Fi/蜂窝网络后重连，若session已过期，触发完整握手（多耗1–2个RTT）
- 单页应用（SPA）频繁发起HTTPS子资源请求，短时间内多次新建连接，易错过复用窗口
- HTTP/2多路复用下，单TCP连接承载多个请求，但连接空闲超时（keepalive_timeout）与session超时不一致时，仍可能丢失复用机会
推荐调优策略
根据业务流量特征选择合适值，兼顾安全性与性能：
- 普通Web站点（含移动端）：设为 10m–20m（600–1200秒），覆盖多数用户活跃会话周期
- 内网API网关或高可信环境：可延长至 4h（14400秒），大幅降低握手开销
- 金融/政务类敏感系统：建议保持 5m–10m，平衡安全（缩短会话泄露影响窗口）与可用性
- 务必同步检查 ssl_session_cache 容量是否充足（例如
shared:SSL:20m），避免因缓存淘汰导致提前失效
验证是否生效
启用后可通过以下方式确认会话复用率提升：
- 使用
openssl s_client -connect example.com:443 -reconnect观察输出中Reused, SSL handshake succeeded出现频次 - Nginx日志中开启
$ssl_session_reused变量（值为.表示未复用，r表示复用），统计比例 - 对比调优前后，监控指标如 “TLS handshake time”（通过APM或eBPF工具）是否下降
不复杂但容易忽略：timeout只是会话复用的一环，还需确保客户端支持、OCSP Stapling启用、且未禁用TLS 1.2+ 的session ticket机制。
