关键在于进程、连接、内核、内存四者协同：worker_processes auto与worker_cpu_affinity auto绑定CPU核心减少调度开销；events中use epoll、multi_accept on、accept_mutex on优化连接处理；worker_connections 16384配合keepalive_timeout 30s和缓冲区精细配置，并同步调优somaxconn、tcp_fin_timeout及ulimit。
要让 Nginx 在高并发下保持低延迟，关键不是堆参数，而是让进程、连接、内核、内存四者协同工作。单调高 worker_connections 或开一堆进程反而容易引发锁竞争、上下文切换和内存碎片。
进程层：匹配硬件，避免调度开销
每个 Worker 进程应绑定到独立 CPU 核心，减少跨核缓存失效和调度抖动：
- worker_processes auto; —— 自动识别逻辑 CPU 数（含超线程），比硬写数字更稳妥
- worker_cpu_affinity auto; —— Nginx 1.20+ 原生支持，自动完成“1 进程 ↔ 1 核心”映射，无需手动算二进制掩码
- worker_rlimit_nofile 65535; —— 显式声明单进程文件描述符上限，防止被系统默认值（常为 1024）卡住
连接层：控制生命周期与队列深度
连接不是越多越好，而要在建立、复用、释放三个阶段做精细干预：
-
events { use epoll; multi_accept on; accept_mutex on; } —— epoll 是 Linux 必选项；
multi_accept让单次唤醒处理多个就绪连接，降低系统调用频次；accept_mutex防止多 Worker 同时争抢 listen 队列导致的“惊群” - worker_connections 16384; —— 单进程万级连接需配合足够内存（约每连接占用 3–4 KB），建议按总内存反推：例如 32 GB 内存服务器，设为 16K 较安全
- keepalive_timeout 30s; keepalive_requests 500; —— API 类服务推荐 30 秒，既避免短连接频繁握手，又不长期占着连接；500 次请求后强制断连，防内存泄漏累积
缓冲与内存：按实际请求特征分配资源
大 Header、大 Body、代理响应都需独立控制，避免一个异常请求拖垮全局：
- client_header_buffer_size 8k; 和 large_client_header_buffers 4 16k; —— 应对含 JWT Token 或多段 Cookie 的请求，避免 414 错误
- client_max_body_size 100m; —— 上传类业务显式设限，防止恶意大包耗尽内存
- proxy_buffer_size 16k; proxy_buffers 8 32k; —— 后端响应头+前段内容先缓存，避免小包频繁 write() 系统调用；缓冲区总大小 ≈ 272 KB，适配多数 JSON/XML 响应
系统级协同：绕过内核瓶颈的必要动作
Nginx 配置再优，若内核网络栈未对齐，仍会卡在 SYN 队列、TIME_WAIT 或文件句柄上：
-
/proc/sys/net/core/somaxconn = 65535 —— 必须 ≥ Nginx
listen ... backlog=65535，否则新连接直接丢弃 -
/proc/sys/net/ipv4/tcp_fin_timeout = 30 —— 缩短 TIME_WAIT 持续时间，加快端口复用（搭配
net.ipv4.tcp_tw_reuse = 1） - ulimit -n 65535 —— 启动 Nginx 前在 service 文件或 systemd 中设置，确保生效
