nginx非阻塞i/o由epoll/kqueue天然支持，无需配置开启；优化核心是减少拷贝、避免等待、匹配业务——如api用默认buffer、上传调大client_body_buffer_size、反向代理设proxy_buffer_size≥12k及proxy_buffers 8 16k，并协同sysctl、tcp_nopush、sendfile等系统级参数。
Nginx 的非阻塞 I/O 本身不是靠配置“开启”的，而是由底层事件机制（如 Linux 的 epoll）天然支撑的。优化高并发读写，关键不在于让 I/O “变非阻塞”，而在于让非阻塞模型真正高效运转——避免等待、减少拷贝、匹配业务节奏。
理解 Non-blocking IO 在 Nginx 中的真实角色
Nginx 启动时默认启用 epoll（Linux）或 kqueue（BSD），这意味着每个 worker 进程能同时监听成千上万个连接，且不会因某个连接没数据就卡住。它不依赖 buffer_size 或 sendfile 等参数来实现非阻塞；这些参数只影响数据在用户空间如何暂存、是否落盘、何时返回给客户端。
真正决定性能上限的，是：是否及时响应事件、是否避免无效轮询、是否减少内核与用户空间之间的数据搬运。
减少小包拷贝与内存浪费
当请求头或响应体太小、但 buffer 设置过大时，Nginx 会为每个请求预分配固定内存，造成碎片和浪费；反之，若 buffer 太小，又会频繁触发临时文件写入或回退逻辑，增加磁盘 I/O 和延迟。
- API 类服务：client_header_buffer_size 保持 1k，client_body_buffer_size 设为 8k 即可覆盖绝大多数 JSON 请求
-
含大量 Cookie 或 JWT 的登录接口：检查 access 日志中是否出现
400 Bad Request，若频繁发生，增大 large_client_header_buffers 到 4 8k - 上传接口：client_body_buffer_size 提至 32k–64k，并确保 client_max_body_size 与业务实际一致，避免小文件反复写 temp 目录
让 proxy 缓冲适配上游分块响应
反向代理场景下，上游（如 FastCGI、gRPC 或微服务）可能分多次发送响应头和响应体。如果 proxy_buffer_size 太小，会导致“upstream sent too big header”错误；如果 proxy_buffers 数量不足或单块太小，Nginx 可能被迫同步等待、阻塞后续连接处理。
- proxy_buffer_size 至少设为 12k，确保能容纳常见框架（Spring Boot、Django、Laravel）的完整响应头
- proxy_buffers 推荐设为
8 16k，即共 128k 缓冲空间，兼顾吞吐与内存占用 - 对流式响应（如 SSE、gRPC streaming），可设
proxy_buffering off，配合chunked_transfer_encoding on直接透传
协同系统层释放非阻塞潜力
非阻塞 I/O 要发挥最大效用，需操作系统与 Nginx 配合：
- 确认 nginx 编译时启用了 epoll：
nginx -V 2>&1 | grep -o with-epoll应有输出 - 调大系统级连接限制：
sysctl -w net.core.somaxconn=65535，并设置 ulimit -n ≥ 65536 - 启用
tcp_nopush on和tcp_nodelay on：前者合并小包发给客户端，后者避免 Nagle 算法延迟实时响应 - 静态资源走
sendfile on，跳过用户空间拷贝，由内核直接 DMA 传输到网卡
非阻塞不是魔法开关，而是整套机制协同的结果。调参不是越大越好，而是让 buffer 容量、事件轮询粒度、系统资源边界三者咬合得严丝合缝。
