nginx 的高性能源于非阻塞 i/o 与事件驱动机制，而非多线程堆砌；它通过 epoll/kqueue 单线程高效轮询数万连接，避免阻塞等待和上下文切换，配合 worker_processes、worker_connections 等配置协同释放性能。
Nginx 的非阻塞 I/O 是它能高效处理高并发请求的核心机制，不是靠“多开线程”堆出来的性能，而是用更少的资源干更多的事。
非阻塞 I/O 怎么让 Nginx 跑得更快
传统服务器（比如 Apache）在处理每个连接时，常分配一个线程或进程全程盯住——数据没来就卡住不动，CPU 白白闲置。Nginx 不这么干：它把所有连接放进一个监听池，靠 epoll（Linux）或 kqueue（BSD/macOS）一次轮询多个 socket 状态。只要某个连接有数据可读、可写或已建立，Nginx 就立刻响应，处理完马上回头继续巡检，不等、不卡、不空转。
- 单个 worker 进程可同时管理数万连接，内存占用几乎不随连接数线性增长
- 握手类轻量操作（如 HTTP 请求头解析、WebSocket 升级）能在一次事件循环内完成
- CPU 时间片被持续利用，避免线程切换开销和上下文等待浪费
关键配置要匹配非阻塞模型
非阻塞能力不会自动满载发挥，需要对应参数协同释放：
- worker_processes auto：让 Nginx 自动按 CPU 核心数启动 worker，避免进程过少压不住多核，或过多引发调度争抢
- worker_connections 10240（或更高）：设为单个 worker 能处理的最大并发连接数，建议不低于 10k，配合系统 ulimit -n 设置一致
- use epoll（Linux 环境下显式声明）：确保启用最优 I/O 多路复用机制，比 select/poll 更高效
- multi_accept on：允许单次事件循环尽可能多地接受新连接，减少瞬时高峰下的排队延迟
哪些地方容易拖慢非阻塞优势
非阻塞只解决 I/O 等待问题，但若后续环节变慢，整个流水线仍会卡住：
- SSL/TLS 握手未优化：wss 场景下，关闭 session 复用或 buffer 过小会显著拉长升级耗时
- 配置中滥用 rewrite、sub_filter 或复杂 Lua 脚本：这些同步执行逻辑会在事件循环中阻塞，延长单次处理时间
- 后端应用响应慢：Nginx 快速转发了请求，但上游服务迟迟不回包，连接就挂在那占着资源
- 系统级瓶颈：net.core.somaxconn 过低导致连接被内核丢弃，或 TIME_WAIT 回收不及时影响端口复用
实际效果看得到
在一台 4 核 8G 的云服务器上：
- 默认配置就能稳定支撑每秒 3000+ 次 HTTP 请求或 WebSocket 握手
- 调优后常见 QPS 达到 8000~12000+，此时 CPU 使用率通常不到 40%
- 真正卡点往往不在 Nginx 本身，而在网络栈配置、SSL 开销或后端服务吞吐能力
