proxy_buffer机制不能削峰，它仅暂存响应数据而非排队请求；真正削峰需用limit_req模块配合burst和nodelay实现控入限流。
不能靠 proxy_buffer 机制实现削峰，它不是为应对大并发设计的。
缓冲区本质是暂存，不是排队队列
proxy_buffer 系统（如 proxy_buffers、proxy_busy_buffers_size）作用是暂存后端响应数据，等客户端就绪后再发出去。它不接收、不缓存客户端请求，也不控制请求进入速率。即使把缓冲区调得再大，也不能让第10001个并发请求“等一等”，Nginx 仍会立即尝试建立 upstream 连接——这反而可能压垮后端或耗尽连接数。
真正用于削峰的是限流模块
应对极端大并发，必须用 ngx_http_limit_req_module 配合 burst 和 nodelay：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- limit_req_zone 定义速率基准（如每秒处理 500 个请求）
- burst 设置等待缓冲区（如 burst=2000），允许突发流量暂存排队
- nodelay 控制是否立即响应排队请求：加 nodelay 表示“不延迟响应，但超限即拒”；不加则按固定节奏匀速放行（带延迟）
削峰需分层配合，缓冲区只起辅助作用
在限流已生效的前提下，合理配置 proxy_buffer 参数可避免因响应慢引发的连锁失败：
- 增大 proxy_buffer_size（如 16k）防止大响应头被截断
- 适当提升 proxy_buffers（如 16 64k）和 proxy_busy_buffers_size（如 128k），避免大响应体频繁落盘影响吞吐
- 调高 proxy_read_timeout（如 300）适配后端慢查询，避免因读超时触发重试放大压力
注意不要混淆“缓冲”与“限流”
常见误区是把 proxy_buffering 关闭或调大 buffer 当作削峰手段。关闭后变成流式透传，失去控制力；盲目调大 buffer 只会拖长失败响应时间，甚至引发 OOM。削峰的核心逻辑是“控入”，不是“缓出”。
