proxy_buffering off为流式转发，on为缓冲转发；前者边收边发适用于sse、llm流式输出等实时场景，后者先缓再发适用于rest api等常规响应，且需同步关闭缓存、请求缓冲并启用分块传输。

直接看效果：设为 off 就是流式转发，设为 on 就是缓冲转发。这不是“倾向”或“优化”，而是行为开关——开即攒、关即转。

proxy_buffering off：边收边发，适合实时流

关闭后，Nginx 收到上游一个字节就尝试发给客户端，不等待、不拼整块、不计算总长。适用于：

• SSE（text/event-stream）：避免事件堆积，确保每条 data: 实时抵达
• LLM 流式输出（如 token 逐个返回）：前端能立刻渲染首个字符，不卡顿
• 大文件/视频分片下载（≥10MB）：跳过内存暂存，降低 worker 内存压力
• 实时日志推送（Loki/Fluentd）：时间戳与发送时刻一致，排障不滞后

proxy_buffering on：先缓再发，适合常规响应

开启后，Nginx 把上游响应体暂存在内存（或磁盘），等收完或缓冲区满再统一发给客户端。好处是吞吐更稳、可重写响应头、支持缓存；代价是延迟升高、内存占用波动大。典型适用场景：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• 普通 REST API（JSON/XML 返回）：响应体小、结构固定，延迟影响不敏感
• 静态资源服务（HTML/CSS/JS）：配合 proxy_cache 提升命中率
• 需统一加 Header 或重写路径的网关层：缓冲让 Nginx 有完整响应可操作

关键配套不能只改一个开关

单独设 proxy_buffering off; 很容易失效或中断连接，必须同步调整：

• proxy_cache off;：防止 Nginx 把流式响应误当静态内容缓存
• proxy_request_buffering off;：避免大请求体（如长 prompt）被截断或延迟上传
• chunked_transfer_encoding on;：显式启用分块传输，不依赖 Content-Length
• proxy_read_timeout 300s; 或更长（SSE 可设 86400）：防止空闲期被超时中断
• tcp_nodelay on;：禁用 Nagle 算法，每个 chunk 立即发出

缓冲区参数在 off 状态下基本失效

一旦 proxy_buffering off;，以下参数不再起作用：

• proxy_buffers
• proxy_busy_buffers_size
• proxy_temp_file_write_size
• proxy_max_temp_file_size 和 proxy_temp_path

唯一仍生效的是 proxy_buffer_size，但它只管响应头（通常 1k–4k 足够），不影响主体流式转发逻辑。