要让Nginx扛住高吞吐低延迟流量，需从进程模型、连接调度、网络传输、HTTP链路四层系统调优：worker_processes auto并配worker_cpu_affinity绑定核心；worker_connections与ulimit同步设至65535以上；启用epoll、sendfile、tcp_nopush和tcp_nodelay；keepalive_timeout按场景分设15–90s，并配proxy_buffering防阻塞。
要让 Nginx 真正扛住高吞吐、低延迟的企业级流量，不能只改一两个参数，得从进程模型、连接调度、内核协同、HTTP链路四个层面系统性对齐硬件与业务特征。核心不是堆数值，而是让每个参数之间逻辑自洽、资源不打架。
进程模型：匹配 CPU 特性，避免调度开销
worker_processes 必须设为 auto，这是最稳妥的选择——它会自动读取 CPU 逻辑核心数（含超线程），既避免手动写死导致资源浪费，也防止多于核心数引发频繁上下文切换。若业务明确偏 CPU 密集（如全站 HTTPS + Gzip + Lua 脚本），可微调为 CPU 核心数；若以静态文件代理或反向代理为主，可尝试 ×1.5，但需压测验证。
必须开启 worker_cpu_affinity，尤其在 4 核及以上机器上。例如 8 核服务器配置为：
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
这样每个 worker 固定绑定一个物理核心，大幅降低 L1/L2 缓存失效和迁移开销。
连接能力：打通从内核到进程的全链路瓶颈
最大并发 = worker_processes × worker_connections，这个等式成立的前提是三者同步到位：
- worker_connections 设为 65535（非默认 512），适用于 64GB+ 内存服务器；若内存紧张，按“每连接约 10KB”估算，确保总内存占用可控
- worker_rlimit_nofile 必须 ≥ worker_connections，建议直接设为 65535 或更高（如 131072）
- 系统级限制必须同步：在 /etc/security/limits.conf 中添加
* soft nofile 65535
* hard nofile 65535
并用 ulimit -n 验证生效
events 块中强制指定 use epoll（Linux 环境），禁用 select/poll；开启 multi_accept on，使单次事件通知能批量接收多个新连接，减少唤醒次数。
网络传输：利用内核零拷贝与 TCP 协议栈特性
以下三项必须成对启用，缺一不可：
- sendfile on：启用内核态零拷贝，静态文件响应吞吐提升 50%+
- tcp_nopush on：配合 sendfile，把响应头和文件数据合并成一个 TCP 包发出，适合大文件下载、图片加载
- tcp_nodelay on：禁用 Nagle 算法，小包（如 API JSON、WebSocket ping）立即发送，延迟可降 30%+
注意：tcp_nopush 和 tcp_nodelay 并不冲突——前者优化“包数量”，后者优化“发包时机”，现代 Nginx 已支持智能协同。
HTTP 长连接与缓冲：平衡复用效率与资源驻留
keepalive_timeout 不宜统一设 75s。应按角色区分：
- API 网关 / 反向代理场景：设为 15–30s，防止后端连接池被长空闲连接占满
- 纯静态资源服务（如 CDN 边缘节点）：可放宽至 60–90s，提升复用率
配套设置 keepalive_requests 1000，即单连接最多处理 1000 次请求后主动关闭，防止因长期复用导致内存泄漏或句柄异常累积。
缓冲区需防“小头大身”问题：
- client_header_buffer_size 4k（覆盖 99% 请求头）
- large_client_header_buffers 4 8k（应对带大量 Cookie 或 JWT 的请求）
- 反向代理场景加 proxy_buffering on + proxy_buffers 8 16k，避免后端慢响应拖垮 worker 连接
