设为 auto 最稳妥但非万能，容器或 cpu 配额下需查真实可用核数；高并发静态服务用物理核数，混部场景设 1–2；worker_connections 受系统 ulimit 限制，需同步调高 limits.conf 和 worker_rlimit_nofile；keepalive_timeout 建议 15–30 秒，http/2 下关注 http2_max_requests；linux 下默认自动使用 epoll，无需手动指定。
nginx worker_processes 怎么设才不浪费 CPU
设成 auto 大多数时候最稳妥，但不是万能解。它会读取 /proc/cpuinfo 的逻辑核数，可如果你跑在容器里、或用了 CPU 配额（比如 cpus: 2），auto 仍可能返回宿主机总核数，导致 worker 进程过多、上下文切换反升。
- 查真实可用核数：
grep -c ^processor /proc/cpuinfo（容器内需结合cat /sys/fs/cgroup/cpuset/cpuset.cpus） - 高并发静态服务（如 CDN 边缘节点）：设为物理核数，禁用超线程更稳
- 混部场景（Nginx + 后端代理）：通常设为
1或2，留资源给 upstream - 改完必须 reload：
nginx -s reload，不是 restart；否则新配置不生效
worker_connections 超过 65535 就报错？
报错 worker_connections are not enough 或 accept() failed (24: Too many open files)，本质是系统级文件描述符限制卡住了，不是 Nginx 自身上限问题。
- 先看当前限制：
ulimit -n，默认常是 1024 - 临时提限：
ulimit -n 65536（仅当前 shell 有效） - 永久生效要改两处：
/etc/security/limits.conf加nginx soft nofile 65536和nginx hard nofile 65536；再确认/etc/nginx/nginx.conf里worker_rlimit_nofile设为同值 -
worker_connections值不能超过ulimit -n的 soft limit，否则启动时就警告
keepalive_timeout 设太长反而拖慢连接回收
这个参数不是“越长越好”。它控制客户端空闲连接保持时间，设太高会让大量空闲连接占着 worker_connections 槽位，新请求进不来。
- HTTP/1.1 默认是 75 秒，对普通 Web 站点偏长；API 网关建议压到 15–30 秒
- 如果用 HTTP/2，
keepalive_timeout影响变小，但要注意http2_max_requests（默认 1000）才是实际断连主因 - 别忽略客户端行为：移动端弱网下，TCP keepalive 探测间隔（
net.ipv4.tcp_keepalive_time）可能比 Nginx 层 timeout 更早触发断连 - 实测建议：先设 30，用
ss -s | grep "timewait"观察 TIME-WAIT 数量变化，再微调
epoll 和 select 在 Linux 上到底该选哪个
Linux 下只用 epoll，select 是历史遗留选项，性能差且有 1024 文件描述符硬限制，现代发行版已基本弃用。
-
events { use epoll; }可以省略——Nginx 在 Linux 上自动选epoll，除非你手动指定select或poll - 真要验证：启动后执行
nginx -V 2>&1 | grep -o 'epoll'，有输出即生效 - 唯一需要干预的场景：某些老旧内核（epoll，但这种环境现在极少遇到
- 注意：Docker 容器里若用
alpine镜像，默认 musl libc 对epoll支持完整，无需额外操作
net.core.somaxconn 没调，SYN 队列溢出；或者 net.ipv4.ip_local_port_range 太窄，代理场景快速耗尽本地端口。这些点不显眼，但一出问题就难定位。
