Nginx的非阻塞I/O由epoll/kqueue实现，buffer_size类参数仅控制应用层数据暂存，不影响I/O模型；调优需匹配业务特征，避免小包拷贝、内存浪费与缓冲区溢出。
nginx 的非阻塞 I/O 本身由 epoll（Linux）或 kqueue（BSD）等事件驱动机制实现，不依赖用户手动设置 buffer_size 参数；buffer_size 类参数影响的是应用层数据暂存行为，而非 I/O 模型是否阻塞。调优的关键在于匹配业务特征——避免小包频繁拷贝、减少内存浪费、防止缓冲区溢出丢包。
理解 buffer_size 相关参数的实际作用
nginx 中常见 buffer 相关指令如 client_body_buffer_size、client_header_buffer_size、large_client_header_buffers、proxy_buffer_size、proxy_buffers 等，并不改变 socket 层的阻塞/非阻塞属性，而是控制 nginx 在内存中如何暂存请求体、请求头、上游响应等数据：
- client_header_buffer_size：用于暂存 HTTP 请求头，默认 1k。若客户端发送超长 header（如含大量 Cookie 或自定义字段），会触发回退到 large_client_header_buffers，否则直接 400 错误
- client_body_buffer_size：暂存请求体（如 POST 数据）。小于该值时全内存处理；超过则写临时文件（受 client_body_temp_path 控制）
- proxy_buffer_size：仅缓存上游响应的 header（必须内存驻留，不可写磁盘）
- proxy_buffers：缓存 upstream 响应 body，第一块固定为 proxy_buffer_size 大小，其余由 proxy_buffers number size 定义
根据典型场景调整 buffer 配置
盲目增大 buffer 不提升吞吐，反而增加延迟和内存压力。应结合真实流量分析：
- API 接口（JSON 小请求）：保持默认即可。client_header_buffer_size 1k、client_body_buffer_size 8k 足够覆盖多数 REST 请求
- 文件上传服务：增大 client_body_buffer_size（如 16k–64k），并确保 client_max_body_size 合理；避免小文件反复落盘
- 反向代理动态内容（如 FastCGI / gRPC）：关注 proxy_buffer_size（建议至少 12k，兼容多数框架 header）、proxy_buffers 8 16k，防止 upstream 分块响应时频繁 read/write
- 静态大文件分发：可关闭 proxy buffering（proxy_buffering off），启用 sendfile on 和 tcp_nopush on，让内核直接零拷贝传输
配合非阻塞 I/O 的关键协同点
buffer 调优需与 nginx 事件模型协同生效：
- 确认使用 epoll：检查 nginx -V 输出含 --with-epoll_module（Linux 默认启用）
- 避免 buffer 成为瓶颈：若日志中频繁出现 "upstream sent too big header" 或 "client intended to send too large body"，说明 buffer 不足，应针对性扩容而非全局调大
- 监控实际内存占用：通过 nginx -s stats（需编译 http_stub_status）或 pidstat -r -p $(pgrep nginx) 观察 worker 进程 RSS，验证 buffer 调整是否引发异常增长
- 注意 OS 层限制：socket receive/send buffer（net.core.rmem_max、net.core.wmem_max）应 ≥ nginx 最大单 buffer，否则内核会截断
一个轻量级调优示例（中等负载 API 网关）
适用于 JSON RPC、JWT 认证、平均请求头 800B、Body ≤16KB 的场景：
client_header_buffer_size 2k; large_client_header_buffers 4 4k; client_body_buffer_size 16k; client_max_body_size 32m; proxy_buffer_size 12k; proxy_buffers 8 16k; proxy_busy_buffers_size 32k; proxy_buffering on;
该配置在内存开销可控前提下，覆盖 99%+ 正常请求，同时保留应对突发大 header/body 的弹性，不牺牲事件循环效率。
