client_body_timeout的调优目标是快速识别并断开节奏异常的慢速恶意连接，仅管控请求体传输中两次数据包到达的最大空闲间隔，需结合client_header_timeout、reset_timedout_connection、client_max_body_size和limit_conn等参数协同防护。
client_body_timeout 的调优目标很明确：不让慢速恶意连接长期卡在“读请求体”阶段，把 worker 进程、socket 句柄和内存缓冲区占着不放。它不是为了等用户慢慢传完大文件，而是为了快速识别“节奏异常”的连接并断开——合法上传靠节奏稳，恶意攻击靠节奏拖。
它管什么、不管什么要分清
这个参数只盯住客户端发 body 数据的节奏空闲时间，即两次 TCP 数据包到达之间的最大间隔。
- ✅ 管：POST/PUT 请求体传输过程中，“上一块数据收完”到“下一块数据开始来”之间停了多久
- ❌ 不管：整个上传花了多少分钟、请求头有没有收完、响应发没发出去、后端处理快不快
默认 60 秒太宽泛，攻击者只要每 59 秒发一个字节就能无限续命，worker 就一直挂着，直到连接数耗尽。
按业务场景设节奏阈值，别一刀切
不同上传行为的数据流节奏差异很大，超时值必须匹配真实数据节奏：
普通表单提交（JSON、文本、小图）：设为 10–20 秒
浏览器和主流 SDK 发送稳定，弱网抖动一般不超过 3–5 秒，留足余量又防慢速移动端 API（头像、语音、日志上报）：设为 15–30 秒
蜂窝切换、App 后台唤醒可能导致短暂停顿，但超过 30 秒基本就是异常或攻击大文件后台上传（PDF、Excel、CMS 资源）：不靠它控总时长，而是设为 300 秒（5 分钟），但必须配套
client_max_body_size 100M和limit_conn perip 5
防攻击者声明 2GB Content-Length 却每分钟只发 1 字节，靠大小限制+连接数限制+节奏超时三重卡位分片/流式上传接口：仍设 60 秒，但要求客户端每 30 秒至少发送一个分片头或心跳包
节奏由业务层定义，Nginx 只做兜底：没心跳＝连接失效
必须同步启用的防护组合，单调没用
只改 client_body_timeout 相当于只关一扇窗，攻击者会从其他门溜进来：
-
client_header_timeout 10s：防攻击者卡在 header 阶段不发 body，头收不完就断 -
reset_timedout_connection on：超时后立刻发 RST 包，释放 socket 句柄，避免 TIME_WAIT 堆积 -
client_max_body_size设合理上限（API 接口 10–20M，后台上传 100–200M）：超限直接 413，不进 timeout 流程 -
limit_conn perip 10：单 IP 最多 10 个并发连接，防几十个慢连接齐发打满 worker
这几个参数缺一不可，否则调低 client_body_timeout 可能引发误杀，调高又等于放行。
验证是否真起效，不能只看配置写了没
光 reload 配置不算完成，得实测两个关键行为：
- 用
curl --limit-rate 100模拟极慢上传（如每秒 100 字节），观察是否在设定值内返回 408，并检查 error log 出现client timed out while reading client request body - 抓包看连接关闭方式：合法超时应看到 Nginx 主动发出 RST 包，而不是等 FIN/ACK 完成——这才是真正释放资源
不复杂但容易忽略
