当网关磁盘压力大且access log出现高延迟时，大概率是proxy_max_temp_file_size未匹配业务响应特征所致；应结合磁盘类型与响应体分布设为合理值（如ssd设10m、机械盘设2m、内存优先场景可设0但需调大缓冲区），并同步优化proxy_temp_path、proxy_buffering等配套参数。

当网关磁盘压力大（如 iostat -x 1 显示 %util ≈ 100%、await 毫秒级飙升），而 Nginx error log 无明显报错、access log 却出现大量高延迟请求时，大概率是代理响应体频繁落盘引发的随机小 I/O 抖动。此时 proxy_max_temp_file_size 是关键调节杠杆——它不控制总磁盘用量，而是决定“单个响应是否写临时文件”，调优目标不是增大，而是**精准匹配业务响应特征，切断抖动源头**。

识别是否真由 proxy_max_temp_file_size 触发的磁盘瓶颈

先确认问题归属，避免误调：

• 检查 Nginx error log 是否有 client intended to send too large body —— 这是 client_max_body_size 或 client_body_buffer_size 问题，与该参数无关；
• 用 lsof -p $(pgrep nginx) 或 iotop -o -p $(pgrep nginx) 确认高 I/O 的 worker 进程是否在读写 /var/cache/nginx/proxy_temp/ 或你自定义的 proxy_temp_path 下的文件；
• 若发现大量 xxx.000001、xxx.000002 等小编号临时文件被高频创建/删除，说明中等大小响应（如 200KB–5MB）反复触发“写→读→删”流程，正是该参数未对齐业务的典型表现。

根据磁盘类型和响应分布选择合理值

设太大或为 0 都可能恶化稳定性，需结合实际硬件与流量结构：

aperture: the L402 aware reverse proxy

安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。

下载

• SSD + 响应体集中于 1–10MB（如报表导出、批量 API 响应）：设为 10m，配合 proxy_temp_path /ssd/nginx/proxy_temp 1 2，让单次写入更连续，减少碎片；
• 机械盘或低配云盘 + 多数响应 ：设为 2m，避免单文件写入耗时过长阻塞 worker；
• 纯内存转发优先场景（如内部微服务间 JSON 调用，平均响应 0，但必须同步开启 proxy_buffering on 并调大缓冲区（如 proxy_buffers 8 256k），否则直接 502；
• 大文件下载服务（如 ISO、视频分片）：不建议设为 0，而应设为足够大的值（如 1024m），并确保 proxy_temp_path 所在分区有充足空间和 inode，避免写满中断。

必须同步调整的配套参数

单独改 proxy_max_temp_file_size 几乎无效，需协同优化缓冲路径：

• proxy_temp_path 必须指向独立、高速的存储路径（如 SSD 分区或 /dev/shm），禁止与系统日志、其他服务共用磁盘；
• proxy_buffering on 是前提（默认即开启），关闭后该参数完全失效；
• proxy_buffer_size 至少设为 4k，确保响应头完整缓存；
• proxy_buffers 总和建议 ≥ 业务常见响应体的 1.5 倍（例如常见响应 1MB，则设 8 256k = 2MB）；
• proxy_busy_buffers_size 设为单块 buffer 大小或略高（如 256k），保证转发接力不卡顿。

验证效果的关键指标

上线后盯住两个信号：

• Nginx error log 中是否新增 upstream sent too big response 或 Connection reset by peer —— 若出现，说明内存缓冲不足，需回退该值或继续调大 proxy_buffers；
• 对比调优前后 iostat -x 1 的 r/s（读请求数）、w/s（写请求数）和 avgqu-sz（平均队列长度）：理想状态是 w/s 显著下降、avgqu-sz 回落至 1 以下，表明磁盘争用解除。