proxy_busy_buffers_size需与proxy_buffering、proxy_buffers协同配置：必须开启proxy_buffering，其值取proxy_buffers总量的1/4～1/2且不低于单buffer大小，不同业务类型需差异化设置并验证响应头与错误日志。

要正确配置 proxy_busy_buffers_size 来限制“已接收但尚未发完”的响应数据内存占用，核心不是单独设一个数，而是让它和 proxy_buffering、proxy_buffers 形成协同关系——它本质是缓冲区流水线里的“忙区配额”，设错会直接导致后端写阻塞或并发吞吐下降。

必须先确认 proxy_buffering 已开启

这个参数只在 proxy_buffering on; 时生效。默认虽为 on，但常见失效场景包括：

• location 块里写了 proxy_buffering off;，整块配置失效
• 启用了 proxy_cache 或 proxy_pass_request_headers off 等指令，间接干扰缓冲行为
• 未显式声明，被上游或子配置覆盖

建议所有需要缓冲的 location 中都显式写上 proxy_buffering on;，并用 curl -I 检查响应头是否含 X-Accel-Buffering: yes（或无该头，默认开启）。

按 proxy_buffers 总量比例设置

proxy_busy_buffers_size 不是独立内存池，而是从 proxy_buffers 分配出的“忙区”上限。设值必须满足两个硬约束：

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

• 取总量的 1/4 至 1/2（推荐保守取 1/3～1/2）
• 不低于单块 buffer 大小（如 128k，则 busy 值不能低于 128k）
• 绝对不可超过 proxy_buffers 总量，否则 nginx -t 启动报错

典型配置示例：

• proxy_buffers 8 128k;（总 1MB）→ proxy_busy_buffers_size 256k; 或 512k;
• proxy_buffers 16 256k;（总 4MB）→ proxy_busy_buffers_size 1m; 或 2m;
• proxy_buffers 32 128k;（总 4MB）→ proxy_busy_buffers_size 2m;

区分业务类型做适配

不同响应特征对“忙区”压力差异大，不能一套参数打天下：

• Next.js / SSR 页面（首屏 HTML 约 50–120KB）：用 proxy_buffers 8 128k; + proxy_busy_buffers_size 128k; 即可，再配合 proxy_read_timeout 90; 预留渲染时间
• 大文件回源（如导出 CSV、安装包 ≥10MB）：建议直接 proxy_buffering off;，此时该参数完全不生效；若坚持开启，则需同步增大 proxy_buffers 数量和 proxy_max_temp_file_size
• 流式响应（SSE、日志 tail、gRPC streaming）：应关缓冲，proxy_buffering off;，靠系统 TCP 缓冲和 event loop 直通更高效
• 大响应头（JWT、多层 Cookie）：调高 proxy_buffer_size（如 16k;），但 proxy_busy_buffers_size 仍按 body 缓冲逻辑设，无需同步放大

验证是否真正起效

reload 后不能只看服务是否启动，重点观察两个信号：

• 用 curl -I 请求目标接口，确认响应头含准确的 Content-Length（说明未被 chunked 截断，缓冲链路完整）
• 检查 Nginx error log 是否仍有 upstream timed out 或 upstream prematurely closed connection 类报错；对比后端 access log 中连接耗时是否明显下降