Nginx并发高时卡顿主因非worker_connections不足，而是CPU被小文件响应拖满、内存被未释放连接占满或磁盘I/O瓶颈；调大worker_connections无效甚至更糟。
为什么 Nginx 并发高时服务器卡顿，和 worker_connections 关系不大
直接调大 worker_connections 通常没用，甚至更糟。它只是单个 worker 进程能同时处理的连接数上限，不是并发能力的“开关”。真正卡顿往往来自：CPU 被大量小文件响应拖满、内存被未释放的连接占满、磁盘 I/O 在频繁读取静态资源——而这些，worker_connections 本身不解决。
典型现象是 top 看到 nginx 进程 CPU 占用高但请求响应慢，ss -s 显示 established 连接数远低于 worker_connections 设置值，说明瓶颈不在连接数限制上。
- 检查实际连接压力：
ss -n state established | wc -l - 确认是否真缺连接额度：对比该值和
worker_connections × worker_processes - 宝塔默认
worker_processes是auto，但某些低配机器会派生过多 worker，反而争抢 CPU
开启 Gzip 压缩必须避开的三个配置坑
Gzip 不是开个开关就完事。宝塔界面勾选“Gzip”后，生成的配置可能漏掉关键条件，导致压缩失效或伤性能。
- 必须显式设置
gzip_vary on，否则 CDN 或代理可能缓存未压缩版本 -
gzip_min_length别设成 1 —— 宝塔默认有时是 1，但极小响应（如 JSON 接口返回 20 字节）压缩后反而更大，徒增 CPU 开销；建议设为1024 - 别对
.jpg/.png/.gif/.webp等本就压缩过的格式再开 gzip，宝塔默认没排除，需手动在配置里加：gzip_disable "msie6\|\.jpg\|\.jpeg\|\.png\|\.gif\|\.webp";
最终生效的最小安全段类似：
gzip on; gzip_vary on; gzip_min_length 1024; gzip_types application/javascript text/css text/xml text/plain application/json; gzip_disable "msie6\|\.jpg\|\.jpeg\|\.png\|\.gif\|\.webp";
worker\_connections 和相关内核参数要一起调
单独改 Nginx 配置里的 worker_connections，系统层面可能根本不让开那么多文件描述符，结果启动报错或静默降级。
- 先看当前限制：
ulimit -n，宝塔环境下常卡在 1024 - 修改
/etc/security/limits.conf，追加两行（注意用户名替换为运行 nginx 的用户，宝塔通常是www）：www soft nofile 65535www hard nofile 65535 - 确认
/etc/nginx/nginx.conf中worker_rlimit_nofile设为相同值，比如worker_rlimit_nofile 65535; - 重启 nginx 前，用
sudo -u www bash -c 'ulimit -n'验证新限制是否生效
比调参更有效的并发优化：用 open_file_cache 缓住静态文件
高并发下最耗时的操作之一，是反复打开同一组 CSS/JS/字体文件。open_file_cache 能把文件句柄和元信息缓存在内存里，效果常比调 worker_connections 明显得多。
- 宝塔不提供界面配置，需手动加到
http块内 - 推荐组合：
open_file_cache max=20000 inactive=60s;open_file_cache_valid 60s;open_file_cache_min_uses 2;open_file_cache_errors on; - 注意：如果站点大量上传临时文件或日志滚动频繁，
inactive时间不宜过长，否则缓存会堆积无效项
这个配置对静态资源占比高的网站（如 WordPress、Vue SPA），QPS 提升常超 30%，且 CPU 负载下降明显。
真正卡顿的根因，往往藏在文件打开、内存分配、TCP 连接复用这些底层行为里，而不是某个数字看起来不够大。改配置前，先用 strace -p $(pgrep nginx) -e trace=open,accept,read 看看 worker 进程实际在忙什么。
