proxy_send_timeout仅控制nginx向后端发送已收完请求体时的空闲超时,需满足非长连接、已收完body等条件才生效;设值须按上传体积与带宽估算,并同步配置client_body_timeout和client_max_body_size。

proxy_send_timeout 不是“让后端慢慢收也没事”的兜底开关,它只管 Nginx 向后端发送已收完请求体(比如大文件、Base64 参数、流式 JSON)时,等待后端确认接收的空闲时间。设得过小会中断上传,设得过大又可能积压连接。关键在算准、配齐、放对位置。
先看它到底在哪起作用
这个参数仅在以下条件同时满足时才生效:
- Nginx 已完整接收客户端的请求体(靠 client_body_timeout 和 client_max_body_size 先把关)
- 使用的是非长连接(每次请求新建 TCP 连接)
- 正在把 body 分块发给后端,但某次发出后迟迟没收到 ACK 或读取反馈(如后端 socket 缓冲区满、WAF 检测卡顿、Spring Boot 没调 getInputStream)
典型错误日志:upstream prematurely closed connection while reading upstream 或 Broken pipe,返回 502/504。
怎么算出一个靠谱的值
别填 300 或 600 碰运气,按实际传输能力估算:
Linux系统管理专家,覆盖12大模块:用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词:useradd、sudo、sshd_config、chmod、SEL...
- 假设最大上传 2GB,后端稳定接收速率为 5MB/s → 理论传输约 400 秒 → 建议设为 600 秒(留出网络抖动、WAF 检测、I/O 延迟余量)
- 支持上传 200MB,客户最低上行带宽约 1.5MB/s → 200 ÷ 1.5 ≈ 133 秒 → 建议设为 150 秒
- 普通 API 接口无大 body → 保持默认 60 秒 即可
严禁设为 0:会导致 worker 连接长期占用,积压后引发资源耗尽。
必须同步调整的三项
单改 proxy_send_timeout 几乎无效,这三项必须一起调:
- client_body_timeout:客户端上传 body 的间隔超时,建议 ≥ proxy_send_timeout(如都设为 600)
-
client_max_body_size:确保 Nginx 允许接收那么大的 body(例如
2000m),否则还没转发就返回 413 -
后端自身限制:Spring Boot 的
spring.servlet.multipart.max-file-size和max-request-size、Gunicorn 的--limit-request-body、Node.js 的 body-parser 都要放开,且数值大于 Nginx 设置
推荐配置写法与增强技巧
放在 location 块里最安全,精准控制业务路径,不影响其他接口:
location /api/upload {
proxy_pass http://backend;
proxy_send_timeout 600;
client_max_body_size 2000m;
client_body_timeout 600;
}
若需进一步提升流式直传效果,可加:
- proxy_buffering off:减少中间缓存,让数据更贴近后端真实接收节奏
- proxy_request_buffering off(Nginx ≥1.7.11):允许边收边发,避免 multipart 上传卡在缓冲阶段
- client_body_temp_path /var/tmp/nginx/client_body 1 2:显式指定临时文件路径,确保目录可写、空间充足










