client_body_timeout在移动端弱网环境的核心作用是匹配真实传输节奏，60–120秒内设值可兼顾拦截慢速攻击与容忍网络抖动、切网唤醒等合法延迟，且仅对已收完请求头并进入body接收阶段的连接生效，超时即返408。
移动端弱网环境下，client_body_timeout 的核心作用不是“压低数值”，而是匹配真实传输节奏——既要拦住每30秒才发1字节的慢速攻击，又不能因网络抖动、切网唤醒或代理重传误杀合法请求。
理解它在移动端的真实触发逻辑
该参数只在以下条件同时满足时开始计时：
- 客户端已完整发送 HTTP 请求头（含
Content-Length或Transfer-Encoding: chunked） - Nginx 收到空行后，进入接收 body 阶段
- 此后任意两次 TCP 数据包之间空闲时间超过设定值，立即断连并返回
408 Request Timeout - 注意：它不管总上传耗时，也不重置计时器——哪怕已传99%，最后1%停顿超时仍会中断
推荐取值：60–120 秒，按链路稳定性微调
统一设 60s 是多数场景的平衡点；若后端接入了运营商代理、CDN 或存在频繁休眠唤醒行为，可放宽至 90–120s：
- 纯 JSON API（如登录、提交表单）：60 秒足够。正常 App 在 TLS 握手+序列化后，5–10 秒内完成 body 发送
- 含图片/语音上传的接口：90 秒起步。弱网下重传、DNS 缓存失效、中间网关缓冲都可能造成 20–40 秒静默
- 使用分片上传协议的场景：仍设 60 秒，但要求客户端每 30 秒至少发送一个分片头或心跳字段，否则视为异常连接
必须同步配置的关键配套项
单设 client_body_timeout 在移动端几乎无效，需组合防御：
-
配
client_header_timeout 15–30s：防攻击者卡在 header 阶段不发 body，尤其应对带 JWT 或多 Cookie 的复杂鉴权头 -
开
reset_timedout_connection on：超时后发 RST 包，立刻释放 socket 句柄，避免 TIME_WAIT 堆积影响新连接建立 -
限大小：
client_max_body_size 20M：超出直接返回 413，不进 timeout 流程；防止攻击者声明 1GB 却只慢速发几字节 -
调缓冲：
client_body_buffer_size 128k：小请求体进内存，减少磁盘 I/O 和等待延迟；大上传不建议盲目调高，易被慢连接长期持占内存 -
控并发：
limit_conn perip 10：限制单设备/IP 最多 10 个并发连接，避免恶意客户端开几十个慢连接打满 worker
验证是否真正生效
别只看配置写了没，要实测弱网模拟效果：
- 用
curl -X POST --data-binary @/dev/stdin http://host/api手动输入 body，中途暂停 65 秒，观察是否返回 408 - 查 Nginx error log，确认出现
client timed out (110: Connection timed out) while reading client request body - 结合 tcpdump 抓包，确认超时后是否发出 RST 包（而非 FIN），确保连接资源即时回收
