client_body_timeout用于限制客户端发送请求体时两次数据包间的最大空闲时间，超时即返回408；它专防慢速攻击而非大文件总上传时长，需配合client_header_timeout、client_max_body_size等协同防御。
client_body_timeout 不是用来限制整个上传耗时的，而是控制客户端发送请求体过程中，两次数据包之间的最大空闲时间。它真正起作用的场景，是识别和阻断慢速上传类攻击（如 Slowloris 变种），而不是防止大文件传太久。
它怎么识别慢速上传攻击
当用户发起 POST 或 PUT 请求并开始发送 body 数据后，Nginx 会持续监听 TCP 数据流。只要客户端在 client_body_timeout 设定的时间内没发下一段数据，连接就会被主动关闭——哪怕总共才传了 1KB，且后续还有 99MB 没发。
这种机制对以下行为特别敏感：
- 攻击者每 15 秒只发一个字节，设为 10s 就能立即断连
- 中间网络抖动导致重传延迟，超过阈值也会误杀
- 移动设备切网、休眠唤醒后继续上传，间隔可能超限
不同业务场景的合理取值
不能统一设成 5s 或 60s，得看实际传输模式：
- 普通表单提交（文本为主）：10–20 秒足够，建议 15s
- 后台 CMS 或管理端文件上传（支持百 MB）：body 传输本身可能断续，设 300s（5 分钟） 更稳妥
- 移动端 API（含图片/语音上传）：网络不可靠，建议 60–120s，避免频繁超时重试
- 流式上传接口（如分片上传、断点续传）：应由业务层控制节奏，Nginx 层可设 60s，但需确保客户端按约定频率心跳保活
配合其他参数才能真正防攻击
单靠 client_body_timeout 不足以防御完整攻击链，必须组合使用：
- client_header_timeout 要同步调整，防止攻击者卡在 header 阶段不发 body
- client_max_body_size 必须设合理上限，避免小包慢传最终塞满磁盘临时目录
- client_body_buffer_size 和 client_body_temp_path 要确认磁盘空间与权限，否则超限会直接 413 错误，掩盖真实攻击行为
- 搭配 limit_conn 限制单 IP 连接数，防止攻击者开大量慢连接耗尽 worker
如何验证配置是否生效
用 curl 模拟慢速上传测试最直接：
curl -X POST http://your-domain.com/upload \-H "Content-Type: application/octet-stream" \
--data-binary "@large-file.bin" \
--limit-rate 1000
再配合 tcpdump 或 Nginx access log 中的 $status 和 $request_time 字段，观察是否在预期时间内返回 408，并检查 error log 是否出现 "client timed out" 提示。
