Nginx 调优别乱改参数，先搞懂 worker 和连接数怎么算
站点上线三个月，访问量从每天几百涨到几万，监控里 502 开始零星冒头。登录服务器一看，CPU 没满，内存也够，Nginx 的 error.log 里却写着 worker_connections are not enough。这种情况我见过不少，配置是从网上抄的，参数看着都对，但没人算过这台机器到底能扛多少连接。
Nginx 调优不是把网上那份「万能配置」粘贴进去就完事。它更像一道算术题：你的机器有几个核、多少内存、后端响应多快，决定了 worker 和连接数该开多大。参数开小了浪费硬件，开大了要么触发系统限制，要么把后端压垮。下面从最容易算错的 worker 数量讲起。
worker_processes 该填几，别抄别人机器上的数字
worker_processes 控制 Nginx 起几个工作进程。默认值是 1，但现在的服务器基本都是 4 核起步，只开一个进程等于让三个核闲着。
通用的填法是 auto，Nginx 会自动读 CPU 核数。我一般直接写 auto，省得换机器时忘了改。如果是 4 核的 VPS，就是 4 个 worker；8 核物理机就是 8 个。
这里有个取舍：worker 不是越多越好。每个 worker 都要占用内存，还要跟系统调度打交道。核数超过 16 的机器，开满反而会因为上下文切换增加开销。按我的经验，8 到 16 个 worker 已经能覆盖绝大多数场景，再往上加收益很小。
另一头是 worker_connections。它决定单个 worker 能同时处理多少连接。默认 512，对现在的流量来说明显偏小。这个值要跟系统层的 ulimit -n 对齐，否则你填 65535 而系统限制是 1024，实际生效的还是 1024。先改 /etc/security/limits.conf，把 nofile 提到 65535，再回来改 Nginx。
连接数怎么算，一张 4 核 8G 机器的账
很多人以为 worker_connections 乘以 worker_processes 就是能扛的并发数，其实不对。反向代理场景下，一个客户端连接会占用两个连接位——一个连客户端，一个连后端。
算一下：4 核机器，worker_processes 设 4，worker_connections 设 10240，理论上限是 40960 个连接。但反向代理要除以 2，实际能服务的客户端并发大约是 20000。这个数字看着很大，可真正跑起来往往到不了，因为瓶颈会先出现在后端应用或者数据库上。
我一般会留出三成余量。也就是说，如果监控显示峰值并发是 5000，那配置按 7000 左右来设，别卡着极限跑。留余量的代价是内存多占一点，换回来的是流量突增时不至于直接 502。
- worker_processes 填 auto，核数超过 16 时手动压到 16 以内
- worker_connections 先对齐 ulimit，反向代理场景按客户端并发的两倍来设
- worker_rlimit_nofile 单独写一行，跟 ulimit 保持一致，避免继承不到
keepalive、gzip、缓存，哪些该开哪些该关
连接数算完，接下来是几个影响体感的开关。
keepalive_timeout 默认 65 秒。对静态资源为主的站点，调大到 75 秒能减少建连次数；但如果后端是长轮询或者 WebSocket，这个值要单独处理，不能一刀切。我一般把静态站设 75，API 网关设 30，分开配。
gzip 是双刃剑。开在 text/html、css、js 上确实省带宽，压缩率通常能到 70% 上下。但图片、视频、woff2 字体本身已经压过，再走一遍 gzip 只是白烧 CPU。gzip_comp_level 也别贪高，4 到 6 之间性价比最好，调到 9 收益只多几个百分点，CPU 却明显上去。
缓存这块，proxy_cache 适合后端响应慢、内容变化不频繁的场景。代价是要额外划磁盘空间，还要处理缓存失效。如果后端本身就在 50ms 内返回，加缓存层的复杂度可能不划算——省下的那点响应时间，换来的是排查缓存不一致的时间。
静态资源多、后端偏慢的站点，值得上缓存；纯 API 网关，先把连接数和 keepalive 调好，缓存可以往后放。
配置改完，怎么验证真的生效了
改完配置别急着 reload。先跑 nginx -t 检查语法，再 nginx -s reload。reload 是平滑的，不会断掉现有连接，但配置写错的话新连接会直接失败。
验证并发上限，可以用 ab 或者 wrk 压一轮。压测时盯着 error.log，如果出现 worker_connections are not enough，说明还得往上加；如果 CPU 先到 100%，那瓶颈在计算不在连接数，加连接数没用。
还有一点常被忽略：Nginx 的日志写入本身也吃 IO。access_log 如果每个请求都同步写盘，高并发下磁盘会成为瓶颈。访问量大的站点，我会把 buffer 打开，让日志批量落盘，或者干脆关掉 access_log 只留 error_log。
最后给个结论。4 核 8G 的机器，worker_processes 填 auto，worker_connections 配 10240，ulimit 提到 65535，keepalive 按业务类型分开设，gzip 只压文本类资源——这套下来，撑住日均几十万 PV 的站点问题不大。真正卡住你的往往不是 Nginx，而是后端那台机器。
如果你还在用共享型的小机器扛流量，连接数调到再高也会被 CPU 和带宽卡住。走量、静态资源为主的站点，换成独立物理服务器会省心很多，比如香港自营国际物理服务器⑤，E5-2686V4 十八核三十六线程配 32G 内存，100M 带宽，月付 1050 元，适合并发稳定在几千以上的业务。