nginx 官方无 proxy_ssl_keepalive 指令；实现后端 https 长连接需在 upstream 块配置 keepalive n，并配合 proxy_http_version 1.1、proxy_set_header connection '' 及 ssl_session_reuse on（1.19.4+）等必要设置。
实际上，Nginx 官方核心模块中并不存在 proxy_ssl_keepalive 这个指令。这是一个常见误解，可能源于对 keepalive（用于 upstream）、proxy_http_version、proxy_set_header Connection 等 SSL 相关长连接配置的混淆。
真正起作用的是 upstream 的 keepalive 指令
要让 Nginx 与后端 HTTPS 服务之间复用 TCP 连接（即实现后端长连接），关键在于 upstream 块中的 keepalive 参数，而非某个“SSL 专用 keepalive”指令：
-
必须在 upstream 中显式配置，例如：
keepalive 64;，表示每个 worker 进程最多缓存 64 个空闲到后端的连接 - 该机制天然支持 HTTPS 后端——只要后端是基于 TLS 的 HTTP/1.1 服务，Nginx 复用的是底层 TCP+TLS 连接，无需额外 SSL 层 keepalive 开关
- 若后端是 HTTP/2，Nginx 1.19.0+ 也支持连接复用，但需配合
http2协议声明及相应 TLS 配置
配套必要配置缺一不可
仅加 keepalive N 不足以生效，以下三项必须同时存在：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
-
proxy_http_version 1.1;：强制使用 HTTP/1.1 协议发起请求（HTTP/1.0 默认关闭连接） -
proxy_set_header Connection '';：清空客户端传来的 Connection 头，防止 Nginx 被动继承close，确保向后端发送Connection: keep-alive -
proxy_set_header Host $host;等基础头信息：保证后端能正确路由和识别请求
HTTPS 后端还需注意 TLS 层行为
即使 TCP 连接复用成功，TLS 握手开销仍可能成为瓶颈。可进一步优化：
- 启用 TLS session reuse：在 upstream server 行中添加
ssl_session_reuse on;（Nginx 1.19.4+ 支持），复用 TLS 会话票据，跳过完整握手 - 确保后端服务器开启 TLS session cache 或 ticket，并支持
session resumption - 避免在 proxy_pass 中频繁切换域名或证书（会导致连接池隔离，降低复用率）
验证是否生效的方法
不依赖日志，直接观察连接复用效果：
- 用
ss -tnp | grep :443查看 Nginx worker 进程与后端 IP 的 ESTABLISHED 连接数，稳定在keepalive设定值附近（而非随请求飙升） - 抓包分析：确认多个请求复用同一 TCP 流，且响应头含
Connection: keep-alive - 对比开启前后
time_wait状态连接数、后端 CPU/连接创建速率，下降明显即说明成功
