核心是协同控制“已收未发”内存上限、落盘时机和写入粒度；需合理设置proxy_buffers总量与单块大小，同步配置proxy_busy_buffers_size为总量的1/4～1/2且不低于单块大小，并调优proxy_max_temp_file_size、proxy_temp_file_write_size及proxy_temp_path。

要解决后端响应过大引发的磁盘临时文件 IO 瓶颈，核心不是单纯加 proxy_buffers，而是协同控制“已收未发”数据的内存上限、落盘时机和写入粒度。只调大缓冲区数量或大小，不配好 busy 区和临时文件策略，反而容易让 Nginx 频繁刷盘、卡住上游连接，甚至触发 502 或超时。

合理设置 proxy_buffers 总量与单块大小

proxy_buffers 决定了 Nginx 为每个请求分配多少内存来缓存响应体（不含响应头）。设得太小，大响应很快溢出进磁盘；设得太大，单 worker 进程可能吃掉数百 MB，增加 OOM 风险。

• 常规 HTML/API 响应：用 proxy_buffers 8 16k（共 128KB），兼顾内存效率与稳定性
• 报表导出、模板渲染等中大响应（几 MB）：可设为 proxy_buffers 16 64k（共 1MB）
• 避免极端值，例如 proxy_buffers 32 4m（128MB）易导致 worker 内存失控，不推荐

必须同步配置 proxy_busy_buffers_size

这个参数管的是“已接收但还没发给客户端”的那部分缓冲区内存上限。它不是独立池子，而是从 proxy_buffers 总量里划出来的“忙区”。设错会直接导致后端写入阻塞。

aperture: the L402 aware reverse proxy

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

下载

• 推荐设为 proxy_buffers 总量的 1/4 到 1/2，且不低于单块 buffer 大小
• 例如 proxy_buffers 8 1M（总 8MB），busy 值设为 2M 或 4M 较稳妥
• 若单块是 128k，busy 值就不能低于 128k；设成 64k 就可能过早暂停接收，拖慢后端

约束临时文件行为，减少磁盘 I/O 压力

当响应超出内存缓冲，Nginx 默认写临时文件——这是 IO 瓶颈的主因。不能禁用，但要管住它怎么写、写在哪。

• proxy_max_temp_file_size 不建议设为 0（会丢请求），也不宜过大（如 4G）。对 GB 级下载，1024m 是较稳选择
• proxy_temp_file_write_size 提高到 128k 或 256k，显著降低 write() 系统调用频次，减轻 I/O 压力
• 若条件允许，把临时目录挂到内存盘：proxy_temp_path /dev/shm/nginx_temp 1 2，跳过磁盘直走 RAM

验证是否真正绕开磁盘瓶颈

改完配置 reload 后，不能只看服务是否起来，要观察真实效果：

• 用 curl -I 请求，确认响应头含准确的 Content-Length（说明未被 chunked 截断，缓冲完整生效）
• 检查 error log 是否仍有 upstream response is buffered to a temporary file —— 若还有，说明整体缓冲仍不足或落盘策略不合理
• 对比前后端日志：后端连接释放是否变快？access_log 中响应时间是否更稳定？