Nginx 调优别只改 worker_connections，先弄明白瓶颈在哪

一台 4 核 8G 的机器，跑一个日均几万 PV 的站点，Nginx 配置还是装完默认那套，白天访问一多就开始 502。很多人第一反应是加内存、换 CPU，其实打开配置文件看一眼，worker_processes 还写着 1。这种情况我见过不少，机器本身没到极限，是配置没跟上。下面按「先看进程和连接数 → 再看哪些模块在拖后腿 → 最后判断该不该换机器」的顺序说，不追求把所有指令列一遍，只讲真正影响响应速度和并发上限的那几个。

worker 进程数和连接数没对齐，CPU 白买

Nginx 默认的 worker_processes 1 是给单核机器准备的。放到 4 核或 8 核上，等于只有一个进程在接请求，其余核心闲着看戏。改成 auto 让 Nginx 自己按 CPU 核数起进程，是最省事的一步。

但进程数上去之后，每个进程能接多少连接由 worker_connections 决定。默认常见值是 512，4 个进程理论上是 2048 条连接。听起来不少，可反向代理场景下一条客户端连接要占两条（前端一条、后端一条），实际能扛的并发直接减半。

• worker_processes 设成 auto，或手动写死 CPU 核数
• worker_connections 反代场景建议 2048 起步，纯静态可以低一些
• worker_rlimit_nofile 必须同步调大，否则连接数先被系统句柄卡死

这里有个容易被忽略的点：worker_connections 调大以后，操作系统的文件句柄上限如果还是 1024，Nginx 会在日志里报「too many open files」，表现就是间歇性 502。我一般会把 worker_rlimit_nofile 设成 worker_connections 乘进程数的两倍左右，留出余量。

再往下是 keepalive_timeout。默认 65 秒，对长连接友好的站点合适；如果站点请求都很短、用户点开一个页面就走，65 秒会让进程一直占着连接不放。反过来，设太短又会让浏览器频繁重建连接，TLS 握手那点开销反而更贵。静态资源站可以压到 20 到 30 秒，API 网关这类要保持长连接的，别动它。

gzip 和缓存：开对了省带宽，开错了费 CPU

gzip 不是开得越全越好。JS、CSS、HTML 这类文本压缩收益明显，通常能压到原体积的三成左右；图片、视频本身已经是压缩格式，再过一遍 gzip 只是白白吃 CPU。

按我的经验，gzip_comp_level 设到 5 或 6 就够，调到 9 压缩率提升有限，CPU 占用却明显上升。真正影响体验的是 gzip_min_length，小于 1KB 的响应压完可能比原文件还大，设成 1024 比较稳妥。

缓存这块，静态资源加 expires 头是基本操作，但要注意版本号。给 CSS、JS 设一年过期时间，前提是文件名里带 hash，否则用户浏览器一直拿旧文件，改一次样式得让所有人清缓存。

代理缓存是另一回事。开 proxy_cache 能显著降低后端压力，代价是内容更新有延迟。新闻类、后台类站点不适合长时间缓存，博客、文档站就很合适。缓存目录别放在系统盘，写满之后会连带影响其它服务。

调到最后还是慢，先分清是软件还是机器的问题

配置能改的都改完，响应还是上不去，这时候要判断瓶颈到底在哪。我的做法是先看两个数：CPU 的 sys 占比和磁盘 IO 等待。sys 高说明在内核态花的时间多，可能是连接数或中断的问题；IO 等待高，多半是磁盘跟不上，跟 Nginx 配置没关系。

如果 CPU 长期跑满、磁盘也正常，那基本是算力不够，继续抠配置收益很小。小站用 1 核 1G 跑静态页没问题，一旦上了动态后端、并发几百，内存和 CPU 都会成为硬限制。

换机器的时候，线路和带宽往往比参数更影响体验。面向国内用户的站点，选美国洛杉矶这类机房通常能拿到 100M 带宽，价格也比同配置的高防机型低。秀米云的美国洛杉矶高防服务器9用的是 E5 2620 加 32G 内存、100M 带宽，月付 149 美元，适合流量中等、又想顺带带点防护的站点。并发再上一档、需要更大内存扛缓存的，可以看美国硅谷高防服务器 XXXIX，双 E5 2698v4 配 64G，100M 带宽月付 629 美元。

要是站点本身是给海外用户看的，机房位置比配置更重要。新加坡节点面向东南亚访问延迟更低，新加坡独立服务器 IV 是双 E5-2660 加 32G，10M 带宽月付 259.20 美元，带宽不大但胜在离用户近。这点我没实测过具体延迟数字，不同线路差异大，选之前最好先确认目标用户集中在哪个区域。

该花的钱花在哪，不该省的地方别省

Nginx 调优有个性价比顺序：先把 worker 相关参数和文件句柄对齐，这是零成本的；再动 gzip 和缓存，这是省带宽的；最后才是加机器，这是花钱的。顺序反了，容易花冤枉钱。

预算有限的小站，1 核 1G 配好 worker_connections 和静态缓存，扛日均几千 PV 没问题，没必要一上来就买高配。真到了需要独立服务器的时候，优先看内存和带宽，CPU 核数反而不是第一位的——Nginx 本身吃 CPU 不算狠，后端应用和数据库才是大头。

最后给个可以直接执行的判断：如果调完配置后 CPU 的 sys 占比还在 30% 以上、连接数经常打满，就该换机器了；如果 CPU 空闲、只是偶尔慢，回去再检查一遍 gzip 级别和缓存策略，多半还有优化空间。