nginx流式响应需关闭proxy_buffering或严格限制缓冲，分离头/体缓冲，禁用磁盘落盘，并配置http/1.1、连接头清理及合理超时，以实现低内存、可控的直通转发。
Nginx 的 Worker Process 本身不主动“控制”响应数据流，而是通过一组明确的反向代理缓冲指令协同上游行为与客户端消费节奏，实现可控、低内存占用的流式转发。核心不是限制 worker 内存，而是切断无节制缓存链路，让数据尽可能直通。
关闭或严格约束 proxy_buffering
默认开启的 proxy_buffering on 是流式响应内存膨胀的主因——Nginx 会把上游发来的响应体暂存在内存（甚至磁盘），等客户端慢速接收时越积越多。真正流式场景（如 SSE、gRPC-Web、实时日志）应直接关掉：
- 设
proxy_buffering off;：收到响应数据立即尝试转发，不暂存；内存仅维持 socket 接收/发送队列和少量元数据，基本恒定 - 若必须保留缓冲（例如需改写 header），则大幅收紧：
proxy_buffers 2 4k;proxy_busy_buffers_size 4k;proxy_max_temp_file_size 0;
这样一旦待发数据超过 4KB 且客户端未及时读取，Nginx 就暂停从 upstream 读取，形成背压，防止内存失控
隔离响应头与响应体缓冲
响应头（headers）和响应体（body）的缓冲逻辑要分开管理：
-
proxy_buffer_size 1k;或4k：专用于存放响应头，独立于 body 缓冲区，通常 1–4KB 足够，无需调大 -
proxy_buffers只管 body，数量和大小要匹配业务预期吞吐；例如proxy_buffers 4 8k表示最多用 32KB 缓存响应体 - 禁用磁盘落盘：
proxy_max_temp_file_size 0;避免缓冲溢出后写临时文件，强制触发背压或返回 502/503，便于快速暴露瓶颈
确保 HTTP 协议语义不被破坏
流式传输依赖正确的 HTTP 版本与连接管理，否则 Nginx 或中间设备可能降级或提前关闭连接：
-
proxy_http_version 1.1;：显式启用 HTTP/1.1，支持 chunked encoding 和持久连接 -
proxy_set_header Connection '';：清空 Connection 头，避免 upstream 或 client 错误地插入close导致连接中断 - 搭配
chunked_transfer_encoding on;（默认开启）确保分块传输正常生效
配合连接与超时联动防护
单个长连接即使不传数据，也会持续占用 worker 连接结构（几 KB 内存）。空闲连接堆积同样导致 OOM：
-
proxy_read_timeout 60;：上游响应慢时，worker 线程被长期占用；根据业务设合理值，避免无限等待 -
keepalive_timeout 30s;：客户端空闲超时断连，释放连接资源；流式接口可适当缩短（如 10–20 秒） -
limit_conn按 IP 或 server 限制并发连接数，防止单一客户端耗尽全部 worker_connections
