Nginx高性能转发依赖异步事件驱动架构：单worker+事件循环通过epoll/kqueue监听socket就绪，零拷贝（sendfile）、连接复用（upstream keepalive）、TCP优化及模块化非阻塞回调协同实现低开销高吞吐。
Nginx 的高性能转发能力，核心在于它用异步事件驱动架构替代了传统阻塞式处理模型。它不靠堆线程或进程来“盯住”每个请求，而是让少量 worker 进程通过操作系统提供的高效事件通知机制，统一调度成千上万的并发连接——真正实现低开销、高吞吐的反向代理转发。
单 worker + 事件循环是调度基础
每个 Nginx worker 进程运行一个独立的事件循环（event loop），不轮询、不休眠，只调用 epoll_wait（Linux）或 kqueue（BSD/macOS）等待内核通知：“哪些 socket 就绪了”。一旦收到就绪列表，就快速处理读请求头、转发、收响应、写回客户端等动作，全程在用户态内存中完成，不阻塞其他连接。
- worker_processes 应设为 CPU 核心数（或 auto），避免进程过多争抢事件队列
- events 块中启用 use epoll; 和 multi_accept on;，提升突发连接接纳效率
- accept_mutex 控制多 worker 间新连接分配，防止“惊群”现象
零拷贝与连接复用降低系统开销
转发过程中，Nginx 尽量绕过用户态数据搬运，并复用底层连接资源：
- 静态文件响应使用 sendfile()，由内核直接从磁盘拷贝到 socket 缓冲区，跳过用户空间
- upstream 配置 keepalive 32; 并配合 proxy_http_version 1.1 和 Connection: '' 清除头，复用到后端的 TCP 连接，减少握手和 TIME_WAIT 堆积
- 启用 TCP_NOPUSH（Linux）合并小包，或 TCP_NODELAY 关闭 Nagle 算法，按业务延迟需求做取舍
模块化回调让功能不拖慢事件流
HTTP 解析、负载均衡、缓存、健康检查等功能都以非阻塞回调形式注册进事件循环，彼此解耦：
- upstream 模块的 health_check 是异步发起的，不影响主请求流转
- proxy_buffering 开启后，Nginx 可先收完后端响应再返回客户端，缓解慢后端对前端的影响
- 避免在 proxy_pass 前使用复杂 rewrite 或正则 location 匹配，防止事件处理路径变长
配置不当会悄悄破坏异步优势
一些常见设置看似合理，实则引入隐式同步阻塞：
- proxy_buffering off 且未设 proxy_read_timeout，可能导致 worker 被长尾响应卡住
- auth_request 指令会强制等待子请求完成，使原本并行的流程变为串行
- 日志写入未开启 buffered 和 flush，磁盘 I/O 可能拖慢整个事件循环
- worker_connections 设置过高但 ulimit -n 未同步调整，会导致 accept 失败或连接被丢弃
