如何利用 proxy_max_temp_file_size 禁止响应落盘提升性能实战-Nginx-PHP中文网

设为0可禁用代理响应体落盘，避免高频小io抖动；需配合proxy_buffering on及足够内存缓冲（如proxy_buffers 16 64k），否则易触发502。

如何利用 proxy_max_temp_file_size 禁止响应落盘提升性能实战

直接设为 0 是禁用代理响应体落盘最有效的方式，但它不是“关磁盘”，而是切断 Nginx 在 proxy_buffering on 模式下将溢出响应写入 proxy_temp_path 临时文件的路径。真正起效的前提是配合内存缓冲策略，否则会快速触发 502 或连接中断。

为什么设为 0 能减少磁盘 I/O

中等大小响应（几十 MB 到几百 MB）最容易引发高频小 IO：Nginx 先用内存缓冲存一部分，满了就刷一小块到磁盘；客户端读得慢，Nginx 又要从小文件里反复读取再发；请求结束还要清理 inode。这一过程在高并发下会显著抬高 iowait 和 %util。设为 0 后，这部分落盘逻辑被跳过，Nginx 要么把整个响应塞进内存转发，要么直接流式边收边发——绕开了磁盘瓶颈。

仅影响 proxy_pass 响应体，不干预请求体、日志、SSL 缓存等其他磁盘行为
生效前提是 proxy_buffering on（默认值），且后端未返回 Transfer-Encoding: chunked 或 Connection: close 导致自动退化为直传
临时文件名如 0000000001 不再出现，iotop -o 中 nginx worker 的写盘行为明显下降

必须同步调整的三个核心参数

单独改 proxy_max_temp_file_size 0 极易导致失败。关键是要让内存缓冲能覆盖常见响应头 + 主体片段，避免一满就断连：

aperture: the L402 aware reverse proxy

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

下载

proxy_buffering on：必须保持开启，否则 proxy_buffers 等参数不生效
proxy_buffer_size 4k–16k：专用于响应头，含 Set-Cookie、Content-Disposition 等，设太大浪费，太小会截断
proxy_buffers 8 128k 或 16 64k：总缓冲建议 ≥1MB，适配报表、HTML、JSON 等典型响应；若常处理 >2MB 响应，可升至 16 256k，但需监控 worker RSS 内存增长

更激进但延迟更低的流式方案

如果业务允许端到端直通（如前端用 fetch().body.getReader()、后端稳定输出 chunked 或分片），可进一步关闭缓冲：

proxy_buffering off：此时 proxy_max_temp_file_size 完全失效，Nginx 彻底放弃缓存，收到即转发
proxy_busy_buffers_size 4k：配合 proxy_buffers 2 4k，形成轻量级背压——一旦接收数据超过 4KB 且未及时发出，Nginx 主动暂停读上游，防止内存撑爆
指定内存临时路径（可选）：proxy_temp_path /dev/shm/nginx/proxy_temp 1 2;，前提是 /dev/shm 已挂载 tmpfs 且空间充足

哪些磁盘 I/O 它管不了

设为 0 并不能消灭所有磁盘交互，以下环节仍会稳定写盘，需单独优化：

访问日志：默认每次写都 fsync，高并发下是 wa% 主因；改用 access_log /var/log/nginx/access.log buffer=64k flush=1s;
大请求体上传：由 client_body_temp_path 和 client_body_buffer_size 控制，与该参数无关
Gzip 流式压缩：若启用 gzip on 且响应未被完整缓冲，Nginx 可能借助临时文件压缩，建议上游已压缩或关闭 gzip
DNS 缓存持久化：某些 resolver 配置会在 /var/cache/nginx 写文件，应避免或改用无状态 resolver