lingering_close off 不是加速连接释放的“开关”，而是关闭延迟关闭行为的指令，它使 nginx 在收到客户端 fin 后立即响应 ack+fin（或 rst），推动 socket 快速进入 closed 状态，避免堆积在 time_wait 或 close_wait；在低延迟、零丢包、无 nat 的内网微服务场景中安全高效，需配合 keepalive_timeout、reset_timeout_connection 等参数协同优化。
lingering_close off 本身不是加速连接释放的“开关”，而是一个关闭延迟关闭行为的指令——但它在内网微服务场景中是否启用、如何配合其他参数使用，直接影响套接字（socket）能否快速进入 CLOSED 状态，避免堆积在 TIME_WAIT 或卡在 CLOSE_WAIT。
关键点在于：lingering_close off 不等于“立刻断开”，而是放弃等待客户端 FIN-ACK 的完整四次挥手收尾，由内核按 TCP 状态机自然推进。在受控内网中，这是安全且高效的策略。
? 为什么在内网微服务集群中可放心设为 off
内网环境具备确定性网络特征：
- 延迟低（通常
- 客户端（如 Spring Cloud Gateway、Envoy、或另一台 Nginx）行为可控、协议栈标准
- 无 NAT、无中间代理干扰 FIN/RST 传递
- 连接生命周期短、请求模式明确（如 gRPC/HTTP/1.1 短连 + keepalive）
此时，Nginx 默认的 lingering_close on（即等待最多 lingering_time，默认 30s）反而造成资源滞留：
→ 客户端已发 FIN 并关闭 socket，但 Nginx 还在“温柔等待”它发完剩余数据；
→ 实际早已无数据可读，白白占用 worker 连接槽位与 TIME_WAIT 槽位。
设为 off 后：
✅ 收到客户端 FIN 后，Nginx 不再阻塞读取残留数据，立即发送 ACK + FIN（或 RST），推动状态快速迁移；
✅ 减少 CLOSE_WAIT 持留时间（常见于后端未及时 close，但此处是 client → nginx 路径）；
✅ 配合合理 keepalive_timeout，让空闲长连接更干净地退出。
⚠️ 注意：
lingering_close off仅影响 主动关闭方为客户端 的连接（即 nginx 作为 server）。若 nginx 是 proxy，后端响应后主动关连接，则由proxy_ignore_client_abort和proxy_buffering控制行为，与此无关。
?️ 必须同步调优的配套参数
单设 lingering_close off 不够，需组合生效：
-
关闭 lingering 行为
lingering_close off;
-
收紧长连接空闲窗口（核心）
keepalive_timeout 15s; # 内网建议 10–30s，避免 75s 默认值 keepalive_requests 1000; # 单连接最大请求数，防老化连接滞留
-
确保连接能被及时感知关闭
client_body_timeout 10s; # 上传体超时（防慢速攻击） send_timeout 10s; # 发送响应超时（防后端卡住） reset_timeout_connection on; # 客户端静默时允许强制关闭（Nginx 1.21.4+）
-
TCP 层辅助（系统级）
# /etc/sysctl.conf（适用于 Linux 内核 4.1+） net.ipv4.tcp_fin_timeout = 30 # 缩短 TIME_WAIT 超时（默认 60） net.ipv4.tcp_tw_reuse = 1 # 允许 TIME_WAIT 套接字重用（仅对 client 有效，内网 safe） net.core.somaxconn = 65535 # 提升 accept 队列长度
? 效果验证方式
部署后可通过以下方式确认优化生效：
-
查看连接状态分布（重点关注
TIME_WAIT是否下降）：ss -s | grep -E "(time|close)" ss -tn state time-wait | wc -l
-
抓包验证 FIN 流程是否缩短（对比开启/关闭
lingering_close）：tcpdump -i any port 80 -w nginx_linger.pcap # 观察 FIN → ACK → FIN → ACK 是否在 1–2 秒内完成
检查 Nginx stub_status 输出中的
Active connections与Reading/Writing/Waiting比例是否更健康（Waiting 应稳定在较低水平）。
✅ 小结：内网微服务下最简高效配置片段
http {
# 连接生命周期控制
keepalive_timeout 15s;
keepalive_requests 1000;
lingering_close off;
reset_timeout_connection on;
# 请求/响应超时
client_body_timeout 10s;
send_timeout 10s;
# 性能基础
sendfile on;
tcp_nopush on;
tcp_nodelay on;
multi_accept on;
}
这套组合在典型 Kubernetes + Istio 或 Spring Cloud Alibaba 微服务内网中，可将平均连接释放耗时从秒级降至亚秒级，显著降低 netstat -an | grep :80 | wc -l 峰值连接数，同时不牺牲稳定性。
