Nginx 在处理客户端请求时，如果客户端在规定时间内没有完成数据发送或接收，就会触发超时机制并关闭连接。默认情况下，Nginx 调用 close() 函数向客户端发送 FIN 包，进入正常的 TCP 四次挥手流程。这种优雅关闭方式在大多数场景下没有问题，但如果客户端已经崩溃或者网络异常，服务端可能会长时间停留在 FIN_WAIT2 状态，占用文件描述符和内存资源。reset_timedout_connection 指令正是为解决这个问题而设计的，它可以在连接超时发生时直接发送 RST 包，强制终止连接，让内核立即回收相关资源。下文会从 TCP 协议行为切入，说明这个指令的配置方法和使用边界。
reset_timedout_connection 指令的作用与底层原理
TCP 连接关闭存在两种典型方式。一种是标准四次挥手，主动关闭方发送 FIN 包，对端回复 ACK 后再发送自己的 FIN，最后经过 TIME_WAIT 等待后完全关闭。这个过程能够保证双方数据都传输完毕，但前提是对端能够正常响应。如果对端进程崩溃、网络中断或者防火墙丢包，FIN 包就得不到回应，主动关闭方会陷入 FIN_WAIT1 或 FIN_WAIT2 状态，直到系统参数设定的超时时间耗尽。另一种是发送 RST 包，这是一种异常终止信号，接收方收到后会立即释放连接，不进行任何等待或确认。
Nginx 中 reset_timedout_connection 指令的取值只有 on 和 off，默认是 off。当指令开启时，Nginx 在检测到连接因超时而被中断的情况下，会通过设置套接字选项 SO_LINGER 的超时时间为 0 来触发 RST 包发送。具体来说，当应用调用 close() 且 SO_LINGER 被设置为 0 时，内核不会尝试发送缓冲区的数据，而是直接发送 RST 并释放套接字。这种机制跳过了 FIN 握手阶段，因此能迅速回收文件描述符、端口和内存对象，对高并发场景下的资源周转非常有利。
需要注意的是，reset_timedout_connection 只针对超时导致的连接关闭生效，并不会影响正常的请求完成或者 keepalive 连接优雅关闭。Nginx 中很多超时指令都会触发这个行为，例如 client_header_timeout 控制读取请求头的超时时间，client_body_timeout 控制读取请求体的超时时间，send_timeout 控制向客户端发送响应的超时时间。只要这些超时发生，并且 reset_timedout_connection 处于开启状态，连接就会被 RST 强制断开。
在 Nginx 中配置 reset_timedout_connection
该指令可以出现在 http、server、location 三个配置层级中，较低层级的配置会覆盖较高层级。通常建议在 http 块中统一开启，然后针对某些特殊 location 单独关闭，例如文件下载、大响应传输等需要客户端完整接收数据的场景。下面给出一个基础配置示例。
http {
# 开启超时连接重置
reset_timedout_connection on;
# 设置各阶段超时时间
client_header_timeout 10s;
client_body_timeout 30s;
send_timeout 30s;
server {
listen 80;
server_name ipipp.com;
location /download/ {
# 下载场景关闭 RST，避免客户端下载中断
reset_timedout_connection off;
}
location /api/ {
# API 场景保持开启，快速回收异常连接
reset_timedout_connection on;
}
}
}
上面配置中，http 块全局开启后，所有普通请求在超时后都会收到 RST。但 /download/ 路径被单独设置为 off，这样即使下载过程中客户端速度过慢触发 send_timeout，Nginx 也会走正常的 FIN 关闭流程，客户端有机会完成最后的响应接收。对于 /api/ 路径，显式开启可以保证在客户端掉线或恶意慢速攻击时，服务端能快速断开连接。
很多开发者会混淆 reset_timedout_connection 与 keepalive_timeout 的关系。keepalive_timeout 控制的是客户端完成一次请求后，连接保持空闲的时间。当这个时间到期时，Nginx 会主动发送 FIN 包关闭连接，这是完全正常且优雅的关闭过程，不会触发 RST。只有在读取请求数据、发送响应数据等过程中发生超时，才会受到 reset_timedout_connection 的影响。因此，如果只想优化 keepalive 空闲连接的回收速度，调整 keepalive_timeout 就足够了，不需要开启 RST。
适用场景与潜在风险
reset_timedout_connection 最典型的应用场景是高并发短连接服务，例如 API 网关、动态接口、反向代理后端。这类服务中，客户端通常不会传输大文件，连接生命周期短，如果因为网络抖动或客户端异常导致超时，长时间停留在 FIN_WAIT2 状态会迅速消耗服务器资源。开启该指令后，超时连接会被立即清理，避免资源耗尽。另一个重要场景是防御慢速攻击，攻击者可能会缓慢发送请求头或请求体，故意占用连接。配合较小的 client_header_timeout 和 client_body_timeout，开启 RST 重置可以让攻击连接无法长时间存活。
然而，RST 强制断开也有明显副作用。对于需要完整传输数据的场景，例如大文件下载、视频流媒体、软件更新包分发等，如果响应发送过程中客户端网络抖动触发了 send_timeout，直接发送 RST 会让客户端收到 Connection reset by peer 错误，已经接收的部分数据可能无法使用，用户体验较差。因此这些场景应该将 reset_timedout_connection 设置为 off，让 Nginx 尽可能完成 FIN 关闭流程，至少客户端有机会保存部分数据。
另一个潜在风险是负载均衡或代理场景中的连接重置传播。如果 Nginx 作为反向代理，并且开启了 proxy_connect_timeout 或 proxy_read_timeout 相关超时，reset_timedout_connection 并不直接控制与上游服务器的连接，它只影响 Nginx 与客户端之间的连接。但若客户端连接被 RST 重置，Nginx 到上游的请求可能已经被处理完成，这会带来一致性问题。因此在设计多层架构时，需要明确每一层的超时与关闭策略，避免因底层 RST 导致业务逻辑异常。
与其他超时指令的协同及性能优化
要让 reset_timedout_connection 发挥最大作用，必须合理配置与之相关的超时参数。client_header_timeout 控制读取请求头的最大等待时间，默认是 60 秒，对于公网服务可以适当调小到 10 秒左右。client_body_timeout 控制读取请求体的超时，如果业务涉及文件上传，需要根据上传大小和客户端带宽调整，不能设置得过短。send_timeout 控制两次成功写操作之间的间隔，超过这个时间没有数据发送就会触发超时。这三个参数在开启 RST 重置后，都会在被触发时直接导致连接 RST，所以需要结合业务容忍度来设定。
从系统层面看，开启 reset_timedout_connection 可以减少 FIN_WAIT2 和 TIME_WAIT 状态的连接数量，因为 RST 关闭不会进入 TIME_WAIT 状态。TIME_WAIT 是四次挥手后主动关闭方必须经历的等待阶段，用于确保对端收到最后的 ACK。RST 重置则没有这个阶段，内核会立即回收套接字。可以使用 ss -s 命令查看 TCP 连接状态分布，对比开启前后的 FIN_WAIT2 和 TIME_WAIT 数量变化。在高并发压测中，开启该指令通常能提高短连接场景下的每秒请求处理能力，因为连接回收速度更快。
不过，RST 重置也可能带来新的问题。例如某些客户端或中间网络设备对 RST 比较敏感，会在收到 RST 后立即断开整个会话，甚至影响同一条 TCP 连接上的其他请求（HTTP/2 或 keepalive 场景）。因此，启用后需要观察业务日志和监控，确认没有大量客户端报告连接被重置。如果发现问题，可以针对特定 location 关闭该指令，或者调整超时阈值，在资源回收和用户体验之间取得平衡。
Nginxreset_timedout_connection超时连接修改时间：2026-10-02 23:27:54