worker_processes auto在容器中是按规则探测而非智能适配，依赖/proc/cpuinfo或cgroups限额，不感知CPU配额限制；未配合资源约束易致CPU争抢、上下文切换激增或OOMKilled。
worker_processes auto 在容器中不是“智能适配”，而是“按规则探测”：它读取 /proc/cpuinfo 或 cgroups 限额，但不会主动感知容器的 CPU 配额限制。若不配合容器资源约束，极易启动过多 worker，引发 CPU 争抢、上下文切换激增，甚至被 OOMKilled。
确认容器真实可用 CPU 数量
auto 的行为取决于底层 cgroups 限制，而非宿主机核数：
- 必须在启动容器时显式设置 CPU 限制，例如：
docker run --cpus=2或 Kubernetes 中配置resources.limits.cpu: "2" - Nginx ≥1.19.0 才支持从 cgroups v1/v2 自动读取（推荐 ≥1.21.0）；旧版本仍会读宿主机
/proc/cpuinfo，导致误判 - 运行环境需为 Linux 主机（Windows/macOS Docker Desktop 的模拟 CPU 不被识别）
- 基础镜像内核建议 ≥5.4，确保 cgroups v2 支持稳定
验证 auto 是否按预期生效
进入容器后逐条执行，交叉比对结果：
-
nginx -t -v：确认 Nginx 版本 ≥1.19.0 -
cat /sys/fs/cgroup/cpu.max 2>/dev/null || cat /sys/fs/cgroup/cpu/cpu.cfs_quota_us：查看实际 cgroups 限额（如200000表示 2 核配额） -
nginx -T 2>/dev/null | grep "worker_processes"：检查最终解析值（注意-T输出的是合并后生效配置） -
ps aux | grep nginx | grep -v grep：统计运行中的 worker 进程数，应与 cgroups 限额匹配
容器环境更稳妥的写法
不完全依赖 auto，采用“显式声明 + 启动时注入”组合策略：
- 主配置中保留
worker_processes auto;（作为 fallback） - 在 entrypoint 脚本或 initContainer 中动态生成覆盖配置：
echo "worker_processes $(getconf _NPROCESSORS_ONLN);" > /etc/nginx/conf.d/worker.conf - 搭配
worker_cpu_affinity auto;（Linux only），让每个 worker 绑定独立 CPU；若仅分配 1 核，该指令自动禁用，避免无效配置 - 同步收紧连接限制：
events { worker_connections 2048; }，防止高并发下文件句柄耗尽
静态分发场景的轻量化加固
纯前端托管、CDN 边缘等静态服务，应在进程数合理基础上进一步降低开销：
- 启用零拷贝加速：
sendfile on; tcp_nopush on; - 静态资源强制长期缓存：
location ~* \.(js|css|png|jpg|gif|ico|svg|woff2?)$ { expires 1y; add_header Cache-Control "public, immutable"; } - 关闭访问日志：
access_log off;，或改用异步日志模块减少 I/O 阻塞 - 编译时裁剪非必要模块（如
--without-http_rewrite_module），减小内存 footprint
