Nginx在Linux上默认启用epoll无需配置，可通过nginx -V | grep epoll验证，禁用use poll/select等误配，调优somaxconn、file-max等内核参数并合理设置worker_connections以发挥高并发性能。

Nginx 默认在 Linux 上就使用 epoll 作为事件驱动模型，无需额外配置即可发挥高并发优势。关键在于确认其生效、避免误配，并配合内核参数优化整体性能。

确认 Nginx 确实使用 epoll

Nginx 在编译时若检测到 Linux 内核支持 epoll（2.6+），会自动选用它作为默认事件模型。可通过以下方式验证：

• 运行 nginx -V 2>&1 | grep -o 'epoll'，输出含 epoll 表示已启用
• 查看运行中的 Nginx 进程是否调用 epoll 系统调用：strace -p $(pgrep nginx) -e trace=epoll_wait 2>&1 | head -5（需 root 权限）
• 检查 nginx.conf 中未显式设置 use select|poll|kqueue 等其他模型（这些会覆盖自动选择）

避免手动指定非必要事件模型

除非调试或兼容极旧系统，否则不要在 nginx.conf 中写 use epoll;。Nginx 不支持该语法（会报错），也不需要显式声明。常见误区包括：

• 误将 use epoll; 写入配置 → 启动失败，提示 "unknown directive 'use'"
• 错误配置为 use poll; 或 use select; → 性能大幅下降，尤其连接数 >1000 时响应延迟明显上升
• 多 worker 进程下，每个进程独立使用 epoll 实例，无需额外配置

配合内核参数提升 epoll 效率

epoll 本身高效，但系统资源限制会影响其表现。建议调整以下内核参数（写入 /etc/sysctl.conf 并执行 sysctl -p）：

• net.core.somaxconn = 65535：提升 listen 队列长度，避免新连接被丢弃
• net.core.netdev_max_backlog = 5000：增大网卡接收队列，应对突发流量
• fs.file-max = 1000000：提高系统级最大文件描述符数（epoll 依赖 fd）
• net.ipv4.ip_local_port_range = 1024 65535：扩大可用端口范围，利于大量上游连接

同时确保 Nginx 的 worker_rlimit_nofile 和 events { worker_connections } 设置合理（如分别设为 100000 和 10240），使单个 worker 能管理足够多的并发连接。

监控与验证实际效果

光看配置不等于生效，建议通过真实压测观察行为：

• 用 ss -s 查看当前 socket 统计，重点关注 total: xxx 和 tcp: 下的 established 数量
• 用 cat /proc/$(pgrep nginx)/fd | wc -l 检查 Nginx 进程打开的文件描述符数，应接近配置的 worker_connections × worker_processes
• 压测时观察 top 中 CPU 是否均匀分布于多个 worker 进程，且无明显 iowait 或 softirq 占用过高

若连接数增长但请求延迟陡增、或出现大量 502/504，需排查 upstream 超时、后端瓶颈或内核参数未生效等问题，而非 epoll 本身。