lingering_close用于已通过tls握手但http请求解析失败的连接，不处理tls握手失败；推荐配置lingering_time 5s、lingering_timeout 1s，确保异常连接快速释放而不占用worker资源。
lingering_close 是 Nginx 处理“半失败”HTTP 连接的关键机制，它不用于 TLS 握手失败（此时连接根本未进入 HTTP 层），而是针对已通过 TLS 握手、却在读取请求行或 headers 时出错的连接——比如客户端发了乱码、截断请求、或超时中断。这类连接若直接粗暴关闭，可能丢弃残留数据；若不加约束地 linger，又会卡住 worker 连接数。调优目标是：**让异常连接快速释放，不拖累正常服务**。
明确 lingering_close 的适用边界
它只对已建立 HTTP 会话但早期解析失败的连接生效。TLS 握手失败、TCP RST、SYN 超时等底层问题，Nginx 不走 lingering 流程。因此：
- 不要指望它解决 HTTPS 握手慢或证书错误导致的连接堆积
- 它真正起作用的场景是：客户端发送了不完整或畸形的 HTTP 请求头后断开
- 默认开启（lingering_close on）是合理选择，覆盖大多数真实 HTTP 层错误
收紧 lingering_time 和 lingering_timeout
这两个参数共同控制 linger 行为的持续时间和退出条件：
- lingering_time：允许 linger 状态持续的总时间（单位秒），默认 30s —— 对失败连接来说太长
- lingering_timeout：每次尝试读取残留数据的超时（单位秒），默认 5s
建议配置为：
lingering_time 5s;<br>lingering_timeout 1s;
这样最多尝试 5 次读取，每次等 1 秒，总耗时不超过 5 秒。既避免丢数据风险，又防止连接滞留过久占用连接槽位。
配合 keepalive_timeout 做协同控制
lingering_close 解决的是“坏请求”的善后，而 keepalive_timeout 控制的是“好连接”的空闲寿命。两者需错位设置：
- keepalive_timeout 设为 30–60s（如 keepalive_timeout 45s）
- lingering_time 必须显著小于它（如 5s），否则 linger 会抢在 keepalive 超时前长期占位
- 同时配 keepalive_requests 500，让高频率小请求主动触发连接回收，减少 linger 触发概率
注意与 proxy_ignore_client_abort 的配合
当后端是代理模式时，若客户端中途断开，Nginx 默认会继续把请求发给后端（proxy_ignore_client_abort off）。这可能导致后端白忙一场，也延长了连接生命周期。
- 若业务可接受丢弃中断请求，设为 proxy_ignore_client_abort on
- 此时 lingering_close 仍有效：Nginx 在发现客户端 FIN 后，按 lingering_time/timeout 清理本地状态
- 但不再向后端转发，整体资源释放更快
