Nginx调优别乱改参数：几个真正影响并发和延迟的落点

服务器上新装完Nginx，用ab压一轮，两三千并发就开始报错，CPU和内存看起来都没跑满。这种场景我见得不少，多数人第一反应是去加机器，其实瓶颈往往在几个默认值上——worker进程能开的连接数被卡死，系统给单进程的文件句柄上限也没放开。这两处不改，配置里写再多参数都是白费。

调优这件事有个前提：先搞清楚你的站点是静态资源为主，还是Nginx在前面做反向代理，还是跑HTTPS终结。三种场景的瓶颈点完全不一样，拿一套参数套所有业务，只会越调越乱。

先看worker_connections和文件句柄，这里卡死了后面全白搭

Nginx能扛多少并发，最直接的一条公式是：worker_processes × worker_connections = 理论最大连接数。默认worker_connections是512，4核机器就是2048，这还是理论值，实际能撑的并发远低于这个数。

把worker_connections提到10240，4核就是40960，看着很美好。但光改这里没用，系统层面单进程能打开的文件句柄默认通常是1024，Nginx每个连接都要占用一个句柄，改到10240之前得先把ulimit -n放开，否则启动就报错。

我一般这么配：worker_processes设成auto让Nginx自己认核数，worker_connections按业务量给到10240到65535之间。静态站给10240够用，反代场景因为每个客户端连接要再占一个后端连接，得按两倍算。

这里有个取舍：worker_connections开太大，单个进程崩溃时影响面也大。所以我更倾向多开worker进程、每个进程连接数别拉太满，而不是一个进程吃下所有连接。4核机器开4个worker，每个10240，比单进程40960稳得多。

如果是海外业务、机器放在境外机房，这类系统级参数改动的效果会更明显——跨境线路本身延迟就高，服务端处理再拖后腿，用户感知就很差。像硅谷裸机云 V这种E5-2697配100M带宽的机器，拿来做反代前端，把上面两组参数调好，单机能顶住的并发比默认配置高出一大截。

keepalive_timeout不是越长越好，长连接要算清楚代价

keepalive_timeout默认65秒，意思是客户端连接保持65秒不关。很多人觉得设长点能省掉重复握手，就把值拉到300秒甚至更高，结果并发一上来，连接数全被闲置连接占着，新请求反而进不来。

这个参数要看业务类型。静态资源站、API接口这种请求密集的场景，我一般设15到30秒，够复用就行。后台管理系统、访问量不大的站，设60秒也没问题。

更关键的是keepalive_requests，默认100，意思是单个长连接最多处理100个请求就关闭重连。高并发下这个值可以提到1000，减少TCP握手次数。但别设太大，连接持有太久，后端服务重启时旧连接会僵在那里。

上行带宽和连接数是一对矛盾。100M带宽的机器，假设每个请求平均50KB，理论上每秒能服务2000个请求，连接保持太久只会让排队更长。带宽越小的机器，keepalive越要设短。

反代和HTTPS场景，gzip与SSL会话缓存才是大头

Nginx在前面挡着后端应用时，真正吃CPU的是gzip压缩和TLS握手。这两块调好了，同样的硬件能多扛不少流量。

• gzip：只压文本类内容，gzip_types里列text/html、text/css、application/javascript、application/json就够。图片和视频别压，压了反而更慢还费CPU。
• gzip_comp_level：默认1，设到5左右是压缩率和CPU的平衡点，再往上收益很小。
• SSL会话缓存：ssl_session_cache设shared:SSL:10m，ssl_session_timeout设10m，能省掉大量重复握手。

我见过不少配置把gzip_comp_level拉到9，CPU直接跑满，响应时间反而从80ms涨到200ms。压缩级别每提高一级，CPU开销大致翻倍，压缩率却只多几个百分点，这笔账不划算。

反代场景还要注意proxy_buffering。默认开着，Nginx会先把后端响应缓冲下来再发给客户端，对慢后端友好；但如果后端吐的是流式数据，比如SSE或大文件下载，就得关掉，否则数据全堵在Nginx缓冲区里。

HTTPS终结吃CPU，单核能处理的握手数有限。如果证书多、并发高，考虑把机器换成主频更高的型号，或者干脆上多核。日本东京机房那台日本大带宽服务器 XXIII，E5-2680双路加G口，做HTTPS终结和静态分发都够用，面向亚太用户延迟也低。

调完一定要压测，别拿生产环境当试验田

参数改完不压测，等于没改。ab、wrk、hey随便挑一个，先在测试机上把修改前后的QPS和P99延迟拉出来对比。

重点看两个数：一是错误率，连接数调高后如果开始出现502、504，说明后端或系统层面还有瓶颈；二是P99延迟，平均值好看不代表体验好，尾部延迟才是用户真正感受到的卡顿。

我的建议是每次只改一到两个参数，压一轮记录一次数据。一次性改十几个参数，出了问题根本不知道是哪条引起的。这套流程跑下来，一台4核8G的机器，静态站从默认的2000并发提到8000到10000并发是能做到的，前提是带宽跟得上。

最后给个直接结论：静态站和小API，worker_connections给10240、keepalive_timeout给30秒、gzip_comp_level给5，这套组合覆盖八成场景；反代和HTTPS业务，额外把SSL会话缓存和proxy_buffering按上面的方式调一遍。机器是1核2G的低配VPS，参数怎么调都有限，该升级硬件就别硬撑；4核8G以上的独立服务器，调优才真正有空间。