proxy_send_timeout仅控制nginx向后端发送请求体的超时,需按“最大文件体积÷最低上行带宽+20–30秒”计算,并同步调大client_max_body_size、client_body_timeout,启用http/1.1长连接。

要解决大包上传时因 proxy_send_timeout 触发的超时断连,关键不是盲目拉高数值,而是明确它只管“Nginx 往后端发请求体”这一段,并结合上传带宽、后端接收能力与客户端配置协同调优。
先搞清 proxy_send_timeout 真正管什么
这个参数仅在 Nginx 向 upstream 发送请求体(如 POST 数据、文件流)过程中生效,且只对非长连接场景起作用。它不控制:
- TCP 建连时间(那是
proxy_connect_timeout) - 等待后端返回响应头或响应体(那是
proxy_read_timeout) - 客户端上传请求头或请求体(那是
client_header_timeout和client_body_timeout) - Nginx 回传响应给客户端的速度(那是
send_timeout)
按上传能力算出合理值
设值要有依据,不能拍脑袋填 300 或 600:
FastAPI + Flask 混合部署最佳实践,解决路由定义、API 代理等常见问题,适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 普通接口(无大文件):保持默认 30 秒即可
- 文件上传接口:用「最大文件体积 ÷ 最低稳定上行带宽」得出基础传输时间,再加 20–30 秒余量
例如:支持上传 200MB 文件,客户最低上行带宽约 1.5MB/s → 200 ÷ 1.5 ≈ 133 秒 → 建议设为proxy_send_timeout 150
必须同步配齐三件事,否则单调无效
proxy_send_timeout 不是孤立参数,需配套落地:
-
放开客户端接收限制:确保
client_max_body_size足够大(如200m),且client_body_timeout≥ 你设的proxy_send_timeout,否则 Nginx 还没开始转发,请求就在接收阶段被拦下了 -
确认后端能及时读取:Java 应用需调用
getInputStream();Spring 需配好流式接收(如@RequestBody InputStream);避免后端阻塞在解析前 -
优先启用长连接复用:若后端支持 HTTP/1.1,配置
proxy_http_version 1.1和proxy_set_header Connection '',并开启upstream keepalive,此时proxy_send_timeout实际可能不触发——因为复用连接后,发 body 走的是已有 socket
配置位置推荐 location 级精细化控制
避免全局一刀切,只对上传路径单独覆盖:
proxy_pass http://backend;
proxy_send_timeout 150;
client_max_body_size 200m;
client_body_timeout 150;










