调优 proxy_buffering 的核心是按业务响应特性分级控制：对小而固定的API或静态资源开启（on），对SSE、WebSocket、LLM流等分块输出场景必须关闭（off）；需按 location 精细化配置，同步调整 proxy_buffer_size、proxy_buffers 等参数，并在关闭时补充 proxy_http_version 1.1、延长超时及禁用 gzip。
调优 proxy_buffering 的核心是按业务响应特性做“分级控制”，而非全局开关。它不是越快越好，也不是越缓越好，关键在平衡实时性、内存开销与后端压力。
明确开启或关闭的判断依据
开启（on）适合：API 响应体小而固定（如 JSON 接口）、静态资源代理、客户端网络质量差（需防后端被慢连接拖住）。此时 Nginx 可快速收完响应、释放后端连接，再匀速发给客户端。
关闭（off）必须用于：SSE、WebSocket 升级响应、LLM token 流、实时日志透传、HMR 热更新等场景。只要后端是分块输出（Transfer-Encoding: chunked）且客户端依赖逐帧接收，就必须关缓冲，否则首字节延迟明显、事件合并、流中断。
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
按 location 精细化配置，避免一刀切
不要在 http 或 server 块中统一设 proxy_buffering off——这会禁用所有优化，还导致 gzip 失效、临时文件不可用。
- 对普通 API 接口（如
/api/）保持默认on，配合合理缓冲大小 - 对流式路径（如
/stream、/events、/llm/chat）显式设proxy_buffering off; - 若前端 dev server 跑在
localhost:3000，其 HMR 和热重载也需对应 location 关闭缓冲
配套缓冲参数要同步调整
proxy_buffering 不是孤立指令，它和以下参数联动生效：
-
proxy_buffer_size 4k;：始终保留，专存响应头；太小会触发 502（Header 写不全） -
proxy_buffers 8 16k;：默认总容量约 128KB；若后端常返回 300KB+ 响应，可调为16 32k，但注意单个 worker 进程内存占用上升 -
proxy_busy_buffers_size 32k;：建议设为单 buffer 大小的 2 倍，确保有空间边读边发 -
proxy_max_temp_file_size 1024m;：macOS 默认 tmpfs 小，代理大文件时需显式放大，并确认client_body_temp_path所在磁盘有足够空间
关闭缓冲后的必要补充项
关了 proxy_buffering 后，Nginx 不再接管响应体生命周期，需额外加固：
- 加
proxy_http_version 1.1;和proxy_set_header Upgrade $http_upgrade;：WebSocket 场景必需 - 延长超时：
proxy_read_timeout 300;（尤其 SSE 长连接），防止 Nginx 主动断连 - 禁用 gzip：
gzip off;（因 Nginx 要求响应完整才压缩，关缓冲后无法满足） - 注意内核 socket 缓冲压力：高并发流式请求下，
net.core.wmem_max和rmem_max可能需调大
