核心是通过 upstream 长连接复用、合理缓冲区配置、收紧超时参数及底层运行时调优，提升 nginx 代理性能；需配置 keepalive、proxy_http_version 1.1、connection 头清空，调整 proxy_buffers 与 busy 缓冲区大小，设置合理超时，并匹配 worker 连接数与系统限制。
核心是让 Nginx 与后端之间复用连接、减少阻塞、加快响应流转，而不是单纯调大缓冲区或加机器。
开启并验证 upstream 长连接
默认每次请求都新建 TCP 连接，握手和 TLS 协商开销极大。必须显式启用长连接复用：
- 在 upstream 块中添加 keepalive 32;（数值按后端连接池容量设，常见 16–64）
- 对应 location 中必须配齐：proxy_http_version 1.1; 和 proxy_set_header Connection '';（清空客户端传来的 close 指令）
- 确认后端服务自身支持 keep-alive（如 Spring Boot 的 max-connections、Tomcat 的 connectionTimeout）
- 用 ss -tnp | grep :backend_port 观察 ESTABLISHED 连接是否稳定存在，而非瞬时涨落
优化 proxy_buffering 与 busy 缓冲区
这是影响大响应吞吐的关键组合，配置不当会导致 Nginx “收得慢”甚至卡住后端：
- proxy_buffers 16 512k;（总缓冲区 8MB，适合多数 API 或页面响应）
- proxy_busy_buffers_size 设为总量的 1/4–1/2，且不低于单块大小（例如上例中设 256k）
- 避免使用默认值（常为 8k–16k），否则 Nginx 很快停止从后端读数据，造成上游等待
- 验证方式：curl -I 查看响应头含 X-Accel-Buffering: yes，且无 Transfer-Encoding: chunked
收紧超时与并发参数
防止连接空耗资源，释放事件循环处理能力：
- proxy_connect_timeout 5s;（连接后端超时，不宜过长）
- proxy_send_timeout 30s;（发请求给后端的超时）
- proxy_read_timeout 60s;（等后端响应的超时，按业务逻辑设）
- 确保 worker_connections 和系统 ulimit -n 匹配（如设 16384，则系统需 ≥65536）
- 禁用 proxy_buffering off，除非明确需要流式传输（如 SSE）；关闭后易引发隐式同步阻塞
协同调优底层运行时
再好的代理策略也依赖底层支撑：
- worker_processes auto;（自动绑定全部 CPU 核心）
- worker_cpu_affinity auto;（减少跨核调度开销）
- 日志写入启用缓冲：access_log /path/log main buffer=64k flush=5s;（防磁盘 I/O 拖慢事件循环）
- 确认后端服务连接池容量 ≥ Nginx upstream keepalive 数，否则连接被拒绝或降级为短连
