requests per second上不去？先查这五个Nginx配置盲区

用wrk压一台4核8G的机器，RPS只有800，换台16核的机器，RPS还是800出头。这时候基本可以确定：瓶颈不在CPU，在配置。下面这五个地方，按顺序查一遍，能解决大部分RPS异常的问题。

第一个盲区：access_log的磁盘写入

默认配置里每个请求都写一条access_log，高并发下磁盘IO会成为隐形瓶颈。压测阶段先把access_log off，或者用buffer参数攒一批再写。生产环境不建议完全关，但buffer=32k flush=5s 这种配置能把写盘频率降下来。我见过一台机器光关掉实时写日志，RPS从900涨到1400。

第二个盲区：upstream的keepalive没开

Nginx作为反向代理时，和后端之间默认是短连接。每个请求都要重新建TCP连接，三次握手加上后端处理，RPS自然上不去。在upstream块里加 keepalive 64，然后在location里把 proxy_http_version 设成1.1，proxy_set_header Connection ""。这三行缺一不可，尤其是最后一行，不设的话Connection头还是close。

第三个盲区：gzip压缩的CPU开销

gzip on 对文本内容能省带宽，但压缩本身吃CPU。压测纯动态接口时，gzip是个纯粹的负担。判断方法很简单：关掉gzip再压一次，如果RPS明显回升，说明CPU花在压缩上了。折中方案是只对text/html和application/json开gzip，图片视频这些已经压缩过的格式不要重复压。

第四个盲区：worker_connections和ulimit不匹配

这个坑很隐蔽。Nginx配置里写了worker_connections 10240，但系统ulimit -n只有1024，Nginx启动时不会报错，实际能用的连接数被限制在1024。用 nginx -T 看配置，再用 cat /proc/$(pidof nginx)/limits 看实际限制，两边对不上就是这个问题。

• 临时改：ulimit -n 65535
• 永久改：/etc/security/limits.conf 加 nginx soft/hard nofile 65535
• 验证：重启Nginx后看进程limits

第五个盲区：proxy_buffering和缓冲区大小

proxy_buffering 默认是on，Nginx会把后端响应先缓存在内存里再发给客户端。如果后端返回大文件，缓冲区不够会写临时文件，反而更慢。动态接口场景下，把 proxy_buffering off 有时能降低延迟。但静态大文件场景要保持on，并且调大 proxy_buffers 和 proxy_buffer_size。

如果你在海外部署，网络延迟本身就会影响RPS表现。像日本大带宽服务器 III这种30M带宽的东京机器，适合跑面向亚太用户的服务，压测时能排除掉跨洋延迟的干扰，更容易定位配置问题。

排查顺序建议从日志开始，再到连接池，最后到缓冲区。每改一项压一次，记录数据。别一次改五个参数然后不知道哪个起了作用。