lingering_close 是 Nginx 优雅处理慢连接的关键机制，默认开启（on），在响应已发送时等待残留数据或确认对端离线，避免 TIME_WAIT 泛滥和 RST 中断；可设为 off（立即关闭，慎用）或 always（始终 linger，加重资源占用），需配合 lingering_time（默认30s）和 lingering_timeout（默认5s）调优。
lingering_close 是 Nginx 用于优雅处理慢连接（如客户端缓慢读取响应、断连不规范）的关键机制，它控制连接关闭前是否等待残留数据或超时。默认开启且行为合理，但不当配置反而会加重资源占用——不是设得越长越好，也不是关掉就更“快”。
lingering_close 的作用与触发场景
当客户端发起 FIN 关闭连接，但服务端仍有未发送完的响应体（比如大文件传输中途断开），或客户端已关闭读端却迟迟不发 FIN（如移动网络瞬断），Nginx 默认会进入“linger 状态”：保持 socket 打开一小段时间，尝试收完剩余数据或确认对端真正离线。这避免了 TIME_WAIT 泛滥和 RST 强制中断带来的日志噪音或上游重试。
常见触发情况包括：
• 客户端下载大文件时突然切后台/关页面
• 移动端弱网下 TCP 连接半关闭不完整
• 使用 HTTP/1.0 且未带 Connection: close
可选值及实际影响
该指令在 http、server 或 location 块中设置，语法为：
lingering_close off | on | always;
- off：立即关闭 socket，不等待任何残留数据。适用于可信内网、短连接 API 服务，可降低连接持有时间，但可能丢弃未读响应、引发上游重试或客户端报错（如 curl 显示 “transfer closed with outstanding read data remaining”）
- on（默认）：仅当请求体已完全接收、响应已开始发送后，才启用 linger；若请求尚未完成（如 POST 数据还没收完），直接关闭。平衡性最好，推荐绝大多数 Web 服务保留此值
- always：无论请求是否完成，只要收到 FIN 就进入 linger 状态。适合需要极致连接可靠性的场景（如金融类长轮询），但会显著增加 worker 进程的连接等待数，慎用
配合 lingering_time 和 lingering_timeout 更精准控制
单独设 lingering_close 不够，必须搭配两个超时参数才能真正优化慢连接行为：
-
lingering_time（默认 30s）：linger 状态最长持续时间。建议根据业务响应体大小调整，例如静态资源服务可设为
5s，API 接口可设为10s -
lingering_timeout（默认 5s）：每次尝试 recv() 的超时。若连续多次无数据到达，提前退出 linger。设太小（如 100ms）易误判断连；设太大（如 10s）则拖慢连接释放。常规值
2s–5s较稳妥
示例配置片段：
server {
listen 443 ssl;
server_name example.com;
# 默认即可，无需显式写 on
# lingering_close on;
# 针对静态资源缩短 linger 时间
location ~ \.(jpg|png|css|js)$ {
lingering_time 5s;
lingering_timeout 2s;
}
# API 接口允许稍长一点缓冲
location /api/ {
lingering_time 10s;
lingering_timeout 3s;
}
}
验证与调优建议
修改后需观察 netstat -ant | grep :443 | grep CLOSE_WAIT 和 nginx -t && nginx -s reload；重点看 Active connections 是否异常升高，以及 error log 中是否有大量 client prematurely closed connection。
- 若日志中该错误激增 + CLOSE_WAIT 连接堆积 → 可适当延长
lingering_time或检查客户端是否真存在异常断连 - 若 worker_connections 频繁打满，且多数是 idle 状态 → 检查是否误配
always或lingering_time过长 - 生产环境不建议全局关掉 lingering_close，除非你 100% 控制客户端行为（如全为 gRPC over HTTP/2 内部调用）
