关键在于协调单进程文件描述符限制与负载均衡：需配置worker_rlimit_nofile（如100000）并同步提升系统级nofile限制，设置worker_processes auto配合worker_cpu_affinity auto，events块启用epoll及multi_accept on、accept_mutex off。
关键在“单进程文件描述符限制”与“负载均衡”之间形成资源闭环：worker 进程能打开多少连接，直接决定它能分担多少流量；而负载均衡能否把请求合理甩给这些进程，取决于每个进程是否真能承载住。
设置合理的 worker_rlimit_nofile
这是 Nginx 内部对单个 worker 进程的硬性上限。必须显式配置，否则默认沿用系统低限（通常是 1024），严重制约并发能力。
- 推荐值设为 65535 或 100000，例如：
worker_rlimit_nofile 100000; - 该值不能高于系统允许的 per-process 上限，否则启动会报错或静默降级
- 需与
worker_connections匹配——后者不能超过前者，否则新连接会被拒绝
同步调高系统级文件描述符限制
Nginx 的 worker_rlimit_nofile 只是“申请额度”，操作系统才是最终审批者。缺这步，再高的配置也无效。
- 编辑
/etc/security/limits.conf，添加两行：* soft nofile 100000* hard nofile 100000 - 若 Nginx 以特定用户（如
nginx）运行，建议写成：nginx soft nofile 100000nginx hard nofile 100000 - 重启 shell 或重新登录使 limits 生效；验证命令：
ulimit -n
确保 worker_processes 与 CPU 核心数协同
负载均衡的吞吐能力，本质是多个 worker 进程并行处理能力的总和。进程数太少，CPU 利用不充分；太多，反而引发调度争抢。
- 优先使用
worker_processes auto;，Nginx 会自动读取 CPU 核心数 - 配合
worker_cpu_affinity auto;，让每个 worker 绑定独立核心，减少上下文切换开销 - 理论最大并发 =
worker_processes × worker_connections，但实际受后端、网络、磁盘 I/O 等制约
在 events 块中启用高效事件模型
Linux 下必须用 epoll，它是支撑高并发连接的基础引擎。没有它，Nginx 无法高效轮询数万连接的状态变化。
- 配置示例：
events {<br> use epoll;<br> worker_connections 65535;<br> multi_accept on;<br> accept_mutex off;<br>} -
multi_accept on表示一个事件循环内尽可能多地接收新连接，减少延迟 - 高负载下
accept_mutex off可避免进程排队抢锁，提升吞吐（适用于现代多核服务器）
