Nginx 调优不只是改配置，服务器选型同样决定上限

配置改了一堆，QPS 还是上不去？先看硬件底气

不少站长调 Nginx 的路径是这样的：改 worker_processes、开 keepalive、上 gzip、调 worker_connections，折腾一晚上，压测结果还是老样子。问题往往不在配置，而在机器本身。

Nginx 是典型的事件驱动模型，单进程能吃多少并发，直接取决于 CPU 单核性能。你给它一颗主频只有 2.2GHz 的老 U，worker 再多也顶不住。反过来，主频高、缓存大的处理器，同样配置下 QPS 能差出一大截。

所以调优的第一步不是打开 nginx.conf，是先确认你手里的机器够不够用。

三个容易被忽略的硬件瓶颈

• 磁盘 IO：静态资源站、图片站最吃这个。机械盘随机读一上来，Nginx 的 sendfile 再快也没用，SSD 是底线。
• 带宽出口：并发上去了，带宽跑满，延迟立刻飙升。很多所谓「性能问题」其实是带宽不够。
• 内存：缓存、连接表、SSL 会话都占内存。16G 和 64G 在几千并发时是两种体验。

举个例子，一个日 PV 百万的图片站，跑在 30M 带宽的机器上，晚高峰必然卡。这时候你把 worker_connections 从 1024 调到 10240，只会让连接堆积得更快。

选型时怎么判断一台机器适不适合扛 Nginx

第一看 CPU 主频和核心数配比。Nginx 偏向高主频，核心数够用就行，不需要堆到几十核。

第二看带宽是否独享。共享带宽在高峰期会被邻居拖累，独享大带宽才是稳定的前提。像 香港大带宽服务器 II 这种 30M 独享出口、双路 E5-2683v4 加 64G 内存的配置，就比较适合静态资源和高并发反向代理场景。

第三看线路质量。面向国内用户时，回程线路决定了首字节时间，CN2 类线路在晚高峰的表现明显更稳。如果业务本身有被攻击的风险，还得把高防能力算进去，比如 香港高防独立服务器 这类带防护的方案，能避免被流量打挂之后再去排查「性能问题」。

调优的正确顺序

先定硬件基线，再压测找瓶颈，最后动配置。顺序反了，就是白忙。压测时用 ab 或 wrk 从低并发往上打，观察 CPU、内存、带宽三条曲线，哪条先到顶，瓶颈就在哪。

配置层面记住几个关键点：worker_processes 设为 CPU 核心数，worker_connections 结合 ulimit 一起调，开启 sendfile 和 tcp_nopush，SSL 场景下开 session 缓存。这些都是锦上添花，前提是机器本身不拉胯。

说到底，Nginx 优化是配置和硬件的配合战。配置决定你能榨出多少性能，硬件决定你的性能天花板在哪。选机器的时候多花十分钟看清楚参数，比事后调三天配置都管用。