Nginx通过事件驱动模型复用upstream连接池，跳过三次握手与TLS握手，由epoll/kqueue监听空闲连接并触发回调复用；keepalive 32限制每worker缓存数，依赖后端keep-alive支持；连接生命周期由读超时、写错误等事件精准控制，非定时器扫描；所有操作非阻塞，DNS、SSL、读写均注册为事件；日志与tcpdump可验证复用效果。
Nginx 通过事件驱动模型高效管理 upstream 连接池，核心在于复用连接、避免阻塞、精准控制生命周期，而非依赖线程或进程等待。
事件驱动如何减少连接建立开销
Nginx 不为每个请求创建新连接，而是在 epoll/kqueue 事件循环中监听已建立的空闲连接。当后端服务器响应就绪、或连接可写入新请求时，事件触发回调，直接复用该 socket。这跳过了三次握手和 TLS 握手（若启用了 keepalive）。
- upstream 中配置 keepalive 32 表示每个 worker 最多缓存 32 个空闲长连接
- 需配合后端开启 Connection: keep-alive 和合理设置 keepalive_timeout
- 未启用 keepalive 时，每次请求都会新建 TCP 连接，事件模型优势无法发挥
连接池生命周期由事件状态精确控制
连接是否放入池中、何时超时、是否因错误被剔除，均由事件状态决定：比如读事件超时（read timeout）、写事件失败（write error）、收到 RST 包等，都会触发 cleanup 回调，立即释放并删除该连接，不等待定时器扫描。
- 使用 proxy_next_upstream error timeout http_502 可在事件异常时快速切换连接
- keepalive_timeout 不是连接池存活时间，而是空闲连接在池中保留的最大秒数，到期由事件机制主动关闭
- 连接池大小实际受限于 worker_connections 和系统文件描述符上限，事件模型让单 worker 能高效调度数千连接
避免阻塞操作破坏事件循环效率
所有 upstream 操作（如 DNS 解析、SSL 握手、包体读写）都注册为非阻塞事件，绝不调用 sleep 或同步 I/O。例如 SSL 握手失败时，Nginx 不重试，而是标记连接不可用并触发下一次 upstream 选择。
- DNS 查询使用异步 resolver，避免阻塞整个 worker
- proxy_buffering on 时，响应体接收由读事件分片驱动，而非一次性读完再处理
- 大文件上传场景下，使用 proxy_request_buffering off 配合流式转发，使请求体边收边发，全程事件驱动
调试与验证连接复用效果
可通过日志和指标确认事件驱动连接池是否生效：启用 log_format 记录 $upstream_addr 和 $upstream_http_connection，观察地址复用频次；同时检查 nginx_stub_status 中 Active connections 与 Writing 数值关系。
- 若 $upstream_addr 出现 “10.0.1.5:8080, 10.0.1.5:8080” 连续多次，说明连接复用成功
- tcpdump 抓包中 SYN 包明显减少、TIME-WAIT 状态连接稳定在低位，是连接池起效的佐证
- 避免将 proxy_http_version 1.0 与 keepalive 混用，会导致连接无法复用
