调大 proxy_temp_file_write_size 是榨取 SSD 吞吐的关键，需配合 proxy_buffering on、充足内存缓冲及专用 SSD 临时路径，并通过 strace 和 iostat 验证 write 块大小与 avgrq-sz 提升。
调大 proxy_temp_file_write_size 是榨取 SSD 吞吐的关键一环，但它不是孤立参数——必须让写入“块够大、路径够快、缓冲够稳”，才能把 NVMe 或高性能 SATA SSD 的顺序写能力真正打满。
SSD 场景下的推荐取值与依据
该值控制 Nginx 每次向临时文件执行 write() 系统调用时的数据量。默认 8k 或 32k 在高并发大响应下会触发海量小 IO，严重浪费 SSD 的 IOPS 和带宽。
- NVMe / 企业级 PCIe SSD：可设为 256k–512k，实测在 CDN 回源、视频分片下载等场景下吞吐提升 30%–60%
- 消费级 SATA SSD 或高负载云盘（如 AWS gp3、阿里云 ESSD PL1）：建议 128k–256k，兼顾稳定性，避免单次写入过大导致短暂延迟毛刺
- 若已将
proxy_temp_path指向/dev/shm（tmpfs 内存盘）：可设为 512k 或 1m，内存无寻道成本，大块写更高效 - 不建议超过 1m：Nginx 内部有隐式缓冲截断逻辑，超限后实际写入仍被切分，反而增加开销
必须同步强化的三项基础
只改这个值，效果会被其他瓶颈吃掉。以下三点缺一不可：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
确保
proxy_buffering on：该参数仅在此模式下生效；若关闭，则整个代理缓冲链路绕过，此值完全无效 -
内存缓冲总量要匹配：例如设了
proxy_buffers 16 256k（共 4MB），再配proxy_temp_file_write_size 256k才有意义；若总 buffer 只有 1MB，大部分数据仍快速溢出到磁盘，写频次降不下来 -
临时路径必须独立挂载 SSD：用
proxy_temp_path /ssd/nginx/proxy_temp 2 2显式指向专用 NVMe 分区，并确认挂载选项含noatime,nobarrier（XFS）或noatime,commit=60,data=writeback（ext4）
验证是否真正打满 SSD 吞吐
调优后不能只看配置，要观测真实行为：
- 用
strace -e trace=write -p $(pgrep -f "nginx: worker")抓取 worker 进程的 write 调用，确认字节数稳定接近你设置的值（如 262144 = 256k） - 运行
iostat -x 1，观察avgrq-sz是否明显上升（如从 8–16KB 升至 200–400KB），同时%util更平稳、await下降 - 对比压测前后，相同 QPS 下的平均响应时间与错误率（特别是 502/503），确认吞吐提升未以稳定性为代价
警惕两个典型失效场景
即使参数全对，也可能因底层逻辑被绕过而无效：
- 后端返回
Transfer-Encoding: chunked或无Content-Length，且未缓存（如含Cache-Control: no-store），Nginx 默认不落盘，proxy_temp_file_write_size不参与流程 - 客户端接收极慢（如弱网移动端），导致 Nginx 长时间 hold 缓冲区，即便设置了大 write size，也会因超时或连接中断提前刷盘或丢弃
