需先调系统级限制：修改/etc/security/limits.conf设nofile，nginx配置中events块外加worker_rlimit_nofile，块内设worker_connections，再重启并验证进程限制。
直接改 worker_connections 不会生效，报错“Too many open files”说明系统级文件描述符卡死了，得先动 ulimit 和 worker_rlimit_nofile。
确认当前限制是否真卡在 worker_connections
很多“高并发报错”其实和连接数无关：用 ss -n state established | wc -l 查真实活跃连接数，再对比 worker_processes × worker_connections 的理论值。如果前者远小于后者，说明瓶颈在 PHP、磁盘 I/O 或 CPU，不是 worker_connections 的问题。检查 Nginx 错误日志：grep "Too many open files" /var/log/nginx/error.log，只有出现这句才说明 fd 耗尽；若看到 accept() failed (24: Too many open files)，那才是真要调限。
phpEnv 下必须同步改三处，缺一不可
phpEnv 默认没开系统级限制，光改 Nginx 配置会静默降级。操作顺序不能乱：
- 编辑
/etc/security/limits.conf，追加两行（注意把www换成 phpEnv 实际运行 Nginx 的用户，通常是www或nginx）：www soft nofile 65535www hard nofile 65535 - 修改
/usr/local/phpenv/nginx/conf/nginx.conf，在events块**外**（即 http 上方）加：worker_rlimit_nofile 65535;，该值必须 ≥ 你准备设的worker_connections - 再进
events块里改：worker_connections 8192;use epoll;multi_accept on;
改完后重启 phpEnv：/etc/init.d/phpenv restart，再用 cat /proc/$(pgrep nginx)/limits | grep "Max open files" 验证进程实际限制是否已升到 65535。
别设太高，8192 是 phpEnv 场景下的安全起点
phpEnv 多用于中小型 PHP 站点，盲目设 worker_connections 65535 反而容易触发上下文切换开销或内存不足（每个连接占 2–4KB）。推荐组合：
- 2 核机器：
worker_processes auto;（通常启 2 个 worker），worker_connections 8192;→ 理论上限 16384，对应ulimit -n和worker_rlimit_nofile设为 18000 更稳妥 - 4 核以上：可试
worker_connections 16384;，但必须确保ulimit -n ≥ 65535，且worker_rlimit_nofile同步设为 65535 - 禁用
keepalive_timeout（设为 0）适合纯短连接 API 场景；若用前端框架（如 Vue/React history 模式），保留keepalive_timeout 15;即可，避免长连接堆积
宝塔用户特别注意：phpEnv 和宝塔共存时权限易冲突
如果服务器同时装了宝塔和 phpEnv，Nginx 很可能由宝塔管理，此时直接改 phpEnv 的 nginx.conf 不生效。先确认 Nginx 进程归属：ps aux | grep nginx，看主进程启动路径是不是 /www/server/nginx/sbin/nginx（宝塔）还是 /usr/local/phpenv/nginx/sbin/nginx（phpEnv）。若是前者，所有配置得去宝塔面板里改——在【软件管理】→ Nginx → 【配置修改】里调 events 块，系统限制则需在宝塔【安全】→【系统命令】里执行 ulimit -n 65535 并写入 /etc/security/limits.conf。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
