Nginx默认不自动流式转发chunked响应，需禁用proxy_buffering并配置HTTP/1.1透传等参数才能实现边收边发；其异步事件驱动模型支持高并发低延迟流式代理。
Nginx 在异步事件驱动模型下原生支持 HTTP/1.1 的 Transfer-Encoding: chunked 流式传输，但实际行为取决于配置、上游协议、缓冲策略及客户端交互方式，并非所有场景都“自动按块转发”。
Chunked 编码在 Nginx 中的流转机制
Nginx 本身不生成 chunked 编码，而是作为代理（proxy）或服务器（server）透明处理它：
- 当后端（如 FastAPI、Node.js 流式接口）以 chunked 方式响应时，Nginx 默认会接收完整响应体后再转发给客户端——这是因默认开启
proxy_buffering on； - 若后端使用 HTTP/1.0 或关闭 keepalive，Nginx 可能自动添加 chunked 编码来传递不定长响应；
- 真正实现“边收边发”的流式透传，需显式禁用缓冲并启用流式代理参数。
启用低延迟流式透传的关键配置
要让 Nginx 在事件驱动下最小化延迟、逐 chunk 转发，需组合以下指令：
-
proxy_buffering off;：禁用响应体缓存，避免等待整个 body 收完再发； -
proxy_cache off;和proxy_buffer_size 4k;（可选调小）：防止首行/headers 被意外缓冲； -
proxy_http_version 1.1;+proxy_set_header Connection '';：确保与上游保持 HTTP/1.1 并透传 Connection 控制； -
chunked_transfer_encoding on;（仅在 Nginx 作 origin server 且需自动生成 chunked 时需要，代理场景通常无需设置）。
注意：proxy_buffering off 后，Nginx 不再做响应体校验或重试，错误响应（如后端提前断连）会直接透传给客户端。
常见误区与调试建议
很多问题并非事件模型限制，而是配置或协议层误解：
-
“Nginx 卡住第一块”：常因
proxy_buffering on+ 后端未及时 flush，或缺少proxy_set_header X-Accel-Buffering no;（某些后端如 PHP-FPM 依赖该 header 控制自身缓冲）； -
Wireshark 看不到 chunked：Nginx 代理时若后端返回带
Content-Length，Nginx 会移除Transfer-Encoding: chunked并改用定长模式； -
超时中断流：检查
proxy_read_timeout（默认60s），流式场景建议设为 300+ 秒或按业务心跳调整； - 用
curl -v或浏览器 DevTools 的 Network → Response Headers 验证是否真实出现Transfer-Encoding: chunked和分块数据。
事件驱动下的实际表现
Nginx 的 epoll/kqueue 事件循环能高效处理数千并发流式连接，每个连接只占用少量内存和文件描述符。只要配置得当，单个 worker 进程可稳定维持数万长连接，每收到一个 TCP 分片中的 chunk 数据头（如 8\r\n...），就立即触发 write 事件转发给客户端，无需轮询或阻塞等待——这正是异步非阻塞 I/O 的价值所在。
