Nginx 的 worker_cpu_affinity 必须配置在 main 全局块（events 块外、http 块之上），属于进程级调度指令，仅支持 main 上下文；放 server 或 http 块会因作用域错误导致启动失败。
Nginx 的 worker_cpu_affinity 不能在 server 块中配置，它属于全局（main）上下文指令，只能出现在 nginx.conf 的最外层，即 events 块之外、http 块之外的主配置区域。
Server 块负责处理 HTTP 请求路由与响应逻辑，不参与进程调度或 CPU 资源分配。把 worker_cpu_affinity 放进 server 或 http 块会导致配置加载失败（Nginx 启动报错：unknown directive "worker_cpu_affinity"）。
真正起作用的配置位置和关键要点如下：
必须放在 main 块（全局块）中
# nginx.conf 顶部，events 块之前
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
events {
use epoll;
worker_connections 4096;
}为什么不能放 server 或 http 块里？
-
worker_cpu_affinity控制的是 Worker 进程启动时绑定哪个 CPU 核心，而 Worker 进程是在 Master 进程启动阶段就 fork 出来的，远早于任何 HTTP 请求解析或 Server 匹配； - Server 块是请求到达后才被匹配执行的运行时逻辑单元，不具备影响进程级资源调度的能力；
- Nginx 配置指令有严格的作用域限制，该指令仅支持
main上下文（官方文档明确标注）。
提升缓存命中率的关键配合项（同样不在 server 块中）
这些也必须写在全局或 http 块，而非 server 块：
-
proxy_cache_path中设置use_temp_path=off，避免临时文件干扰缓存一致性； -
open_file_cache开启并合理配置，减少磁盘缓存文件的stat()开销； -
proxy_buffering on+proxy_busy_buffers_size，防止响应体未完整写入导致缓存截断； - NUMA 感知部署：若服务器为双路 CPU，需确保
worker_cpu_affinity掩码不跨 NUMA 节点（例如不把 Worker 同时绑在 CPU0 和 CPU16 上，除非它们属同一节点）。
验证是否生效的方法
- 查看 Worker 进程 PID：
ps -eo pid,args,psr | grep 'nginx: worker' - 检查亲和性：
taskset -cp <PID>，输出应显示唯一 CPU ID（如pid 12345's current affinity list: 0） - 观察
/proc/<PID>/status中Cpus_allowed_list字段是否与预期一致
不复杂但容易忽略。
