Nginx调优别乱抄：几个压测出来的真实参数
很多Nginx优化文章只给参数不给场景。这篇从worker连接数、内核队列到缓存策略，结合真实压测数据讲清楚每个参数改了之后到底影响什么，以及小内存机器该怎么取舍。
先把worker_connections和worker_processes算清楚
大多数教程只告诉你把这两个值调大，但没人说清楚它们相乘才是理论上限。一台4核8G的机器，worker_processes设成auto，worker_connections设1024，理论上能扛的并发就是4096。实际跑起来还要扣掉反向代理占用的连接，能到七成就算不错了。
压测时用ab或者wrk打一个静态页，你会发现连接数到3000左右就开始出现超时。这时候先别急着加参数，用ss -s看看TIME_WAIT是不是堆了一大堆。如果是，把net.ipv4.tcp_tw_reuse打开比调Nginx本身更管用。
内核参数不调，Nginx再优化也白搭
Nginx跑在高并发场景，瓶颈往往不在它自己身上。somaxconn默认128，你的backlog写512也没用，内核直接截断。netdev_max_backlog在万兆网卡下不改，丢包会让你怀疑人生。
- net.core.somaxconn = 65535：让listen队列真正生效
- net.ipv4.tcp_max_syn_backlog = 65535：半连接队列别成瓶颈
- net.ipv4.ip_local_port_range = 1024 65000：反代场景端口不够用会报错
- net.ipv4.tcp_fin_timeout = 15：缩短FIN_WAIT2，加快连接回收
改完记得sysctl -p，然后重新压一遍。很多所谓“优化”其实就是把内核默认值从十年前的水平拉到现代水平。
缓存和压缩：省带宽还是省CPU，得看业务
gzip开不开、开几级，争议一直很大。静态资源多、带宽贵，gzip_static配合预压缩文件最划算，CPU几乎零消耗。动态接口为主，gzip on加gzip_comp_level 3就够了，再往上压缩率提升有限，CPU倒是涨得明显。
proxy_cache适合后端响应慢但内容变化不频繁的场景。缓存时间设太长，用户看到旧数据；设太短，等于没缓存。一个经验值：商品详情页5到10分钟，列表页1分钟，用户中心直接不缓存。
如果机器本身配置不高，又跑着多个站点，与其在Nginx参数上抠性能，不如换一台资源更充裕的机器。像香港自营物理服务器②这种16核32线程、32G内存的配置，跑Nginx加后端服务余量充足，10M带宽应付中小流量站点也够用。真要跑大流量分发，香港自营国际物理服务器⑥的1G口和18核配置更能扛住并发压力。
日志和监控：别等出事了才看
access_log默认同步写盘，QPS一高就是磁盘瓶颈。buffer设成64k，flush设成5s，写入量能降一个数量级。error_log级别别长期开warn，线上用error就够，排查问题时临时调。
最后说一句：所有参数都要在压测环境验证过再上生产。别人机器上跑得欢的配置，换到你的业务模型下可能就是另一回事。