proxy_send_timeout需精准匹配上传时数据块间隔而非总耗时，仅作用于nginx向后端转发请求体的空闲等待期；须同步校准client_body_timeout、proxy_read_timeout及后端接收超时，并用精确location匹配上传路径。
要避免大数据上传时后端因 Nginx 主动断开连接而失败，proxy_send_timeout 必须精准匹配上传行为本身——它只管 Nginx 往后端“发完请求体”这一段的耐心，不是整个请求周期，也不管建连或响应。
明确它的作用边界
这个参数生效的前提是：Nginx 正在把客户端发来的请求体（比如大文件、长 JSON）转发给后端，且使用的是非长连接（即每次请求新建连接）。它监控的是两次数据包之间的空闲等待时间，不是总上传耗时。
- 它不控制 TCP 建连：那是 proxy_connect_timeout
- 它不控制后端处理或返回响应：那是 proxy_read_timeout
- 它不控制客户端上传慢：那是 client_body_timeout
- 如果后端支持 HTTP/1.1 长连接并已复用连接，该参数实际可能不触发
按上传场景合理设值
数值应略大于你观察到的最慢单次数据块间隔，而非总上传时间。例如：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 客户端通过弱网上传 200MB 文件，实测分块发送间隔最长为 90 秒 → 设为 120 秒较稳妥
- 后端接收逻辑存在阻塞（如未及时调用 InputStream.read()），导致某次接收停顿 45 秒 → 至少设为 60 秒
- WAF 或中间设备对 multipart 请求做深度扫描，引入额外延迟 → 可设为 150 秒并配合日志验证
必须同步检查的关键项
单改 proxy_send_timeout 很容易白忙一场，以下几项必须一并确认：
- client_body_timeout ≥ proxy_send_timeout：否则 Nginx 还没开始转发，就在接收阶段被自己掐断
- proxy_read_timeout ≥ proxy_send_timeout：确保请求体发完后，后端有足够时间处理并返回响应
- 后端自身接收超时（如 Tomcat 的
connectionTimeout、Spring Boot 的server.tomcat.connection-timeout）必须大于 proxy_send_timeout，否则后端先断 - 若路径专用于上传（如
/api/upload），务必用location ^~ /api/upload精确匹配，避免正则开销和误配
推荐配置示例
针对上传接口路径，建议这样写：
location ^~ /api/upload {
proxy_pass http://backend;
client_max_body_size 500m;
client_body_timeout 180s;
proxy_send_timeout 150s;
proxy_read_timeout 300s;
proxy_http_version 1.1;
proxy_set_header Connection '';
}
注意：不要全局统一设成 3600s；过长会卡住 worker 连接，影响并发能力。重点看真实上传节奏，再留出 20–30 秒缓冲即可。
