Nginx中worker_cpu_affinity掩码错误导致绑定失效，核心是验证语法合法、内核支持及运行时生效：掩码数须等于worker_processes，位数不超逻辑CPU总数，仅支持二进制空格分隔；需查error_log（debug级）、taskset -cp 和/proc//status确认实际绑定。
排查 Nginx 中因 worker_cpu_affinity 掩码书写错误导致的 CPU 绑定失效，核心是验证配置语法是否合法、内核是否支持、实际运行时是否生效。重点看日志、进程状态和系统级绑定结果。
检查配置语法与 CPU 数量匹配
Nginx 要求每个 worker 进程对应一个 32 位（或 64 位）CPU 掩码，掩码数量必须 ≥ worker_processes 值，且每位代表一个逻辑 CPU。常见错误包括：
- 掩码位数不足：如系统有 8 个逻辑 CPU（0–7），却只写
00000001 00000010（仅两个掩码），但worker_processes 4，后两个 worker 无法分配掩码，Nginx 启动时会静默忽略绑定（不报错，但不生效） - 掩码超范围：写
100000000（9 位）绑定到第 9 个 CPU，而系统只有 8 核 → 掩码被截断或忽略 - 十六进制误用：Nginx 只接受二进制格式的空格分隔掩码，如
0001 0010；写成0x1 0x2或1 2（十进制）均无效 - 掩码全零：
0000 0000表示不绑定，等同于未配置
确认 Nginx 启动时是否加载了 affinity 配置
启动后立即检查 error log（默认 logs/error.log，级别至少为 info）：
- 成功绑定会输出类似：
bind() to 0.0.0.0:80 failed (98: Address already in use)不相关；真正线索是：using the "epoll" event method, worker process is bound to cpu #0—— 但 Nginx 官方日志默认不打印绑定详情 - 更可靠方式：临时把
error_log级别设为debug，重启后搜索cpu affinity关键字，正常会有：set cpu affinity mask 00000001 - 若没看到任何 affinity 相关日志，说明配置未被解析（语法错、被注释、或在 if 段中非法使用）
验证运行时进程是否真实绑定
不能只信配置，要查 OS 层面的实际效果：
- 查 Nginx master 和 worker 进程 PID：
ps -eo pid,comm,args | grep nginx - 对每个 worker PID（非 master），执行：
taskset -cp <pid></pid>，输出形如pid's current affinity list: 0表示绑在 CPU 0；若显示0-7或全集，说明未绑定 - 注意：Linux 的
taskset显示的是“当前允许运行的 CPU 列表”，不是“已固定到某核”。如果输出是完整范围（如0-7），即表示未绑定；若为单个数字（如3）或离散集合（如1,3,5），才表示生效 - 补充验证：
cat /proc/<pid>/status | grep Cpus_allowed_list</pid>，结果应与taskset一致
排除内核与运行环境干扰
即使配置正确，也可能因系统限制失效：
- 确认内核启用 CPU affinity 支持：
grep CONFIG_SCHED_SMT /boot/config-$(uname -r)应为y或m；CONFIG_CPUSETS非必需，但影响 cgroup 场景 - Docker/K8s 环境下：
worker_cpu_affinity通常失效，因为容器默认受限于 cgroup cpuset；需在容器启动时通过--cpus或cpuset-cpus显式分配，Nginx 内部绑定无意义 - systemd 启动时，若 service 文件中设置了
CPUSchedulingPolicy=other或禁用了CPUAffinity=，会覆盖 Nginx 自身设置 - 虚拟机场景：确保 Hypervisor 暴露了 vCPU topology，且未启用 CPU 热插拔或动态迁移（会破坏绑定稳定性）
不复杂但容易忽略：掩码顺序必须与 worker_processes 启动顺序严格对应，第一个掩码给第一个 fork 出的 worker（通常 PID 最小），而非按配置文件顺序“从上到下”理解。调试时优先用 worker_processes 2 + 两个明确掩码（如 0001 0010），再逐步扩展。
