Nginx非阻塞I/O由epoll/kqueue天然支持，无需配置开启；优化核心是减少拷贝、避免等待、匹配API特征——如header设1k、body设8k、proxy_buffer_size≥12k、proxy_buffers 8 16k，并协同multi_accept、tcp_nodelay等参数提升响应速度与吞吐。
Nginx 的非阻塞 I/O 本身不是靠配置“打开”的，而是由底层 epoll（Linux）或 kqueue（BSD）事件机制天然支撑的。真正影响海量 API 调用性能的，是让这套非阻塞模型跑得更稳、更快、更省——不空等、少拷贝、准响应、低开销。
匹配 API 请求特征调缓冲区
API 多为轻量 JSON 请求，头部短、体小、响应快，缓冲区设太大反而浪费内存、拖慢首次分配： - client_header_buffer_size 1k 足够覆盖标准 HTTP 头；若接口带长 JWT 或大量 Cookie，观察 access 日志中 400 错误频次，再调 large_client_header_buffers 4 8k - client_body_buffer_size 8k 可承载绝大多数 POST/PUT JSON 数据；上传类 API 才需提到 32k–64k - client_max_body_size 必须与业务实际一致，避免小请求反复落盘到 temp 目录，增加磁盘 I/O加速代理链路，减少上游等待
多数 API 经由 Nginx 反向代理转发，非阻塞能力必须延伸到 upstream 侧： - proxy_buffer_size 至少 12k，确保能一次性收全 Spring Boot、Django 等框架返回的响应头，避免 “upstream sent too big header” 报错 - proxy_buffers 8 16k 提供 128k 缓冲空间，平衡吞吐与内存占用；流式接口（如 SSE、gRPC streaming）可设 proxy_buffering off 直接透传 - proxy_http_version 1.1 + proxy_set_header Connection ""，复用连接，减少 handshake 开销释放事件驱动真实潜力
非阻塞只是基础，高效事件调度才是高并发落地的关键： - events { use epoll; multi_accept on; accept_mutex off; }：Linux 下必选 epoll；multi_accept 允许单次事件批量接收连接；QPS 过 5000 后关闭 accept_mutex，避免 worker 争抢锁 - worker_processes auto; + worker_cpu_affinity auto;：自动绑定每个 worker 到独占物理核心，减少跨核缓存失效 - worker_connections 16384; 配合系统级 ulimit -n 65535 和内核 net.core.somaxconn = 65535，支撑万级并发连接剪掉干扰项，专注传输本身
API 场景下，任何非必要开销都会被放大： - access_log off; 关闭日志（尤其边缘节点或压测环境），直接消除磁盘写延迟 - sendfile on; + tcp_nopush on; 加速静态响应（如 Swagger 页面、健康检查端点） - tcp_nodelay on; 禁用 Nagle 算法，让小包（如 ACK、短 JSON 响应）立即发出，降低首字节延迟 - 不启用 gzip、sub_filter 等修改响应体的模块——它们会迫使 Nginx 退回到 read()+write() 模式，丢失 sendfile 零拷贝优势不复杂但容易忽略。
