proxy_busy_buffers_size不是独立内存池，而是从proxy_buffers总量中划出的“已接收、待发送”数据上限，必须配合proxy_buffering on使用，推荐设为总量的1/4至1/2且不低于单块大小；设错会导致延迟飙升、502或上游写阻塞。
proxy_busy_buffers_size 不是独立内存池，而是从 proxy_buffers 总量中划出的“已接收、待发送”数据上限。它不决定能收多少响应体，只管那一段卡在半路的 body 数据最多占多大空间——设对了，后端持续输出、客户端稳定接收；设错了，轻则延迟飙升，重则触发 502 或上游写阻塞。
必须和 proxy_buffering on 显式配合
这个参数仅在 proxy_buffering 开启时生效。默认虽为 on，但极易被覆盖：
- location 块里写了 proxy_buffering off;，整块配置失效
- 用了 proxy_cache 或 proxy_pass_request_headers off 等指令，可能间接禁用缓冲
- 务必在对应 location 或 server 块中显式声明 proxy_buffering on;
- 验证方式：curl -I 请求，响应头不含 X-Accel-Buffering: no 即表示生效
按 proxy_buffers 总量比例设置
它不是孤立参数，必须与 proxy_buffers 挂钩。推荐值为总量的 1/4 至 1/2，且不低于单块大小、不超过总量本身：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- proxy_buffers 8 128k;（总 1MB）→ proxy_busy_buffers_size 256k; 或 512k;
- proxy_buffers 16 256k;（总 4MB）→ proxy_busy_buffers_size 1m; 或 2m;
- 单块为 256k，则 busy 值不可低于 256k；设成 128k 可能刚填满一块就停，频繁唤醒 epoll，吞吐反降
- 若设超总量（如 buffers 总 2MB，busy 设 8MB），nginx -t 直接报错
区分响应类型做针对性配置
不同业务对缓冲节奏要求差异很大，不能一刀切：
- SSR 首屏 HTML（约 80–150KB）：用 proxy_buffers 8 128k; + proxy_busy_buffers_size 256k;，再配 proxy_read_timeout 90; 预留渲染时间
- 流式响应（SSE、日志 tail）：直接 proxy_buffering off;，此时该参数完全不生效，强行调大无意义
- 大文件下载（≥10MB）：优先关缓冲（proxy_buffering off;）；若必须开启（如需改写 header），则 proxy_buffers 单块至少 512k，busy 值设为 512k–1m
- 响应头较大（JWT、多层 Cookie）：单独调高 proxy_buffer_size（如 16k–32k），但 proxy_busy_buffers_size 仍按 body 缓冲逻辑计算，无需同步加
验证是否真正起效，不止 reload
改完配置后，关键看运行态表现，而非语法通过：
- curl -I 查响应头：有 Content-Length 且无 chunked → 缓冲完整生效；含 X-Accel-Buffering: no → buffering 已关，当前设置未参与
- 查 error log：upstream timed out 或 upstream response is buffered to a temporary file 频繁出现 → busy 区过早饱和或 buffers 总量不足
- 对比 access log 中 $upstream_response_time 与 $request_time：后者显著更长 → 数据积压在 busy 区未及时发出
