send_timeout是Nginx控制响应发送阶段两次写操作间最大空闲时间的参数，仅防worker被慢速读卡住，不干预请求接收、空闲连接或后端响应；静态服务建议设10–30秒，并需配合reset_timedout_connection on生效。

send_timeout 是 Nginx 主动释放“慢速读响应”连接的关键开关，它不防攻击本身，而是防止一个已建立的连接在发送响应时长期卡住 worker 进程。

send_timeout 管什么、不管什么

它只控制 Nginx 向客户端发送响应数据过程中，两次写操作之间的最大空闲时间。比如：Nginx 已准备好 1MB 静态文件要发，但客户端接收窗口极小、网络丢包严重或故意缓慢读取，导致 Nginx 发出一部分后，迟迟等不到下一次可写事件——此时 send_timeout 触发，直接断连。

它不管以下情况：

• 客户端发请求头有多慢（那是 client_header_timeout 的职责）
• 客户端传请求体有多慢（归 client_body_timeout 管）
• 连接建立后一直空闲不发请求（由 keepalive_timeout 处理）
• 后端响应慢（那是 proxy_read_timeout）

静态资源场景下的合理取值

对纯静态文件服务（如图片、JS、CSS），send_timeout 不宜设长，因为这类响应本应快速完成，拖得越久越可能是异常行为：

• 普通静态站：设为 10–20 秒 即可。99% 的浏览器和 CDN 节点都能在毫秒级完成接收
• 面向弱网移动设备的资源站：可放宽到 30 秒，但需配合日志观察真实 P95 发送耗时
• 绝对不要设为 0 或极大值（如 300 秒），否则一个慢速下载会独占 worker 直至超时，放大 Slow Read 攻击效果

必须搭配 reset_timedout_connection 才真正释放资源

仅设 send_timeout 不够。默认情况下，Nginx 超时后发 FIN 关闭连接，对方可能不响应，连接停留在 TIME_WAIT 状态，socket 资源未被立即回收。

加上这行配置，才能让超时断连更“果断”：

reset_timedout_connection on;

该指令让 Nginx 直接发送 RST 包强制中断，worker 可立即复用该连接槽位，避免因大量半关闭连接挤满连接表。

验证是否生效的简单方法

• 用 curl -v --limit-rate 10 http://your-site/logo.png 模拟低速客户端，观察是否在设定秒数内断开并返回 408 或连接重置
• 检查 error.log 是否出现 client timed out (110: Connection timed out) while sending response to client
• 用 ss -tan state time-wait | wc -l 对比开启前后 TIME_WAIT 数量变化