proxy_max_temp_file_size 不是越大越好，需按响应特征、磁盘类型和系统能力配置：api设1m，报表导出设2–10m，视频分片设5–50m；机械盘≤2m，nvme ssd可设10–20m；必须配合proxy_buffering on、proxy_buffers 8 128k等参数协同调优。
proxy_max_temp_file_size 不是“越大越好”，也不是简单设为 0 就万事大吉。它只限制单个临时文件大小，不控制总磁盘用量，真正作用是给响应体落盘行为加一道“单次闸门”——值设高了，一个异常响应就可能打满分区；设低了，又会把中等响应强行拆成大量小文件，加剧随机 IO。关键得按业务响应特征、磁盘类型和系统能力来配。
按响应体分布和磁盘余量设合理上限
别凭感觉填数字，先看真实数据：
- 查后端常见响应大小：API JSON 多在 100KB–800KB，报表导出常为 2–10MB，视频分片多在 5–50MB
- 确认 proxy_temp_path 所在分区空闲空间 ≥ 3 倍该值（预留并发写入余量）
- 机械盘或共享云盘建议 ≤2m；NVMe SSD 可设 10m–20m；纯小响应网关（如微服务 API 网关）设 1m 更稳妥
必须同步调优的配套缓冲参数
单改这一项基本无效，要组合生效：
- proxy_buffering on：必须开启，否则 proxy_buffers 等参数不触发
- proxy_buffer_size 128k：覆盖含长 JWT、多 Cookie 的响应头
- proxy_buffers 8 128k：总内存缓冲达 1MB，减少落盘概率
- proxy_busy_buffers_size 256k：留出边收边发空间，避免转发阻塞
- proxy_temp_path /ssd/nginx/proxy_temp 1 2：显式指定 SSD 专用路径，避开系统盘争抢
不同场景下的典型配置策略
没有万能值，按实际场景选：
- 突发流量敏感型（如秒杀、实时指标推送）：设为 0，但需确保 proxy_buffers 总容量 ≥1MB，且上游具备幂等重试能力
- 混合型网关（既有 API 又有导出接口）：设为 1m，并将大文件路径（如 /export/）单独配置 proxy_buffering off，走纯流式
- 大文件下载代理（ISO、视频）：设为 20m–50m，配合 proxy_temp_path 指向高速 SSD，同时检查 client_max_body_size 是否匹配
上线后必须验证的关键点
配置不是终点，行为才是重点：
- error log 中是否还有 "an upstream response is buffered to a temporary file" —— 出现说明还在落盘
- 执行 ls -l /path/to/proxy_temp/*/* | wc -l 查看临时文件数量，长期稳定在个位数较理想
- iostat -x 1 观察 %util 和 await，若仍高频抖动，需排查 client_body_in_file_only、日志级别或 fastcgi/uwsgi 独立落盘行为
