这些 Nginx 优化参数，配错了比不配还糟
网上流传的 Nginx 优化清单里，有些参数被无脑套用后反而拖慢服务。本文挑出 worker_connections、gzip、keepalive、缓存时间四个最容易配错的点，讲清楚什么场景该用、什么场景该避开。
优化清单看得越多越容易上头，恨不得每条都加上。但 Nginx 参数之间会互相影响，加错一条可能让整条链路变慢。下面这几个是踩坑率最高的。
worker_connections 不是越大越好
有人直接设成 65535，觉得越大越能扛。实际上每个连接都要占内存，连接数虚高但实际用不到，只是白白浪费。更合理的做法是按业务峰值估算，留出 20% 余量即可。
还要注意 worker_connections 和系统 ulimit 的关系。如果系统限制是 1024，Nginx 里写 65535 也没用，实际只能开到 1024。两边要一起调。
gzip 开太猛，小文件反而变慢
gzip 对文本类内容效果很好，HTML、CSS、JS 能压到三成。但有人把 gzip_min_length 设成 0，连几百字节的响应也压，压缩本身的 CPU 开销比省下的流量还大。
建议 gzip_min_length 设在 1k 以上，并且只对 text 类 MIME 开启。图片、视频本身已经压缩过，再 gzip 纯属浪费 CPU。
keepalive_timeout 设太长会拖垮高并发
长连接能减少握手，但每个空闲连接都占着 worker 的连接槽。如果站点并发高、请求间隔长，长连接反而让连接池被占满，新请求排队。API 类服务建议 keepalive_timeout 设在 15 到 30 秒，静态资源站可以放宽到 60 秒以上。
另外别忘了 keepalive_requests，一个连接处理太多请求后应该主动关闭，避免内存泄漏和负载不均。
缓存时间拍脑袋设，后端压力不降反升
proxy_cache_valid 设成 1 秒，等于没缓存；设成 1 天，内容更新又跟不上。更麻烦的是缓存过期瞬间的惊群效应，大量请求同时打到后端。
解决办法是给缓存加 stale 机制，过期后先返回旧内容，后台异步更新。这样既能保证响应速度，又不会让后端瞬间被打爆。
如果站点面向海外用户、后端又在国内，缓存和回源之间的网络延迟也会影响体验。这种情况下物理机的稳定带宽更有优势，比如台湾服务器3，E5-2680 配 16G 内存、20M 带宽，做反向代理和缓存节点都比较合适，线路延迟可控。
调优的核心不是加参数，而是理解每个参数解决什么问题。搞不清用途就照抄，迟早要还回来。