lingering_timeout必须配合lingering_close生效，控制客户端FIN后服务端读残留数据的等待时长，默认30秒；合理设值为3–10秒，过短丢请求体、过长拖慢吞吐，仅对POST/PUT等带body请求有意义。
lingering_timeout 不是独立生效的参数，它必须配合 lingering_close 才起作用，本质是控制“客户端主动断开后、服务端仍尝试读残留数据”的最大等待时长。调优目标不是让它更长，而是设得足够但不过度——太短可能丢请求体，太长会堆积连接、拖慢吞吐。
lingering_timeout 的作用边界要清楚
- 它只在客户端发 FIN 后触发，且仅当
lingering_close on或always时才进入延迟读阶段 - 不影响 keepalive 连接，也不干预服务端主动关闭（如超时或错误终止）
- 默认 30 秒，单位是秒（支持小数，如
5.5s），不是毫秒
合理设值的关键判断依据
-
对 POST/PUT 等带请求体的请求：如果客户端可能发送不完整数据（比如少一个
\r\n、中断上传），留 3–10 秒足够探测残余内容 -
纯 GET/HEAD 且无 body 场景：若已设
lingering_close on，其实无需 linger，可直接设5s或更低 -
高并发短连接网关（如 API 前端）：建议
3s–5s，避免大量连接卡在 linger 阶段占用 worker 进程 -
后端是 FastCGI/gRPC/HTTP2 代理：通常不依赖 linger 读取，可设
off或lingering_close off彻底跳过
典型安全配置组合
http {
# 仅对非 GET/HEAD 请求启用延迟关闭（最常用）
lingering_close on;
# 5 秒内尝试读完残留数据，超时即强制关连接
lingering_timeout 5s;
# 其他配套建议（非必须但推荐）
keepalive_timeout 60s;
client_header_timeout 10s;
client_body_timeout 10s;
}别踩的坑
- ❌ 设为
0：等同于禁用探测，可能截断未收完的请求体 - ❌ 设为
30s+：尤其在每秒数百次短连接场景下，容易导致 worker 连接数虚高、响应延迟上升 - ❌ 忘记同步检查
lingering_close：单独改lingering_timeout没效果 - ❌ 在
server或location块里配：它只能在http块生效
验证是否生效，可用 curl -X POST http://your.site --data-binary @large-file.bin 模拟发送中途断开，观察响应延迟是否接近你设的 lingering_timeout 值。
不复杂但容易忽略
