开启 proxy_buffering 能提升 cdn 回源吞吐与后端稳定性，关闭虽降 ttfb 但易致上游阻塞、带宽浪费和超时；应结合场景调优而非全局关闭。

开启 proxy_buffering 通常能显著提升 CDN 回源的吞吐效率和后端服务稳定性，而关闭它虽可降低首字节延迟（TTFB），但容易引发上游连接阻塞、带宽浪费和超时风险，实际生产环境不建议全局关闭。

proxy_buffering 开启时的回源行为

启用后，Nginx 会将上游（源站）响应暂存到内存 buffer（由 proxy_buffer_size 和 proxy_buffers 控制），再按需分块转发给客户端。这一机制带来三方面优势：

• 解耦上下游速率：CDN 节点或终端网络慢时，Nginx 仍可快速读完源站响应，避免源站连接长时间挂起
• 支持响应头优化：例如自动添加 Content-Length（当响应体确定且未分块时），利于 CDN 缓存识别与复用
• 减少源站压力：缩短源站连接占用时间，尤其在高并发小文件回源场景下更明显

proxy_buffering 关闭时的真实代价

设为 off 后，Nginx 变成“直通模式”：收到源站一个 TCP 包就立刻转发给客户端。表面看 TTFB 更低，但隐藏问题突出：

• 源站响应速度受限于下游消费能力——若 CDN 或用户网络卡顿，源站连接会被迫等待，拖慢整体回源队列
• 无法合并小包，TCP 层频繁发包，增加网络开销和丢包敏感度
• 无法缓存完整响应，导致部分场景下 proxy_cache 失效（如需要完整响应体做哈希校验时）
• 若源站使用 HTTP/1.1 分块传输（chunked），关闭 buffering 会导致 Nginx 无法正确处理末尾 chunk，可能截断响应

针对性优化比简单开关更有效

遇到 TTFB 敏感业务（如 API 实时推送），不应直接关 buffering，而是结合场景精细调优：

• 对特定 location 使用 proxy_buffering off，仅限已知流式响应（如 SSE、gRPC-Web）且下游稳定可控的路径
• 调大 proxy_buffer_size（如设为 16k）以容纳较大响应头，避免因 header 溢出触发额外磁盘缓存
• 合理设置 proxy_busy_buffers_size（建议 ≤ proxy_buffers 总大小的 50%）防止过早刷新影响吞吐
• 配合 proxy_cache_bypass 和 proxy_no_cache 精确控制哪些请求不走缓存，而非依赖关闭 buffering 来“加速”

CDN 回源链路中的关键协同点

CDN 厂商通常要求回源响应具备明确长度或分块标识。开启 buffering 后，Nginx 更易满足这些要求：

• 若源站返回静态文件且无 chunked，则开启 buffering 后 Nginx 可补全 Content-Length，提升 CDN 缓存命中率
• CDN 的回源请求常带 Connection: close，此时 Nginx 开启 buffering 能更快释放源站连接，避免 TIME_WAIT 积压
• 部分 CDN 对回源响应的 header 大小有限制（如 ≤ 8KB），需确保 proxy_buffer_size 不小于该值，否则 buffering 会退化为临时文件缓存，反而增加延迟