client_body_timeout防慢速POST攻击，即限制两次TCP数据包间空闲时间而非总上传时长；需按业务设值：API用15–25s、文件上传配300s+大小限制、移动端60–120s，并须协同client_header_timeout、limit_conn等组合防御。
要让 client_body_timeout 真正起效，关键不是压低数值，而是精准匹配业务数据节奏，同时切断“只发头、不发体”或“每几十秒才送1字节”的恶意连接。
它到底防什么、怎么触发
这个参数只在以下条件同时满足时开始计时：
- 请求已完整收到 HTTP 头（含
Content-Length或Transfer-Encoding: chunked） - 空行之后，客户端开始发送 body 数据
- Nginx 在两次 TCP 数据包之间等待超时——不是总上传时间，而是“停顿太久”
攻击者正是利用这点：发完 POST /api 和头后，就卡住不发 body；或每 20 秒发一个字节。若你设为 60s，Nginx 就会等满 60 秒才断连，期间 worker 被锁死，无法服务其他请求。
按场景设合理值
统一设 60s 或 10s 都容易出问题。应结合真实传输行为来定：
- 纯 JSON API（无文件）：15–25 秒。正常客户端完成 TLS 握手、序列化、网络发送，10 秒内基本传完 body
- 管理后台文件上传（如 CMS 表单）：300 秒（5 分钟），但必须配
client_max_body_size 100m，防止攻击者用超大 body 拖长总耗时 - 移动端接口（含图片/语音）：60–120 秒。弱网重传、切网唤醒易造成短暂中断，过短会导致大量 408
- 流式上传或分片接口：设 60 秒，但要求客户端按约定频率（如每 30 秒）发心跳或续传数据包
单靠它不行，必须组合防御
慢速 POST 是链式攻击，仅调 client_body_timeout 会被绕过：
- 同步调优
client_header_timeout（建议 10–30 秒），防攻击者卡在 header 阶段不发 body - 启用缓冲：
client_body_buffer_size 128k，小 body 直接进内存，减少磁盘依赖和等待 - 限制连接数：
limit_conn perip 10，防单 IP 开一堆慢连接耗尽worker_connections - 反向代理场景下，
proxy_read_timeout应略大于后端 P95 响应时间（建议加 20% 余量），避免 Nginx 卡在等后端时又被拖住
验证是否生效
别只看配置写了没，要实测：
- 用
curl -X POST --data-binary @/dev/stdin http://host/api手动输入 body，中途暂停超过设定值，观察是否返回 408 - 查 Nginx error log，确认出现
client timed out (110: Connection timed out) while reading client request body - 用
ss -i或tcpdump观察连接是否在超时后被 RST，而非自然关闭
