send_timeout仅管控nginx向客户端发送响应时两次写操作间的空闲超时，专防slow read攻击；不干预请求头/体接收、空闲连接或后端响应慢等问题，需配合reset_timedout_connection等配置生效。

send_timeout 本身不能“防止”慢速攻击，但它能快速切断已被建立、却在响应阶段故意慢读的连接，从而保护 Nginx 的 worker 进程和 socket 资源不被长期占用。它专治 Slow Read（慢读） 类攻击，是防御 Slowloris 攻击链中关键一环。

send_timeout 管什么、不管什么

• 它只监控 Nginx 向客户端发送响应数据时，两次成功写操作之间的空闲等待时间
  比如：发完第一个 TCP 包后，等了 25 秒才发第二个——哪怕整个响应只用了 30 秒，也会触发超时断连

• 它不负责以下环节：

  • 请求头接收太慢 → 由 client_header_timeout 控制
  • 请求体上传太慢 → 由 client_body_timeout 控制
  • 连接建立后一直空闲不发请求 → 由 keepalive_timeout 控制
  • 后端（如 PHP-FPM）响应慢 → 应调 proxy_read_timeout 或 fastcgi_read_timeout

在 http 块中合理配置 send_timeout

• 推荐值设为 15–30 秒

  • 小于 10 秒可能误杀弱网用户（如地铁隧道中短暂失速）
  • 大于 60 秒等于给攻击者留出充足拖延空间

• 必须放在 http{} 块顶层，全局生效

  http {
      send_timeout 20s;
      reset_timedout_connection on;
      client_header_timeout 10s;
      client_body_timeout 20s;
      keepalive_timeout 15s;
      # 其他配套项...
  }

• 静态资源服务可更激进：设为 10–20 秒
  因为 JS/CSS/图片本应秒级传输完成，拖得越久越可疑

• 流式接口（SSE、长轮询、大文件下载）需单独处理
  在对应 location 中提高值，并关闭缓冲：

  location ~ \.(mp4|pdf|zip)$ {
      send_timeout 120s;
      proxy_buffering off;
  }

必须搭配的关键配置才能真正起效

• reset_timedout_connection on;
  让 Nginx 超时后发 RST 强制断连，而非 FIN 等待四次挥手，避免大量 TIME_WAIT 占用 socket

• tcp_nodelay on;
  关闭 Nagle 算法，防止小包攒批发送造成“假卡顿”，让超时判断更准确

• limit_conn_zone $binary_remote_addr zone=addr:10m; + limit_conn addr 5;
  单 IP 并发连接数兜底限制，防住漏网之鱼

• keepalive_timeout 15s;
  缩短空闲长连接生命周期，减少被复用为慢速通道的机会

如何验证是否生效

• 用 curl 模拟慢速客户端：

  curl -v --limit-rate 10 --max-time 120 http://your-site/logo.png

  观察是否在 20 秒左右断开，并返回 408 Request Timeout 或连接重置

• 查看 error.log 是否出现：
  client timed out (110: Connection timed out) while sending response to client

• 检查 access.log 中是否有大量状态码 499（Nginx 主动关闭连接）

• 对比 ss -tan state time-wait | wc -l 开启前后的数值变化，确认 TIME_WAIT 显著下降

不复杂但容易忽略