proxy_buffers 本身不配合缓存机制，也不能“配合缓存写入”来减少磁盘写，它与 proxy_cache 是两套独立机制；真正避免 writing to temp file 的关键是让响应体全程内存流转，需合理设置 proxy_buffers 总量、proxy_busy_buffers_size，并禁用或优化临时文件路径。
直接说结论：proxy_buffers 本身不配合缓存机制，也不能“配合缓存写入”来减少磁盘写——它和 Nginx 的 proxy_cache 是两套独立机制。真正减少磁盘写（即避免 writing to temp file），关键在于让响应体全程在内存中收发完毕，而不是靠缓存策略兜底。
明确 proxy_buffers 的作用边界
proxy_buffers 只负责「反向代理时，把后端响应体暂存在内存里，等客户端慢慢读」。它不参与 cache 存储、不读写 proxy_cache_path 下的文件、也不受 proxy_cache_valid 等缓存指令影响。所谓“配合缓存”，是常见误解。
磁盘写只发生在一种情况：缓冲区不够用，Nginx 被迫把已接收但尚未发出的数据写进临时文件。这个行为由以下三者共同决定：
- proxy_buffers 总量是否覆盖典型响应体大小
- proxy_busy_buffers_size 是否合理，避免过早停收或堆积失控
- proxy_max_temp_file_size 是否为 0（禁用落盘）或路径是否指向内存盘（如 /dev/shm）
按响应特征设对 buffer 总量与单块大小
不能统一用“越大越好”，要匹配你后端实际输出节奏和体积分布：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- API / HTML / JSON（平均 50–300KB）：proxy_buffers 8 256k（总量 2MB），够用且单 worker RSS 易控在 512MB 内
- 报表导出 / 镜像回源（几 MB～百 MB）：proxy_buffers 32 256k（总量 8MB），但必须同步限并发（如 limit_conn addr 50）或改用 proxy_buffering off
- 高频小包（IoT 上报、心跳）：proxy_buffers 16 16k（总量 256KB），单块贴合常见消息粒度，减少跨 buffer copy
严禁 proxy_buffers 64 4m 这类配置——单请求吃 256MB，3 并发就可能触发 OOM。
严格约束“已收未发”数据驻留上限
proxy_busy_buffers_size 不是额外内存，而是从 proxy_buffers 总量里划出的“正在发送给客户端”的那部分缓冲区上限。设错会直接导致后端写阻塞或内存滞留：
- 总量 2MB（如 8 256k）→ 设 proxy_busy_buffers_size 1m
- 总量 8MB（如 32 256k）→ 设 proxy_busy_buffers_size 4m
- 该值必须 ≥ 单块大小（例如单块是 256k，busy 就不能设成 128k），否则几轮响应就暂停接收
切断落盘路径：禁用 or 强制走内存盘
只要开始写临时文件，就会污染 page cache、拖慢内存回收、引发 I/O 等待——这才是磁盘写拖慢响应的根本原因：
- 内存充足且可接受超限时失败：proxy_max_temp_file_size 0，超限直接返回 502，暴露瓶颈而非掩盖
- 必须允许落盘时：proxy_temp_path /dev/shm/nginx_temp 1 2，挂载到内存盘；再配 proxy_temp_file_write_size 256k，降低 write() 频次
- 绝对不要把 proxy_temp_path 指向系统盘、日志盘或低速存储
reload 后，务必检查 error log 是否还有 writing to temp file —— 有就是缓冲仍不足，不是“缓存没配好”。
