Nginx 调优别乱改：先搞清 worker 和连接数到底怎么算
刚接手一台跑着 Nginx 的机器时，很多人第一反应是打开配置文件搜「性能」两个字，然后把能调的参数全往上调一遍。结果 QPS 不升反降，CPU 反而先跑满了。我见过不少这样的配置：4 核的机器写着 worker_processes 8，worker_connections 还是默认的 512，keepalive_timeout 拉到 300 秒。看起来每个参数都「优化」了，凑在一起却互相打架。
Nginx 的调优不是把数字调大，而是让几个互相牵制的参数落在同一档位上。下面按「先算清楚机器能扛多少」到「再决定哪些功能值得开」的顺序讲，最后给一份可以直接对照的配置区间。
worker_processes 不是越大越好，超线程要算进去
worker_processes 决定开几个工作进程，每个进程独立处理请求。设成 auto 时 Nginx 会读 CPU 核数，这是多数场景的起点。
但「核数」这件事要看清楚。一台标称 8 核的机器，如果是 4 物理核加超线程，实际能并行跑满的只有 4 个。把 worker 设成 8，多出来的进程要抢同一批执行单元，上下文切换的开销就吃掉了收益。我的经验是：独占物理机的场景按物理核数设，虚拟化环境先试着设成物理核数，压测再决定要不要加。
如果你跑的是 CPU 密集型模块，比如大量 gzip 压缩或者 Lua 脚本，worker 数超过物理核数基本是负收益。反过来，如果请求大部分时间在等后端响应，稍多一点 worker 能掩盖等待。
连接数上限是乘法，不是单个数字
这是最容易算错的地方。单机能承载的理论连接上限大致等于 worker_processes 乘以 worker_connections，但这是「所有 worker 加起来」的峰值，而且反向代理场景下一条客户端连接会占用两个连接数——一个对客户端，一个对上游。
所以一台 4 核机器，worker_connections 设 10240，理论上限约 40960，实际能稳定接住的并发连接要打个对折。想接住 2 万并发，worker_connections 就得往 20480 这个量级走。
- 反向代理按「目标并发 × 2」反推 worker_connections
- 纯静态站可以按目标并发直接估算
算出来之后还得过一道系统关：worker_rlimit_nofile 要大于 worker_connections，系统的 fs.file-max 和 ulimit -n 也要跟着放开。这三个地方只要有一个卡住，配置写得再大也没用，日志里会出现「too many open files」，然后开始丢请求。
keepalive 与 gzip：省下的和付出的
keepalive_timeout 拉长能减少 TCP 握手，对长连接 API 友好。但每条空闲连接都占着内存和文件句柄，超时设到 300 秒意味着峰值过后连接迟迟不释放。多数站点 15 到 30 秒是个平衡点，内部服务之间可以更长。
upstream 里的 keepalive 是另一回事，它管的是 Nginx 到后端的连接复用。设成 32 到 64，配合 keepalive_requests，能明显减少和后端反复建连的开销。这部分收益通常比调前端 keepalive 更实在。
gzip 要算 CPU 账。压缩比和 CPU 占用是互换的，gzip_comp_level 从 5 提到 9，压缩率提升有限，CPU 却可能多花一倍。图片、视频这类已经压过的资源没必要再过一遍 gzip，用 gzip_types 把范围收窄到文本类就行。
落到具体配置上怎么填
把这些串起来，一台 4 核 8G、跑反向代理的机器，我一般会从这组值起步：
- worker_processes 4；worker_connections 10240
- worker_rlimit_nofile 65535；系统 ulimit -n 同步放开
- keepalive_timeout 30；upstream keepalive 64
- gzip_comp_level 5；gzip_types 只留 text/css/js/json
配置改完别急着上生产，先压一轮看 CPU 和连接数曲线。如果连接数远低于上限而 CPU 先满，说明瓶颈在计算不在连接，该收的是 worker 数。反过来连接数贴着上限、CPU 还有余量，才是往上加 worker_connections 的信号。
调优的终点不是某个神奇参数，而是让 worker 数、连接上限、文件句柄三者对得上，再根据真实压测结果微调。机器规格和业务类型不同，能扛的并发差别很大，拿别人的配置直接抄往往适得其反。
如果连机器规格都还没定，比如要跑高并发反向代理或站群，香港宿主机(大母鸡)④ 这类 E5-2699C V4 双路、256G 内存的配置能把连接数和内存瓶颈推得很远，30M 带宽适合请求密集但回包不大的场景。