运行状态比配置更可靠，需验证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 读到宿主机配置
