运行状态比配置更可靠，需验证worker进程数匹配、CPU绑定生效、连接负载均衡三方面。先用ps查进程数，再用psr和taskset验CPU亲和性，最后通过stub_status和ss检查连接分布与资源使用。

直接看运行状态比猜配置更可靠。worker_processes 的实际效果不取决于你写了多少，而在于进程是否真正在不同核心上稳定运行、有没有被调度干扰、连接是否撑得住——这三件事必须一起验证。

查进程数和分布是否匹配预期

先确认启动了多少 worker 进程：

• 运行 ps -ef | grep "nginx: worker"，数一下行数（排除 grep 自身）
• 对比配置中的 worker_processes 值：若少于预期，可能是 worker_rlimit_nofile 不足或系统 ulimit 限制导致进程启动失败
• 若多于预期（比如配置为 4 却看到 8 个），检查是否启用了 master_process off 或存在多个 nginx 实例

验 CPU 绑定是否真正生效

光有进程数不够，关键看它们跑在哪些核上：

• 执行 ps -eo pid,args,psr | grep 'nginx: worker'，观察每行末尾的 PSR 列（即当前调度到的 CPU 编号）
• 理想状态：数字不重复、覆盖你期望的核范围（如设了 4 核，应看到 0/1/2/3 各一次）
• 若多个 worker 显示同一 PSR（如全是 0），说明 worker_cpu_affinity 没生效，或配置掩码位数错误（例如 4 核却用了 8 位掩码）
• 再用 taskset -cp $(pgrep -f "nginx: worker" | head -1) 查首进程亲和性掩码，确认是否按配置锁定

看连接负载是否均衡且无瓶颈

即使进程绑对了，也可能因连接分配不均或资源不足拖垮性能：

• 启用 ngx_http_stub_status_module，访问 /nginx_status 查看每个 worker 的活跃连接数（Active connections）
• 若各 worker 连接数差异超过 3 倍（如一个 5000+，另一个不到 1000），说明 accept_mutex 关闭或 upstream 轮询策略失衡
• 检查 worker_connections × worker_processes 是否远超当前 ss -s 显示的 ESTAB 连接总数——若长期只用到 30%，说明并发压力未上来，或前端有连接池/keepalive 配置过严
• 出现 “accept() failed (24: Too many open files)” 错误，立刻检查 ulimit -n 和 worker_rlimit_nofile 是否一致且足够

结合反代场景做针对性调整

纯转发（非静态服务）的瓶颈常不在 CPU，而在连接维持与上游等待：

• 若 upstream 响应慢（平均 >200ms），适当增加 worker_processes 到物理核数 ×1.2～1.5，缓解阻塞积压
• 但必须同步调高 worker_connections（建议 ≥4096）并启用 multi_accept on，避免新连接排队
• 禁用 worker_priority 和外部 sched_setaffinity 脚本——Nginx 自身绑定已足够，额外干预反而干扰调度
• 容器环境务必用 nproc 而非 /proc/cpuinfo 判定核数，避免 auto 读到宿主机配置