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 本身。
