关闭proxy_request_buffering可消除Nginx对大文件上传的串行阻塞，实现边收边传，显著降低首字节延迟、提升端到端吞吐、避免内存或磁盘打满；需在location块中同步配置client_max_body_size、client_body_timeout、proxy_read_timeout、client_body_buffer_size 0、proxy_buffering off、proxy_http_version 1.1等参数，并确保后端流式解析请求体。
关闭 proxy_request_buffering 本身不加快网络上传速度，但它能彻底消除 Nginx 对大文件上传的串行阻塞，让后端真正“边收边处理”，从而显著降低首字节转发延迟、提升端到端吞吐、避免内存或磁盘打满——这是提升大文件上传实际性能的关键前提。
为什么默认开启会严重拖慢上传体验
当 proxy_request_buffering on（默认）时，Nginx 会把整个上传请求体（比如一个 5GB 视频）完整接收并暂存到内存或磁盘临时目录（如 /var/lib/nginx/body/），校验完再一次性发给后端。这带来三个硬伤：
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 所有数据必须先堆积在 Nginx 这一层，后端集群无法并行接收，白白闲置计算资源
- 单个 worker 进程可能因缓存大文件而耗尽内存，或写爆磁盘导致 500 错误
- 客户端上传进度卡在 99%，后端却迟迟收不到第一个字节——首字节转发延迟 = 整个上传耗时
关闭后如何真正释放性能潜力
设为 off 后，Nginx 变成透明流管道：收到 TCP 数据包就立刻尝试转发，不等待、不校验、不暂存。但仅这一行配置远远不够，必须同步调整以下参数才能稳定生效：
-
放开大小限制：在 location 块中设置
client_max_body_size 20G;（或0表示不限），否则上传中途直接返回 413 错误 -
延长传输容忍窗口：设
client_body_timeout 3600;和proxy_read_timeout 3600;，适应弱网分片间隔波动与后端流式处理耗时 -
禁用冗余缓冲：显式加
client_body_buffer_size 0;，防止小包仍被内存暂存；同时配proxy_buffering off;，确保后端返回的状态流（如进度 JSON）也能实时透传 -
启用 HTTP/1.1 长连接：加上
proxy_http_version 1.1;和proxy_set_header Connection '';，避免连接被意外关闭
后端服务必须适配流式请求体
Nginx 不再缓存和解析 body，意味着原始字节流（含 multipart boundary）会以未拆解形式抵达后端。常见框架需主动切换为流式读取方式：
-
Node.js（Express）：禁用
body-parser，改用busboy监听req.on('data') -
Python（Flask/FastAPI）：不调用
request.files，而是通过request.stream.read(chunk_size)分块读取 -
Go（net/http）：直接读
req.Body，用io.Copy或循环Read()处理
部署注意事项
该指令必须放在具体上传路径的 location 块内（如 location /api/upload { ... }），不可全局启用，否则会影响登录、表单等普通 POST 接口。Kubernetes Ingress 用户应使用注解：nginx.ingress.kubernetes.io/proxy-request-buffering: "off"
并配套设置：nginx.ingress.kubernetes.io/proxy-body-size: "20G" 和 nginx.ingress.kubernetes.io/client-body-timeout: "3600"。
