默认proxy_buffers 8 4k为短响应设计，不适用websocket长连接；高频小包易致内存碎片、gc频繁、copy开销大；应按消息体积设单块16k/32k、控制总数防浪费、协同proxy_busy_buffers_size，并关闭proxy_buffering。
要让高频 WebSocket 消息推送更稳、更省内存，proxy_buffers 的设置不能照搬 HTTP 接口那一套——它得配合长连接特性来调，否则容易卡消息、抖连接、吃内存。
为什么默认值在 WebSocket 场景下容易出问题
默认 proxy_buffers 8 4k（共 32KB）是为短响应设计的。WebSocket 是持续双向流，高频小包（比如每秒几十条心跳或状态更新）会频繁触发缓冲区分配/释放，造成：
- 内核页分配压力上升，GC 频繁
- 缓冲区碎片化，实际可用空间下降
- 小包被分散写入多个 buffer，增加 copy 开销
合理设置 proxy_buffers 的三个关键点
1. 单块大小要匹配典型消息体积
多数业务中，单条 WebSocket 消息在 1–8KB 之间（如 JSON 状态包、二进制指令）。建议设为 16k 或 32k，避免一条消息跨多块 buffer。
2. 总数量不宜过多，但需留足并发缓冲余量
每个活跃连接至少占用 1–2 块 buffer。若预期峰值连接数 5000，用 proxy_buffers 16 16k（共 256KB/连接理论上限），总内存开销可控；盲目设成 64 8k 反而易引发内存浪费和调度延迟。
3. 必须与 proxy_busy_buffers_size 协同
busy 值应为 buffers 总量的 1/2 左右，且不低于单块大小。例如：proxy_buffers 16 16k; → 总量 256k → 推荐 proxy_busy_buffers_size 128k;
不同业务类型的推荐配置
高频小包型（如 IM 心跳、IoT 设备状态上报）：proxy_buffer_size 16k;proxy_buffers 16 16k;proxy_busy_buffers_size 128k;
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
混合大包型（如含图片缩略图、日志片段）：proxy_buffer_size 32k;proxy_buffers 8 32k;proxy_busy_buffers_size 128k;
注意：WebSocket 场景下务必关闭缓冲 —— 上述配置仅在 proxy_buffering off; 时作为底层 I/O 缓冲参考值生效；真正起效的是 proxy_buffer_size（首包缓冲）和 OS TCP 层行为。
验证是否调得合适
改完 reload 后，重点看两点：
- 用
ss -i或netstat -s | grep -i "retransmit\|recovered"观察重传是否减少 - 监控 Nginx worker 进程 RSS 内存波动：若高频推送时内存阶梯式上涨不回落，说明 buffer 分配未复用，需调大单块或减少总数
