proxy_buffering需按响应类型分级控制：小响应开启以解耦收发，流式响应（如sse、llm token流、websocket）必须关闭保实时性，并须按location精细化配置，同步调优proxy_buffer_size、proxy_buffers、proxy_read_timeout等参数。

proxy_buffering 不是“开或关”的二选一，而是根据响应类型做路径选择：小响应靠内存缓冲解耦收发，流式响应必须关闭缓冲保实时性。关键不在开关本身，而在它如何联动 proxy_buffer_size、proxy_buffers 和超时参数，形成匹配业务特征的缓冲策略。

什么情况下必须关 buffering

只要后端是分块输出且客户端依赖逐帧接收，就必须设 proxy_buffering off：

• SSE 接口（Content-Type: text/event-stream），缓冲会导致事件堆积、心跳延迟、连接频繁重连
• LLM token 流（如 FastAPI / vLLM 返回的 chunked JSON），前端需逐 token 渲染，缓冲会打断语义流
• 实时日志透传（Loki / Fluentd）、WebSocket 升级前响应、前端 HMR 热更新，都要求首字节延迟最低

关了之后要补哪些配置

单独关 buffering 不够，否则仍可能卡顿或中断：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• proxy_cache off：避免缓存层拦截流式生命周期
• proxy_http_version 1.1 + proxy_set_header Upgrade $http_upgrade：WebSocket 场景必需
• tcp_nodelay on：禁用 Nagle 算法，确保每个 chunk 立即发出
• proxy_read_timeout 300（或更长）：防止长空闲触发超时断连
• gzip off：Nginx 压缩需完整响应体，关 buffering 后无法满足

开 buffering 时怎么防磁盘 IO 暴增

高并发下中等大小响应（如 200–600MB 报表）反复落盘，根源是默认缓冲太小、临时文件阈值太宽：

• 默认 proxy_buffers 8 16k（总 128KB）远不够，建议按典型响应体调为 16 256k（总 4MB）
• 设 proxy_max_temp_file_size 0，强制跳过写盘逻辑，逼 Nginx 全走内存或直接报错（比随机 IO 更可控）
• proxy_busy_buffers_size 设为总缓冲量的 1/2～1 倍（如 2m），避免转发卡顿
• 始终检查 proxy_buffer_size 是否足够——它只管响应头，JWT 或多 Cookie 容易撑爆，默认 4k 常需调至 8k 或 16k

按 location 精准控制，别一刀切

全局关 buffering 会废掉静态资源压缩、API 重试、统一超时等能力：

• /api/、/static/ 等路径保持 proxy_buffering on，配合理缓冲
• /events、/stream、/llm/chat 等路径显式设 off，并套用流式配套参数
• 本地开发代理（如 localhost:3000）若用 HMR 或 SSE，也应在对应 location 中关闭