核心是合理配置 proxy_buffers、proxy_busy_buffers_size 和 proxy_buffer_size，并禁用临时文件写入：proxy_buffers 16 128k、proxy_busy_buffers_size 1m、proxy_buffer_size 16k、proxy_max_temp_file_size 0，确保响应数据尽量内存流转，避免频繁磁盘 i/o。

要让 Nginx 在转发后端响应时不频繁写临时文件，核心是让数据尽量留在内存里流转——proxy_buffers 不是调大就行，而是要和响应特征、网络节奏对齐。默认的 8 4k（共 32KB）在现代业务中基本不够用，尤其面对几十 KB 以上的 API 响应或 MB 级文件时，极易触发磁盘落盘。

匹配后端响应块大小与频率

proxy_buffers 每次从后端读取数据，优先填满一块 buffer 再换下一块。若单块设得太小（如 4k），而你的后端按 64k 分块推送日志流，就会频繁切换 buffer、增加内存管理开销；若设得太大（如 4m），又容易造成单请求独占过多内存。

• 后端典型响应块为 32KB（如 SSE 流、分块 JSON）→ 设 proxy_buffers 16 32k
• 常见 HTML/JSON 接口多在 100–500KB → 推荐 proxy_buffers 16 128k（总 2MB）
• 报表导出或镜像回源常达 10–100MB → 可设 proxy_buffers 32 256k（总 8MB）

控制“已收未发”数据的内存上限

仅增大 proxy_buffers 不够，还必须通过 proxy_busy_buffers_size 控制有多少缓冲区可以处于“正在发给客户端但还没清空”的状态。它决定了 Nginx 是否还能继续从后端读数据。

FastAPI Flask Proxy

FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。

下载

• 该值必须 ≥ 单块 buffer 大小，否则刚写满一块就停住
• 建议设为 proxy_buffers 总量的 1/4 到 1/2，例如：
  　　proxy_buffers 16 128k（总 2MB）→ proxy_busy_buffers_size 1m
　　proxy_buffers 32 256k（总 8MB）→ proxy_busy_buffers_size 4m
• 设太小会导致后端写入阻塞，甚至触发 502；设太大则挤占空闲 buffer，降低并发接收能力

配合响应头与临时文件策略

proxy_buffer_size 单独管响应头，默认 4k。若后端返回超长 header（如含大量 Cookie 或 JWT），会报 “upstream sent too big header”，此时需同步调大，比如 proxy_buffer_size 16k，且该值必须小于单块 proxy_buffers 大小。

• 禁用临时文件写入（内存充足时）：
  　　proxy_max_temp_file_size 0; —— 超出内存直接返回 502，避免磁盘 I/O 成瓶颈
• 允许落盘但优化 IO：
  　　proxy_temp_file_write_size 256k;（减少小 write() 调用）
  　　proxy_temp_path /dev/shm/nginx_temp 1 2;（挂载到内存盘）

验证是否真正起效

reload 配置后，不能只看服务是否启动，要观察实际行为：

• 开启 debug 日志：error_log /var/log/nginx/error.log debug;，搜索 “writing to temp file” —— 若高频出现，说明缓冲设计仍不足
• 监控指标：disk writes 突增、$upstream_response_time 显著高于 $request_time，都指向缓冲区卡顿
• 注意：这些参数仅在 proxy_buffering on; 时生效；若你关了 buffering（如大文件下载场景），它们全部不参与工作