关闭 proxy_request_buffering 是大文件上传实现“边收边传”的关键——设为 off 后 Nginx 退化为透明流管道，后端可即时处理首字节，但需同步调整 client_max_body_size、client_body_timeout 等参数并改造后端流式读取逻辑。
关闭 proxy_request_buffering 是大文件上传能否“边收边传”的分水岭——它不提速网络，但决定后端能不能在第一个字节抵达时就开始处理。
默认开启（on）时的真实表现
这是 Nginx 的默认行为，对小请求友好，却会严重拖垮大上传：
- 整个请求体（比如 2GB 视频）必须先被 Nginx 完整接收，暂存在内存或磁盘（如
/var/lib/nginx/body/），校验完毕后再一次性发给后端 - 后端全程“空等”，首字节转发延迟 = 整个上传耗时，前端进度条卡在 99% 时后端可能还没收到一个字节
- 并发上传多路时，worker 进程容易因缓存堆积导致内存耗尽，或写爆磁盘引发 500 错误
- 与分片上传、流式推理等场景逻辑冲突：前端按 chunk 发，后端想边收边算，Nginx 却硬要攒齐再交
设为 off 后的核心变化
此时 Nginx 退化为透明 TCP 流管道，不再缓冲、不等待、不校验：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 客户端每发一个 TCP 包，Nginx 就立刻尝试转发给后端，实现真正意义上的流式透传
- 后端可即时开始解析、转码、校验或推理，大幅降低端到端延迟
- 内存和磁盘压力显著下降，避免因临时文件目录满导致上传中断
- 注意：Nginx 不再做请求体完整性检查（如大小拦截），
client_max_body_size仅在 header 解析阶段生效
必须同步调整的关键参数
单设 proxy_request_buffering off 无效，以下配置需成组出现在 location 块中：
-
client_max_body_size 20G—— 放在server或http块，防止请求被提前拦截返回 413 -
client_body_timeout 3600和proxy_read_timeout 3600—— 适应弱网分片间隔与后端流式处理耗时 -
client_body_buffer_size 0—— 防止小包仍被内存暂存；proxy_buffering off—— 确保后端流式响应（如进度 JSON）也能实时透传 -
proxy_http_version 1.1+proxy_set_header Connection ''—— 维持长连接，避免中间设备误关 - 如需断点续传，补上：
proxy_set_header Range $http_range和proxy_set_header If-Range $http_if_range
后端必须适配流式读取
Nginx 不再拆解 multipart 或解析 body，原始字节流直接抵达，后端框架需主动切换读取方式：
- 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()处理
