nginx处理大体积响应时的吞吐瓶颈在于缓冲区调度失衡、隐式阻塞和磁盘落盘，关键在于避免卡住上游、拖慢客户端和浪费内存；需合理配置proxy_buffering、busy缓冲区、upstream长连接及系统资源。
Nginx 处理后端返回的大体积响应（如大文件下载、长 HTML 渲染、视频流、批量 JSON 导出）时，吞吐瓶颈往往不出现在网络带宽，而在于缓冲区调度失衡、隐式阻塞和磁盘落盘。关键不是“让 Nginx 更快”，而是“不让它卡住上游、不拖慢客户端、不浪费内存”。
合理配置 proxy_buffering 与 busy 缓冲区
proxy_buffering 控制 Nginx 是否缓存整个响应体再转发。默认 on，适合多数场景；但对超大或流式响应，需精细调优：
- proxy_buffer_size 128k：专存响应头，应大于后端最大 Header（含 Cookie、自定义字段等）
- proxy_buffers 8 128k：共 1MB 内存缓冲区，覆盖常见大响应体（如 800KB 的仪表盘 HTML）
- proxy_busy_buffers_size 256k：设为单 buffer 大小的 2 倍，确保有足够“正在发送中”的缓冲空间，避免过早停读上游
- proxy_max_temp_file_size 0：禁用临时文件，彻底规避磁盘 I/O——前提是内存缓冲充足且后端稳定
注意：proxy_busy_buffers_size 必须 ≤ proxy_buffers 总量，且必须在 proxy_buffering on 时才生效。
启用 upstream 长连接并匹配 HTTP/1.1
每次请求新建后端连接会显著拖慢大响应传输节奏：
- upstream 中配置 keepalive 32（按后端连接池容量设，通常 16–64）
- location 中设置 proxy_http_version 1.1 和 proxy_set_header Connection ""
- 确保后端支持 keepalive（如 Spring Boot 默认 max-connections=8192，需核对）
可用 ss -tnp | grep :8080 观察 ESTABLISHED 连接是否稳定维持，而非瞬时飙升后归零。
根据场景决定是否关闭 proxy_buffering
开启（on）：适用于需要完整响应校验、重写、缓存或压缩的场景；此时必须同步调大 proxy_buffers 和 proxy_busy_buffers_size
-
关闭（off）：适用于真正流式场景（如 SSE、实时日志流、分片视频），Nginx 边收边发，无缓冲堆积；但要求客户端网络稳定，且必须延长超时：
- proxy_read_timeout 120
- proxy_send_timeout 60
关闭后，proxy_busy_buffers_size 失效，所有缓冲参数退化，仅靠内核 socket 缓冲区流转。
协同系统与 worker 层资源
再好的缓冲策略也依赖底层支撑：
- worker_processes auto：自动绑定全部 CPU 核心
- worker_connections 16384
- worker_rlimit_nofile 65536
- 系统级 ulimit -n 65536 需同步生效
访问日志开启缓冲：access_log /var/log/nginx/access.log main buffer=64k flush=5s;，避免磁盘写入干扰事件循环。
不复杂但容易忽略
