必须关闭proxy_buffering以保障流式日志推送实时性，因其在sse、chunked响应等动态无长场景下完全绕过output_buffers机制；关键配置包括proxy_buffering off、tcp_nodelay on，并需后端配合flush及设置x-accel-buffering: no。
output_buffers 对大流式日志推送完全不生效，不能用于平滑这类场景。
它只在 Nginx 直接提供静态文件、且满足 sendfile off + Content-Length + 无 chunked + 未启用 aio/directio 的特定条件下起作用。而流式日志推送（如 SSE、tail -f 接口、实时日志流）本质是动态生成、分块传输（Transfer-Encoding: chunked）、无预知长度的响应，Nginx 会跳过 output_buffers 机制，直接走 event loop + socket write 路径。
真正影响流式日志推送是否“卡顿”或“延迟高”的，是以下几项：
1. 必须关闭代理级缓冲，避免阻塞后端写入
流式响应要求后端（如 PHP、Python、Go 服务）持续输出，Nginx 若在中间缓存整段内容，就会破坏流式语义：
-
proxy_buffering off;—— 关键！禁用 Nginx 对 upstream 响应的缓冲 -
proxy_buffer_size 4k;—— 仅保留足够放响应头的最小缓冲 -
proxy_busy_buffers_size和proxy_buffers在proxy_buffering off下完全无效，无需调整
2. 控制 TCP 发送节奏，兼顾吞吐与首字节延迟
流式场景对 TTFB（首字节时间）敏感，不能盲目凑包：
-
tcp_nodelay on;—— 禁用 Nagle 算法，让每个小块尽快发出，降低感知延迟 -
tcp_nopush off;—— 不启用 TCP_CORK/NOPUSH，避免等待凑满一包 - 避免
postpone_output（已废弃，Nginx ≥1.1.4 会报错）
3. 后端配合：确保真实流式输出行为
Nginx 只是通道，源头决定是否真流式：
- 后端需发送
Content-Type: text/event-stream（SSE）或text/plain+Transfer-Encoding: chunked - 每次输出后调用
flush()/ob_flush()/sys.stdout.flush()，并确认未被中间件（如某些 WSGI 封装）拦截 - 设置
X-Accel-Buffering: no响应头，可强制 Nginx 忽略内部缓冲逻辑（部分版本支持）
4. 验证是否真正流式生效
- 用
curl -N http://your-log-endpoint（-N禁用 curl 自身缓冲），观察是否逐块打印 - 查看响应头：必须含
Transfer-Encoding: chunked或Content-Encoding: gzip（若压缩）+ 无Content-Length - 若出现长延迟后突然刷出大量日志，大概率是某层（Nginx、后端、反向代理）仍在攒包，需回溯检查
proxy_buffering和后端 flush 行为
不复杂但容易忽略：流式优化的核心从来不是“加大缓冲”，而是拆除不必要的缓冲层，让数据从后端到客户端尽可能直通。
