直接配 worker_cpu_affinity auto 最稳妥，适配性强，尤其适合反向代理等I/O密集又偶有CPU热点的高并发场景；它自动按物理核分配、跳过超线程逻辑核，并需配合 worker_processes auto 及足够大的 worker_connections、worker_rlimit_nofile 等参数。

直接配 worker_cpu_affinity auto 就行，这是当前最稳妥、适配性最强的方案，尤其适合反向代理这类 I/O 密集又偶有 CPU 热点的高并发场景。

为什么反代场景特别需要绑定 CPU 核心

反向代理流量不是纯计算型，但 worker 进程仍会频繁处理 SSL 握手、header 解析、gzip 压缩、连接复用等操作。Linux 默认调度器可能把同一个 worker 在不同核心间来回迁移，导致 L1/L2 缓存反复失效、TLB 刷新，延迟抖动变大。绑定后，每个 worker 固定在一颗物理核上运行，热点数据（如 SSL session cache、共享内存 slab）更容易留在本地缓存中，对长连接、HTTPS 高频请求尤为明显。

推荐配置方式：优先用 auto，慎用手动掩码

自动模式已足够智能，无需自己算二进制：

• 标准写法（Nginx ≥ 1.9.10）：worker_processes auto; 和 worker_cpu_affinity auto; 配套使用，Nginx 会按物理核顺序分配，自动跳过超线程逻辑核（如 8 物理核 + HT = 16 逻辑 CPU，auto 默认只用前 8 个）
• 限制使用范围（例如只用前 4 核）：worker_cpu_affinity auto 00001111; —— 后缀十六进制掩码限定可用 CPU 集合
• 手动掩码仅用于特殊拓扑：比如 NUMA 架构下需强制绑定到某节点内核，才考虑写 0001 0010 0100 1000 这类，否则容易配错位数或重复绑核

必须同步调整的配套参数

CPU 绑定效果要真正发挥，得让 worker 有足够资源干活：

• worker_connections：设为 10240 或更高，配合 use epoll; 和 multi_accept on;
• worker_rlimit_nofile：设为 65535，并确保系统级 ulimit -n ≥ 该值（修改 /etc/security/limits.conf 和 sysctl fs.file-max）
• 避免干扰调度：不建议再设 worker_priority 或自定义 sched_setaffinity 脚本，Nginx 自身绑定已足够

验证是否生效的三步检查法

改完配置 reload 后，别只信日志，实打实看进程状态：

• 查当前运行核：ps -eo pid,args,psr | grep 'nginx: worker' —— 每个 PID 对应的 PSR 列应是不同数字（如 0、1、2、3），且不重复
• 查亲和性掩码：taskset -cp $(pgrep -f "nginx: worker" | head -1) —— 显示类似 pid 12345's current affinity list: 0
• 查底层允许列表：grep -i "cpus_allowed_list" /proc/$(pgrep -f "nginx: worker" | head -1)/status —— 应为单个数字，如 0，而非 0-7