proxy_max_temp_file_size仅限制单个临时文件最大大小（如20m），不控制总磁盘用量；须协同proxy_buffering on、proxy_buffers、proxy_temp_file_write_size等参数，才能有效约束单次请求落盘行为。
proxy_max_temp_file_size 并不用于“限制缓存总量”，它只控制单个临时文件的最大大小，且仅在 proxy_buffering on 且后端响应超出内存缓冲时，将溢出部分写入磁盘临时文件的场景下生效。
很多人误以为设这个值就能管住 Nginx 总共用多少磁盘缓存，其实不是——它不统计、不限制所有临时文件加起来用了多少空间，也不影响 proxy_cache 的总容量（那是 proxy_cache_path max_size 管的）。
✅ 它真正能做什么？
- 防止单个上游响应（比如一个大 PDF 或视频分片）生成一个超大临时文件（如 2GB），把整个
/var/tmp分区撑爆； - 在 SSD 上避免单次写入过大导致写放大或延迟毛刺；
- 配合业务响应体分布，卡住“该落盘但不能太野”的边界。
例如：
proxy_max_temp_file_size 20m;
表示：每个临时文件最多写 20MB；若响应是 150MB，Nginx 会生成 8 个左右 ≤20MB 的文件（如 0000000001、0000000002…），而不是一个 150MB 文件。
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
⚙️ 必须配套配置才有效
单独写这一行基本没用。需与以下参数协同：
proxy_buffering on;
→ 必须开启，否则不走临时文件路径。proxy_buffer_size 128k;proxy_buffers 8 256k;
→ 总内存缓冲 = 128KB（头）+ 2MB（主体）= 2.128MB；越大，越少落盘。proxy_temp_file_write_size 64k;
→ 每次往临时文件写 64KB，减少系统调用频次，适合中大响应。proxy_temp_path /ssd/nginx/proxy_temp 1 2;
→ 显式指定高性能路径（如 NVMe SSD 或 tmpfs），避免和日志争盘。client_max_body_size 500m;
→ 和它无关，但必须设好，防止上传请求在代理前就被拦，别让proxy_max_temp_file_size白配。
? 常见误区澄清
❌ 设成
0不是“关闭所有磁盘缓存”
它只是禁用 响应体溢出时的临时文件写入，不影响access_log、client_body_temp_path、ssl_session_cache、resolver缓存等其他磁盘行为。❌ 它不管
proxy_cache总大小
缓存总盘用量由proxy_cache_path /path levels=... keys_zone=cache:10m max_size=1g;中的max_size控制。❌ 不等于“本次请求最多用多少磁盘”
单次请求仍可能生成多个临时文件，总占用 ≈ 响应体大小（若全落盘）。真要控总量，得靠源头限响应大小（如后端压缩、前端分页）或改用流式转发（proxy_buffering off）。
? 实用建议（按场景）
| 场景 | 推荐值 | 补充动作 |
|---|---|---|
| 内网微服务 API（响应多 <800KB） | 0 |
同步调大 proxy_buffers 至 16 128k（共 2MB），确保常见响应不落盘 |
| 报表导出/大 JSON 下载（2–20MB） | 50m |
proxy_temp_path 指向 SSD，proxy_temp_file_write_size 128k
|
| 云主机共享盘（IOPS 有限） | 2m |
强制 >2MB 响应走流式（配合监控告警识别异常响应） |
| 视频分片代理（每片 5–50MB） | 100m |
避免切片被拆成多个小文件，降低 inode 和元数据压力 |
配置完记得重载：
nginx -s reload
再观察 error log 是否还有 "upstream response is buffered to a temporary file"，以及 proxy_temp_path 目录下临时文件增长是否符合预期。
