proxy_max_temp_file_size 0 的核心作用是：在 proxy_buffering on 时禁用上游响应体超出内存缓冲后的磁盘临时文件写入，精准切断反向代理中唯一可配置且对延迟抖动影响最直接的磁盘落盘环节，但不干预请求体、日志、ssl缓存等其他磁盘行为。

`proxy_max_temp_file_size 0` 的核心作用很明确：**在 proxy_buffering on 的前提下，禁止 Nginx 将上游响应体超出内存缓冲的部分写入磁盘临时文件**。它不追求“彻底禁用所有磁盘行为”，而是精准切断反向代理链路中**唯一可配置、且对延迟抖动影响最直接的磁盘落盘环节**——即响应体缓存溢出时的临时文件写入。 要让这个配置真正服务于极致实时性，必须理解它生效的前提、配套动作和适用边界。

它只管响应体，不管请求体、日志或 SSL

设为 0 后，Nginx 不再创建 proxy_temp_path 下的响应临时文件，但以下磁盘操作照常发生：

• 大文件上传仍会写入 client_body_temp_path（受 client_max_body_size 和 client_body_buffer_size 控制）
• 访问日志默认每次写都 fsync，高并发下显著抬升 I/O 等待（await）
• SSL 会话缓存若使用 shared，底层依赖 /dev/shm，但初始化可能触发少量元数据磁盘操作
• DNS 缓存若启用持久化（如某些 resolver 配置），会落盘到 /var/cache/nginx

必须同步调整的缓冲参数

单独设为 0 很可能引发 502 或连接中断，因为 Nginx 在无法缓存又不能写磁盘时，只能放弃。需确保内存缓冲能覆盖典型响应头+部分正文：

CPA Update - Secure CLI Proxy API Maintenance

安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。

下载

• proxy_buffering on; —— 必须开启，否则 proxy_buffers 等无效
• proxy_buffer_size 16k; —— 至少容纳完整响应头（含长 Cookie、JWT、多 Set-Cookie）
• proxy_buffers 8 128k; —— 总缓冲达 1MB，适配中等 JSON/API 响应体
• proxy_busy_buffers_size 256k; —— 保证转发过程中有足够接力缓冲，避免阻塞读取

更激进的选择：关闭缓冲，直通流式转发

若业务允许端到端低延迟直通（如微服务间 gRPC-Web、SSE 推送、OpenTelemetry trace 上报），可直接：

• proxy_buffering off; —— 此时 proxy_max_temp_file_size 完全失效，但获得理论最低转发延迟
• proxy_busy_buffers_size 4k; + proxy_buffers 2 4k; —— 构成轻量级背压：接收 >4KB 未发出时暂停读上游，保护 worker 内存
• 搭配 tcp_nodelay on; 和短超时（如 proxy_read_timeout 5s;）进一步收紧链路

适合哪些真实场景

该配置不是通用银弹，仅适用于满足以下条件的内部链路：

• 后端稳定、响应体可控（如 JSON API 平均
• 网关层已内置重试/熔断/降级（能容忍偶发 502）
• 流量路径短、跳数少（如 service mesh 数据平面、API 网关到核心服务）
• 监控可观测：可通过 error log 检查是否还有 “buffered to a temporary file” 提示，或用 iostat -x 1 观察 %util 和 await 在并发上升时是否明显回落