Nginx在Linux 2.6+上默认启用epoll，无需且不可配置use epoll；关键在于确认其编译支持（nginx -V | grep with-epoll）、运行生效（错误日志含“using epoll”）、避免use select/poll降级，并协同调优内核参数、worker_connections及multi_accept等释放性能。
直接启用并正确配合 epoll 就能显著提升 Nginx 高并发响应效率，它不是要“手动开启”的功能，而是 Linux 下的默认高效基础。关键在于确认生效、避免干扰、协同调优。
确认 epoll 已实际启用
不必写 use epoll;，Nginx 在 Linux 2.6+ 内核上编译时自动包含并默认使用 epoll。验证方式有两种：
- 运行 nginx -V 2>&1 | grep -o with-epoll，输出含 with-epoll 表示编译支持
- 运行 nginx -V 2>&1 | grep -o 'epoll'，有输出即表示运行时已选用
- 检查配置中未出现 use select; 或 use poll; —— 这类显式设置会强制降级，大幅拉低性能
理解并信任边缘触发（ET）模式
Nginx 默认用 epoll 的边缘触发（ET）模式，它只在 socket 状态变化时通知一次，减少重复唤醒和系统调用。这要求：
- 所有网络 socket 必须设为非阻塞（Nginx 内部已强制实现）
- 读数据时需循环调用 recv() 直到返回 EAGAIN；写数据同理，未发完则缓存并注册写事件
- 无需、也不应尝试关闭 ET——Nginx 不提供开关，强行干预反而破坏机制
协同内核与 Nginx 参数调优
epoll 高效的前提是系统资源不卡脖子。需同步调整：
- net.core.somaxconn = 65535：增大 listen 队列，防新连接被丢弃
- fs.file-max = 1000000：提高全局限制，支撑高连接数
- net.core.netdev_max_backlog = 5000：应对突发包洪峰
- Nginx 配置中设 worker_rlimit_nofile 100000 和 events { worker_connections 10240; }，确保单 worker 能用足文件描述符
补充增强配置项
这些不改变 epoll 本身，但能放大其优势：
- multi_accept on;：让一次 epoll_wait 返回后尽可能多地 accept 新连接，减少事件唤醒次数
- accept_mutex off;（高负载下可选）：降低 worker 间争抢 accept 锁的开销
- sendfile on; 与 tcp_nopush on;：减少内存拷贝，加速静态资源分发
