Nginx默认启用异步非阻塞I/O（基于epoll/kqueue），关键在于保障连接层、上游转发、限流重试全链路非阻塞：调大内核accept队列、合理配置proxy缓冲与超时、避免同步阻塞操作。
Nginx 本身不直接暴露“Non-blocking IO”配置项，它底层默认且强制使用异步非阻塞 I/O 模型（基于 epoll/kqueue），这是它能扛住突发流量的根本前提。真正要做的不是“开启”它，而是确保整个链路不被阻塞点拖垮——从连接接入、请求处理到后端转发，每一环都要保持非阻塞特性。
Nginx 的非阻塞 I/O 是默认启用的，关键在避免人为引入阻塞
Nginx worker 进程采用单线程事件驱动模型：一个进程可同时管理数万并发连接，靠的是内核事件通知（如 epoll_wait）而非为每个连接分配线程。这意味着：
- 客户端 TCP 握手、数据接收、响应发送全部由事件循环调度；
- 不会因某个慢客户端或后端延迟，卡住整个 worker；
- 即使突发 10 万连接，只要内核参数和 Nginx 配置得当，连接建立和首包读取仍能毫秒级完成。
必须加固的三个非阻塞关键点
连接层不能丢包
若 accept 队列溢出，新连接会被内核直接丢弃（表现为客户端 connect timeout 或 RST），这等于在入口就“阻塞”了流量。
必须调大：net.core.somaxconn和net.ipv4.tcp_max_syn_backlog至 65535；
Nginx listen 指令显式写backlog=65535（不写则默认 511，极易打满）；
压测时用ss -lnt查看 Recv-Q 是否持续 > 0，确认生效。上游转发不能同步阻塞
proxy_pass默认是非阻塞的，但若后端响应慢，Nginx 会缓存响应体到内存或临时文件——若未限制，可能耗尽内存或填满磁盘。
应配置：proxy_buffering on;（启用缓冲，避免阻塞 client socket）proxy_buffers 8 16k; proxy_busy_buffers_size 32k;（控制缓冲区大小）proxy_read_timeout 15; proxy_send_timeout 15;（防后端僵死拖住连接）限流与重试策略必须配合非阻塞语义
limit_req burst=20 nodelay表示允许 20 个请求瞬时排队，超限立即返回 503——不等待、不阻塞后续请求；proxy_next_upstream error timeout http_500–504+tries=2，让失败请求快速切换节点，而不是卡在原连接上重试。
长连接场景下更需警惕“伪阻塞”
WebSocket 或 MQTT 接入时，单连接可能持续数小时。此时：
- 不要用
limit_conn粗暴限制总连接数，而应结合limit_req按$connection或$http_upgrade分类限频； - 启用
keepalive_timeout 75s并配upstream的keepalive 32，复用连接减少握手开销； - 避免在
location中使用auth_request或复杂 Lua 脚本做鉴权——它们可能隐式阻塞事件循环，改用auth_jwt或前置网关处理。
非阻塞不是一劳永逸的开关，而是整条链路的设计约束。Nginx 已为你铺好地基，剩下的是别在上面盖砖混结构的阻塞模块。
