Nginx 的 proxy_buffering 开启会导致流式输出变卡，它缓存 token 流直至凑满缓冲区或响应结束才转发，造成首字节延迟高、响应体一次性到达、服务端与前端时间戳不匹配等“假流式”现象。
当大模型流式输出在部署后“变卡”——本地跑得飞快，线上却等十几秒才一次性吐完全部内容，大概率不是模型慢了，而是 Nginx 的 proxy_buffering 在悄悄“攒包”。它不报错、不超时、不中断连接，只是把本该逐块发出的 token 流，硬生生缓存起来，等凑够缓冲区大小或响应结束才一并转发。这种延迟是隐性的，容易被误判为后端性能问题或网络抖动。
看现象：三类典型“假流式”表现
不用查日志，先观察前端行为和网络面板就能快速定位：
- 首字节延迟（TTFB）异常高：比如后端实际 200ms 就开始 yield 第一个 token，但浏览器 Network 面板显示 TTFB 是 8.2s——说明 Nginx 在等后端“说完”才发头
- 响应体一次性到达：Response 标签页里整段 JSON 或文本瞬间出现，没有滚动加载感；DevTools 的 “Streaming” 模式下看不到分段数据流
- 服务端日志时间戳对不上：后端 log 显示 token 从第 0.3 秒持续输出到第 8.5 秒，但前端只在第 8.5 秒收到全部内容——中间 8 秒“静默”，正是缓冲区在积压
查配置：直接确认 proxy_buffering 是否开启
登录服务器，打开对应 site 的 Nginx 配置文件（通常在 /etc/nginx/conf.d/ 或 /etc/nginx/sites-enabled/），重点搜索以下三项：
-
proxy_buffering on;（默认值，即开启）→ ⚠️ 危险信号 -
proxy_buffering off;（显式关闭）→ ✅ 正确配置 - 未声明该指令 → 默认生效，等同于
on
注意：即使 location 块里写了 proxy_buffering off，也要确认它没被更外层的 http/server 块中同名指令覆盖（Nginx 配置继承优先级：location > server > http）。
验行为：用 curl 绕过浏览器，直击代理链
在服务器本地执行命令，排除浏览器渲染和 JS 逻辑干扰：
curl -N -H "Accept: text/event-stream" http://localhost/your-stream-endpoint
-
-N关闭 curl 自身缓冲，强制实时输出 - 如果命令行里字符是“一个一个蹦出来”的 → 后端和 Nginx 之间已通，问题在前端或浏览器
- 如果命令行也卡住几秒后突然刷出全部 → 问题 100% 出在 Nginx 的 buffering 或 chunked 配置上
测边界：用最小化复现排除干扰
写一个极简后端接口（如 FastAPI 的 StreamingResponse，每 500ms yield 一个数字），部署后仅用 Nginx 反向代理，不做任何业务逻辑。然后：
- 先关掉
proxy_buffering，curl 测试是否流式正常 - 再打开它，观察是否回归“全量延迟”现象
- 这个对比能干净地剥离模型、框架、前端的影响，把问题锁定在 Nginx 缓冲机制本身
