Nginx 调优别只改 worker_connections，这几处才是真正的瓶颈

先搞清楚瓶颈在哪，再动手改配置

大部分人优化 Nginx 的动作是：把 worker_processes 设成 auto，worker_connections 拉到几万，keepalive_timeout 调大，然后重启。压测一轮，QPS 没涨多少，CPU 倒是先满了。

原因很简单——Nginx 本身很少是第一个扛不住的。真正的瓶颈通常在三个地方：操作系统文件描述符上限、内核网络参数、以及后端应用或数据库的响应速度。Nginx 只是把请求转过去，后端慢，前面调得再花哨也没用。

所以顺序应该是：先压测拿到基线，看 CPU、内存、连接数、后端响应时间分别卡在哪里，再针对性地改。

事件模型与连接数：别被 worker_connections 骗了

worker_connections 决定单个 worker 能同时处理的连接数，但系统层面的 fs.file-max 和 ulimit -n 才是硬天花板。ulimit 没放开，配置里写 65535 也只是个数字。

• 检查 ulimit -n，确认运行 Nginx 的用户能打开足够多的文件描述符
• worker_rlimit_nofile 要和系统限制对齐，否则 worker 一多就报 too many open files
• Linux 下用 epoll，配置里写 use epoll，别用 select
• multi_accept 打开可以让 worker 一次接受多个新连接，高并发下有效

还有一个细节：keepalive 连接会占用 worker_connections 配额。如果客户端大量复用长连接，实际可用并发会比理论值低不少。

内核参数不调，Nginx 配置等于白改

这是最容易被跳过的一环。sysctl 里几个参数对高并发影响极大：

• net.core.somaxconn：监听队列长度，默认 128 太小，建议 65535
• net.ipv4.tcp_tw_reuse：允许复用 TIME_WAIT 连接，短连接场景收益明显
• net.ipv4.tcp_max_syn_backlog：SYN 队列，抗突发连接
• net.ipv4.ip_local_port_range：本地端口范围，做反向代理时源端口不够会报错

改完记得 sysctl -p 生效，并写进 /etc/sysctl.conf 持久化。很多人只在当前会话改了，重启服务器又回到默认值。

如果业务本身对延迟敏感、又需要稳定的出口带宽，硬件层面选一台网络质量好的机器比反复调参数更省事。比如面向日本及东亚用户的业务，可以考虑 日本东京多IP站群这类机房线路较优的机器，减少网络抖动带来的干扰。

反向代理与缓存：把压力挡在 Nginx 这一层

Nginx 做反向代理时，proxy_pass 的性能和连接池配置有关。开启 upstream keepalive，能显著减少和后端建连的开销：

• upstream 块里加 keepalive 64，并在 proxy_set_header 里设置 Connection ""
• proxy_buffering 打开，让 Nginx 先缓冲后端响应再发给客户端
• 静态资源交给 Nginx 直接返回，别转发到后端
• gzip 压缩开启，但别对图片、视频再压缩

另外，open_file_cache 对大量静态文件访问很有效，能减少磁盘 IO。缓存时间设短一点，比如 30 秒，避免文件更新后读到旧内容。

最后提醒一句：优化完一定要用 ab、wrk 或 siege 重新压测，对比基线数据。没有数据支撑的调优，都是心理安慰。