proxy_send_timeout控制Nginx向后端发送请求体的超时，仅适用于非长连接下数据发送阶段，不控制TCP建连、响应头等待或整周期；默认60秒，宜按location精细配置。
proxy_send_timeout 控制的是 Nginx 从后端服务器接收响应数据时，两次连续数据包之间的最大等待时间，不是整个响应的总耗时。它针对的是“传输中卡顿”，而非“处理慢”。当后端正在生成大文件（如导出百万行 Excel、流式返回视频切片、长日志下载）但发送节奏不均匀时，这个参数就非常关键。
proxy_send_timeout 的真实作用场景
它不决定“后端要花多久算完”，而是防止 Nginx 因为等不到下一段响应数据而主动断开连接。比如后端已开始写入响应体，但因数据库分页拉取慢、磁盘 I/O 延迟或人为 sleep(5)，中间隔了 62 秒才发第二块数据——若 proxy_send_timeout 仍为默认 60s，Nginx 就会直接关闭连接，客户端收到不完整的响应甚至 502/504。
如何设置合理的值
- 数值应略大于后端最可能的单次数据块间隔，而不是总响应时间。例如后端每 30 秒 flush 一次日志，设为 45s 更稳妥
- 对持续流式接口（如 SSE、分块下载），建议设为 300s（5 分钟），避免网络抖动或 GC 暂停导致误断
- 不要盲目设成 3600s；过长会占用 worker 连接，影响并发能力
- 该指令生效范围是 location 或 server 块，建议按业务路径精细化配置，比如只在
/export/下调高
必须同步检查的关联项
单独调高 proxy_send_timeout 往往不够，还需确认：
-
后端自身输出缓冲策略：Spring Boot 需配
server.tomcat.connection-timeout和响应流的flush()行为；Netty 要检查ChannelHandlerContext.writeAndFlush()是否及时 - proxy_read_timeout：它控制 Nginx 等待后端**首次响应头**及**整个响应完成**的总时间，需 ≥ proxy_send_timeout，否则还没开始传数据就被掐了
- client_body_timeout / client_header_timeout：上传阶段超时不影响下行，但若用同一 location 处理上传+下载，需一并评估
-
TCP 层保活：Linux 的
net.ipv4.tcp_keepalive_time若过短（如默认 7200s），也可能干扰长连接，但一般无需调整
验证是否生效的小技巧
改完配置后别只看是否不报错，要验证实际行为：
- 用
curl -v观察响应头中的Content-Length或Transfer-Encoding: chunked，确认是流式响应 - 在后端加日志，记录每次
write()和flush()的时间戳，对比 Nginx error.log 中的 “upstream timed out” 时间点 - 临时把后端某次 flush 延迟到超过当前 proxy_send_timeout，复现问题再调参验证
