proxy_send_timeout专管Nginx向后端发送已收完请求体的超时，仅在非长连接下生效，需据文件大小与后端接收速率估算（如2GB/5MB/s→设600秒），并同步调大client_body_timeout、client_max_body_size及后端限制。
proxy_send_timeout 不是“延长整体请求时间”的万能开关，而是专治 Nginx 向后端发送请求体（比如大文件、长 JSON、Base64 参数）时卡在半路的问题——它只管“发完 body”这一段是否停滞，且仅在非长连接场景下生效。
它真正控制什么
这个超时值生效的前提很具体：
- Nginx 已完整收完客户端的请求体（由 client_body_timeout 和 client_max_body_size 先把关）
- 正通过新建的 TCP 连接（非 keepalive 复用）向后端转发该 body
- 后端未及时确认接收：可能是 socket 缓冲区满、应用没调 read()、WAF 深度检测延迟、磁盘 I/O 暂停或 GC 卡顿
一旦某次数据发出后，在设定时间内没收到 ACK 或读取反馈，Nginx 就会断开与后端的连接，日志中常见 upstream prematurely closed connection while reading upstream 或 Broken pipe，返回 502/504。
怎么设才靠谱
数值必须基于实际传输能力估算，不是拍脑袋填 300 或 600：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 假设最大上传 2GB，后端稳定接收速率为 5MB/s → 理论传输约 400 秒 → 建议设为 600 秒（留出网络抖动、WAF 检测、I/O 延迟余量）
- 普通 API 接口无大 body → 保持默认 60 秒即可
- 流式上传或导出接口（如 /api/upload、/export/csv）→ 建议 300～600 秒，并写在对应 location 块中
- 严禁设为 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;，减少 Nginx 中间缓存环节，让数据更贴近后端真实接收节奏
- 长连接场景下 proxy_send_timeout 基本不生效，此时应聚焦 proxy_read_timeout、keepalive_timeout 和 tcp_keepalive 等机制
