lingering_time 是仅在 server 或 location 块中有效的指令，用于设置客户端关闭连接后接收残留数据的最长时间（默认30秒），需配合 lingering_close 使用，不能置于 http 块。
在 Nginx 的 http 块中，lingering_time 并不是一个合法的配置指令 —— 它**不能直接写在 http 块里**，也不属于全局 HTTP 配置项。这个指令实际只在 location 或 server 块中有效，且必须配合 lingering_close 使用。
lingering\_time 的真实作用和生效条件
lingering_time 用于控制 Nginx 在客户端主动关闭连接后，仍保持连接打开以接收残留数据的**最长时间（单位：秒）**。它仅在启用延迟关闭（lingering_close on 或 lingering_close always）时才起作用。
- 默认值为 30 秒，即最多等待 30 秒来读取客户端未发完的数据
- 设为
0表示不等待，立即关闭连接（等效于lingering_close off） - 该指令对 HTTPS、HTTP/2 连接同样适用，但对 keepalive 连接无影响（因为 keepalive 是复用连接，不触发 lingering 流程）
正确配置位置和典型用法
必须放在 server 或 location 块中，例如：
server {
listen 80;
server_name example.com;
<pre class="brush:php;toolbar:false;"># 启用延迟关闭
lingering_close on;
# 最多等待 10 秒接收残余数据
lingering_time 10;
location /upload {
# 大文件上传场景可适当延长
lingering_time 60;
client_max_body_size 100m;
}}
-
lingering_close off：禁用延迟关闭，收到 FIN 后立即关闭（不读残余数据） -
lingering_close on：仅对非 GET/HEAD 请求启用（如 POST、PUT） -
lingering_close always：对所有请求启用（包括 GET）
为什么不能放在 http 块？
Nginx 配置指令有明确的作用域（context）。查阅官方文档可知：lingering_time 的 context 是 http, server, location，但注意——这里的 http 是指“支持在 http 块中声明”，**并不表示它能在 http 块中生效并继承给所有子块**。实际上，Nginx 源码实现中，该指令仅在 ngx_http_core_merge_loc_conf 阶段被解析，也就是说，它最终只在 location 级别起作用；若写在 http 或 server 块中，会被忽略或报错（取决于版本）。
- Nginx 1.19.0+ 版本会在启动时提示 “directive is not allowed here” 错误
- 旧版本可能静默忽略，导致配置失效却不报警
- 真正能统一控制的等效方式是：在每个需要的
server或location中显式设置
实用建议：何时调大或调小 lingering\_time
调整应基于客户端行为和业务特征，而非盲目优化：
- 调小（如 5~10 秒）：面向移动端、弱网用户较多，或服务端资源紧张（避免大量连接卡在 lingering 状态）
- 调大（如 60 秒）：处理大文件上传、客户端网络不稳定、或使用自定义协议头（需确保完整接收）
- 配合
lingering_timeout（单次 recv 超时，默认 5 秒）和lingering_close类型，才能完整控制 linger 行为
