关键不是简单开关，而是按响应类型精准控制：普通API/页面开启proxy_buffering on以释放后端连接；SSE、WebSocket、LLM流、大文件下载等必须在location块中设proxy_buffering off，并同步配置proxy_http_version 1.1、proxy_read_timeout、禁用proxy_cache等。
要解决 proxy_buffering 带来的缓冲区延迟，关键不是简单地“开”或“关”，而是根据响应类型做精准控制：对普通 API 和页面开启以释放后端连接；对流式响应（如 SSE、WebSocket、LLM token 流、大文件下载）必须关闭，并同步调整配套参数。
识别哪些场景必须关掉 proxy_buffering
以下路径或响应类型不能依赖缓冲，否则会出现毫秒级消息卡顿数秒、首字节延迟高、数据堆积不实时等问题：
- SSE 接口（如
/events、/stream），后端逐行输出data:消息，但 Nginx 默认攒满缓冲才发 - WebSocket 升级响应（
101 Switching Protocols），缓冲会干扰Upgrade和Connection头透传 - 大文件下载（≥10MB）、视频分片、日志推送等流式体，内存缓冲易溢出或频繁落盘
- LLM 流式生成（如
/chat返回 token 流），用户等待体验直接受首包延迟影响
在 location 块中精准关闭并补全必要配置
不要在 http 或 server 级全局关闭——这会让所有请求失去缓冲优化，还可能导致 gzip 失效。只在对应路径内操作：
- 加
proxy_buffering off;—— 这是核心开关，缺它其他都无效 - 设
proxy_http_version 1.1;和proxy_set_header Connection '';，维持长连接不被降级 - 配
proxy_read_timeout 3600;或更长（如86400），防止空闲时误断连 - 关
proxy_cache off;，避免握手阶段被缓存拦截（尤其 WebSocket） - 可选加
add_header X-Accel-Buffering no;，显式告知浏览器不缓冲
开启 proxy_buffering 时如何避免延迟积压
对常规 JSON、HTML 等非流式响应，开启 proxy_buffering on 能提升吞吐、释放后端连接，但需精细调参防卡顿：
-
proxy_buffer_size 16k;—— 确保容纳大响应头（含 JWT、多 Cookie、重定向 Location） -
proxy_buffers 8 16k;—— 总内存缓冲约 128KB；若后端常返回 300KB+ 数据，可调为16 32k -
proxy_busy_buffers_size 32k;—— 控制“正在发送中”的缓冲上限，建议为单 buffer 大小的 2 倍 -
proxy_max_temp_file_size 1024m;—— 允许大响应写临时文件，避免因缓冲不足直接失败 - 配合
proxy_read_timeout 90;和proxy_ignore_client_abort on;，防止慢客户端拖住后端
验证与排查常见卡点
延迟问题往往不是单一配置导致，需结合日志和行为交叉判断：
- 看 Nginx error 日志：出现
upstream sent too big header→ 加大proxy_buffer_size - 发现大量
.tmp文件生成 → 检查proxy_buffers是否过小或proxy_max_temp_file_size是否受限 - 前端收不到首条 SSE 消息 → 90% 是没关
proxy_buffering，剩下 10% 是Upgrade/Connection头未透传 - WebSocket 握手返回 200 而非 101 →
proxy_cache未关，或proxy_buffering开着干扰了协议升级
