proxy_max_temp_file_size仅限单个临时文件大小，不控总量；设2m–4m（API）、50m–80m（报表）、128m（视频）并同步迁移temp_path至SSD、调大write_size至256k、过滤长尾请求。
proxy_max_temp_file_size 不是用来“限制 Worker 写入临时盘的总大小”的，它只管单个临时文件能写多大。想靠它保护 SSD 寿命，关键不是堵住所有落盘，而是让落盘更少、更大、更可控——避开高频小文件随机写这个 SSD 的头号杀手。
它真正控制什么
- 仅限制 Nginx 在
proxy_buffering on时，为单次后端响应生成的一个临时磁盘文件的最大尺寸（例如设为10m，那一个响应最多只写一个 10MB 文件） -
不控制：
- 所有临时文件加起来占多少空间（那是磁盘配额或运维监控的事）
-
proxy_cache缓存大小（归proxy_cache_path max_size管） - 客户端上传产生的临时文件（归
client_body_temp_path和client_max_body_size管） - 日志、SSL 会话缓存等其他磁盘行为
怎么设才对 SSD 友好
盲目设成 0 或 2g 都不行：
- 设
0→ 强制全内存缓冲，但一旦响应超 buffer 总和，直接 502；高并发下内存压力陡增，还可能触发 OOM - 设
1g（默认）→ 一个 500MB 报表响应可能被切成 500 个 1MB 小文件，元数据更新 + 随机写放大，SSD P/E 消耗翻倍
推荐按业务响应体分布来定：
- API/微服务网关（95% 响应 2m～
4m，绝大多数不落盘，偶有大响应直接流式转发 - 报表导出或日志聚合（常见 5–30MB）：设
50m～80m，避免切片，单次写入更连续 - 视频分片代理（稳定在 20–100MB）：设
128m，并把proxy_temp_path指向/dev/shm/nginx_temp（tmpfs 内存盘），物理磁盘零写入
必须同步做的三件事，否则调参白搭
-
挪路径：用
proxy_temp_path /ssd/nginx/proxy_temp 1 2;显式指定 NVMe SSD 上的独立分区，不和日志、系统共盘 -
提写入粒度：配
proxy_temp_file_write_size 256k;，大幅减少write()系统调用次数，让 IO 更接近顺序写 -
砍长尾落盘：对 URI 高度离散的路径（如
/log?uid=xxx&t=123456789），用proxy_cache_bypass $arg_t;或location ~ ^/log { proxy_buffering off; }直接禁用缓冲，从源头跳过临时文件流程
不复杂但容易忽略
