proxy_max_temp_file_size 是 Nginx 在 proxy_buffering on 时限制单个代理响应临时磁盘文件大小的参数；当上游响应超出内存缓冲（proxy_buffer_size + proxy_buffers 总和）时，Nginx 将溢出部分写入磁盘临时文件，该参数即控制每个此类文件的最大尺寸。
proxy_max_temp_file_size 是什么，什么时候会触发写磁盘
这个配置控制 Nginx 在 proxy_buffering 开启时，单个临时文件的最大大小。当上游响应体超过 proxy_buffer_size + proxy_buffers 总和，且未被完全缓存在内存中时，Nginx 会把超出部分写入磁盘临时文件——而 proxy_max_temp_file_size 就是每个这样的临时文件的上限。
高负载下如果大量请求的响应体略超内存缓冲区（比如 128KB ~ 1MB），又没设好这个值，就会频繁创建、写入、合并小临时文件，导致大量随机 IO，表现为 iowait 飙升、iotop 显示 nginx: worker process 持续刷盘。
默认值太保守，高并发场景下必须调大
默认是 1024m（1GB），听起来不小，但实际容易误判：它不是“所有临时文件总大小”，而是“每个临时文件”的上限。Nginx 会把一个大响应拆成多个不超过该值的文件（如 2GB 响应可能生成两个 1GB 文件），而频繁切分正是 IO 抖动的源头。
- 若业务响应体普遍在 5–50MB（如报表导出、大图代理），建议设为
50m～100m，避免切分过多 - 若响应体多在 100KB 以内，可直接设为
0（禁用磁盘临时文件），强制走内存缓冲或直接流式转发（需同时关proxy_buffering） - 设为
0时，Nginx 不会写任何临时文件，但要求proxy_buffering off或响应能被完整塞进内存缓冲区，否则会报502 Bad Gateway
和 proxy_buffering、proxy_buffers 的协同关系
单独调 proxy_max_temp_file_size 没用，它只是“缓冲溢出后怎么落盘”的规则。真正决定是否落盘、落多少，取决于内存缓冲策略：
⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**
-
proxy_buffering on（默认）：启用缓冲，响应先存内存/磁盘，再发给客户端；此时proxy_max_temp_file_size生效 -
proxy_buffering off：禁用缓冲，响应边收边转，不落盘也不缓存，proxy_max_temp_file_size完全无效 -
proxy_buffers 8 16k表示最多用 8 个 16KB 缓冲区（共 128KB），加上proxy_buffer_size（通常 4k～8k）用于响应头；总内存缓冲 ≈ 132KB～136KB - 若响应 > 总内存缓冲，且
proxy_buffering on，才走到proxy_max_temp_file_size控制的落盘逻辑
实测建议与容易踩的坑
线上调优不能只看文档值，得结合 nginx -t + ab 或 wrk 压测观察 iostat -x 1 和 nginx error log 中的 upstream sent too big header 或 client intended to send too large body 类错误。
- 不要盲目设成
2g：单文件过大虽减少切分，但可能拖慢单个大响应的释放速度，影响 worker 进程调度 - 检查
client_body_temp_path和proxy_temp_path所在磁盘是否 SSD，是否与其他高 IO 服务共盘——即使参数调对，硬件瓶颈也白搭 - 改完必须
nginx -s reload，且注意：已有连接不会立即应用新配置，要等旧连接自然结束或主动断连 - 如果用了
proxy_cache，proxy_max_temp_file_size对缓存写入过程也有影响，此时还需同步检查proxy_cache_path的levels和max_size
最常被忽略的是：这个参数只在 proxy_buffering on 且响应溢出内存时起作用。很多团队压测发现 IO 高，第一反应调它，结果发现其实是 proxy_buffering off 下走流式转发，根本没走这套逻辑——先确认当前 buffering 状态，比调参重要得多。
