要实现nginx流式代理chunked响应,必须关闭proxy_buffering off;同时需设proxy_http_version 1.1、清空connection头、禁用缓存,并确保后端返回合法chunked响应。

Nginx 默认能识别并转发后端返回的 Transfer-Encoding: chunked 响应,但不会自动透传——它更倾向于缓存、适配或降级。能否真正实现“边收边发”的流式代理,取决于 ngx_http_proxy_module 的几个关键配置是否协同生效。
必须关闭响应缓冲才能透传 chunked
Nginx 默认开启 proxy_buffering on,这意味着它会等后端把整个响应体发完,再统一计算长度、改写为 Content-Length 并转发。此时原始的 chunked 编码被完全抹除。
要保留 chunked 流式行为,必须显式关闭:
-
proxy_buffering off;
这是唯一不可替代的核心项。关掉后,Nginx 改为流式转发:收到一个 chunk 就立即发给客户端,不暂存、不校验、不重试。
其他缓冲相关设置只是辅助:
-
proxy_buffer_size 4k;和proxy_buffers 8 4k;可设小些,减少首部或小数据的延迟,但不影响 chunked 本身 -
proxy_cache off;防止缓存机制意外截断或重组流式响应
必须使用 HTTP/1.1 并清理 Connection 头
HTTP/1.0 不支持 chunked,若 Nginx 与后端协商成 HTTP/1.0(比如后端用 http:// 且未显式声明版本),它会主动丢弃 Transfer-Encoding 头,并加 Connection: close。
所以务必确保:
-
proxy_http_version 1.1; -
proxy_set_header Connection '';
清空该头,避免 Nginx 或后端误传keep-alive/close指令,干扰流式连接维持。
注意:chunked_transfer_encoding 对代理无效
这个指令只控制 Nginx 自己生成的响应(如 return 200 "hello";、静态文件、error_page)是否启用 chunked。
它对 proxy_pass 完全不起作用。加在 proxy location 里属于无效配置,可直接删掉。
后端响应本身必须合规
Nginx 的透传前提是后端真的发出了合法的 chunked 响应:
FastAPI + Flask 混合部署最佳实践,解决路由定义、API 代理等常见问题,适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 有
Transfer-Encoding: chunked头 - 没有同时带
Content-Length(二者互斥,Nginx 遇到会优先信Content-Length并丢弃 chunked) - 后端未提前关闭连接,且持续输出数据(如 FastAPI 的
StreamingResponse、Node.js 的res.write()+res.flush())
推荐最小可用配置示例
location /stream/ {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection '';
proxy_buffering off;
proxy_cache off;
proxy_redirect off;
}
如果用于 SSE 或日志流,还可加:
-
add_header Content-Type "text/event-stream"; -
proxy_set_header Accept-Encoding "";(禁用 gzip,避免压缩后长度固定导致 Nginx 强加Content-Length)
不复杂但容易忽略










