Nginx调优别只改worker数：从连接数到缓存，一线运维的实战笔记
很多站长以为改改worker_processes就算优化完了，结果并发一上来还是502。这篇从连接数、内核参数、缓存到日志四个层面，讲清楚Nginx真正该动哪些参数，以及调完之后怎么验证效果。
前几天帮朋友看一台跑WordPress的机器，配置不低，8核16G，但晚高峰打开首页要三四秒。他信誓旦旦说Nginx已经优化过了，我问他改了啥，回答是“worker_processes设成auto了”。
这大概是很多人的现状——把Nginx调优等同于改一两个参数。实际上，Nginx的瓶颈往往不在它自己，而在它和操作系统、后端服务之间的配合。
连接数和文件描述符，先别急着往上堆
worker_connections和worker_rlimit_nofile是最常被调的两个值。有人直接把连接数拉到65535，结果机器没扛住，反而因为内存占用飙升导致OOM。
正确的做法是先搞清楚理论并发上限：worker_processes乘以worker_connections。但更关键的是文件描述符限制，Linux默认单进程1024，你不改ulimit，Nginx里写再大也是白搭。
建议在nginx.conf里设置worker_rlimit_nofile 65535，同时在系统层面把nofile调到65535以上。改完用ulimit -n确认，别只看配置文件。
内核参数不调，Nginx再快也白搭
Nginx处理的是海量短连接，内核的TCP参数直接决定它能不能吃下这些连接。几个必须动的：
- net.core.somaxconn：默认128，高并发下队列瞬间满，改成65535
- net.ipv4.tcp_tw_reuse：开启后允许复用TIME_WAIT连接，对短连接场景提升明显
- net.ipv4.tcp_max_tw_buckets：控制TIME_WAIT数量上限，避免端口耗尽
- net.ipv4.tcp_fin_timeout：默认60秒，可以降到15秒加快回收
这些参数写进/etc/sysctl.conf，用sysctl -p生效。改完用ss -s看TIME_WAIT数量有没有降下来。
缓存和压缩，别让后端背锅
如果你的Nginx前面挡着PHP或Java后端，那反向代理缓存能救命。proxy_cache_path配好之后，静态资源和部分动态页面直接由Nginx返回，后端压力能降一半以上。
但缓存有个坑：默认只缓存200状态码，而且对带Cookie的请求不缓存。如果你的站点登录用户多，得在proxy_cache_key里做区分，否则要么缓存不生效，要么把用户A的页面给了用户B。
Gzip压缩也是类似，开太猛CPU扛不住，开太小省不了带宽。建议只对text、json、js、css这类文本资源开，图片视频别碰。压缩级别用5就够了，9的收益比太低。
调完这些，别急着上线。用ab或wrk压一轮，对比调优前后的QPS和响应时间。没有数据支撑的优化，都是心理安慰。
如果你跑的是面向海外用户的站点，服务器本身的线路和位置比Nginx参数更影响体验。像美国硅谷物理服务器6这种E5-2697双路加100M带宽的配置，配合上面的调优手段，国内访问也能压到可接受范围。