调优worker_connections必须与系统文件描述符限制、Nginx进程级限制（worker_rlimit_nofile）及内核网络参数三者对齐，否则会触发“Too many open files”或静默丢连接；需按短连、长连、HTTPS等业务类型差异化设值，并同步配置use epoll、multi_accept等events参数。
很多人以为调高 worker_connections、开个 gzip 就算完成了 Nginx 性能优化，结果一压测就崩——连接打满、日志刷屏 “too many open files”、CPU 空转但请求排队。问题往往不在 Nginx 配置本身，而在于忽略了它运行的底层土壤：Linux 系统限制、TCP 协议栈行为、以及请求链路上各环节的协同关系。真正有效的调优，是系统级、配置层、业务场景三者对齐的过程。
只改 nginx.conf，不碰系统限制
这是最普遍也最致命的误区。比如把 worker_connections 65535 写进配置，却没动系统级文件描述符上限：
-
ulimit -n默认通常只有 1024，nginx worker 进程根本无法打开那么多 socket； -
/etc/security/limits.conf中需为 nginx 用户（或 *）设置：
nginx soft nofile 65535
nginx hard nofile 65535 - 还要同步调整内核全局上限：
echo "fs.file-max = 65535" >> /etc/sysctl.conf
sysctl -p
否则，Nginx 启动时可能静默降级，压测时直接触发系统级拒绝连接。
盲目堆高 worker_processes，忽视 CPU 争抢与 I/O 瓶颈
设成 auto 并不总是最优解。尤其当服务器还跑着 MySQL、Redis 或其他高负载服务时：
- 用
top -H或htop观察 CPU idle 和 %wa（I/O wait）：若 %wa 持续高于 20%，说明磁盘或网络才是瓶颈，加 worker 进程只会加剧锁竞争； - 单机仅作反向代理且后端响应快时，worker 数可设为 CPU 核心数；
- 若 Nginx 自身承担大量 rewrite、Lua 脚本或 SSL 卸载，则建议减少 worker 数（如设为核心数的 70%），留出资源给计算密集型任务。
忽略 TCP 连接生命周期，导致 TIME_WAIT 泛滥或连接复用失效
高并发短连接场景下，未调优内核参数会迅速拖垮连接能力：
- 客户端频繁新建连接，服务端大量
TIME_WAIT占用端口和内存，需开启快速回收：
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 30 - keepalive 配置不匹配：Nginx 设了
keepalive_timeout 65，但 upstream 后端（如 Tomcat）默认只保持 5 秒，连接很快被后端断开，前端反复重建连接； - 务必确保上下游 keepalive_requests 和 timeout 协同：建议后端长连接超时 ≥ Nginx 的
keepalive_timeout，并启用keepalive 32（upstream 模块）复用连接池。
压测时用错工具或指标，误判瓶颈
用 ab 压单 URL 或不带连接复用的脚本，得出的 QPS 完全不具备参考性：
-
ab -n 10000 -c 1000默认不复用连接，每请求建一次 TCP，测的是三次握手+SSL 握手能力，不是真实 Web 服务吞吐； - 推荐使用
wrk或hey，显式开启 HTTP/1.1 keep-alive：
wrk -t4 -c400 -d30s --latency http://host/ - 压测中必须同时监控：
– Nginx 状态页（stub_status）的 Active connections、Reading/Writing/Waiting；
–ss -s查看 socket 状态分布（尤其是TIME-WAIT数量）；
–netstat -s | grep -i "packet.*drop"判断是否丢包或队列溢出。
