Nginx 高频连接变动不会直接压垮 worker 进程，关键在于避免事件循环阻塞、及时释放连接资源、禁用用户态阻塞操作，并配合系统级调优。
在 Nginx 的事件驱动架构中，高频率连接变动（如短连接激增、频繁建连/断连）本身不会直接压垮 worker 进程，关键在于如何避免事件循环被低效操作阻塞，以及资源是否被合理复用与回收。
epoll/kqueue 机制天然适配连接快速变动
Nginx 在 Linux 下默认使用 epoll（macOS 使用 kqueue），它不轮询所有 socket，而是由内核主动通知“哪些 fd 就绪”。这意味着：即使每秒数万次 connect/close，只要没有大量就绪事件堆积，事件分发开销几乎恒定。
- 连接建立（accept）和关闭（close）都转化为 epoll_ctl 的添加/删除操作，时间复杂度为 O(1)
- 避免了 select/poll 的线性扫描瓶颈，尤其适合连接生命周期短、数量波动大的场景
- 需确保监听 socket 设置了 SO_REUSEPORT（多 worker 共享监听端口），缓解 accept 惊群问题
连接资源及时释放是性能稳定的核心
高频变动真正引发问题的环节，往往不是事件分发，而是连接对象未及时销毁或内存未归还。Nginx 通过内存池 + 连接池双层管理：
- 每个请求生命周期绑定一个
ngx_connection_t结构，连接关闭后立即调用 ngx_free_connection() 归还至空闲连接池 - HTTP 请求结束后，自动触发 ngx_http_close_request()，清理 request body 缓冲、headers、变量等，防止内存泄漏
- 注意配置 reset_timedout_connection on，对超时但尚未 close 的连接强制重置，避免 TIME_WAIT 占用过多本地端口
避免用户态阻塞操作破坏事件循环
哪怕 epoll 高效，一旦某个 handler 同步执行耗时操作（如阻塞 I/O、长循环、大文件同步读写），整个 worker 就会卡住，无法响应其他连接事件：
- 禁用 proxy_buffering off 且后端响应慢时，可能触发同步等待；建议始终开启缓冲并合理设置 proxy_buffer_size 和 proxy_buffers
- 自定义模块若调用 read()/write() 而非异步接口（如 ngx_unix_recv/ngx_unix_send），极易阻塞；应使用 Nginx 提供的异步读写回调机制
- 日志写入若配置为 access_log /path main buffer=64k flush=1s，可避免每次请求都刷盘，降低 syscalls 频次
系统级调优支撑高频连接吞吐
Nginx 是用户态程序，底层依赖内核网络栈能力。高频连接变动下，需协同调优：
- 增大 net.core.somaxconn（如设为 65535）和 net.core.netdev_max_backlog，应对突发 SYN 包队列积压
- 启用 net.ipv4.tcp_tw_reuse = 1（仅对客户端有效）和 net.ipv4.ip_local_port_range 扩展端口范围，缓解端口耗尽
- worker 进程数建议设为 cpu cores 数量，避免上下文切换开销；每个 worker 的 worker_connections 建议 ≤ 65535，结合 ulimit -n 实际值调整
