proxy_buffering 控制Nginx反向代理对后端响应体的缓存行为：开启时缓冲后再转发，降低后端压力并提升一致性但可能增加TTFB；关闭时立即透传，适用于实时流式服务等场景。
proxy_buffering 是 Nginx 反向代理中控制响应体是否缓存到内存/磁盘的关键开关，它不决定“要不要转发”，而是决定“怎么转发”——直接影响后端响应吞吐、客户端感知延迟和服务器资源占用。
proxy_buffering 开启时的典型行为
当 proxy_buffering on（默认值），Nginx 会把后端返回的响应体分块读入缓冲区（由 proxy_buffer_size 和 proxy_buffers 控制），等全部收完或缓冲区填满再统一发给客户端。这种机制带来三个实际效果：
- 降低后端压力：避免后端因客户端网络慢而长时间挂起连接（即“慢客户端拖垮后端”问题）
- 提升响应一致性：Nginx 可对整个响应做统一处理，比如添加头、启用 gzip、配合
proxy_cache缓存整条响应 - 可能增加首字节延迟（TTFB）：尤其对大响应或流式接口（如 SSE、长轮询），客户端需等待缓冲区填满或响应结束才收到数据
proxy_buffering 关闭时的适用场景
设为 off 后，Nginx 收到后端数据就立即透传给客户端，不暂存、不合并、不判断完整性。适合以下情况：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 实时性要求高的流式服务（如直播 API、日志推送、WebSocket 降级 fallback）
- 后端已自行处理慢客户端（例如用 chunked transfer + keepalive 维持连接）
- 响应体极小且固定（如 JSON 状态接口），缓冲收益微乎其微
注意：关闭后 proxy_buffer_size 和 proxy_buffers 不再生效，但 proxy_buffer_size 仍用于存储响应头，不可省略。
缓冲区大小配置与性能权衡
即使开启 buffering，缓冲区过小会导致频繁磁盘落盘（触发 proxy_busy_buffers_size 限流），过大则浪费内存。推荐组合：
- 普通 Web 接口：
proxy_buffer_size 4k; proxy_buffers 8 16k;（总缓冲约 132KB） - 含较大 HTML 或 JS 的页面：
proxy_buffers 16 32k;，并确保proxy_busy_buffers_size不超过总和的 50% - 避免使用
proxy_max_temp_file_size 0强制禁用临时文件——这会导致超限响应直接报 500，而非优雅降级
和 upstream 超时、客户端行为的联动影响
proxy_buffering 效果受上下游两端共同制约：
- 若
proxy_read_timeout过短，Nginx 可能在缓冲未满时就中断后端连接，导致截断响应 - 若客户端启用 HTTP/2 流控或 TLS record 分片过小，即使 Nginx 缓冲完成，也可能因网络层拆包造成“卡顿感”
- 搭配
proxy_http_version 1.1和Connection: keep-alive头，能更好发挥 buffering 的连接复用优势
