nginx高并发需从进程模型、连接管理、系统协同三层面协同调优：worker_processes auto并绑定cpu亲和性；events中启用epoll、multi_accept on、worker_connections匹配ulimit；http层优化keepalive、缓冲区及sendfile等参数。
要让 Nginx 真正撑住高并发，光改几个参数远远不够——得从进程模型、连接管理、系统协同三个层面一起动手。调优不是堆数值，而是让每个环节不拖后腿。
worker 进程与 CPU 绑定：别让进程满处跑
worker_processes 决定能并行处理多少路请求，设太少压不住流量，设太多反而因频繁切换浪费 CPU。推荐直接写 worker_processes auto;，Nginx 会自动匹配物理核心数。若需精细控制（比如 8 核服务器），可手动设为 8，并同步绑定 CPU：
- worker_cpu_affinity 00000001 00000010 ... 10000000;（共 8 组，每组对应一个核心）
- 绑定后可用
ps axo pid,cmd,psr | grep nginx验证各 worker 是否均匀落在不同 CPU 上 - 在 NUMA 架构或大内存场景下，绑定还能减少跨节点内存访问延迟
events 模块：连接数与事件模型必须配对
单个 worker 能管多少连接，由 worker_connections 决定；但它能否高效响应这些连接，取决于底层事件模型。Linux 下必须用 epoll：
- use epoll; —— 不加这句，万级连接时 CPU 使用率可能飙升 3 倍以上
-
worker_connections 65535; —— 建议设为 64K 或 100K，但要确保系统
ulimit -n≥ 此值 × worker 数 - multi_accept on; —— 允许单次 accept 系统调用收多个新连接，降低内核态/用户态切换频次
- accept_mutex off;（高并发反向代理场景）—— 关闭互斥锁，避免 worker 争抢 listen 队列，减少排队等待
HTTP 层关键缓冲与复用：稳住短连接洪峰
大量小请求打进来时，头部解析、响应打包、连接重建都是瓶颈。这几个参数直接影响 QPS 和延迟稳定性：
- keepalive_timeout 60; 和 keepalive_requests 1000; —— 复用连接省去三次握手和 TLS 握手开销；超时不宜过长，否则空闲连接占满 worker_connections
- client_header_buffer_size 4k; + large_client_header_buffers 4 8k; —— 应对带大 Cookie 或 JWT 的请求，防 414 错误
- sendfile on; + tcp_nopush on; + tcp_nodelay on; —— 静态文件走零拷贝，大包攒发提吞吐，小包即时发保响应
- reset_timedout_connection on; —— 主动断开卡死的客户端连接，防止资源被长期占用
压测验证不能跳过：用 wrk 看真实水位
配置改完不压测，等于没调。推荐用 wrk 做分层验证：
- 先测基础能力：
wrk -t4 -c2000 -d30s http://localhost/（观察平均延迟和错误率） - 再压连接极限：
wrk -t16 -c50000 -d60s --latency http://localhost/（关注 99 分位延迟是否突增） - 对比关键指标：QPS、error rate、CPU idle、nginx worker 进程 RSS 内存增长趋势
- 若出现大量 502/504，优先查 upstream 连接池或 proxy_timeout 设置；若连接拒绝增多，回头检查 ulimit 和 backlog 参数
