proxy_send_timeout是Nginx向后端发送已收完请求体时等待ACK确认的超时值，仅在非长连接下生效，需据文件大小与后端接收速率估算（如2GB/5MB/s→设600秒），并同步调大client_body_timeout、client_max_body_size及后端限制。
proxy_send_timeout 不是“让后端慢点也没事”的万能开关，而是 Nginx 在向后端发送已收完的请求体（比如大文件、流式 JSON、Base64 数据）时，等待后端确认接收的耐心时限。它只在非长连接场景下生效，且只管“发 body”这一段是否卡住——不是客户端上传慢，也不是后端处理久，更不是响应返回慢。
它真正起作用的几个典型场景
当上传过程出现以下情况时，proxy_send_timeout 就会成为关键防线：
- 客户端网络波动或带宽受限，导致 Nginx 分块转发请求体时，后端迟迟没回 ACK
- 后端应用未及时调用
read()或getInputStream()（如 Spring Boot 缺少流式接收配置） - WAF 或防火墙对请求体做深度检测、缓冲，造成传输节奏不稳
- 后端 socket 缓冲区满、磁盘 I/O 延迟、GC 暂停，导致接收间隔拉长
怎么算出一个靠谱的值？别拍脑袋
数值必须基于实际传输能力估算，而不是随便填个 300 或 600：
- 假设最大上传为 2GB，后端稳定接收速率为 5MB/s → 理论传输约 400 秒 → 建议设为 600 秒（留出网络抖动、WAF 检测、I/O 延迟等余量）
- 普通 API 接口无大 body → 保持默认 60 秒 即可
- 流式上传或导出接口（如
/api/upload、/export/csv）→ 建议 300～600 秒，并写在对应 location 块中
单改它几乎没用：必须同步调这三项
只调 proxy_send_timeout 是治标不治本，以下三项必须一并检查和调整：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
- client_body_timeout：客户端上传 body 的间隔超时，建议 ≥ proxy_send_timeout（如都设为 600）
-
client_max_body_size：确保 Nginx 允许接收那么大的 body（例如
2000m），否则还没转发就直接 413 -
后端自身限制：Spring Boot 的
spring.servlet.multipart.max-file-size和max-request-size、Gunicorn 的--limit-request-body、Node.js 的body-parser选项等，都要放开且数值大于 Nginx 设置
推荐配置位置与增强技巧
放在 location 块 中最安全，精准控制业务路径，不影响其他接口：
location /api/upload {
proxy_pass http://backend;
proxy_send_timeout 600;
client_max_body_size 2000m;
client_body_timeout 600;
}
若需进一步提升流式直传效果，可加：
proxy_buffering off;
减少 Nginx 中间缓存环节，让数据更贴近后端真实接收节奏。
