Nginx微服务网关调优核心是匹配内核与流量特征：启用epoll+multi_accept、worker_connections需满足ulimit和somaxconn、keepalive_timeout设为15s、worker_cpu_affinity auto绑定CPU。
微服务架构下，服务间通信频繁、请求体小、连接数多，Nginx 作为 API 网关或边车代理时，events 块的配置直接影响小报文（如 JSON RPC、gRPC metadata、健康检查）的并发吞吐与延迟稳定性。关键不在“调大数值”，而在匹配内核能力与业务流量特征。
用 epoll + multi_accept 减少事件唤醒开销
Linux 下默认使用 epoll，但需显式启用并配合 multi_accept 才能高效处理突发的小连接请求（如服务发现心跳、熔断器探测）：
-
必须写明
use epoll;：避免 Nginx 在运行时自动降级为较慢的select或poll -
开启
multi_accept on;：让单次事件就绪后尽可能多地 accept 新连接，降低小报文场景下“一次只收一个连接”的调度抖动 - 不建议混用
accept_mutex（默认 on）：微服务网关常为单 worker 多核绑定或容器化部署，mutex 会人为串行化 accept，反而增加首包延迟
worker_connections 要匹配 ulimit 和 net.core.somaxconn
设为 65536 不代表真能撑住 6.5 万并发连接——它受限于系统层两个硬指标：
-
ulimit -n必须 ≥worker_processes × worker_connections：否则 Nginx 启动报错或静默降级 -
net.core.somaxconn（内核全连接队列长度）应 ≥worker_connections：尤其在秒级高频健康检查（如 /actuator/health）下，避免连接被内核丢弃 - 容器环境注意：Docker/K8s 默认限制
ulimit，需在securityContext或docker run --ulimit中显式提升
keepalive_timeout 和 keepalive_requests 针对短会话调优
微服务间 HTTP/1.1 调用多为“一请求一响应”，长连接价值有限，但盲目关闭又增 TLS 握手开销。折中策略是：
-
keepalive_timeout 15s;：比默认 75s 更激进，快速回收空闲连接，释放 fd 给新请求 -
keepalive_requests 100;：限制单连接最大请求数，防个别客户端长期霸占连接（如 misconfigured sidecar） - 若用 HTTP/2 或 gRPC over TLS，可适当延长
keepalive_timeout至 30–60s，因复用更充分
worker_cpu_affinity 自动绑定提升缓存局部性
在多核宿主机或 K8s 节点上，让每个 worker 固定绑定 CPU 核心，减少上下文切换和 L3 缓存失效：
-
推荐写法：
worker_cpu_affinity auto;（Nginx 1.9.10+）：自动按核心数分配，比手动写0001 0010更健壮 - 配合
worker_processes auto;：确保 worker 数 ≤ CPU 核心数，避免争抢 - K8s 中若设置
resources.limits.cpu: "2"，则worker_processes 2;+worker_cpu_affinity auto;是安全组合
