proxy_buffers是nginx为每个代理请求预分配的内存缓冲区集合，专存后端响应体数据；它不是全局池、非page cache、更非磁盘文件，而是per-request、固定大小、仅在proxy_buffering on时生效的内存块组。
proxy_buffers 是什么，不是什么
proxy_buffers 是 Nginx 为每个活跃代理请求预分配的一组内存缓冲区，专用于暂存后端返回的响应体（body）数据。它不是全局共享池，也不是操作系统 page cache，更不是磁盘临时文件——它是 per-request 的、可复用的、固定大小的内存块集合。
关键点： • 每个请求独占一组 buffer，数量 × 单块大小 = 该请求最大可用缓冲内存 • 它只在 proxy_buffering on 时生效；一旦设为 off，整个 proxy_buffers 配置完全失效 • proxy_buffer_size 不属于它，那是单独管响应头的，二者互不干扰
怎么设才不踩坑：按响应体分档配总量
设错的核心原因是“拿一套参数套所有业务”。真实场景中，API 响应和报表导出的体积差百倍，必须分档处理：
-
中小响应（JSON/API/SSR HTML，平均 50–200KB）：用
proxy_buffers 8 256k（总量 2MB）。够覆盖 95% 请求，单 worker 在百并发下 RSS 稳定可控 -
大响应（报表导出、镜像回源，10–100MB）：用
proxy_buffers 32 256k（总量 8MB），但必须同步限制并发或改用proxy_buffering off -
高频小包（IoT 上报、心跳）：用
proxy_buffers 16 16k（总量 256KB/连接），单块匹配典型消息，避免跨 buffer copy 和频繁分配抖动
严禁：proxy_buffers 64 4m——单请求吃 256MB，10 并发就能触发 OOM。
WeChat macOS Proxy
下载
macOS 微信消息自动化工具。通过 GUI 自动化实现：发送消息给指定联系人、读取聊天内容、监控新消息。适用于需要自动化微信操作的场景，如定时发送、批量回复、消息备份等。依赖 peekaboo 进行屏幕截图和 UI 交互。仅支持 macOS。开源地址：https://github.com/chairmanmia...
proxy_busy_buffers_size：决定“已收未发”能留多少
这个值不是额外加内存，而是从 proxy_buffers 总量里划出一块，专供“正在发给客户端但还没清空”的数据驻留。设错会直接卡住后端：
- 推荐设为总量的 1/4 至 1/2，且 不低于单块大小
→
proxy_buffers 8 128k（总量 1MB）→ 设proxy_busy_buffers_size 512k→proxy_buffers 16 256k（总量 4MB）→ 设proxy_busy_buffers_size 2m - 设太小（如沿用默认 8k）：Nginx 收几 KB 就暂停读上游，后端 write() 阻塞，日志出现
upstream timed out - 设太大（如 8m 对应总量仅 2MB）：启动失败或退化为同步阻塞
配套动作：禁落盘、控超时、验实效
只调 proxy_buffers 不解决问题，必须协同收敛：
-
禁用临时文件：内存充足时设
proxy_max_temp_file_size 0，超限直接 502，比默默刷盘更利于暴露瓶颈 -
延长等待窗口：对慢响应（如导出），设
proxy_read_timeout 300，防中途断连 -
验证是否真起效：
• 查
/proc/<nginx-pid>/status | grep VmRSS</nginx-pid>，确认单 worker RSS 符合预期（如总量 4MB 缓冲 + 开销 ≈ 120–180MB） • curl -I 看响应头是否含准确 Content-Length（说明没被 chunked 截断） • error_log 开 debug，搜writing to temp file或upstream buffer is too small
