关闭 proxy_request_buffering 可消除 Nginx 对大文件上传的串行阻塞，实现边收边传，提升负载均衡下端到端吞吐与首字节延迟；需同步配置 client_max_body_size、client_body_timeout、proxy_read_timeout 等参数，并确保后端支持流式读取。
关闭 proxy_request_buffering 本身不直接“提升上传速度”，但它能消除 Nginx 对超大文件上传的串行阻塞，让后端真正实现边收边处理，从而显著改善端到端吞吐和首字节转发延迟——这对负载均衡场景下的大文件上传尤为关键。
为什么默认开启会拖慢负载均衡上传
在负载均衡架构中（如 Nginx 作为前置网关分发至多个后端节点），默认 proxy_request_buffering on 会让 Nginx 先把整个文件（比如 5GB 视频）完整接收并暂存，再一次性发给某个 upstream。这带来三个瓶颈：
- 所有上传流量必须先堆积在 Nginx 这一层，无法利用后端集群的并行接收能力
- 单个 worker 进程内存或磁盘临时目录极易打满，尤其高并发时，/var/lib/nginx/body/ 可能被写爆
- 首字节转发延迟 = 客户端总上传耗时，后端节点空闲等待，资源利用率极低
关闭后如何真正释放负载均衡潜力
proxy_request_buffering off 让 Nginx 变成透明流管道，配合合理配置，可使每个后端节点实时、独立地消费数据流：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 客户端上传的数据包到达即转发，后端节点可立即解帧、校验或转码，无需等待“全量就绪”
- 若使用 IP Hash 或一致性哈希等会话保持策略，同一文件分片持续落到同一后端，天然支持断点续传与状态复用
- 多个上传请求不再争抢同一块缓冲区，而是各自走独立 TCP 流，降低锁竞争与上下文切换开销
负载均衡上传必须同步调整的关键参数
只写 proxy_request_buffering off 不足以稳定运行，需在 location 块中成组配置：
-
放开大小限制：
client_max_body_size 0;或设为业务上限（如50G），避免 413 在流式转发前就拦截 -
延长传输容忍窗口：
client_body_timeout 3600;防止弱网下分片间隔波动触发中断 -
匹配后端处理节奏：
proxy_read_timeout 3600;确保 Nginx 不因后端流式响应慢而提前断连 -
禁用冗余缓存：
client_body_buffer_size 0;显式关闭内存缓冲，避免小包仍被暂存 -
透传协议语义：加上
proxy_http_version 1.1;和proxy_set_header Connection '';，保障分块传输与连接复用
后端与负载均衡协同要点
流式转发把压力从 Nginx 转移到了后端和调度层，需注意：
- 后端服务必须支持流式读取（如用
req.on('data')或iter_body），不能依赖Content-Length或完整 body 解析 - 健康检查要覆盖流式路径（例如对
/api/upload/health发起长连接 POST），避免节点假存活 - 若用 K8s Ingress，须通过注解配置：
nginx.ingress.kubernetes.io/proxy-request-buffering: "off"，字符串值不可省略引号 - 建议搭配
limit_rate限速（如limit_rate_after 10m; limit_rate 20m;），防止单连接压垮某台后端
