nginx.conf 的 main 段全局参数直接决定 worker 进程行为与系统稳定性：worker_processes 应设为 auto 或匹配 CPU 核数；worker_connections 需配合系统 ulimit 和 events 模块调优；worker_rlimit_nofile 主动提升文件描述符上限；accept_mutex 与 multi_accept 协同优化连接分发。
nginx.conf 的 main 段（全局配置块）虽不处理请求，却直接决定 worker 进程行为、资源调度能力与整体稳定性。参数设得不合理，轻则浪费 CPU 内存，重则触发惊群、连接堆积甚至进程崩溃。
worker_processes：进程数量与 CPU 利用率
该值控制 nginx 启动的 worker 进程数。设为 auto 最稳妥——nginx 会自动读取 CPU 核心数并一一对应；手动指定时，超过物理核心数反而可能因上下文切换增加开销。若部署在容器中且未限制 CPU 配额，auto 可能误读宿主机核数，此时应显式设为容器实际可用核数（如 2 或 4）。
- 单核机器设为 1，避免争抢
- 高并发静态服务场景，可设为 auto，但需配合 worker_cpu_affinity 绑核提升缓存命中率
- 动态 upstream 多、后端延迟高的场景，适当减少 worker 数（如设为核数的 70%），降低事件队列竞争
worker_connections 与 events 模块联动
每个 worker 进程允许的最大并发连接数，必须结合 events { use epoll; } 和系统级限制共同评估。其理论最大并发 = worker_processes × worker_connections，但真实上限受 ulimit -n 和内核 net.core.somaxconn 制约。若只调高此值却不调大系统打开文件数，启动时会报错 “too many open files”。
- 默认 512 仅适用于开发环境；生产建议设为 4096–65535，视内存和业务压力调整
- 搭配 use epoll;（Linux）或 kqueue;（FreeBSD），才能真正发挥高连接性能
- 若开启 http_v2 或大量长连接（如 WebSocket），需预留更多连接槽位，避免 accept 队列溢出
worker_rlimit_nofile：主动突破系统限制
该指令让 nginx 在启动时主动调用 setrlimit() 提升自身可打开文件数上限，无需依赖外部 ulimit 设置。它必须 ≤ 系统 hard limit（可通过 ulimit -Hn 查看），否则启动失败。设得太低会导致连接被拒绝；设得过高而系统资源不足，可能引发 OOM Killer 杀进程。
- 推荐设为与 worker_connections 相同或略高（如 65536）
- 需同步调整系统级配置：/etc/security/limits.conf 中为 nginx 用户添加 nofile soft/hard 限制
- systemd 环境下还需在 service 文件中配置 LimitNOFILE=65536
multi_accept 与 accept_mutex：连接分发策略
accept_mutex on;（默认）启用互斥锁，防止多个 worker 同时唤醒争抢新连接（即“惊群”）；multi_accept on; 则允许单个 worker 一次 accept 多个就绪连接，减少事件循环次数。两者配合可在高并发下平衡负载与响应延迟。
- Linux + epoll 下，建议保持 accept_mutex on; 和 multi_accept on;
- 短连接高频场景（如 API 网关），开启 multi_accept 可降低平均延迟
- 若使用 reuseport（需 kernel ≥ 3.9，nginx ≥ 1.9.1），可关闭 accept_mutex，由内核完成负载分发，性能更优
main 段不是越复杂越好，而是要贴合运行环境与业务特征做收敛配置。多数线上问题，根源不在 location 或 upstream，而在这些看似“静态”的全局参数没对齐真实资源边界。
