proxy_send_timeout专管Nginx向后端发送请求体（如大文件、Base64、JSON）的超时，仅在非长连接且Nginx已收完客户端body、后端未及时确认接收时生效；超时断连致502/504，需据传输速率估算设值（如2GB/8MB/s→≥300秒），并同步调大client_body_timeout、client_max_body_size及后端限制，推荐在location块中配置。
proxy_send_timeout 专管 Nginx 向后端发送请求体（比如大文件、长 Base64、批量 JSON）这一段过程的耐心程度——它不负责建连、不等响应、也不管客户端上传，只盯住“把 body 发完”这件事。
它真正控制什么
这个超时仅在以下条件同时满足时生效：
- Nginx 已完整接收完客户端请求体（由 client_body_timeout 和 client_max_body_size 先把关）
- Nginx 正通过非长连接（即每次新建连接）向后端转发该 body
- 后端未及时确认接收（例如 socket 缓冲区满、应用没调用 read()、WAF 深度检测卡顿）
一旦某次数据发出后，在设定时间内没收到 ACK 或读取反馈，Nginx 就会断开与后端的连接，日志中常见 upstream prematurely closed connection while reading upstream 或 Broken pipe，返回 502/504。
怎么设才合理
不能凭感觉填 300 或 0，得结合实际传输能力估算：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 假设最大上传 2GB，后端稳定接收速率为 8MB/s → 理论传输约 250 秒 → proxy_send_timeout 至少设为 300 秒（5 分钟），留出网络抖动和处理余量
- 普通 API 接口无大 body：保持默认 60 秒即可，无需调整
- 严禁设为 0（无限等待）：会导致 worker 连接长期占用，积压后引发资源耗尽
必须同步配齐的三项
单改 proxy_send_timeout 基本无效，这三项必须一起调：
- client_body_timeout：客户端上传 body 的间隔超时，建议 ≥ proxy_send_timeout（如都设 300）
- client_max_body_size：确保 Nginx 允许接收那么大的 body（如 2000m）
-
后端自身限制：Spring Boot 的
spring.servlet.multipart.max-file-size、Gunicorn 的--limit-request-body、Node.js 的body-parser都要放开，且数值需大于 Nginx 设置
推荐配置位置与写法
放在 location 块里最安全，避免影响其他接口：
location /api/upload {
proxy_pass http://backend;
proxy_send_timeout 300;
client_max_body_size 2000m;
client_body_timeout 300;
}
若后端支持 HTTP/1.1 长连接，该值可能不触发（连接复用后走已有 socket）；若确需流式直传，可加 proxy_buffering off，减少中间缓存环节。
