send_timeout是Nginx释放慢速读响应连接的核心参数，仅控制响应发送时两次写操作间的空闲超时（如发完一包后卡住25秒即断连），不管理请求头/体接收、空闲连接或后端响应；建议静态资源设10–20秒，需配合reset_timedout_connection on生效。
send_timeout 是 Nginx 主动释放“慢速读响应”连接的核心参数，它不拦截攻击，而是让 worker 进程不被拖住——只要客户端接收太慢，Nginx 就果断断开，腾出资源服务新请求。
明确它管什么、不管什么
它只监控响应发送阶段：Nginx 已生成响应（比如一个 2MB 的图片），开始往客户端发数据，但两次成功写操作之间空等太久（比如发完第一包后卡住 25 秒没再发），这时就触发断连。
它不管这些情况：
- 客户端发请求头慢（归 client_header_timeout 管）
- 客户端传文件体慢（归 client_body_timeout 管）
- 连接建好后一直不发请求（归 keepalive_timeout 管）
- 后端处理慢或返回慢（归 proxy_read_timeout 管）
设多少才合理
默认 60 秒太宽松，容易被 Slow Read 攻击利用。实际取值要结合业务类型：
- 普通静态资源（JS/CSS/图片）：10–20 秒足够。真实用户极少连续 15 秒完全无法接收数据
- 面向弱网移动设备的资源站：可放宽到 30 秒，但建议配合 access.log 中的
$request_time和 error.log 中的超时日志观察 P95 发送耗时 - 流式接口（SSE、长轮询）：必须在对应
location块中单独调高，并加proxy_buffering off;，否则缓冲会掩盖慢读行为
必须搭配 reset\_timedout\_connection 才真正生效
只设 send_timeout 不够。默认超时后发 FIN 关闭连接，若客户端不响应，socket 会长期卡在 TIME_WAIT 状态，资源没真正释放。
加上这行配置，才能让断连更“干净”：
reset_timedout_connection on;
它让 Nginx 直接发 RST 包强制中断，worker 可立即复用该连接槽位，避免半关闭连接挤满连接表。
验证是否起效
用低速模拟测试最直观：
- 运行
curl -v --limit-rate 10 http://your-site/logo.png（限速 10B/s） - 观察是否在设定秒数内断开，并返回 408 或连接重置
- 检查 error.log 是否出现
client timed out (110: Connection timed out) while sending response to client - 用
ss -tan state time-wait | wc -l对比开启前后 TIME_WAIT 数量变化
