proxy_send_timeout 控制 nginx 向后端发送请求体时的超时，仅在带 body 的非长连接请求中生效，用于防止传输中断；它不控制客户端上传、后端处理、响应返回等环节。
proxy_send_timeout 控制的是 Nginx 向后端（upstream）发送已接收完毕的请求体时的等待上限，它不决定整个请求是否成功，只影响“发 body 这一段”是否中途断连。
它生效的前提很明确：
- 请求必须带请求体（如 POST、PUT 的 multipart/form-data、大 JSON、Base64 等）；
- Nginx 与后端使用的是非长连接（即每次请求新建 TCP 连接）；
- Nginx 已完整收完客户端传来的 body，正把数据分块写入 upstream socket；
- 某次 write() 发出数据后，在设定时间内没收到 ACK 或读取反馈（比如后端 socket 缓冲区满、未及时 read、WAF 深度检测卡顿），Nginx 就主动关闭连接，返回 502 或 504。
它不管这些事：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 客户端上传慢（那是
client_body_timeout的职责）； - 后端处理请求花多久（那是业务逻辑，Nginx 不管）；
- 后端返回响应慢（那是
proxy_read_timeout）； - TCP 建连失败（那是
proxy_connect_timeout）； - 静态资源 GET 请求（无 body，此参数完全不触发）；
- 正向代理场景（纯隧道透传，该参数被忽略）。
哪些情况会真正受它影响？
- 大文件上传过程中，后端接收节奏不稳（如 Java 应用没配流式读取、Spring Boot 缺少 `@RequestBody` + 流式处理）； - WAF 或防火墙对请求体做缓冲或深度解析，导致传输延迟； - 后端磁盘 I/O 阻塞、GC 暂停、socket 缓冲区写满，造成 ACK 回复滞后； - 客户端网络波动，Nginx 分块转发时某一块迟迟得不到确认。设多大才合理？
不能拍脑袋填 300 或 600。要结合两个关键数字估算： - 最大允许上传体积（由 `client_max_body_size` 决定）； - 后端稳定接收速率（实测或预估，单位 MB/s）。例如：
- 上限 2GB 文件，后端平均接收速率为 5MB/s → 理论传输约 400 秒；
- 建议设为 600 秒（10 分钟），预留网络抖动、WAF 检测、I/O 延迟等余量。
普通接口无大 body，保持默认 60 秒即可；流式上传或导出路径（如 /api/upload、/export/csv），建议单独设为 300～600 秒。
单改它基本没用，必须同步调这三项
- `client_body_timeout`：客户端上传 body 的间隔超时，建议 ≥ `proxy_send_timeout`（如都设 600）； - `client_max_body_size`：确保 Nginx 允许接收那么大的 body（如 `2000m`），否则直接 413； - 后端自身限制：Spring Boot 的 `spring.servlet.multipart.max-file-size`、Gunicorn 的 `--limit-request-body`、Node.js 的 `body-parser` 限额等，都要放开且大于 Nginx 设置。配置位置建议
放在 `location` 块里最安全，精准控制业务路径： ```nginx location /api/upload { proxy_pass http://backend; proxy_send_timeout 600; client_body_timeout 600; client_max_body_size 2000m; } ``` 若后端支持 HTTP/1.1 长连接，该值可能不触发（复用已有连接）；如需更贴近真实传输节奏，可加 `proxy_buffering off;` 减少中间缓存环节。不复杂但容易忽略。
