Nginx 的 least_conn 是反向代理场景下显式配置的 upstream 调度算法，基于各后端当前活跃 TCP 连接数选择目标；epoll 则是 Worker 进程级 I/O 事件驱动机制，负责高效收发请求，二者分工协作：least_conn 决定“发给谁”，epoll 确保“如何高效发和收”。
Nginx 本身并不原生支持“最少连接”（Least Connections）作为 upstream 调度算法的默认行为——它默认使用轮询（round-robin），而“最少连接”需显式配置 least_conn 指令，且仅作用于反向代理场景下的后端服务器选择。它和 epoll 事件驱动机制不在同一层级，也不直接协作；但二者共同服务于高并发下的高效请求处理：前者决定“把请求发给哪个后端”，后者决定“本机如何高效收发这个请求”。理解它们的分工与衔接点，才能避免常见误用。
最少连接调度只发生在 upstream 阶段
当 Nginx 作为反向代理（即配置了 proxy_pass）时，least_conn 才生效。它的逻辑很简单：
- 维护每个 upstream server 的当前活跃连接数（基于已建立、尚未关闭的 TCP 连接）
- 新请求到来时，选当前连接数最少的 server 发起转发
- 该计数不依赖 epoll，而是由 Nginx 自身在连接建立/关闭时原子更新
注意：它不感知后端响应耗时、队列长度或 CPU 负载，仅统计“已建立未断开”的连接数。若后端使用长连接（keepalive），该值可能滞后于真实负载。
Epoll 负责本机所有 I/O 的高效调度
无论 upstream 是否启用 least_conn，每个 Worker 进程都独立运行 epoll 事件循环：
- 监听 accept socket（如 80/443 端口），收到新连接时触发 accept 事件
- 为每个客户端连接注册读事件（EPOLLIN），等待 HTTP 请求到达
- 发起 upstream 连接后，也为该 socket 注册读写事件，异步等待后端响应
- 所有这些文件描述符（fd）统一由一个 epoll 实例管理，无须轮询，只响应就绪事件
也就是说，epoll 不关心你用的是轮询还是最少连接——它只确保：一旦某个 upstream 连接可写（能发请求）或可读（收到响应），就立刻通知 Nginx 处理，不阻塞其他连接。
两者实际协作的关键节点
真正体现协作的地方，在于 upstream 连接的生命周期管理：
- 当 least_conn 选出目标 server 后，Nginx 调用
connect()尝试建立连接 - 若连接未立即完成（如网络延迟），Nginx 不会阻塞，而是将该 socket 设为非阻塞，并用
epoll_ctl(ADD)注册 EPOLLOUT 事件 - epoll_wait 返回该 fd 就绪后，Nginx 检查 connect 是否成功，再发送请求数据
- 后续接收响应的过程同样依赖 epoll 的 EPOLLIN 事件驱动
这种异步衔接，使得即使在 least_conn 选中的后端响应较慢时，Nginx 仍能继续处理其他客户端请求，不会因单个 upstream 操作卡住整个 Worker。
配置与调优建议
要让 least_conn 和 epoll 协同发挥最大效用，需注意：
- 确保
worker_processes auto或设为 CPU 核心数，使每个 Worker 充分利用 epoll 并行能力 - 调整
epoll_events（默认 512）以匹配峰值并发连接数，避免单次 epoll_wait 返回事件不足 - upstream 块中开启
keepalive（如keepalive 32），复用连接，减少频繁建连对 least_conn 计数和 epoll 注册/注销的开销 - 避免在 least_conn 后端列表中混入健康状态不稳定的节点，否则连接数统计失真，反而加剧倾斜
