proxy_buffering 控制响应体是否被 nginx 缓存转发，响应头始终由 proxy_buffer_size 单独处理；on 时响应体经 proxy_buffers 缓冲并可落盘，off 时响应体实时透传；proxy_buffer_size 专用于响应头，须足够容纳全部 header，一般设 4k 或 16k。
proxy_buffering 控制的是响应体（即 HTTP 响应的 body 部分）是否被 Nginx 缓存转发，它本身不决定响应头如何处理，但会间接影响响应头的使用方式和缓冲区分工。
响应头始终由 proxy_buffer_size 单独处理
无论 proxy_buffering 是 on 还是 off，proxy_buffer_size 都生效——它专用于存放后端返回的响应头（headers），比如 Status、Content-Type、Set-Cookie 等。这个缓冲区大小必须足够容纳全部响应头，否则会报 upstream sent too big header 错误。常见设置是 4K 或 16K，一般无需随 body 缓冲区同步放大。
响应体缓冲行为完全取决于 proxy_buffering 开关
当 proxy_buffering on（默认）时：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- Nginx 先收完响应头（进
proxy_buffer_size），再开始接收响应体 - 响应体数据进入
proxy_buffers定义的内存缓冲区组，边收边传给客户端 - 若响应体超出内存缓冲总量，多余部分写入磁盘临时文件（受
proxy_max_temp_file_size约束） - 此时
proxy_busy_buffers_size控制“正在发送中”的那部分缓冲区上限
当 proxy_buffering off 时：
- 响应头仍走
proxy_buffer_size，但响应体不再进proxy_buffers -
proxy_buffers和proxy_busy_buffers_size失效，Nginx 改为收到多少字节就发多少字节 - 适合 SSE、token 流、日志 tail 等需逐块实时透传的场景
关键分工：头与体不混用，但协同工作
响应头和响应体在 Nginx 内部有明确分工：
-
proxy_buffer_size是“头专用缓冲区”，独立存在、始终启用 -
proxy_buffers是“体主缓冲区”，仅在proxy_buffering on时激活 - 响应头必须完整收到后，Nginx 才能决定是否 gzip、加缓存头、执行重写等逻辑——这是开启缓冲带来的头处理优势
- 关闭缓冲后，响应头虽仍被缓存，但无法触发基于完整响应头的优化动作（如条件压缩）
配置建议：按需隔离头/体参数
不要把 proxy_buffer_size 和 proxy_buffers 设成相同值或盲目放大：
- 响应头通常很小，
proxy_buffer_size 4k或16k足够，过大浪费内存 - 响应体缓冲根据业务定：
proxy_buffers 8 16k（共 128KB）适合常规 API；流式接口则直接关 buffering - 流式场景下即使关了 buffering，也要保留合理的
proxy_buffer_size，避免截断长响应头
