https连接时长限制核心是合理设置超时参数：keepalive_timeout控制空闲连接时长（推荐300秒），ssl_session_timeout提升tls复用率（建议8小时），client_header/body/send_timeout分阶段防慢速攻击，需协同后端配置避免time_wait泛滥。
HTTPS 环境下配置连接时长限制，核心是控制客户端与 Nginx 之间 TLS 连接的存活时间，避免空闲连接长期占用资源，同时兼顾 HTTPS 性能优化。关键不在于“禁止长连接”，而在于合理设定超时参数，让连接在无活动时及时释放。
keepalive_timeout：控制 HTTPS 长连接空闲时长
这是最直接的连接时长限制参数，作用于客户端与 Nginx 的 HTTPS 连接（即 SSL/TLS 层之上、HTTP 层之下的 TCP 连接）。
- 默认值通常为 75 秒，对 HTTPS 场景偏短——频繁重建 TLS 握手会显著增加延迟和 CPU 开销
- 推荐设为 300 秒（5 分钟），平衡资源占用与性能收益；高并发低活跃度场景可设为 120–180 秒
- 配置示例（放在
http或server块中）：keepalive_timeout 300s; - 注意：该值需与后端服务（如 Tomcat、Node.js）的 keepalive 设置一致，否则上游连接可能先断，引发 502
ssl_session_timeout：复用 TLS 会话，减少握手开销
它不直接限制连接时长，但通过缓存 TLS 会话状态，让后续连接跳过完整握手，间接提升“有效连接寿命”体验。
- 建议设为 4–24 小时，例如：
ssl_session_timeout 8h; - 配合会话缓存使用：
ssl_session_cache shared:SSL:10m;（10MB 共享缓存，支持约 4 万会话） - 值过大可能增加内存压力；过小则复用率下降，失去优化意义
client_header_timeout / client_body_timeout / send_timeout：分阶段控制交互节奏
这三项不是“连接总时长”，而是限定连接建立后各环节的等待上限，防止慢速攻击或异常客户端拖垮服务。
-
client_header_timeout 30s;：等待客户端发完请求头的最大时间 -
client_body_timeout 60s;：两次接收请求体数据的间隔上限（如大文件上传中断） -
send_timeout 60s;：向客户端发送响应时，两次写操作的间隔上限 - HTTPS 下这些值可比 HTTP 略宽松（因加密开销），但不宜超过 120 秒，避免资源滞留
补充：避免 TIME_WAIT 泛滥的协同配置
不当的超时设置易导致大量 TIME_WAIT 状态，尤其在反向代理场景：
- 确保
upstream块中也启用长连接：keepalive 32;（与后端保持最多 32 个空闲连接） - 后端服务（如 Tomcat）的
maxKeepAliveRequests和keepAliveTimeout需 ≥ Nginx 对应值 - 若发现 Nginx 侧大量 TIME_WAIT，优先检查是否漏配
keepalive_requests（单连接最大请求数，默认 100）或keepalive_timeout过短
