proxy_send_timeout控制nginx向后端发送已缓存请求体的超时，非客户端上传本身；默认60秒，超时导致502/504，需结合文件大小、后端接收速率及proxy_read_timeout协同调优。

proxy_send_timeout 本身不负责“上传中断”，它只控制 Nginx 向后端发送请求体（request body）时的等待时间——也就是从 Nginx 开始向后端发数据起，到后端完全接收完这一段数据之间，Nginx 能等多久。如果后端处理慢、网络卡顿或带宽低，Nginx 等不及就会断开连接，导致上传失败。

真正影响大数据上传的关键参数是 client_max_body_size 和 client_body_timeout，而 proxy_send_timeout 只在Nginx 已经拿到完整请求体、正往下游转发时才起作用。所以“上传中断”往往不是它的问题，而是配置组合没对上。

---

? 关键参数分工要清楚

• client_max_body_size
  控制客户端能上传多大的文件（比如设为 100m），默认仅 1MB。上传超限直接返回 413。

• client_body_timeout
  客户端上传过程中，两次数据包之间的最大空闲时间（如设为 60s）。上传太慢或卡住就会断。

• proxy_send_timeout
  Nginx 把请求体（已缓存好）发给后端时，等后端 ACK 的最长时间。适用于后端写入慢（如写磁盘、校验大文件）、网络延迟高场景。

• proxy_read_timeout
  后端处理完后，Nginx 等它返回响应的时间。上传完成后的业务处理耗时（如压缩、转码、入库）卡在这里会触发 504。

• proxy_buffering off（慎用）
  关闭缓冲后，Nginx 会流式转发请求体，避免内存积压，但会放大 proxy_send_timeout 的影响——因为此时每一段数据都要等后端确认。

---

? 实际调优建议（针对大文件上传）

• 先确认上传失败时的错误码：

  • 413 Request Entity Too Large → 检查 client_max_body_size
  • 408 Request Timeout → 检查 client_body_timeout
  • 502 Bad Gateway + error log 提示 upstream prematurely closed connection → 往往是 proxy_send_timeout 或 proxy_read_timeout 不足
  • 504 Gateway Timeout → 多半是 proxy_read_timeout 不够，后端还没返回

• 常见安全且稳定的配置片段（以 500MB 文件为例）：

  

  FastAPI Flask Proxy

  FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

  下载

client_max_body_size 500m;
client_body_timeout 300s;     # 允许客户端花最多 5 分钟传完
proxy_send_timeout 300s;      # Nginx 发给后端时，每段数据等 5 分钟
proxy_read_timeout 600s;      # 后端处理+返回，最长等 10 分钟
proxy_buffering off;          # 如后端支持流式接收，可关缓冲；否则保持 on 更稳

• 如果后端是 Spring Boot，默认 spring.servlet.context-path 或 server.tomcat.max-http-post-size 也要同步调大，否则 Nginx 没问题，后端先拒了。

• 日志里重点盯 error.log 中这类行：
  upstream timed out (110: Connection timed out) while sending request to upstream
  → 明确指向 proxy_send_timeout 不足。

---

⚠️ 注意一个典型陷阱

AI 生成配置常把 proxy_send_timeout 设成 60s，但实际上传 2GB 文件到慢磁盘后端，光传输就可能花 3–5 分钟。这时必须同步调高 proxy_send_timeout 和 proxy_read_timeout，否则上传刚结束，后端还在处理，Nginx 就因 proxy_read_timeout 超时断开了。

不复杂但容易忽略。