Nginx 在 Linux 下的高性能核心依赖 epoll 机制实现事件驱动 I/O，通过单进程、多连接、非阻塞 + epoll 高效分发请求；epoll 具 O(1) 时间复杂度、内核就绪队列和 ET 模式等优势，使单 worker 可支撑数万并发；配置需调优 worker_connections、use epoll、multi_accept 等，并协同优化 upstream 超时与健康检查。
Nginx 在 Linux 下的高性能，核心之一正是深度依赖 epoll 机制实现事件驱动的 I/O 处理，而非传统阻塞式或轮询式模型。它本身不是“负载均衡器”意义上的独立服务（如 LVS），而是通过单进程、多连接、非阻塞 + epoll 的方式，高效地将客户端请求分发给后端服务器——这才是其高并发能力的底层支撑。
epoll 是什么，为什么 Nginx 非用不可？
epoll 是 Linux 内核提供的 I/O 多路复用接口，相比 select/poll，它在连接数多、活跃度低的场景下优势显著：
- 时间复杂度为 O(1)，增删查事件不随连接数增长而变慢
- 内核维护就绪队列，只通知真正有事件的 fd，避免遍历全部连接
- 支持边缘触发（ET）模式，配合非阻塞 socket 可最大限度减少系统调用次数
Nginx 默认启用 epoll（Linux 2.6+ 自动选择），无需手动开启，但可通过 nginx -V 2>&1 | grep -o with-epoll 确认编译时是否包含该模块。
epoll 如何支撑 Nginx 的请求分发逻辑？
Nginx 的 worker 进程启动后，每个进程会：
- 创建一个 epoll 实例（
epoll_create） - 将监听 socket（如 80/443）注册进 epoll，关注
EPOLLIN - 进入事件循环：
epoll_wait阻塞等待就绪事件（毫秒级超时） - 一旦有新连接或数据到达，内核返回就绪 fd 列表，Nginx 快速处理 accept 或 recv
- 对后端转发（proxy_pass），同样用非阻塞 socket + epoll 管理与 upstream 的连接生命周期
整个过程无线程切换、无连接阻塞，单 worker 即可轻松维持数万并发连接。
配置层面如何配合 epoll 发挥最大效能？
epoll 本身由内核和 Nginx 自动调度，但以下配置直接影响其效率：
-
worker_connections：每个 worker 允许的最大并发连接数，应 ≤
ulimit -n，并留余量；建议设为 10240 或更高 - use epoll;：显式声明（虽默认生效，但写上更明确，尤其跨平台部署时）
-
multi_accept on;：让一个
epoll_wait返回后，尽可能多地 accept 新连接，减少事件唤醒次数 - sendfile on; 和 tcp_nopush on;：减少用户态/内核态拷贝，配合 epoll 提升静态文件吞吐
注意：epoll 不解决后端瓶颈，只优化分发链路
epoll 让 Nginx 能快速收发、调度请求，但它不加速后端应用响应。若 upstream 响应慢、超时设置不合理或健康检查缺失，Nginx 仍会积压连接甚至触发 502/504。因此需同步优化：
- 设置合理的
proxy_read_timeout、proxy_connect_timeout - 启用
upstream health_check（需 stream 模块或商业版）或自定义心跳探测 - 结合
least_conn、ip_hash等负载策略，避免单点过载
