静态资源超时配置需兼顾安全与兼容：client_header_timeout 和 client_body_timeout 建议设为 8s（普通静态资源）或 15s/30s（含小上传），keepalive_timeout 推荐 15s～30s，send_timeout 设为 10s，location 级可进一步优化。
静态资源本身不涉及后端处理，但连接仍会占用 worker 进程、内存和文件描述符。合理配置超时能快速释放空闲连接，防止资源被长期占满，尤其在高并发或慢速攻击场景下很关键。
client_header_timeout 和 client_body_timeout 要设得紧凑
静态资源请求通常极快完成，客户端应在几秒内发完请求头和（如有）请求体。设太长易被 Slowloris 类攻击利用；设太短又可能误伤弱网用户。
- 普通 HTML/CSS/JS/图片等：建议 client_header_timeout 8s、client_body_timeout 8s
- 若站点含小体积上传（如头像裁剪），可放宽到 client_header_timeout 15s、client_body_timeout 30s
- 注意：client_body_timeout 不影响 GET 请求，只对 POST/PUT 等带 body 的请求生效
keepalive_timeout 控制长连接生命周期
静态资源最受益于 HTTP/1.1 keep-alive，但空闲连接不能无限保持。这个值决定“连接建立后，多久没新请求就断开”。
- 常规静态服务：设为 keepalive_timeout 15s 30s（第一个值是关闭连接时间，第二个是响应头中 Keep-Alive: timeout=30 的提示值）
- CDN 回源或内部调用场景：可适当延长至 30s～60s，减少 TCP 握手开销
- 纯 API 或移动端接口：建议 5s～10s，加快连接回收
send_timeout 防止响应卡住
该参数控制 Nginx 向客户端发送响应数据时，两次写操作之间的最大间隔。对静态文件来说，一旦开始发送，通常很快完成；但如果网络拥塞或客户端接收缓慢，它能避免单个连接长时间挂起。
- 推荐设为 send_timeout 10s
- 不要设为 0（禁用）或过大（如 60s+），否则慢客户端可能长期占用连接
- 它不影响总传输时间，只限制“停顿太久就断”
location 级别针对性优化
静态资源常放在独立 location 块（如 /static/、/images/），可在其中覆盖全局超时，更精细地控制。
- 示例配置：
location /static/ {
root /var/www/assets;
expires 1y;
add_header Cache-Control "public, immutable";
keepalive_timeout 10s;
send_timeout 5s;
}
这样既不影响动态接口的超时策略，又能对静态路径做更激进的连接回收。
