必须启用lingering_close才能使lingering_timeout生效，它仅在客户端发送FIN后等待残留请求数据，单位为秒，默认30秒，仅在http块配置，与client_body_timeout等其他超时无关。
要精准控制 Nginx 在客户端关闭连接后读取残留数据的等待时间，关键不是单独设 lingering_timeout，而是必须配合 lingering_close 启用延迟关闭机制。它不作用于常规请求处理流程，只在 TCP 半关闭（如客户端发 FIN 后未发完数据）时生效，目的是防止请求截断，而非延长响应或上传时间。
lingering_close 是前提，必须显式开启
lingering_timeout 完全依赖 lingering_close 的状态。默认情况下该指令是 off，此时 lingering_timeout 无效。
-
lingering_close on;：仅对非 GET/HEAD 请求（如 POST、PUT、DELETE）启用延迟读取 -
lingering_close always;：对所有请求（包括 GET）都启用，适用需要强一致性的场景 -
lingering_close off;：彻底禁用，Nginx 收到 FIN 后立即关闭连接，lingering_timeout被忽略
lingering_timeout 的实际行为与单位
该值定义的是“收到 FIN 后尝试 recv() 读取残留数据”的最大持续时间，单位为秒（支持小数），默认 30 秒。它不是整个连接生命周期，也不影响 keepalive 或响应传输。
- 计时起点：客户端发送 FIN 包，Nginx 进入延迟关闭流程
- 期间动作：Nginx 循环调用系统 recv()，等待可能存在的残余请求体或 pipelined 请求
- 终止条件：读到数据、系统返回 EOF、发生错误，或达到
lingering_timeout设定值 - 超时后果：强制关闭 socket，不再等待
配置位置与典型值建议
lingering_timeout 只能在 http 块中全局设置，不能写在 server 或 location 里。是否启用及设多少，取决于你的业务容忍度和网络环境：
- 内网稳定环境、API 网关类服务：可设为
5s或10s，平衡安全与资源释放速度 - 公网面向移动端、弱网用户较多：建议保持默认
30s，避免因 TCP 重传延迟导致数据丢失 - 高并发短连接场景（如静态资源 CDN 边缘节点）：可设为
off配合lingering_close off，减少 worker 占用
不要和其它 timeout 混淆
它和以下常见超时完全无关，配置时需区分用途：
-
client_body_timeout：控制客户端上传过程中两次数据包之间的静默间隔 -
proxy_read_timeout：控制 Nginx 等待上游服务器响应的时间 -
keepalive_timeout：控制空闲长连接保持时间 -
send_timeout：控制 Nginx 向客户端回传响应时两次 write 的间隔
