proxy_buffering 是明确的物理缓冲开关：on启用内存/磁盘暂存，off则边收边发直通转发；配套需同步关闭 proxy_cache 和 proxy_request_buffering，并调整超时、分块传输等参数以适配流式或非流式场景。
proxy_buffering 不是“优化倾向”，而是明确的物理缓冲开关：开即启用内存（或磁盘）暂存，关即绕过缓冲、直通转发。
on：启用缓冲，响应体先攒后发
开启后，Nginx 把上游响应数据暂存在 proxy_buffers 指定的内存区域中；未满时不急着发，收完或 busy 缓冲区填满才批量吐给客户端。这带来三个实际效果：
- 响应头可被完整读取，支持 Header 重写、Set-Cookie 修改等网关级操作
- 配合 proxy_cache 可缓存整条响应（含状态码、Body），实现静态资源加速
- 吞吐更平稳，但首字节延迟（TTFB）升高，大响应易触发 proxy_temp_path 写临时文件
off：关闭缓冲，响应体边收边发
关闭后，Nginx 收到上游一个 TCP 包就尝试转发一个包，不等待、不拼整块、不校验 Content-Length。此时：
- proxy_buffers、proxy_busy_buffers_size、proxy_temp_file_write_size 等全部失效
- 仅 proxy_buffer_size 仍起作用——它只管响应头（建议设为 4k–8k，ThinkPHP 调试模式下可调至 16k）
- 必须同步关闭 proxy_cache 和 proxy_request_buffering，否则流式行为会被拦截或中断
配套动作决定开关是否真正生效
单改 proxy_buffering 很难稳定工作，尤其在流式场景下。关键配套包括：
- proxy_cache off; —— 防止 Nginx 把 SSE 或 token 流误判为可缓存静态内容
- proxy_request_buffering off; —— 避免大请求体（如长 prompt）被截断或延迟上传
- chunked_transfer_encoding on; —— 显式启用分块传输，替代依赖 Content-Length 的旧逻辑
- proxy_read_timeout 300s; 或更高（SSE 建议设为 86400）—— 防止空闲连接被超时断开
- tcp_nodelay on; —— 关闭 Nagle 算法，让每个 chunk 立即发出，不攒包
典型场景匹配建议
按业务特征选开关，不是按“性能好坏”拍板：
- 用 SSE 推送实时事件、LLM 逐 token 输出、日志流推送 → 必须 proxy_buffering off
- 普通 REST API（JSON/XML）、静态 HTML/CSS/JS、需加统一 Header 的网关层 → 保持 proxy_buffering on（默认值）
- ThinkPHP 导出 CSV 或调试模式下响应头膨胀 → 先设 proxy_buffer_size 8k，再根据是否流式决定 on/off
