最直接有效的办法是启用 proxy_ssl_session_reuse on 并配套 upstream keepalive、http/2、ssl 缓存与协议优化等组合调优，可将建连延迟从 80–120ms 降至 20–40ms，端到端延迟下降超 30%，复用率稳定在 90% 以上。
最直接有效的办法是减少 TLS 握手开销、复用连接、压缩传输，并让各环节协同生效。单改一两个参数效果有限，关键在组合调优。
复用 TLS 会话，跳过完整握手
启用 proxy_ssl_session_reuse on 是降低建连延迟最直接的手段——Nginx 会复用已建立的 HTTPS 连接，避免重复证书交换与密钥协商。实测可将建连延迟从 80–120ms 降至 20–40ms，端到端延迟下降超 30%，复用率通常稳定在 90% 以上。
- 必须配套 upstream 中设置 keepalive 32（每个 worker 维护最多 32 个空闲连接）
- 显式声明 proxy_http_version 1.1 和 proxy_set_header Connection ""，防止上游主动断连清空连接池
- 若后端是多域名共 IP 的网关（如 Istio Ingress），需加 proxy_ssl_server_name on，确保 SNI 一致，否则无法匹配证书、复用失败
- 后端 idle timeout（如 Spring Boot 的 connection-timeout）不能早于 Nginx 的 keepalive_timeout，否则连接被提前回收
优化 SSL 缓存与协议栈
服务端 TLS 缓存直接影响客户端首次访问后的复用效率，尤其对返回用户至关重要。
- 在 server 块中启用共享会话缓存：ssl_session_cache shared:SSL:10m（10MB 内存约支持 4000 个会话）
- 延长缓存有效期：ssl_session_timeout 4h（兼顾复用率与内存安全）
- 统一并精简协议与加密套件：ssl_protocols TLSv1.2 TLSv1.3；推荐 cipher 如 ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256
- 开启 ssl_prefer_server_ciphers on，确保服务端主导加密套件选择
- 关闭 session tickets：ssl_session_tickets off（Nginx 对其支持不完善，且有安全顾虑）
启用 HTTP/2 并调优传输细节
HTTP/2 支持多路复用，能显著降低并发请求的连接开销；配合 buffer 调整可进一步压低 TTFB（首字节时间）。
- 监听配置改为：listen 443 ssl http2（要求 Nginx ≥ 1.9.5 + OpenSSL ≥ 1.0.2）
- 对 REST API 或网页类服务，缩小发送缓冲区：ssl_buffer_size 4k（默认 16k 容易拖慢首包）
- 启用 OCSP Stapling：ssl_stapling on; ssl_stapling_verify on;，避免客户端自行验证证书导致不可控延迟
- 开启 Gzip 压缩：gzip on，搭配 gzip_comp_level 2–4 和常用 MIME 类型，减少传输体积
验证与避坑要点
配置生效不等于复用成功，需结合日志与工具交叉确认。
- 检查日志变量：$upstream_ssl_session_reused 是否频繁输出 "t"（true）
- 抓包观察 TCP+TLS 流程：复用成功时应无 ServerHello → Certificate → ServerKeyExchange 等完整握手流程
- 用 curl -w "%{time_starttransfer}\n" 测试首包时间变化，建议在真实网络环境（含丢包/延迟）下多轮采样
- 确认 ssl_session_cache 容量是否足够：每万并发约需 2–3MB，20MB 可支撑 5–8 万连接
