非阻塞 I/O 是 Nginx 反向代理高性能运转的底层支撑，它不加速单次传输，但使每个 worker 能同时调度成千上万上下游连接，避免慢请求拖垮吞吐；结合 epoll/kqueue 实现零阻塞、无上下文切换的并行处理，并依赖 proxy_buffer_size≥12k、proxy_buffers 8 16k 等配置匹配业务节奏。
非阻塞 I/O 是 Nginx 反向代理高性能运转的底层支撑，它本身不加速单次数据传输，但让每个 worker 进程能同时、独立地调度成千上万的上游和下游连接，避免慢请求拖垮整体吞吐。
让反向代理真正“并行处理”多个请求
传统阻塞模型中，一个连接卡在等待后端响应时，整个线程或进程就空转；而 Nginx 的非阻塞 I/O 结合 epoll/kqueue 事件机制，使每个 worker 能在等待 upstream 响应的同时，继续读取新 client 请求、写回已就绪的响应、或处理其他连接的超时与关闭——所有操作都在同一事件循环内切换，无需上下文切换开销。
- 下游（客户端）连接可随时被唤醒：比如大文件下载中途暂停，Nginx 不会为它独占资源，而是将其挂起，等 socket 可写再继续发送
- 上游（后端服务）响应到达即触发回调：无需轮询，也不阻塞其他请求的 upstream 连接建立或 header 解析
- 连接状态完全解耦：一个后端响应延迟 5 秒，不影响同一 worker 内其他 1000+ 连接的正常收发
缓冲策略必须匹配非阻塞节奏
非阻塞 I/O 的效率高度依赖缓冲配置是否适配业务响应模式。缓冲太小会频繁落盘或触发重试；太大则浪费内存、增加 GC 压力，还可能放大长尾延迟。
- proxy_buffer_size 至少设为 12k：确保能一次性接收 Spring Boot、Django 等框架返回的完整响应头（含 Set-Cookie、JWT、自定义 header）
- proxy_buffers 推荐 8 16k：提供 128k 总缓冲空间，平衡流式响应吞吐与内存占用；对 JSON API 类接口足够，对视频切片或大附件需单独评估
- 流式场景（如 SSE、gRPC streaming）建议 proxy_buffering off：直接透传 chunked 数据，避免缓冲积压导致延迟突增
避免业务逻辑破坏非阻塞流水线
即使 I/O 层完全非阻塞，一段同步代码仍会让整个 worker 卡住。反向代理环节尤其要注意：
- 不要在 rewrite 或 access 阶段执行阻塞 DNS 查询：改用 resolver 127.0.0.1 valid=30s 后配合 $host 变量异步解析
- 禁用 require() 加载大 Lua 模块或同步读取本地配置文件：这类操作发生在用户态，不触发事件调度，会中断当前 worker 的所有连接处理
- upstream keepalive 必须开启：否则每次请求都新建 TCP 连接，握手 + TIME_WAIT 会快速耗尽端口和连接槽位，抵消非阻塞优势
协同系统层释放事件驱动潜力
非阻塞 I/O 的上限由内核与 Nginx 共同决定。关键协同点包括：
- 启用 sendfile on 和 tcp_nopush on：静态资源响应走零拷贝路径，减少用户态内存搬运，合并 TCP 小包提升带宽利用率
- 调高系统级连接限制：ulimit -n 至少 65536，并设置 net.core.somaxconn=65535，防止事件队列溢出丢连接
- worker_connections 与 CPU 核心数匹配：例如 4 核机器设为 16384，确保每个 worker 有足够事件槽位，又不因过大导致内存碎片
