改 worker_processes 没效果是因为宝塔会自动覆盖手动修改的主配置文件，需在宝塔Nginx模板或「软件商店→Nginx设置→全局配置」中修改；设为auto在低配VPS易引发CPU争抢，推荐按真实核心数设（1核设1、2核设2、4核及以上设4）；还需同步调整 events 块中的 worker_connections 和系统 ulimit，否则无法提升并发；验证须用 nginx -t + ps -ef + ss -s 综合判断。
为什么改 worker_processes 没效果？
直接在宝塔面板「网站」→「配置文件」里改 worker_processes，重启 Nginx 后发现并发没提升——大概率是被宝塔自动覆盖了。宝塔的 Nginx 配置由模板生成，手动改主配置文件 /www/server/nginx/conf/nginx.conf 会被下次「重载配置」或「升级」清掉。
- 真正生效的位置是宝塔的 Nginx 模板：
/www/server/panel/vhost/nginx/conf/nginx.conf（注意路径里有vhost，不是主 conf） - 或者更稳妥：进宝塔「软件商店」→ 找到 Nginx →「设置」→「配置修改」→ 在「全局配置」区域加
worker_processes - 别设成
auto：在低配 VPS（比如 1 核）上，auto会起满逻辑核数（如超线程后显示 2），反而因进程争抢 CPU 导致响应变慢
worker_processes 设多少才合理？
不是越多越好，关键看 CPU 核心数和工作负载类型。静态小文件多、IO 等待少的场景，进程数略高于核心数可能有收益；但 PHP-FPM 做大量计算或数据库交互时，Nginx 进程太多反而挤占系统资源。
- 查真实可用核心数：
nproc（不是lscpu里写的“CPU(s): 4”，要看 “On-line CPU(s) list” 或直接跑nproc） - 推荐值：1 核 → 设
1；2 核 →2；4 核及以上 →4就够用，除非你压测确认瓶颈真在 Nginx 调度层 - 别碰
worker_cpu_affinity：宝塔默认关着，手动开容易绑错核，反而让某些核空转、某些核过热
改完 worker_processes 还要调啥？
单改进程数就像只换轮胎不调胎压——worker_connections 和 events 块必须同步匹配，否则新进程根本接不到连接。
- 检查
events块是否已存在，没有就补上（宝塔默认有，但可能被删）：
events {
worker_connections 1024;
use epoll;
}
worker_connections × worker_processes = 理论最大并发连接数。设 4 进程 × 1024 = 4096，但实际受系统 ulimit -n 限制，得一起调高（echo "* soft nofile 65535" >> /etc/security/limits.conf）worker_connections 到 65535：内存占用翻倍，且多数网站远达不到这个连接量，反而增加内核调度开销怎么验证改对了没？
看日志和指标比看配置文件更可靠。宝塔改完点「重载配置」，不是「重启」，否则可能中断已有连接。
- 确认生效：
nginx -t检查语法，再ps -ef | grep nginx | grep -v grep数一下 master + worker 进程数是否匹配 - 观察真实压力：
ss -s看当前 ESTAB 连接数，对比改前后变化；同时盯住top里%Cpu(s)是否更均衡（而不是单核飙满） - 注意隐藏坑：如果用了「网站监控」或「防火墙」插件，它们可能自身吃 CPU，掩盖 Nginx 调优效果——先临时关掉再压测
真正卡并发的地方，八成不在 worker_processes，而在 PHP-FPM 的 pm.max_children 或 MySQL 连接池。调 Nginx 前，先用 ab 或 wrk 定位到底是哪一层在排队。
