keepalive_timeout在HTTPS中仅控制Nginx关闭空闲TCP连接的等待时间，不管理TLS会话复用；其效果受限于客户端限制、中间设备干扰及OCSP延迟，需协同keepalive_requests、客户端行为与链路特性调优。
单纯调大 keepalive_timeout 对 HTTPS 连接复用率提升有限，关键在于理解它在 TLS 场景下的实际作用边界，并配合客户端行为、中间链路和后端协同调整。
明确 keepalive_timeout 在 HTTPS 中的真实职责
该指令只控制 Nginx 主动关闭“已建立且无数据传输”的空闲 TCP 连接的等待时间，单位秒。它不管理 TLS 会话复用（如 session ticket）、不影响证书验证或握手流程，也不决定连接是否能被浏览器复用。
- 设为
keepalive_timeout 60s;表示：连接空闲满 60 秒，Nginx 就发送 FIN 断开 - 只要客户端在 60 秒内发起第二个 HTTPS 请求，连接就继续存活
- 正在 TLS 握手或传输中的连接，不会因该超时被强制中断
HTTPS 下复用常失效的典型原因
即使 Nginx 配置了 60 秒甚至更长，客户端仍频繁断连，常见干扰源包括：
- 浏览器主动限制：Chrome 默认约 5–10 分钟，iOS Safari 更短；早于 Nginx 超时即关闭连接
- 中间设备截断：企业防火墙、WAF、旧版负载均衡器可能不透传
Connection: keep-alive或重写响应头，导致客户端误判 - OCSP Stapling 延迟：若开启
ssl_stapling on但 OCSP 响应慢，TLS 握手卡顿，客户端放弃复用而新建连接 - HTTP/2 自动启用长连接：虽默认复用率高，但单连接承载多路请求后空闲期缩短，
keepalive_timeout实际触发概率下降
针对性调优建议
不靠盲目拉长超时，而是让配置与真实链路节奏匹配：
- API 服务（尤其移动端）：设为
15–30s。移动网络 NAT 超时普遍在 2–5 分钟，过长等待无意义，反而堆积空闲连接 - 静态资源服务：可设
30–45s。页面加载期间请求密集，并发下载后空闲期短，无需保留太久 - 务必联动
keepalive_requests：默认 100 不够用，建议设为500–1000，避免单连接处理少量请求就被关闭 - 检查客户端声明值：用
curl -v观察响应中是否含Keep-Alive: timeout=XX，确保 Nginx 设置与客户端预期不冲突
验证是否真正复用
不能只看响应头有没有 Connection: keep-alive（HTTPS 下该头默认不出现），应结合：
-
curl -v https://example.com：观察是否出现* Connection #0 to host example.com left intact - Wireshark 抓包：过滤
tcp.stream eq X，确认多个 HTTPS 请求是否共用同一 TCP 流（端口对不变） - Nginx 日志开启
$connection和$connection_requests变量：同一$connection值对应多个请求，说明复用成功
