RPS 上不去？Nginx 性能瓶颈排查的完整思路

压测报告里 RPS 只有几百，CPU 使用率却不到 20%，这种情况最让人抓狂。配置改了一轮又一轮，数字纹丝不动。问题往往不在 Nginx，而在你还没找到真正的瓶颈。

先别急着改配置，用工具定位瓶颈在哪一层

排查的第一步是分清瓶颈在 CPU、内存、磁盘还是网络。top 看 CPU 的 wa 和 si 占比，iostat 看磁盘 await，ss -s 看连接状态分布。如果大量连接卡在 SYN-RECV，说明是握手环节的问题；如果 TIME_WAIT 堆积如山，那是端口复用没开。

Nginx 自带的 stub_status 模块能给出 active connections、reading、writing、waiting 四个关键指标。waiting 数高说明连接空闲，瓶颈可能在 upstream；reading/writing 高则说明 Nginx 自身处理不过来。这一步能帮你少走很多弯路。

最常见的三个瓶颈：连接队列、文件句柄、上游响应

• 连接队列溢出：somaxconn 和 tcp_max_syn_backlog 默认值太小，高并发时新连接直接被内核丢弃，客户端表现为超时。调大这两个值通常立竿见影。
• 文件句柄耗尽：日志里出现「too many open files」，说明 worker_rlimit_nofile 和系统 ulimit 没对齐。两处都要改，只改一处没用。
• 上游响应慢：Nginx 本身没问题，但后端 PHP、数据库或 API 拖后腿。用 upstream_response_time 记录日志，把慢请求揪出来。

还有一种容易被忽略的情况：压测客户端自己成了瓶颈。用单机 ab 压测时，客户端端口耗尽或 CPU 打满，测出来的数字根本不准。换 wrk 或多机分布式压测再下结论。

调优后的验证方式，别只看一个数字

RPS 只是结果，不是全部。真正要盯的是 P95、P99 延迟和错误率。RPS 涨了但 P99 从 50ms 飙到 800ms，这种「优化」是负收益。建议每次只改一到两个参数，压测后对比完整指标，确认收益再进下一项。

如果排查下来发现瓶颈在带宽或硬件本身，配置再怎么调也是天花板。这时候可以考虑换一台带宽更充裕的机器，比如美国洛杉矶大带宽服务器 II，G 口带宽配合独立物理资源，压测时不会再被硬件拖住。

记住一句话：优化不是堆参数，是找到那个真正的短板。