必须禁用proxy_buffering——这是保障SSE、AI token流、实时日志等流式接口语义正确性的前提，因默认缓冲会等待后端响应收完才转发，导致事件堆积、首字节延迟激增及连接中断。
在流式接口（如 SSE、AI token 流、实时日志推送）中，必须禁用 proxy_buffering——这不是可选项，而是保障语义正确性的前提。Nginx 默认开启缓冲，会等后端响应“收完”再发给客户端，直接破坏流式逐块输出的核心逻辑。
为什么默认缓冲会卡住流式响应
Nginx 的 proxy_buffering on 行为是：接收上游完整响应体（或填满缓冲区）后，才开始向客户端发送。这对流式场景造成三重阻断：
- 后端每秒输出一个 chunk（例如
data: 5%），Nginx 却攒着不发，直到缓冲区满（默认 8KB）或连接关闭 - 首字节延迟（TTFB）从毫秒级拉长到数秒甚至超时，SSE 连接频繁重连
- 若后端未显式 flush 或使用 HTTP/1.0，Nginx 可能永远等不到“结束信号”，最终触发
proxy_read_timeout中断
哪些流式场景必须关 buffering
以下接口类型一旦经 Nginx 代理，且要求低延迟、逐块透传，就必须设 proxy_buffering off：
-
Server-Sent Events（SSE）：依赖
Content-Type: text/event-stream和持续空行心跳，缓冲会导致事件堆积、时间戳失真 -
LLM 推理流式输出：如 FastAPI 返回
application/json分块 JSON，前端需逐 token 渲染，缓冲会打断体验 - 实时日志转发（如 Loki/Fluentd）：日志时间戳与写入时刻强相关，缓冲导致“日志滞后”问题，排障失效
-
WebSocket 升级前的协商响应：部分框架在
Upgrade: websocket前返回短响应头，缓冲可能干扰协议识别
关 buffering 后的关键配套配置
单独设 proxy_buffering off 不够，还需同步调整以下参数，否则仍可能延迟或出错：
-
proxy_cache off;：避免缓存层干扰流式响应生命周期 -
proxy_request_buffering off;：防止客户端请求体被意外缓冲，影响长连接稳定性 -
tcp_nodelay on;：禁用 Nagle 算法，确保每个 chunk 立即发出，不等待合并 -
proxy_read_timeout 300s;（或更长）：流式连接需大幅延长读超时，避免因无数据间隔触发中断 -
proxy_buffer_size 4k;：仅保留最小 header 缓冲，避免响应头被截断
常见误区与替代思路
不是所有“想快”的需求都要关 buffering：
-
误判“卡顿”源于 buffering：实际可能是后端未 flush、缺少
X-Accel-Buffering: no头（PHP-FPM 场景）、或客户端未启用 EventSource -
盲目全局关闭：CDN 回源、静态文件下载等场景开启 buffering 更稳；应按
location精确控制 -
试图用
chunked_transfer_encoding on强制分块：该指令仅对 Nginx 自身作为 origin 生效，代理模式下无效，还可能引发 HTTP/2 协议错误 -
调小缓冲代替关闭：如
proxy_buffers 4 2k;可降低延迟，但无法解决“必须边收边发”的本质需求
