proxy_send_timeout仅控制nginx向后端发送已收完请求体时两次数据包间的空闲等待上限，需按“最大文件体积÷最低上行带宽＋缓冲”估算，并同步调大client_body_timeout、client_max_body_size及后端接收限制。

proxy_send_timeout 只管一件事：Nginx 向后端发送请求体（比如大 JSON、Base64 参数、文件流）时，两次数据包之间的空闲等待上限。它不控制建连、不等响应、也不管客户端上传多慢——只盯住“发给后端的 body 是否卡住了”。

大数据上传中断常不是因为 Nginx 没耐心，而是这个参数和上游接收能力、客户端上传节奏、系统缓冲没对齐。

---

它真正生效的场景

• 客户端已把完整请求体（如 100MB 文件）发给了 Nginx
• Nginx 开始把这段 body 转发给后端（比如 Java 应用或 Python Flask）
• 但后端读得慢、没及时调 request.body.read()、或中间 WAF 做深度检测导致转发卡顿
• 两次写入 upstream socket 的间隔超过 proxy_send_timeout → Nginx 主动断开与后端的连接，返回 502 或 504

⚠️ 注意：如果客户端还没传完请求体，触发的是 client_body_timeout；如果后端根本没响应 header，问题在 proxy_read_timeout 或 proxy_connect_timeout。

FastAPI Flask Proxy

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

下载

---

怎么设才合理

• 别拍脑袋填 300 或 3600，要按实际上传带宽和文件体积估算
• 公式：基础时间 = 最大文件体积 ÷ 最低稳定上行带宽，再加 20–30 秒缓冲
  • 例：支持上传 200MB，客户最低上行 1.2MB/s → 200 ÷ 1.2 ≈ 167 秒 → 设为 180
• 若后端明确支持 HTTP/1.1 长连接且复用连接，该值影响变小；但首次上传或连接池未复用时仍关键

---

必须同步检查的三项

• client_body_timeout ≥ proxy_send_timeout
  否则 Nginx 还没开始转发，就在接收阶段被拦（报 413 或直接断连）
• client_max_body_size 要匹配上传上限
  比如设了 200m，但 Nginx 默认是 1m，会先返回 413，根本轮不到 proxy_send_timeout 生效
• 后端接收超时（如 Tomcat 的 connectionTimeout、Spring 的 max-http-header-size）必须比 proxy_send_timeout 小至少 5 秒
  确保后端先断，避免 Nginx 等不到 FIN 而僵持

---

推荐配置写法（针对上传路径）

location /api/upload {
    proxy_pass http://backend;
    proxy_send_timeout 180;
    client_body_timeout 180;
    client_max_body_size 200m;
    # 关键：禁用缓冲，避免 Nginx 把大 body 写磁盘再转发（增加延迟和失败风险）
    proxy_buffering off;
}

✅ proxy_buffering off 对大上传很关键——默认开启时，Nginx 会先把整个 body 写入临时文件（client_body_temp_path），再读取转发；磁盘 I/O 慢或空间不足就会中断。关掉后，body 直接流式转发，更稳。

---

容易被忽略的底层细节

• 确认 client_body_temp_path 所在磁盘有足够空间且 I/O 稳定（即使 proxy_buffering off，某些版本仍可能用到）
• HTTPS 场景下，TLS 握手或 OCSP Stapling 延迟也会占用传输窗口，可启用 TLS session reuse 缓解
• Linux 内核参数如 net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog 建议 ≥ 65535，防高并发上传时连接队列溢出

不复杂但容易忽略。