Nginx 调优别急着改参数，先把这几个瓶颈找准

后台常收到类似提问：照着网上的 Nginx 优化清单改完，ab 压测的 Requests per second 反而掉了。问题多半不在参数本身，而在于没搞清楚当前瓶颈在哪。调优第一步永远是测量，不是抄配置。

先看 worker 和连接数，这是最容易被忽略的起点

Nginx 默认 worker_processes 是 1，在 8 核机器上等于只用了八分之一的 CPU。改成 auto 之后，再用 worker_connections 乘以 worker 数，才是理论最大并发连接。很多人只改了 worker_connections 却没动 worker_processes，等于白改。

还有个隐形限制：Linux 默认单进程可打开文件描述符是 1024。高并发下 Nginx 报 too many open files，就是它。需要在系统层面调大 nofile，同时确认 Nginx 的 worker_rlimit_nofile 不低于这个值。这两处不一致，照样撞墙。

TCP 队列和内核参数，决定你能不能扛住突发流量

压测时如果发现连接被拒或者超时，但 CPU 和内存都很闲，八成是内核 accept 队列满了。somaxconn 和 tcp_max_syn_backlog 这两个值偏小，突发流量一来，握手请求直接丢。把它调到 65535 级别，再配合 Nginx 的 listen backlog，效果立竿见影。

另外，keepalive 不是越长越好。长连接能省握手开销，但会占住 worker 连接槽。静态资源站可以把 keepalive_timeout 设到 30 秒以上，而 API 网关类场景反而建议缩短，让连接快速释放给新请求。

静态资源和磁盘 IO，往往才是真正的天花板

Nginx 处理静态文件很强，但前提是文件系统跟得上。如果站点以图片、视频为主，机械盘上跑再好的配置也白搭。开启 sendfile、tcp_nopush 能减少用户态和内核态的数据拷贝，但底层存储慢，这些优化只是杯水车薪。

这时候更该考虑的是换一台 IO 更稳的机器。比如面向海外用户的站点，可以看看圣何塞独立服务器，2 颗 E5-2699V3 加 64G 内存，30Mbps 带宽，跑静态资源站和反向代理都够用，物理机没有邻居抢占 IO 的问题。

缓存策略配错，前面所有优化都白费

proxy_cache 和 fastcgi_cache 能大幅降低后端压力，但很多人缓存时间设得太短，或者没设 stale-while-revalidate，缓存过期瞬间所有请求同时穿透到后端，形成惊群。合理设置缓存有效期，加上 stale 机制，后端压力能降一个数量级。

建议每次只改一个变量，改完立刻压测对比。Nginx 调优没有万能模板，只有针对当前业务和硬件的最优解。把测量做扎实，比背一百条配置有用得多。