proxy_send_timeout仅控制Nginx向后端分块发送请求体时等待ACK的最长时间，不涉客户端上传或后端响应；须在location块中按文件体积与后端接收速率估算设值（如2GB/8MB/s→400秒），并同步调大proxy_connect_timeout、proxy_read_timeout、client_body_timeout及client_max_body_size。
直接调大 proxy_send_timeout 是解决大文件上传过程中因“Nginx 向后端发数据太慢”触发 504 的关键操作，但它只管“发请求体”这一个环节，不能单独生效，必须配合路径粒度、单位估算和上下游协同。
明确 proxy_send_timeout 的作用边界
这个参数控制的是 Nginx 把已收到的请求体（比如上传的文件流）**分块发送给后端时，每一块发出后等待后端 ACK 或接收反馈的最长时间**。它不负责客户端上传、也不负责后端返回响应——这两个阶段分别由 client_body_timeout 和 proxy_read_timeout 管理。常见误判是把上传卡住归因于后端慢，实际可能是后端应用（如 Spring Boot）没及时从 socket 读取数据，导致 Nginx 在发送中途超时断连，日志里常出现 upstream prematurely closed connection while reading upstream 或 Broken pipe。
在 location 块中显式配置并合理估算值
该参数必须写在具体 location 块内，不能放在 http 或 server 级别，否则不生效。设置前建议按以下方式粗算：
- 预估最大文件体积（如 2GB）和后端稳定接收速率（如 8MB/s），理论传输时间 ≈ 250 秒
- 在此基础上加 30%~50% 余量，设为
proxy_send_timeout 400（单位秒，不写 s 也可） - 若后端部署在跨云或高延迟环境，或存在冷启动场景，可进一步上浮至 600（10 分钟）
同步补全关联超时与客户端限制
只改 proxy_send_timeout 往往不够，三个环节必须对齐：
-
proxy_connect_timeout：确保 Nginx 能连上后端，跨机房建议设为 180 -
proxy_read_timeout：后端处理完再返回响应，至少要比proxy_send_timeout长，例如设为 600 -
client_body_timeout和client_max_body_size：防止客户端还没传完就被 Nginx 中断，前者建议 ≥proxy_send_timeout，后者要匹配文件上限（如200m）
区分协议类型，避免参数错用
如果你后端是 PHP-FPM，proxy_send_timeout 完全无效——它只对 HTTP 类后端（Java/Node.js/Python）起作用。PHP 场景下应使用 fastcgi_send_timeout，并同步调整 PHP 层的 request_terminate_timeout 和 max_execution_time。切勿混用指令，也禁止设为 0，否则连接长期挂起，耗尽 worker 连接数。
