高防CDN节点的worker_processes需设为物理核心数（如16核设16），配合worker_cpu_affinity绑定、multi_accept、accept_mutex_delay调优及系统级资源提升，才能应对DDoS攻击下的高并发场景。
在高防CDN节点上，worker_processes 不是简单设为 auto 就能发挥最大效能的参数——它必须与硬件拓扑、流量特征和防御模型深度耦合。
CPU物理核心识别与超线程规避
高防节点常部署在物理服务器或裸金属云实例上，需区分逻辑核与物理核。启用超线程（HT）后，lscpu 显示 32 个逻辑 CPU，但实际仅 16 个物理核心。若盲目设 worker_processes 32，会加剧缓存争用和上下文切换开销。
- 用
grep 'core id' /proc/cpuinfo | sort -u | wc -l获取真实物理核心数 - 优先设为物理核心数，例如 16 核 →
worker_processes 16 - 如需压测验证，可对比
16与auto在 DDoS 攻击包洪泛下的 CPU cache-miss 率（用perf stat -e cache-misses,cache-references）
worker_cpu_affinity 绑定提升缓存局部性
CDN 节点处理海量短连接（如 HTTPS 握手、小图请求），CPU 缓存命中率直接影响 TLS 握手吞吐。未绑定时，Worker 进程可能在不同核心间迁移，反复清空 L1/L2 缓存。
- 配置示例（16 核）：
worker_cpu_affinity 0000000000000001 0000000000000010 ...（每位对应一个逻辑 CPU） - 更简洁写法：
worker_cpu_affinity auto 01;（自动按物理核顺序绑定，跳过超线程姐妹核） - 配合
worker_priority -5可保障防御模块（如限速、规则匹配）获得更高调度权重
防御场景下的进程负载再平衡
传统 CDN 流量较均衡，但高防节点面临突发攻击流（SYN Flood、HTTP Flood），部分 Worker 可能因连接哈希不均被“打爆”，而其他进程闲置。
- 启用
multi_accept on;，让每个 Worker 尽可能一次 accept 多个就绪连接，缓解事件队列堆积 - 调低
accept_mutex_delay 100ms;（默认 500ms），加快锁释放节奏，提升高并发下新连接分发效率 - 结合
ip_hash或一致性哈希做 upstream 负载，避免单个后端被攻击流集中冲击
系统级协同：文件描述符与内存页对齐
worker_processes 的实际能力受限于系统资源上限。高防节点每秒处理数万连接，worker_connections 常设为 16384+，必须同步放宽限制。
- 全局配置加
worker_rlimit_nofile 1048576; - 系统级永久生效：
echo "* soft nofile 1048576" >> /etc/security/limits.conf并重启 systemd 用户 session - 开启大页内存：
echo 1 > /proc/sys/vm/nr_hugepages（配合 Nginx 编译时加--with-file-aio）减少 TLB miss，加速 SSL 加解密路径
