Nginx 调优别只改 worker_connections，这几个参数才是瓶颈所在

先把压测数据摆出来，再谈改哪个参数

见过太多人上来就把 worker_processes 改成 CPU 核数，然后跑一遍 ab 发现 QPS 只涨了几百，就觉得「Nginx 优化没用」。问题不在 Nginx，而在于你根本没找到瓶颈。

一个典型的排查顺序是：先用 wrk 或 ab 压出当前 QPS 和延迟分布，再看 nginx -T 导出的完整配置，最后对照 ss -s、top -H 看连接状态和线程占用。没有这一步，改参数就是碰运气。

举个真实场景：一台 4 核 8G 的机器，静态文件压测只有 3000 QPS，CPU 却只跑到 40%。查下来是 worker_connections 只有默认的 512，而系统 ulimit -n 还卡在 1024，连接数先到顶了，CPU 自然闲。

三个最容易被忽略的参数组

第一组是连接与文件句柄。worker_connections 要和 worker_rlimit_nofile 一起调，同时 Linux 的 fs.file-max、nofile 也要跟上。只改 Nginx 不改内核，等于只开了一半的门。

第二组是 keepalive 相关。keepalive_timeout 设太长，空闲连接占着 worker 不放；设太短，TLS 握手反复做，延迟反而上升。反向代理场景里，upstream 的 keepalive 连接池更关键，很多人只配了客户端侧，回源还是短连接，后端压力一点没减。

第三组是缓冲区。client_body_buffer_size、proxy_buffer_size 这些设小了会触发磁盘临时文件，设大了则吃内存。经验值是先按业务请求体大小分布取 P95，再留 20% 余量。

• worker_processes：按核数或 auto，别写死 1
• worker_connections：单 worker 可处理连接数，配合 nofile 调
• keepalive_timeout：静态站可 30s 左右，动态接口短一些
• proxy_buffering：大响应体场景建议开启并调大 buffer

硬件底子不行，参数调出花也没用

Nginx 本身很轻，但它对磁盘 IO 和网络带宽敏感。如果回源是慢速公网、磁盘是机械盘，参数再怎么调，瓶颈也还在那里。做高并发静态分发或反向代理时，选一台 IO 和带宽都够用的机器，比抠配置省事得多。

比如面向亚太用户的站点，香港自营国际物理服务器⑥ 这类 18 核 32G、1G 带宽的独立服务器，跑 Nginx 反代或静态分发时，连接数和带宽都不容易成为短板。配置调优是锦上添花，硬件是地基。

调完记得回归验证

每次只改一到两个参数，改完重新压测，记录 QPS、P99 延迟、错误率三项。把改动和结果记成表格，几轮下来你就知道这台机器真正的天花板在哪。

另外别忘了 nginx -s reload 是平滑重载，但内核参数如 somaxconn、tcp_tw_reuse 改完需要 sysctl 生效。压测环境尽量和生产一致，否则数据没有参考价值。