改worker_connections不生效是因为未同步调整worker_processes和系统ulimit-n限制，三者必须匹配；否则会报“too many open files”错误或连接卡顿。
直接改 worker_connections 不生效，大概率是因为没配对 worker_processes，也没调系统文件描述符限制。
为什么改了 worker_connections 却没提升并发？
宝塔默认的 worker_connections 常是 1024，但这个值必须和 worker_processes、系统 ulimit -n 三者匹配才真正起作用。单独调高它，Nginx 启动时会报 accept() failed (24: Too many open files)，或者压测时卡在连接建立阶段。
-
worker_processes × worker_connections是理论最大连接数，但受制于ulimit -n—— 宝塔环境常卡在默认的 1024 - 宝塔的 Nginx 主配置（
/www/server/nginx/conf/nginx.conf）会被重载或升级覆盖，真要改得去「软件商店 → Nginx → 设置 → 配置修改」里的全局配置区 - 如果
worker_processes还是auto，而服务器开了超线程（比如显示 4 核实为 2 物理核），auto可能起 4 个进程，反而挤占 CPU
怎么设 worker_connections 才合理？
别盲目堆数字。设太高会吃内存、增调度开销；设太低又扛不住长连接（比如 WebSocket、慢上传）。关键是算清楚你的真实瓶颈在哪。
- 先查系统上限：
ulimit -n，再查 Nginx 进程实际看到的限制：cat /proc/$(pgrep nginx)/limits | grep "Max open files" - 推荐公式：
worker_connections = (ulimit -n ÷ worker_processes) × 0.9（留 10% 余量） - 常见组合：2 核服务器，
ulimit -n调到 65535，worker_processes设为 2，则worker_connections设 24576 或 32768 更稳，比硬塞 65535 更可靠 - 静态资源多、连接短（如 CDN 回源），可适当提高；PHP-FPM 耗时长、DB 交互多的站，优先保 PHP 并发，Nginx 连接数不必拉满
改完必须同步做的三件事
只改 worker_connections 就重启 Nginx，等于只拧紧一个螺丝就开车——其他地方随时可能松脱。
- 确认
worker_rlimit_nofile在nginx.conf的 main 块里已设为和ulimit -n一致（例如worker_rlimit_nofile 65535;） - 检查
events块是否含use epoll;（Linux 必须有，否则高并发下性能断崖下跌） - 验证 systemd 是否覆盖限制：查
/etc/systemd/system/multi-user.target.wants/nginx.service有没有LimitNOFILE=，有就改成同值，然后运行systemctl daemon-reload && systemctl restart nginx
最容易被忽略的是 use epoll; 和 systemd 的 LimitNOFILE 冲突——前者缺了，epoll 模式不启用；后者没改，systemd 会把 ulimit 重置回 4096，所有 Nginx 配置都白调。
