Nginx 中 Server 配置如何设置 lingering_close 优化慢连接的断开处理

作者：袖梨 2026-08-21

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。