proxy_busy_buffers_size设得太小是导致“后端还在发、nginx却停着不收”的最常见原因；它需在proxy_buffering on时，按proxy_buffers总量的1/4至1/2且不低于单块大小来协同设置，否则仍会触发假阻塞。

proxy_busy_buffers_size 设得太小，是导致“后端还在发、Nginx 却停着不收”的最常见原因。它不是性能锦上添花的参数，而是大响应（如 SSR HTML、API 批量导出、CDN 回源文件）场景下避免假阻塞的关键开关。

为什么改了 proxy_busy_buffers_size 还卡在后端写入？

这个值只在 proxy_buffering on 时生效，且必须和 proxy_buffers 协同。单独调大它，但 proxy_buffers 总量太小或单块太小，照样会触发忙区满→暂停读取→后端 TCP 窗口收缩→超时中断。

• 检查是否真启用了缓冲：proxy_buffering on;（默认是 on，但某些 location 可能被覆盖为 off）
• 确认 proxy_buffers 总量足够：例如 proxy_buffers 16 256k; 总共 4MB，那 proxy_busy_buffers_size 设成 512k 就偏小，应至少 1m
• 注意单位大小写：256k 和 256K 都合法，但 256kb 会静默失效，变成默认值
• 若后端用 chunked encoding 且无 Content-Length，Nginx 更依赖 busy 缓冲区来维持流式接收节奏，此时设小极易断流

怎么设才不踩坑：比例 + 下限双约束

别记死数字，按 proxy_buffers 总量动态算。它的合理范围不是“越大越好”，而是“够用且留余量”。

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• 通用公式：proxy_busy_buffers_size = proxy_buffers 总量 × (1/4 ~ 1/2)，且 ≥ 单块大小（如 128k）
• 示例：若配置 proxy_buffers 8 128k;（总 1MB），则 proxy_busy_buffers_size 256k; 比默认 8k 更稳妥
• 再示例：若用 proxy_buffers 32 256k;（总 8MB），设 proxy_busy_buffers_size 2m; 是常用选择，而非盲目填 4m
• 设得过大（如 > 总量 2/3）会挤占空闲缓冲区，反而降低并发接收能力，尤其在多连接并行时

哪些场景根本不用调它？

不是所有大响应都走内存缓冲路径。该参数对以下情况完全无效，调了也没用：

• proxy_buffering off;：此时 Nginx 边收边转，不管理“忙缓冲区”，整个 buffering 逻辑跳过
• 流式响应（SSE、日志 tail、gRPC streaming）：建议直接关 buffering，靠 proxy_buffer_size 控制 header，body 走直通
• 后端返回超大响应头（如含长 JWT）：那是 proxy_buffer_size 的事，和 busy_buffers_size 无关
• 大量临时文件生成：问题在 proxy_max_temp_file_size 或 proxy_buffers 不足，不是 busy 值小

真正难调的从来不是单个参数，而是 proxy_buffering、proxy_buffers、proxy_busy_buffers_size 三者之间的咬合关系——差一个数量级，就可能让后端以为客户端断连，而你只看到 error log 里一句模糊的 “upstream prematurely closed connection”。