提升Nginx代理吞吐能力需三方面协同：启用upstream keepalive复用连接、按响应特征调优proxy缓冲区、释放epoll/kqueue异步事件模型潜力，并分层收紧两端超时与连接生命周期。
提升 Nginx 作为 HTTP 代理的系统吞吐能力，核心不是堆配置，而是让请求转发链路全程“不卡、不等、不浪费”。它依赖三方面协同：连接复用减少开销、缓冲策略匹配响应特征、事件模型不被隐式阻塞。
启用 upstream keepalive 复用后端连接
默认情况下，Nginx 每次请求都新建 TCP 连接到后端，三次握手 + TLS 握手（若启用 HTTPS）+ 关闭连接，开销远超业务本身。启用 keepalive 后，空闲连接被缓存复用，显著降低延迟和 FD 消耗。
- 在 upstream 块中设置
keepalive 32（建议 16–64，视后端连接池容量而定） - 对应 location 中必须写明：
proxy_http_version 1.1;和proxy_set_header Connection '';（清空 Connection 头，避免被误设为 close） - 验证方式：运行
ss -tan | grep :后端端口，ESTABLISHED 连接数应稳定在几十个，而非随 QPS 线性飙升
调优 proxy 缓冲区以适配响应大小
缓冲区配置不当会导致 Nginx 被大响应拖慢，甚至触发磁盘临时文件写入，吞吐骤降。关键不是“越大越好”，而是内存分配合理、避免落盘。
- 小/中响应（如 JSON API）：启用缓冲，设
proxy_buffers 8 128k（共 1MB），proxy_busy_buffers_size 256k，proxy_max_temp_file_size 0（禁用磁盘缓存） - 大响应或流式场景（如文件下载、SSE）：直接关闭缓冲，
proxy_buffering off，配合延长proxy_read_timeout 120 - 响应头较大时（如含长 JWT 或多 Cookie）：调高
proxy_buffer_size 128k
释放异步事件模型的真实潜力
Nginx 的 epoll/kqueue 机制本可单 worker 承载万级连接，但错误配置会让它退化成“伪异步”——表面并发高，实际某环节阻塞整个 worker。
- 确保
worker_processes auto;和worker_connections 16384;，并同步设置worker_rlimit_nofile 65536; - 避免隐式同步：慎用
auth_request；减少 location 级复杂正则；关闭proxy_buffering off时务必配好超时，否则易挂起连接 - 日志写入开启缓冲：
access_log /var/log/nginx/access.log main buffer=64k flush=5s;，防止磁盘 I/O 拖慢事件循环
收紧两端超时与连接生命周期
过长的空闲连接会占满 FD 和内存，过短又导致频繁重连。需分层控制，让连接“该活时活，该死时死”。
- 客户端到 Nginx：
keepalive_timeout 65s; keepalive_requests 10000; - Nginx 到后端：
proxy_read_timeout 60;（普通 API）、proxy_read_timeout 120;（大响应），并配合 upstream 内keepalive_timeout 60s; - 后端自身也要调大 keep-alive timeout，且略大于 Nginx 的
proxy_read_timeout，防止单边断连
