客户端在响应刚发完就断开TCP连接，Nginx为什么偶尔会丢掉尾部数据？这个问题的答案不在HTTP层，而在TCP关闭语义上。当一个进程调用close()关闭套接字时，如果接收缓冲区里还有未读取的数据，内核会认为应用层主动放弃这些数据，于是可能直接向对端发送RST报文。对于Nginx来说，这意味着客户端可能还没读完响应内容就收到RST，导致页面截断或请求失败。lingering_close指令提供了一种延迟关闭机制，让Nginx在真正关闭连接前尽量读取并丢弃客户端发来的多余数据，使关闭过程回到正常的FIN四次挥手。
先理解问题：为什么不优雅关闭会丢数据
TCP连接的关闭与建立不同，两端都可以独立关闭自己的写方向。正常流程下，主动关闭方调用shutdown()或close()后，内核会发送FIN报文，等待对端确认并完成TIME_WAIT等状态迁移。但如果主动关闭方在接收缓冲区中仍有未读数据，调用close()会让内核直接丢弃这些数据，同时向对端发送RST复位报文。客户端一旦收到RST，会立即终止连接，即使它还没有读完对端发来的响应数据。
Nginx处理HTTP请求时，客户端可能在发送完请求数据后主动关闭写端，或者在使用Connection: close的请求中提前断开。如果Nginx此时已经生成了响应并准备关闭连接，直接调用close()就可能触发RST。更隐蔽的是，客户端即使正常关闭了写方向，也可能在完全读取响应前就关闭整个套接字。lingering_close的价值在于把关闭动作拆成两个阶段：先停止向客户端写入，再继续读取客户端方向的数据，直到读空或超过设定时间，最后才完全关闭连接。
这个读取和丢弃的过程看起来没有必要，毕竟这些数据可能只是HTTP流水线中的下一个请求，或者客户端误发的额外数据。但关键在于，只要Nginx在完全关闭前维持读取，内核就不会因为未读数据而发送RST，TCP连接可以按照FIN与ACK的顺序正常结束。也就是说，lingering_close并不是真的需要处理这些数据，而是通过暂时不关闭读取端来避免触发复位语义。
lingering_close 指令与配套参数
lingering_close的语法为：
http {
lingering_close on;
lingering_time 30s;
lingering_timeout 5s;
server {
listen 8080;
server_name localhost;
location /upload {
lingering_close always;
lingering_time 10s;
lingering_timeout 2s;
}
}
}它有三个可选值：off、on、always，默认值是on，可出现在http、server、location级别。off表示Nginx在关闭连接时直接调用close()，不读取任何残留数据。这种模式释放连接最快，但客户端可能收到RST。on则是有条件地延迟关闭，Nginx会根据连接状态和协议启发式判断当前是否可能存在未读数据，如果判断有数据则进入lingering关闭流程。always最为保守，无论连接上是否还有数据，都会无条件地先停止写入并等待读取，直到超时或读空。
与它直接配合的还有lingering_time和lingering_timeout。前者限制整个延迟关闭阶段的最长持续时间，默认30秒；后者是两次读取操作之间的最大空闲时间，默认5秒。比如某个客户端断开后每隔1秒发来一个字节，lingering_timeout不会触发，但lingering_time会在达到总时长后强制关闭连接。这两个参数决定了连接停留在半关闭状态的时间上限，过大会占用文件描述符，过小则可能来不及读空缓冲区。
需要注意的是，这套机制主要作用于Nginx与下游客户端之间的HTTP/1.x连接。对于HTTP/2连接，Nginx通过GOAWAY帧和流的关闭状态来管理连接，虽然底层TCP关闭仍然会涉及linger行为，但应用层语义已经不同。因此如果站点主要使用HTTP/2，不应只依赖lingering_close来保证响应完整性。
用抓包对比 on 与 off 的实际行为
要确认lingering_close是否真正影响TCP关闭过程，可以搭建一个最小实验。思路是让客户端发送一个带Connection: close的GET请求，收到响应后不立即关闭，而是再发送一段额外数据，然后立刻关闭整个套接字。服务端如果开启lingering_close on，会先进入延迟关闭并读取这段额外数据；如果设置为off，则可能在未读数据存在时直接关闭，从而向客户端发送RST。
下面是一个简单的Nginx配置，监听8080端口：
server {
listen 8080;
server_name localhost;
lingering_close on;
lingering_time 5s;
lingering_timeout 1s;
location / {
return 200 "ok";
}
}客户端可以用Python的socket模块编写。请求头中的Connection: close告诉Nginx在响应结束后关闭连接，客户端收到响应后再发送字符串extra data，模拟连接缓冲区中未被Nginx读取的数据。
import socket
s = socket.create_connection(("127.0.0.1", 8080))
s.sendall(b"GET / HTTP/1.1\r\nHost: localhost\r\nConnection: close\r\n\r\n")
resp = s.recv(4096)
print(resp.decode(errors="replace"))
s.sendall(b"extra data")
s.close()在服务端抓包：
sudo tcpdump -i lo tcp port 8080 -S -nn -tttt
开启lingering_close on时，抓包中通常可以看到服务端先发送FIN，客户端回复ACK，随后服务端读取数据，最终以FIN/ACK序列正常结束。将配置改为off并重载Nginx后再执行同一客户端脚本，较大概率会看到服务端在收到extra data后直接回复RST，客户端返回类似connection reset by peer的错误。这个对比直观说明了该指令的底层价值。
当然，实验是否每次都能复现RST与客户端发送数据的时机、接收缓冲区大小和操作系统协议栈行为有关。为了保证对比效果，可以在客户端发送extra data前不做任何休眠，并且多跑几次。生产环境中，这种差异可能表现为偶发的资源加载失败、API调用异常，或者日志中出现大量reset相关信息。
生产调优建议与常见误区
对于绝大多数Web服务，保持lingering_close默认开启是合理的。默认的30秒延迟关闭和5秒读取超时已经足够覆盖正常网络波动。过早关闭可能引入难以排查的偶发RST问题，尤其是在客户端通过代理、负载均衡或NAT设备访问时，这些中间设备对RST更加敏感，可能提前断开用户连接。
但在某些高并发长连接场景下，可以适当调整参数。例如静态资源服务器通常响应体积小、客户端行为相对规范，保留默认值即可。对于需要承载大量短连接、并且客户端频繁异常断开的API网关，可以考虑将lingering_time调小到5至10秒，同时把lingering_timeout调到1至2秒，以缩短连接半关闭状态的占用。如果已经确认客户端侧不会因为RST产生问题，也可以对特定location设置lingering_close off，但必须经过抓包验证。
常见误区是把lingering_close与keepalive_timeout、proxy_ignore_client_abort混为一谈。keepalive_timeout控制的是连接在两次请求之间的存活时间，与关闭时的linger阶段没有直接关系；proxy_ignore_client_abort决定客户端断开后Nginx是否继续读取上游后端的响应并写回，而lingering_close只影响Nginx与客户端之间的TCP连接如何结束。另一个误解是认为关闭lingering_close能让Nginx性能显著提升。实际在现代Linux内核中，延迟关闭的额外开销很小，盲目关闭反而可能让偶发错误更难排查。
监控方面，可以通过ss -tan观察连接是否大量处于CLOSE_WAIT或FIN_WAIT2状态。CLOSE_WAIT通常表示应用层没有及时调用close()，如果持续增长可能说明linger阶段过长或某些代码路径未关闭连接；FIN_WAIT2则与对端未及时关闭有关。结合tcpdump抓包分析RST报文来源，可以更准确地判断是否需要调整参数。
总的来说，lingering_close是Nginx在TCP层面对HTTP响应完整性的重要保护。它解决的不是性能问题，而是关闭语义上的正确性问题。调优时优先保留默认开启状态，仅当监控数据明确显示连接堆积与linger相关时，才考虑缩短时间或在特定场景下关闭。任何变更都应通过抓包确认客户端不再收到意外RST。
